Architecture Overview¶

This section provides the documented architecture overview for AirsSys OSL based on the established memory bank documentation and architectural decisions.

Layered Architecture¶

AirsSys OSL follows a layered architecture pattern with clear separation of concerns:

┌─────────────────────────────────────────┐
│           Application Layer             │ ← Client Applications
├─────────────────────────────────────────┤
│           API Abstraction Layer         │ ← High-level APIs
├─────────────────────────────────────────┤
│         Security & Policy Layer         │ ← Security enforcement
├─────────────────────────────────────────┤
│         Activity Logging Layer          │ ← Comprehensive logging
├─────────────────────────────────────────┤
│          Platform Abstraction           │ ← OS-specific implementations
├─────────────────────────────────────────┤
│          Operating System               │ ← Linux, macOS, Windows
└─────────────────────────────────────────┘

Core Module Structure¶

Based on the documented architecture, the system is organized in priority-based modules:

src/
├── core/           # PRIORITY 1: Essential trait abstractions only
│   ├── operation.rs    # Core Operation trait and basic types
│   ├── executor.rs     # Core OSExecutor trait (simplified)
│   ├── middleware.rs   # Core Middleware trait
│   ├── context.rs      # Execution contexts
│   └── result.rs       # Core result and error types
├── middleware/     # PRIORITY 2: Standalone middleware modules
│   ├── logger/         # Activity logging subsystem
│   └── security/       # Security validation subsystem (consolidated)
├── api/           # PRIORITY 3: High-level user APIs
├── executor/      # PRIORITY 3: OS-specific implementations
└── config/        # PRIORITY 4: Configuration management

Design Principles¶

Generic-First Design Pattern¶

Following Microsoft Rust Guidelines M-DI-HIERARCHY and workspace standard §6.2:

Hierarchy of Abstraction: 1. Concrete types - Use specific implementations when behavior is fixed 2. Generic constraints - Use impl Trait or <T: Trait> for flexibility 3. dyn traits - Only when generics cause excessive nesting (last resort)

Security-First Approach¶

All system operations are designed with security as the primary concern: - Deny-by-default access control - Comprehensive audit logging integrated into security middleware - Input validation at all boundaries - Consolidated security concerns within middleware/security/

Cross-Platform Consistency¶

Platform abstraction provides unified APIs across: - Linux: Primary platform with full feature support - macOS: Secondary platform with feature parity - Windows: Tertiary platform with core functionality

Performance Targets¶

Based on documented requirements: - File Operations: <1ms latency for basic operations - Process Spawning: <10ms for simple process creation - Memory Usage: Bounded memory growth under load

Architecture Status¶

Current Phase: Foundation Setup and Architecture Design
Implementation Status: Core module foundation (OSL-TASK-001) ready for implementation

The architecture documentation reflects the established memory bank specifications and will be updated as implementation progresses.