IX Sustainment OS is a non-weapon, defense-adjacent sustainment operating system for maintenance, readiness, parts bottlenecks, technical-data access, and auditable AI-assisted decision support.
It is designed to help sustainment organizations answer a simple but high-value question:
What can we fix right now, what is blocked, why is it blocked, and what evidence supports the next action?
Sustainment organizations do not fail only because a part is missing.
They fail because the decision chain is fragmented across:
- maintenance records
- fault history
- technical manuals
- entitlement and data-rights boundaries
- parts availability
- approval chains
- inconsistent local workflows
- poor auditability of recommendations and overrides
IX Sustainment OS is intended to unify those fragments into one operational layer.
This repo is being built as a serious product concept for:
- depot maintenance environments
- field sustainment support workflows
- readiness and fleet-health teams
- program offices
- prime contractor sustainment teams
- controlled government or government-adjacent environments
IX Sustainment OS is a CUI-conscious sustainment platform that combines:
- Maintenance triage
- Technical-data and entitlement checks
- Parts and supply bottleneck visibility
- Human-governed AI recommendations
- Tamper-evident operational evidence
The goal is not to replace maintainers, engineers, logisticians, or program staff.
The goal is to give them a shared operating picture with traceable, reviewable, decision-grade evidence.
A maintainer, analyst, or operations lead needs to:
- ingest a fault or discrepancy
- classify severity and mission effect
- see similar prior cases
- determine if action is possible at current echelon
- identify blockers immediately
A user needs to know:
- which technical reference applies
- whether access is permitted
- whether a procedure is current
- whether a requested action crosses a data-rights or approval boundary
A sustainment planner needs to know:
- what parts are constraining readiness
- which shortages affect highest-priority assets
- which work orders are waiting on material, approval, tooling, or data
- where local fixes are being delayed by process, not physics
A user needs machine support for:
- suggested triage paths
- likely fault families
- recommended next-step evidence collection
- probable bottleneck causes
- prioritization support
But every recommendation must remain:
- reviewable
- attributable
- overrideable
- auditable
Leads and program stakeholders need a record of:
- who saw what
- which data informed a recommendation
- which user approved or rejected it
- what changed
- when it changed
- under which policy boundary it changed
IX Sustainment OS is not:
- a weapon system
- a targeting platform
- a strike-planning tool
- a kill-chain optimization system
- a battlefield fires-control product
- an autonomous engagement system
It is also not intended to make unsupported claims such as:
- automatic authority to operate
- automatic CMMC compliance
- automatic NIST certification
- replacement of official logistics or maintenance systems of record
This project stays on the sustainment, readiness, workflow, auditability, and human-governed decision-support side.
The first credible wedge is:
“A sustainment triage and bottleneck operating layer for maintenance, parts, entitlement, and auditable AI recommendations.”
That means Release 1 focuses on six modules:
Structured fault and discrepancy intake with mission context, asset context, severity, and supporting evidence.
A queue-based operational view for fault families, blockers, aging items, and recommended next actions.
Controlled linking of procedures, references, revisions, access restrictions, and entitlement status.
Visibility into work stoppage causes driven by supply, tooling, approval, or documentation constraints.
AI-assisted recommendations that remain human-reviewed, policy-bounded, and fully logged.
A durable record of actions, approvals, overrides, recommendation provenance, and state transitions.
Needs fast clarity on what to do next and what is blocking execution.
Needs queue visibility, blocker trends, and work prioritization.
Needs shortage impact visibility and readiness consequence mapping.
Needs case history, recurring fault visibility, and procedure/evidence traceability.
Needs readiness picture, delay cause concentration, and accountable decision history.
Needs role boundaries, policy enforcement, evidence trails, and reviewable AI behavior.
Recommendations can assist, but accountable humans approve meaningful actions.
Every important suggestion must trace back to observable inputs, policy context, and user action.
This product must reduce friction in real operational flow, not just look impressive in screenshots.
Data exposure, recommendations, and workflow actions must respect access and policy boundaries.
Every feature should improve one of these:
- maintenance velocity
- blocker identification
- readiness clarity
- evidence quality
- coordination speed
IX Sustainment OS is planned as a modular web platform with policy-bounded services.
Mission-critical operator UI for:
- queue triage
- case review
- approvals
- parts impact views
- evidence inspection
Business logic for:
- case lifecycle
- blocker classification
- workflow transitions
- approvals
- recommendation routing
Controls for:
- role-based access
- entitlement checks
- recommendation gating
- approval requirements
- action logging
Structured objects for:
- assets
- cases
- discrepancies
- procedures
- parts constraints
- approvals
- evidence events
Connectors for:
- maintenance systems
- reference libraries
- supply feeds
- identity providers
- export/report pipelines
The repo will be built around a small, serious domain model.
- Asset
- Case
- FaultEvent
- ProcedureRef
- EntitlementRule
- PartConstraint
- Recommendation
- ApprovalDecision
- EvidenceEvent
- UserRole
- PolicyBundle
A case will generally move through states such as:
newtriageawaiting-dataawaiting-partsawaiting-approvalactionabledeferredresolvedclosed
AI in this platform is assistive, not sovereign.
AI may help with:
- classification support
- similarity matching
- next-step suggestion
- blocker explanation
- prioritization hints
- summarization of case history
AI may not silently:
- execute irreversible actions
- bypass approvals
- bypass access policy
- rewrite audit history
- promote itself to decision authority
The system must preserve:
- recommendation provenance
- confidence or uncertainty markers
- user override capability
- reviewable change history
This project is being shaped for CUI-conscious environments, which means the design intent includes:
- least-privilege access boundaries
- strong auditability
- role-aware data exposure
- secure defaults
- reviewable workflow actions
- deployment patterns compatible with controlled environments
Important: This repo does not claim certification, accreditation, or compliance by declaration alone. Those outcomes depend on deployment, controls, environment, documentation, and assessment.
This repository will be completed in a staged manner across focused commits that establish:
- product scope
- license and commercial posture
- repository structure
- architecture documentation
- operator workflows
- domain schema
- API surface
- policy and audit model
- backend scaffolding
- UI scaffolding
- demo data
- compliance and deployment documentation
IX-Sustainment-OS/
├── README.md
├── LICENSE
├── COMMERCIAL_TERMS.md
├── .gitignore
├── Makefile
├── docs/
│ ├── architecture/
│ ├── product/
│ ├── workflows/
│ ├── security/
│ ├── compliance/
│ └── ux/
├── api/
│ └── openapi.yaml
├── schemas/
│ ├── case.schema.json
│ ├── recommendation.schema.json
│ ├── approval.schema.json
│ └── evidence-event.schema.json
├── cmd/
│ └── ix-sustainment-os/
├── internal/
│ ├── domain/
│ ├── policy/
│ ├── audit/
│ ├── entitlement/
│ ├── recommendation/
│ └── workflow/
├── web/
│ ├── app/
│ └── components/
├── demo/
│ ├── fixtures/
│ └── screenshots/
└── .github/
└── workflows/
The commercial objective is straightforward:
- allow serious evaluation
- protect monetizable production value
- preserve leverage for pilots, support, and enterprise deployment
The planned licensing posture for this repo is:
- Business Source License 1.1 for the public codebase
- separate commercial terms for production, pilot, support, and controlled deployment use
The actual license text and commercial-terms file will be added in follow-on commits.
This repo is successful if a serious buyer can look at it and say:
- this solves a real sustainment workflow problem
- this is disciplined, not vague
- this respects policy and audit boundaries
- this could be piloted without pretending to be a weapon or autonomous command layer
- this has enough architecture, workflow clarity, and product seriousness to justify a conversation
This is the founding commit.
It establishes:
- product identity
- operating boundary
- user problem framing
- first-release wedge
- architecture direction
- commercial posture
- repo shape
All implementation, policy files, schemas, and scaffolding follow from here.