A project isn't a folder.It's a ledger.
Every DjiniousEngineering project is a System Ledger — the digital thread that holds one system's Technical Baseline and Technical Data Package. Not documents in drives, but typed items connected by `produces` edges: eleven ISO/IEC/IEEE 15288 lifecycle stages, each item carrying an artifact type, an evidence class, a revision and a validation state. The agent works it stage by stage and stops at every review gate for a human.
Typed items on a thread, not files in a drive
The ledger is a directed graph. Each item is one output with a declared artifact type — a requirement_set, a trade_study, an architecture, a sizing_model, a bom, a test_result, a technical_data_package — and it is joined to what it came from by a `produces` edge. Follow the edges and you have the whole chain: needs produce requirements, requirements produce components, components produce suppliers, and verification closes the loop. Nothing floats free; every item can name what it was derived from.
- Thirty artifact types, from spec_brief through the final technical_data_package, one type per item
- `produces` edges are the digital thread — the DAG that ties every output back to the need it serves
- Traceability is explicit: derives_from, allocated_to / satisfies, verifies, interfaces_with, supplied_by
- Every item carries a revision and a validation state, so the thread records not just what exists but how sure we are
Weak evidence cannot close a requirement
A claim is only as strong as what backs it. Every value on the ledger carries an evidence class on an ordered ladder — MEASURED, TEST_DATABASE, SUPPLIER, ANALYTICAL, NUMERICAL, ANALOG, JUDGMENT, UNKNOWN — strongest to weakest. A requirement declares the verification method it demands, and the ledger refuses to close it on evidence weaker than that method allows. You cannot retire a MEASURED requirement on JUDGMENT, and a value still marked UNKNOWN blocks anything that depends on it.
- Eight evidence classes, MEASURED > TEST_DATABASE > SUPPLIER > ANALYTICAL > NUMERICAL > ANALOG > JUDGMENT > UNKNOWN
- A requirement's verification method sets the floor — evidence below it does not count as fulfilment
- UNKNOWN is a hard stop: it blocks closure of every requirement that leans on it
- The class travels with the value, so a number's provenance is on the ledger, not in someone's head
Change one item and everything downstream knows
The thread is live. Revise an item's content and the ledger walks forward along its `produces` edges — a breadth-first sweep over the DAG — and marks every item reachable from it stale. A stale item stops counting as a valid contract fulfilment, so a requirement whose parent changed no longer reads as closed until the work below it is redone. Nothing quietly keeps its green tick because a decision three stages back moved.
- Editing an item's content marks its whole forward reachable set stale, computed by BFS over the produces DAG
- A stale item no longer satisfies the contract it fulfilled — downstream closure is withdrawn, not assumed
- Superseding an item requires a written reason, recorded against the revision that replaced it
- The blast radius is visible on the graph, so you see exactly what a change reopened before you commit to it
Three things a document-and-spreadsheet toolchain cannot
Answer 'why does this exist?' for any item
Pick any component and trace it back — the requirement it satisfies, the need that requirement derives from, the verification that closes it, the supplier it is sourced from. The chain is a query over the edges, not an afternoon spent reconciling a requirements spreadsheet against a separate BOM.
Refuse a claim that isn't earned
A requirement in a spreadsheet is closed when someone types 'closed'. A ledger requirement closes only when an item of the right artifact type, at or above the evidence class its verification method demands, produces the result — and never while any input is still UNKNOWN.
Keep the baseline honest under change
Move a decision and the toolchain leaves stale copies scattered across documents. The ledger propagates the change: everything downstream goes stale, the affected gates reopen, and the Technical Baseline stops claiming to be something it no longer is.
Five gates the agent cannot pass on its own
The agent proposes items stage by stage and then stops. At each of five ISO 15288 review gates it can only present the upstream work; a human validates the evidence and lets it through. These are the real acceptance criteria the ledger checks before a gate is even offered for validation.
| Gate | Review | Stage it follows | What a human must validate |
|---|---|---|---|
| SRR | System Requirements Review | after Requirements | Every requirement is singular and verifiable, a verification method is assigned to each, and the initial hazard list exists. |
| PDR | Preliminary Design Review | after Engineering Models | The sizing loop has converged and margins against every hard constraint are positive. |
| CDR | Critical Design Review | after Supply Chain | Geometry, BOM and software baseline are released, and every part has a qualified source and a lead time. |
| TRR | Test Readiness Review | after Verification & Validation | The digital replica correlates with the analytical models, and abort criteria and safety cases are agreed. |
| PRR | Production Readiness Review | after Baseline Release | The Technical Data Package is complete and internally consistent. |
One machine-checkable model over the whole thing
Four pillars, twenty-seven kinds
ELANG — the Engineering Language for Artifacts, Processes, and Governance — is one declarative model of the system. Its 27 entity kinds fall into four pillars: WHAT is built, WHY it must hold, HOW it is done, and WHO does it and WHEN.
Twenty-six well-formedness rules
The model is checked against 26 WFRs. The core one, WFR-9, is uncompromising: every obligation must tie to at least one implementation, one test, one responsible actor and one lifecycle gate. An obligation with nothing implementing it is a gap the model shows you.
Conformance L0 to L3
The model reports its own level: L0 lexes and parses, L1 is well-formed, L2 closes all four pillars with a verification matrix, L3 adds lifecycle, risk and change to reach production-ready. It ships with its gap list, so the distance to the next level is named, not guessed.
Authored and graphed in-app
The model lives as its own system_model item, written in a CodeMirror editor, shown with its conformance level and gaps, and rendered as a navigable graph so the four pillars can be read as a picture, not only as source.
Three limits worth stating plainly
This is an engineering system of record, so the page ends with the limits rather than hiding them. If one of these is what you were hoping for, say so on a call and we will tell you plainly where we stand.
It does not predict or forecast
There is no forecasting, no trend extrapolation and no predictive model in the product. The ledger records what has been established and how strongly; it does not tell you unprompted what a result will turn out to be.
The agent never passes a gate itself
The agent proposes items and presents the upstream evidence, but it does not validate its own work through a review gate. Every SRR, PDR, CDR, TRR and PRR is passed by a human validating the ledger, or it is not passed at all.
UNKNOWN evidence blocks closure
A requirement whose backing is still UNKNOWN cannot be closed, and the agent will not paper over it. Weak evidence is left visible as weak evidence rather than promoted to make a gate look ready.
Bring a system you need to carry to a data package.
One mission need and its top-level constraints. We will open a ledger, let the agent frame the requirements and propose the thread, and stop it at the first gate in front of you — so you see the evidence classes and the gaps before anything is called closed.