Architecture
A three-layer deterministic stack — from native runtime to healing engine to platform tooling. Each layer has a clear responsibility and a defined contract boundary.
Three-Layer Stack
Aeostara is built on three distinct layers, each with clear ownership.
Aeostara Platform
The user-facing layer. CLI tools, file I/O adapters, backup management, audit logging, and configuration management interface. Aeostara translates real-world files into structured inputs for the healing engine and executes the resulting repair plans with full safety guarantees.
ASH Pattern System
The computational layer. Deterministic healing engine with pattern matching and policy evaluation. ASH takes structured configuration state, matches drift against known patterns, evaluates policy constraints, and produces repair plans. No I/O, no side effects — pure computation.
Forsetti Framework
The foundation layer. Native modular runtime with contract enforcement and lifecycle management. Forsetti provides structural guarantees — module boundaries, initialization contracts, and dependency resolution — that ASH and Aeostara inherit as Forsetti-compliant modules.
Deterministic Flow
Every healing operation follows the same six-stage pipeline. No exceptions, no shortcuts.
Load
Read the configuration file from disk, parse the JSON structure, and validate it against expected schema. Malformed or unparseable input is rejected before any downstream processing begins.
Compare
Diff the actual configuration state against the declared desired state. Identify every addition, removal, and value change. Report deviations with precise key-path locations for unambiguous drift identification.
Evaluate
Apply policy invariants to the detected drift. Determine whether repair is permitted, required, or prohibited. Policy evaluation gates all downstream action — no mutation proceeds without policy approval.
Repair
Execute the deterministic correction. Back up the current file with a timestamp, apply the computed repair plan to the configuration, and write the corrected state to disk. Every mutation is preceded by a backup.
Verify
Validate the repair outcome against acceptance criteria. Re-read the modified file, compare it to the desired state, and confirm that all deviations have been resolved. Failed verification triggers automatic rollback.
Log
Append the complete operation record to the audit trail. Every stage — detection, evaluation, repair, verification, and any rollback — is logged with timestamps, inputs, outputs, and outcomes in structured JSON Lines format.
Safety Model
Three guarantees that protect every configuration mutation.
Pre-Mutation Backup
Every configuration file is copied to a timestamped backup before any modification is applied. The backup is written and verified before the repair proceeds. If the backup fails, the repair is aborted. Recovery from any repair is always one step away.
Post-Mutation Verification
After every repair, the modified configuration is re-read from disk and validated against the desired state and acceptance criteria. Verification confirms that the repair achieved its intended outcome. No repair is considered complete until verification passes.
Automatic Rollback on Failure
If post-mutation verification fails, the system automatically restores the configuration from the timestamped backup. No manual intervention is required. The rollback itself is logged to the audit trail, providing a complete record of the failed repair and recovery.
See where we are headed.
The architecture is the foundation. The roadmap shows what comes next — from ASH kernel isolation to multi-format support and continuous monitoring.