Djinious
System Ledger canvas
The digital thread as eleven stage columns. Every item carries an artifact type, an evidence class, a revision and a validation state; revising one marks everything downstream stale.
ISO/IEC/IEEE 15288
DjiniousEngineeringOrchestrationNothing is releaseduntil it is traced.
AI systems engineer · System Ledger · ISO/IEC/IEEE 15288Every stage
DjiniousEngineering is an AI systems engineer. Hand it a handful of specifications and it carries the system to a manufacturing or deployment data package — deriving requirements, trading architectures, sizing the design and closing verification. Each project is a System Ledger: the digital thread, worked stage by stage, and stopped at every review gate for a human.
DjiniousEngineering
- lifecycle stages
- 11lifecycle stagesISO/IEC/IEEE 15288
- review gates
- 5review gatesSRR · PDR · CDR · TRR · PRR
- evidence classes
- 8evidence classesMEASURED → UNKNOWN
- ELANG conformance
- L0–L3ELANG conformance26 well-formedness rules
What it is
A systems-engineering platform, not a document template
Everything the lifecycle needs, in one product with one data model — so there is no seam between the requirement you derive, the component it is allocated to, and the verification that closes it.
Requirements & traceability
Requirements derived from needs, allocated onto components, sourced from suppliers, and closed by verification — all as graph edges you can walk, not links kept by hand.
ISO/IEC/IEEE 29148The ELANG model
One machine-checkable model of the whole system across four pillars and twenty-seven entity kinds, checked against twenty-six well-formedness rules, with its gaps listed.
Conformance L0–L3Review gates
Five gates the agent evaluates but only a person passes. Each blocks the run until the items upstream are user-validated and the criteria are met.
SRR · PDR · CDR · TRR · PRRSupply chain & BOM
A bill of materials with make-or-buy, lead times, second sources and risk, reaching the shared component library — because CDR will not pass without a qualified source on every part.
Make-or-buyTechnical Data Package
The release artifact — baseline, procedures and evidence — generated from the validated ledger and exported as a document bundle, not written up alongside it.
Generated from the threadInside the product
See it working.
Every capture below is the running product.
01 · System Ledger
A project isn’t a folder. It’s a ledger.
Every 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. Follow the edges and you have the whole chain: needs produce requirements, requirements produce components, components produce suppliers, and verification closes the loop.
- Eleven stage columns — Mission & Need, Requirements, Concept & Trades, Architecture, Engineering Models, Digital Replica, Safety & Assurance, Supply Chain, V&V, Baseline Release, Production & Operation
- 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
- Every item carries a revision and a validation state, so the thread records not just what exists but how sure we are
- Revise an item and the ledger walks forward along its produces edges, marking everything reachable from it stale — a stale item stops counting as a valid contract fulfilment
- Superseding an item requires a written reason, recorded against the revision that replaced it
DjiniousEngineering
02 · Evidence classes
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, 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
- Trace edges — derives_from, allocated_to, satisfies, verifies and supplied_by — walked in both directions
- 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
DjiniousEngineering
03 · The ELANG model
One machine-checkable model over the whole thing
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 is built, WHY it must hold, HOW it is done, and WHO does it and WHEN
- Twenty-six well-formedness rules; the core one, WFR-9, 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
- Rendered as a navigable graph from the same source the conformance checker reads; there is no second diagram to maintain
DjiniousEngineering
04 · The review gates
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 — which is what stops an autonomous run from designing on top of an unreviewed baseline.
- SRR, after Requirements — every requirement is singular and verifiable, a verification method is assigned to each, and the initial hazard list exists
- PDR, after Engineering Models — the sizing loop has converged and margins against every hard constraint are positive
- CDR, after Supply Chain — geometry, BOM and software baseline are released, and every part has a qualified source and a lead time
- TRR, after Verification & Validation — the digital replica correlates with the analytical models, and abort criteria and safety cases are agreed
- PRR, after Baseline Release — the Technical Data Package is complete and internally consistent
05 · Supply chain
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 DjiniousWorkshop 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
DjiniousEngineering
06 · Deliverables
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 whole ledger, or one stage, exported as a document bundle
- 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
DjiniousEngineering
AI & agents
An agent that works the thread — and stops at the gate
The agent reads the ledger, works one stage at a time against a recipe and emits a single typed item per step. What it cannot do is push past a review gate on its own — it stops at every gate until a human has validated the evidence upstream, enforced server-side on every step. AI is an accelerant, never a dependency: turn every tool class to deny and the same human review still closes the same gates.
Frame
The mission need is grounded first: what the system must do and the conditions it must do it in. From it the agent derives singular, verifiable requirements and assigns a verification method to each — nothing enters the thread that cannot later be closed against evidence.
Model
Candidate concepts are traded, an architecture is chosen, and the sizing loop runs until it converges with positive margin against every hard constraint. The result is captured as one machine-checkable ELANG model, checked against its well-formedness rules.
Prove
Requirements are closed against evidence, never assertion. Nothing closes a requirement on JUDGMENT when its verification method demands MEASURED, and an UNKNOWN class blocks closure outright. The digital replica is correlated against the models it claims to represent.
Gate
A human reviews the proposal and the evidence behind it, then validates or rejects. Only user_validated items count as fulfilled contracts — the agent cannot carry an unreviewed baseline past a gate.
Autonomy policy
Autonomy is a policy over tool classes: read, write and browser, each set independently to ask, allow or deny. The default is ask — a call that needs approval routes to a human queue.
The approval queue
Any tool call the policy sends to ask routes to a human approval queue before it runs. Nothing waits forever: a call left unapproved auto-rejects after five minutes.
Ledger tools
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 — with the reasoning and tool calls streamed live.
DjiniousEngineering
Capabilities
The platform at a glance
Requirements, trades, architecture, models, safety, supply chain and verification are not seven documents here — they are one traced thread with one data model.
Lifecycle & gates5 capabilities
Lifecycle
Eleven stages named after ISO/IEC/IEEE 15288 processes, from Mission & Need to Production & Operation.
Review gates
Five human-validated gates, after Requirements, Engineering Models, Supply Chain, Verification & Validation and Baseline Release.
Artifact types
Thirty typed item outputs, spec_brief through technical_data_package.
Evidence classes
Eight ranked — MEASURED → … → JUDGMENT → UNKNOWN; UNKNOWN blocks closure.
Recipes
Per-system-class instruction sets the agents execute, extending the generic ISO 15288 baseline with explicit inputs, outputs, evidence rules and automated assertions.
Model & traceability5 capabilities
ELANG model
Four pillars, twenty-seven entity kinds, one machine-checkable source.
Well-formedness
Twenty-six 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.
Architecture
Candidate architectures traded on explicit, weighted criteria, with a recorded decision and requirements allocated onto the components that implement them.
Automation & governance4 capabilities
Agent runtime
Recipe-driven on pi-agent-core, one item per step, stops at every gate.
Autonomy policy
Per tool class — read, write, browser — each set to ask, allow or deny.
Approval
A human approval queue for gated calls; a human validates every gate.
Agent access
An MCP endpoint of about thirty tools plus REST, behind scoped API keys.
Platform5 capabilities
Runtime
Bun · React 19 · TypeScript.
Data
SurrealDB — graph, vectors and full-text in one store.
Auth
JWT (OIDC) plus scoped long-lived API tokens.
Roles
admin · user · viewer.
Connectors
One authenticated place to reach DjiniousLab, Workshop, Safe, World, Map and CC.
Trust
Built to be handed to an auditor
DjiniousEngineering is API-first and self-hostable. Every capability is a REST endpoint, the whole System Ledger is exposed over one MCP endpoint, and every item on the digital thread carries a revision, a validation state and the evidence it was closed against.
A human clears every gate
The agent works the ledger stage by stage and stops at each review gate until the upstream items are user-validated against explicit criteria. It proposes; a person validates. No gate passes itself.
SRR · PDR · CDR · TRR · PRRState and revision on every item
Each item moves draft → proposed → agent_validated → user_validated, carries a revision, and names its artifact type. agent_validated means awaiting a human; user_validated is the human’s signature on the record.
Supersede with a reason, staleness follows
Replacing an item requires a written reason, and changing its content marks everything reachable forward along the produces edges stale — so nothing silently rests on a moved foundation.
Evidence you can defend
A requirement cannot close on evidence weaker than its verification method demands — UNKNOWN blocks closure outright. Roles are admin, user and viewer, with a per-user autonomy policy over what the agent may do unattended.
The lifecycle is the standard
The eleven stages are named after ISO/IEC/IEEE 15288 processes, requirements follow ISO/IEC/IEEE 29148 and architecture follows ISO/IEC/IEEE 42010. The Technical Data Package is the release artifact, not an afterthought bolted on at the end.
ISO/IEC/IEEE 15288 · 29148 · 42010Every capability is an endpoint
The same REST API the product’s own front end uses is the one you build against. The ledger is exposed over a single MCP endpoint of about thirty tools, and the dje CLI drives the agent straight from a terminal, so a run belongs in a pipeline as easily as in the browser.
REST · MCP · CLISelf-hosted by default
A Docker Swarm stack — the Bun application on React 19, backed by SurrealDB for graph, vectors and full-text in one store — behind your reverse proxy. Your data and your thread stay on your infrastructure.
Docker SwarmSecrets sealed, auth explicit
Authentication is JWT over OIDC; scoped, long-lived API tokens secure automation. Connector credentials and other secrets are sealed at rest with AES-256-GCM and never returned to the browser — nothing shares a blanket key.
AES-256-GCMWhat it does not do
It does not predict or forecast: the ledger records what has been established and how strongly. The agent never passes a gate itself. And a requirement whose backing is still UNKNOWN cannot be closed — weak evidence is left visible as weak evidence rather than promoted to make a gate look ready.
In the digital thread
What it takes in. What it hands on.
DjiniousEngineering does its part of the engineering loop and passes its evidence along — and it works just as well on its own.
Receives
DjiniousDataThe specifications, standards and source documents the mission need is grounded in, as governed, searchable knowledge.
DjiniousLabNumerical models, solver runs and generated code, arriving on the ledger as evidence with their provenance intact.
DjiniousWorkshopComponents from the shared component library, system integration and Isaac Sim simulation results.
DjiniousSafeFormally verified safety-critical code for the items that must be proven, not merely tested.
DjiniousWorld3D models, mock-ups and digital replicas of the system and its surroundings.
DjiniousMapGeographic data for the operating environment.
DjiniousCCSCADA supervision and the operation of the digital replica once the system runs.DjiniousEngineeringOrchestrationDelivers
DjiniousLabThe modelling work of each stage: the system to capture, with the requirements and parameters it must be tested against.DjiniousWorkshopThe architecture and bill of materials to integrate into a complete system and close in simulation.DjiniousSafeThe safety-critical functions and the requirements their verified code must satisfy.DjiniousWorldThe replica and mock-up requests the Digital Replica stage depends on.DjiniousMapThe operating environment each project needs described.DjiniousCCThe released baseline and Technical Data Package the deployed system is operated against.On its own
On its own, DjiniousEngineering is a complete systems-engineering platform: the System Ledger, requirements and traceability, the ELANG model, review gates, supply chain and the Technical Data Package in one product with one data model. The connectors are optional; the ledger and its gates work without them.
Commercial model
One licence. Your whole program. Unlimited.
DjiniousEngineering is licensed per program — one organization, one engineering practice — with nothing inside it metered. No per-requirement charge, no per-project fee, no seat count, no cap on agent runs or connected apps. Nobody should ration requirements or spin down a project because of a licence.
Program licence
One licence covers your organization’s engineering practice, not a single project. Every System Ledger you open, every ledger item your agents author, every ELANG model you check and every gate a human validates is inside it.
- Unlimited projects (System Ledgers), ledger items and ELANG models
- Unlimited agent runs, connectors and API tokens, and seats
- The whole lifecycle: all 8 recipes across the system classes, all 11 ISO/IEC/IEEE 15288 stages and the 5 review gates
- ELANG and its checker — the four pillars, the well-formedness rules and conformance checking to L0–L3, with gap list and graph
- The complete REST + MCP API and the dje CLI, plus the six sibling-app connectors — Lab, Workshop, Safe, World, Map and CC — where you bring your own accounts
- Self-hosted on Docker Swarm or managed by us — the licence is the same either way
There is no price list, because the number depends on your program. Pricing is worked out on the call — bring the kind of systems you engineer, a sense of how many projects and engineers, and whether you want it self-hosted or managed.
Use cases
DjiniousEngineering in use.
5 worked cases.
Subsea autonomyMarlin-XR Seabed Survey AUVAn autonomous underwater vehicle surveying the export-cable corridor of the Dogger Bank offshore wind farm. The bundled demo ledger: forty items seeded across all eleven lifecycle stages, from the mission brief to the deployment procedure.DjiniousEngineeringUncrewed aircraftKestrel-1 Survey UAVA fixed-wing survey UAV, seeded as a worked example: eight requirements, six components, four suppliers and four verifications, wired into a traceability graph, with a real ELANG system_model and an inline Technical Data Package.DjiniousEngineering
Industrial roboticsKronos Robotic Work CellA six-axis robotic work cell modelled end to end in ELANG as an audited reference — roughly a thousand lines carrying a functional-safety design to ISO 13849-1 Performance Level d, with every safeguard traced to the hazard it mitigates.DjiniousEngineeringGrid-scale energySunnyGrid80 Solar-Storage PlantAn 80 MW photovoltaic plant with a 40 MW / 80 MWh battery energy-storage system and its grid substation, modelled in ELANG as an audited reference to UL 9540A and IEC 62443 — a system-of-systems where the interfaces carry as much of the design as the boxes.DjiniousEngineeringRF & radar sensingEmbedded Radar Sensing ModuleAn embedded radar sensing module — the system class the RF/radar recipe covers: a mixed-signal board where spectrum, EMC, environmental and fabrication standards constrain the design as hard as the sensing requirement does.DjiniousEngineeringBook a demo
See it on your problem.
A working session, not a slide deck. Bring us a system — a handful of specs and one requirement you actually care about — and we take it through the ledger: frame the need, derive verifiable requirements, stand up the ELANG model and walk a review gate, live. Or we tell you plainly which part DjiniousEngineering does not do yet.
- Open your system as a System Ledger — the 11 ISO 15288 stages laid out as one traced thread
- Frame the need, derive verifiable requirements, and stand up the ELANG model with its conformance level and gap list
- Watch the AI agent work a recipe step by step, emit typed items with evidence classes, and stop at a review gate for you
- Walk traceability and evidence — derives_from, allocated_to, verifies — and see UNKNOWN evidence block a requirement it cannot close
- Reach the connected apps and the REST/MCP API live, so external agents can navigate the same ledger
Along the thread
Works well with
DjiniousLabModelling & simulationMulti-domain system models, digital replicas and a mathematical toolbox, driven by AI.
DjiniousWorkshopSystem integrationComponents wired into a complete system and closed through GPU physics in NVIDIA Isaac Sim.
DjiniousSafeCertifiable codeLean 4 specifications and kernel-checked proofs turned into panic-free embedded Rust, up to SIL 4.
DjiniousWorld3D replicasReal environments reconstructed from LiDAR, photographs and video — the physical surroundings of the twin.