One backend holds the truth. Every workbench, AI component, and integration is a thin client over the same governed model — never a second copy of it.
The backend owns the model — the NFSI requirements, the four relationships, the library and its governance rules. Nothing else stores a rival copy. The workbench renders it, the AI proposes against it, and your existing tools read and write it through a single interface. Change it once, and everyone sees the same change.
Clients on top. One authoritative engine in the middle. The library beneath. Knowledge and AI feed in from the side — each part replaceable without touching the model.
Because the governed model is exposed as a REST API and a Model Context Protocol server, three very different clients meet on the same ground:
Engineers author requirements, trace links, and run reviews in a web app that is only ever a view of the backend.
Norn and your own agents reason over the methodology in its own terms — proposing against the live model, never a stale export.
DOORS or Jama read and write the same requirements. Integrate the engine behind the stack you already run.
The model does not only store requirements — it tells you when they have gone stale, freezes them when a milestone demands it, shows every engineer what is waiting on them, and hands a subcontractor exactly their scope. All of it inside the instance; nothing depends on mail or a service outside your network.
When an input a link's derivation consumed changes after the link was last confirmed, the link is suspect — computed from the record, not set by hand. Review the set grouped by cause, confirm what still holds, and the confirmation is recorded. Baseline capture warns over unreviewed edges; the release gate reports them.
Capture the requirement set at a moment that matters — a review, a contract milestone — and it is frozen. Compare any baseline against the live set or another baseline and download the change report: what was added, what changed, what went away.
A self-contained HTML report across the whole portfolio, built from the same rows the portfolio screen shows — status, coverage, and who is waiting on whom. The thing you send to the people who were not in the room.
Each engineer sees what was returned to them, their drafts, what awaits their review, and the suspect links in requirements they own. Decisions and comments on your requirements arrive in an in-app inbox derived from the record itself — no mail server, nothing leaving the instance.
Hand a subcontractor exactly their scope: an architecture subtree with its Solution and Implementation requirements, links, attachments and upstream provenance, pinned to a baseline. Every package is signed; once the partner's key is registered it is encrypted end to end — no certificate authority, works air-gapped. The supplier receives it, builds under it, and returns their requirements with verification evidence and change requests; the prime accepts evidence and dispositions requests in the tool, and every step is a signed, baseline-pinned package in the ledger. A small team on either side of that contract can run the Lite edition — the same instance with the upper layers set aside — and it works just as well with a prime who sends a spreadsheet.
The methodology text ships inside the backend, versioned, and is served to humans and agents alike — one method per instance. The client contract — enums, roles, the capability matrix — is generated from the backend, so the workbench cannot drift from the server it renders; any drift shows on the admin page.
The AI is a tier, not a dependency. Remove it and the methodology still stands — the model, the governance, and the workbench all keep working.
Proposes the structured requirement set from stakeholder needs, layer by layer. Every proposal passes a human review gate.
Retrieval grounded in your library. Answers are drawn from the stored model, and every claim traces back to a requirement you can open.
The generative half — drafts what the library is missing, always for a human to decide. Kept inside the airgap.
The same stack runs in three postures. You choose by data-sovereignty and risk — the methodology does not change between them.
We run and operate the stack in the cloud for you. Nothing to provision, nothing to maintain.
The whole stack as Docker containers on infrastructure you control — inside your own network and policies.
A self-contained box — database, retrieval, and UI — running disconnected. Nothing phones home.
Two views of the same backend. We walk you through both against a live model — ask for a session and we will show you the whole path.
Requirements, traceability, architecture, design decisions, and the Norn derivation engine — the full engineering environment. Work it one node at a time: the Board lays a node's Needs, Functions, Solutions and Implementations out as columns, with the gaps stated where the fix happens; a command palette, saved views and keyboard reach every verb from anywhere. The Workbench screen pins one requirement and writes its children across and down, with the library, existing items and Norn beside it; Model View and a Function-level DSM help decide how a node splits; a delivery project answers its customer from one compliance table.
Request a walkthrough → ᚠThe failure-propagation canvas over the same requirement set, scoped per solution node, with mitigation writeback, ratings anchored to controls, and a presenter seat for running the analysis live in a workshop.
Request a walkthrough →