Deep Dives
This section is for readers who want to understand why TramAI is structured the way it is. These guides go beyond usage and explain module boundaries, orchestration concepts, design constraints, and the direction of the system.
In This Section
| Guide | Focus |
|---|---|
| Architecture Overview | System shape, the runtime execution flow, and the architectural priorities |
| Module Architecture | The 0.6.0 ten-layer model, the machine-readable catalog and boundary rules, and how the architecture gate enforces them |
| Module Design | Which modules to use, how responsibilities are split, and what each layer is for |
| Design Deep Dive | Core design choices and the reasoning behind them |
| API and Binary Compatibility | What the stable freeze covers, what is preview, and how consumer compatibility is proven |
| Quality Gates | The 0.6.0 gate system — formatting, analysis, safety guards, coverage and mutation ratchets |
| Orchestration | Workflow orchestration concepts, step shapes, and execution flow |
| Orchestration Persistence | Checkpoint, resume, leases, and persistence-related architecture |
| Orchestrator Vision | Forward-looking direction for the orchestration model |
When To Start Here
Start here when you are contributing to the project, evaluating architecture tradeoffs, or trying to understand how the internals fit together.
If you are evaluating TramAI for an application rather than contributing to it, start with Why TramAI? and Modules Catalog instead.