Every stage,on one thread.
Requirements, trades, architecture, models, safety, supply chain and verification are not seven documents here — they are one traced thread with one data model. Which is why a requirement can be derived on the canvas, allocated to a component, and closed by evidence of a class the method actually demands.
A ledger the whole system is built on, not a folder of documents
Each project is a System Ledger: eleven lifecycle-stage columns named after ISO/IEC/IEEE 15288 processes, from Mission & Need to Production & Operation. Every item carries an artifact type, an evidence class, a revision and a validation state, and every item names the items it was produced from — so the thread is a graph, not a pile.
- Eleven stage columns — Mission & Need, Requirements, Concept & Trades, Architecture, Engineering Models, Digital Replica, Safety & Assurance, Supply Chain, V&V, Baseline Release, Production & Operation
- Typed items: an artifact type from thirty kinds, one of eight evidence classes, a revision and a validation state on every card
- Produces-edges make the digital thread explicit; changing an item marks everything reachable forward along those edges stale
- Five review gates sit between the stages, and the agent stops at each one until a human validates the upstream evidence
One machine-checkable model, not a diagram nobody runs
ELANG — the Engineering Language for Artifacts, Processes, and Governance — is one declarative model of the whole system, authored in-app in a CodeMirror editor as the system_model item. It is checked against well-formedness rules and reported at a conformance level with the exact gaps that hold it back, not a green tick.
- Four pillars, twenty-seven entity kinds — WHAT, WHY, HOW and WHO/WHEN — over one namespace
- Twenty-six well-formedness rules; the core rule ties every obligation to an implementation, a test, a responsible actor and a lifecycle gate
- Conformance L0 to L3: lexed and parsed, well-formed, four-pillar closure with a verification matrix, then lifecycle, risk and change coverage
- The editor shows the current level and the gap list, so an incomplete model reads as an honest list of what is missing
The model as a graph you can walk
The same ELANG model lays out as a graph of entities and the traceability edges between them. Select a node to read its details, open the gaps panel to see which obligations are still unmet — the model and the picture are the same object, so the picture cannot drift from what is checked.
- Entities and traceability edges laid out with an interactive graph engine
- A node-details panel for any entity, and a gaps panel listing the unmet obligations
- The chain reads end to end — needs to requirements to components to suppliers, closed by verification
- Rendered from the same source the conformance checker reads; there is no second diagram to maintain
A requirement is closed by evidence, or it is not closed
Traceability is edges, not a spreadsheet column. A requirement derives from its parent, is allocated to and satisfied by a component, and is verified by a verification item — and it can only be closed by evidence of a class its verification method allows. Evidence class UNKNOWN blocks closure outright.
- Trace edges: derives_from, allocated_to, satisfies, verifies and supplied_by, walked in both directions
- Eight evidence classes, strongest to weakest — MEASURED, TEST_DATABASE, SUPPLIER, ANALYTICAL, NUMERICAL, ANALOG, JUDGMENT, UNKNOWN
- Nothing closes a requirement on JUDGMENT when its method demands MEASURED; UNKNOWN blocks any requirement that depends on it
- The chain is auditable end to end — needs to requirements to components to suppliers, closed by verification
Requirements reach all the way to a source and a lead time
The supply-chain stage turns an architecture into a bill of materials with make-or-buy on every line. Components are drawn from the component library reached over the Workshop connector, each carrying a qualified source, a second source and a lead time — which is exactly what the Critical Design Review gate checks for.
- A BOM with make-or-buy, lead time and a second source on every part
- Components pulled from the component library over the DjiniousWorkshop connector, with provenance recorded on the item
- supplied_by edges tie each component back to its source, so a sourcing change is a traced change
- The CDR gate holds until every part has a qualified source and a lead time — sourcing is engineering, not an afterthought
The agent proposes; a human validates every gate
AI agents work the ledger stage by stage from a recipe — a per-system-class instruction set that extends the generic ISO 15288 baseline. The agent emits one ledger item per step, streams its reasoning and tool calls as it goes, and stops dead at every review gate until a human validates the evidence upstream.
- Recipe-driven: one ledger item per produces-edge, with the reasoning and tool calls streamed live
- An autonomy policy per tool class — read, write and browser, each set to ask, allow or deny
- Calls that need approval route to a human approval queue; the human validates every gate regardless of policy
- Tools work the ledger directly — read it, find the next step, check a gate, append an item, supersede one with a written reason, trace a requirement
The Technical Data Package falls out of the thread
Because every item is typed, traced and validated, the deliverables are generated from the ledger rather than written alongside it. At Baseline Release the whole thread compiles into a Technical Data Package — complete and internally consistent, which is precisely what the Production Readiness Review gate requires before it opens.
- Documents generated from the typed, traced items, not maintained as a separate document set
- The Technical Data Package exports the released baseline as one internally consistent package
- Every figure in a deliverable traces back to the item and the evidence class it came from
- The PRR gate holds until the package is complete and internally consistent — the check is on the data, not on a checklist
A project IS a System Ledger
The projects grid is the front door: every project is a System Ledger holding one system's Technical Baseline and Technical Data Package. Open one and it reads as a narrative of the thread — the same items, in the order they were produced, from mission need to the released package.
- Each project is a self-contained ledger with its own recipe, model and gates
- The notebook view reads the thread as a linear narrative, item by item along its produces-edges
- Worked examples ship seeded — a seabed-survey AUV carried across all eleven stages, and a survey-UAV seed with a real ELANG model and an inline Technical Data Package
- Unlimited projects under the program: the licensing model is per program or organization, not per ledger
Every system, one ledger, one grid
A program's worth of systems in one deployment means one projects grid, one model language and one set of gates — not a stack of disconnected tools that happen to share a login.
What it actually is
Lifecycle & gates
- Lifecycle
- 11 stages, ISO/IEC/IEEE 15288 processes
- Review gates
- SRR · PDR · CDR · TRR · PRR, human-validated
- Artifact types
- 30 typed item outputs, spec_brief through technical_data_package
- Evidence classes
- 8 ranked — MEASURED → … → JUDGMENT → UNKNOWN (UNKNOWN blocks closure)
Model & traceability
- ELANG model
- 4 pillars, 27 entity kinds, one machine-checkable source
- Well-formedness
- 26 WFRs, conformance levels L0–L3 with a gap list
- Trace edges
- derives_from · allocated_to · satisfies · verifies · supplied_by
- Thread
- produces-edges over a DAG; forward staleness on any change
Automation & governance
- Agent runtime
- recipe-driven on pi-agent-core, one item per step, stops at every gate
- Autonomy policy
- per tool class read/write/browser — ask · allow · deny
- Approval
- human approval queue for gated calls; a human validates every gate
- Agent access
- MCP endpoint (~30 tools) + REST, scoped API keys
Platform
- Runtime
- Bun · React 19 · TypeScript
- Data
- SurrealDB (graph, vectors, full-text)
- Auth
- JWT (OIDC) + scoped long-lived API tokens
- Roles
- admin · user · viewer
See it against your system.
Bring a mission need and a handful of top-level requirements. We will frame the ledger and walk it to its first gate with you on the call.