IX-Style is an assured-autonomy reference architecture and executable review baseline for this aerospace question:
When trust degrades, faults accumulate, comms weaken, recovery is requested, or a subsystem lies, can the vehicle stay inside a bounded safe envelope and leave a usable evidence trail showing why it acted?
This repository is built to answer that question in a structured, reviewable way.
The current baseline includes:
- command authority evaluation
- runtime-assurance guard logic with explicit named constraints
- trust degradation and bounded trust recovery logic
- FDIR lifecycle handling
- dominant safety-posture allocation
- recovery-gate evaluation before authority restoration
- mission-health snapshot generation
- operator-facing concise safety summaries
- tamper-evident evidence bundles with hash chaining
- review-ready JSON artifact package export
- executable invariant checks over baseline scenarios
At the current baseline, IX-Style is not:
- flight-qualified software
- a real-time embedded deployment
- a complete cFS flight application set
- a certification package
- a hardware-in-the-loop campaign
It is a serious reference implementation and review baseline.
A lot of autonomy work looks fine until one of these happens:
- navigation trust collapses
- sensor confidence degrades
- actuation confidence weakens
- power margin drops
- comms become intermittent or stale
- recovery is requested too early
- evidence is weak or easy to rewrite
IX-Style is designed around the idea that those are not edge cases.
They are exactly where the architecture has to prove itself.
From the repository root:
python -m pip install --upgrade pip
python -m pip install -e ".[dev]"
python scripts/run_quickstart_flow.py
That quickstart flow runs the repo self-audit, executes the baseline scenarios, checks invariants, and exports review-ready artifact packages.
Recommended first commands
Run these in order if you want to inspect the repo step by step:
python scripts/run_repo_self_audit.py
python scripts/run_sample_scenarios.py
python scripts/run_invariant_checks.py
python scripts/export_sample_review_artifacts.py
python scripts/run_quickstart_flow.py
Current baseline scenarios
IX-Style currently ships three main executable review scenarios:
1. Power fault clamp
Shows that low power/resource posture narrows mission-progress behavior.
2. Navigation spoof transition
Shows that navigation trust collapse drives degraded posture and evidence generation.
3. Recovery deferred over weak comms
Shows that remote recovery-expanding intent is deferred when communications trust is weak.
What gets produced
A successful scenario run can produce:
decision receipt
trust transitions
fault transitions
mode transitions
mission-health snapshot
operator safety summary
tamper-evident evidence bundle
exported review package
Review order
If you open one exported review package, inspect files in this order:
manifest.json
operator_safety_summary.json
mission_health_snapshot.json
decision_receipt.json
evidence_package.json
evidence_bundle.json
verification_result.json
That sequence moves from fast human understanding to detailed machine evidence.
Repository map
Core architecture and execution
src/ix_style/core
src/ix_style/authority
src/ix_style/guard
src/ix_style/trust
src/ix_style/fdir
src/ix_style/modes
src/ix_style/recovery
Evidence, telemetry, and review outputs
src/ix_style/messages
src/ix_style/telemetry
src/ix_style/verification
Docs
docs/architecture
docs/operations
docs/verification
docs/developer
docs/review
Scripts
scripts/run_repo_self_audit.py
scripts/run_sample_scenarios.py
scripts/run_invariant_checks.py
scripts/export_sample_review_artifacts.py
scripts/run_quickstart_flow.py
Recommended reading order
For a serious technical read, go in this order:
docs/PROJECT_CHARTER.md
docs/requirements/IXS-SYS-REQ-BASELINE.md
docs/hazards/IXS-HAZARD-REGISTER.md
docs/architecture/IXS-COMMAND-AUTHORITY-MODEL.md
docs/architecture/IXS-RUNTIME-ASSURANCE-GUARD.md
docs/architecture/IXS-SENSOR-TRUST-AND-ESTIMATION-FRAMEWORK.md
docs/architecture/IXS-FDIR-ARCHITECTURE.md
docs/architecture/IXS-MODE-ALLOCATION-AND-POSTURE-RESOLUTION.md
docs/architecture/IXS-RECOVERY-GATE-AND-AUTHORITY-RESTORATION.md
docs/architecture/IXS-TAMPER-EVIDENT-EVIDENCE-BUNDLES.md
docs/operations/IXS-MISSION-HEALTH-AND-OPERATOR-SUPPORT.md
docs/operations/IXS-OPERATOR-RATIONALE-AND-SUMMARY-LAYER.md
docs/verification/IXS-VERIFICATION-AND-TRACEABILITY-STRATEGY.md
docs/verification/IXS-INVARIANT-CHECKS-AND-PROPERTY-LAYER.md
docs/developer/IXS-DEVELOPER-ONBOARDING-AND-QUICKSTART.md
docs/review/IXS-REVIEW-WALKTHROUGH.md
Current technical posture
IX-Style is strongest today as:
an assured-autonomy architecture repo
a verification-oriented reference implementation
a review artifact generator
a foundation for future platform-specific integration
It is designed to be taken seriously by engineers who care about:
FDIR
runtime assurance
degraded-mode behavior
authority containment
recovery gating
operator decision support
evidence quality
review survivability under scrutiny
CI
The repository includes CI that runs:
unit tests
repository self-audit
sample scenarios
invariant checks
See:
.github/workflows/ci.yml
Exported artifacts
Quickstart and export scripts write review packages under:
artifacts/review_packages
artifacts/quickstart_review_packages
Each package includes the baseline machine and human-facing outputs needed for technical inspection.
Current maturity statement
The repo is now at the point where a reviewer can:
run the baseline flow
inspect scenario outcomes
verify posture and authority behavior
validate evidence bundles
review operator-facing summaries
inspect exported artifact packages without guessing the intended order
That is the current bar IX-Style is aiming to clear.
License
IX-Style is licensed under the Apache License 2.0.
See:
LICENSE
NOTICE
Author: Bryce Lovell