The Weavers of Fate
In systems engineering, the same work must be done at the root of every project. Norn derives the threads of requirements — from Stakeholder Needs to Functions, from Functions to Solution Requirements, and from system-level requirements to subsystem-level requirements through decomposition — layer by layer and level by level, with structure, traceability, and the methodology woven in.
Two Modes, One Pipeline
Norn currently supports four derivation modes across two categories. All use the same pipeline: Norn Lite library pre-derive, fast AI derivation, background quality gate, and mandatory human review before commit.
Need to Function
Derives Function requirements from Stakeholder Needs. Horizontal derivation — crosses the abstraction layer boundary. Library reuse is proposed before the LLM runs (Norn Lite anchor-and-walk); the AI receives Needs, existing project Functions (gap analysis), and domain knowledge — no library items in the prompt.
Function to Solution
Derives Solution Requirements from confirmed Functions. Horizontal derivation — crosses the abstraction layer boundary. Library reuse is proposed before the LLM runs (Norn Lite provenance walk over adopted Functions); the AI receives Functions with their connected Needs (for contractual threshold extraction) and existing project Solutions.
Function Decompose
Vertical decomposition — derives subsystem-level Function requirements from a selected system-level Function. The engineer selects the parent Function; the AI derives child Functions scoped to each subsystem. Design Decisions bound to the parent Function are injected as the decomposition authority — the AI must respect the decision rather than inventing structure.
Solution Decompose
Vertical decomposition — derives subsystem-level Solution Requirements from a selected system-level Solution Requirement. Requires the parent Solution to be allocated to a Solution Architecture node with defined child nodes. Where the parent carries a quantified threshold, this is technical budgeting: the parent value — mass, power, cost, latency, noise — is a budget to distribute, and each child states a concrete per-subsystem share. Design Decisions arrive through two channels: Bind-linked to the parent for overall allocation authority, or attached to an architecture node to govern that node's share. Each proposed child is allocated to a specific architecture node on commit.
How Norn Works
Context Assembly
Norn loads the full project context for the selected derivation mode — input requirements, existing requirements at the target layer, and the domain knowledge document. A selectable item list lets the engineer focus on specific inputs.
Library Pre-Derive
Before any LLM call, Norn Lite checks whether the library already answers part of the session. N→F: each Need is matched to library Needs by vector similarity, and the library Functions fulfilling the matches become pre-validated adoption proposals (anchor-and-walk). F→S: adopted Functions structurally know their library Solutions (provenance walk — no embeddings needed). If anything is proposed, the session opens straight into review; if the library is silent, the full derivation flow proceeds unchanged.
AI Derivation
The selected inputs are handed to Norn's derivation engine — separate N→F, F→S, and decompose lanes that drive the configured language model with structured, schema-constrained prompts encoding the Bifrost NFSI model rules. The model can be a commercial LLM API, or a local model running on your own hardware. A validator stage checks every proposal and issues correction retries; the F→S lane sweeps each parent across constraint dimensions for broad coverage. The engine returns structured data — not free text — with proposed requirements, rationale, confidence, and traceability links. Derivation runs in the background while the engineer works elsewhere, and a failed run can always be retried. For sessions that opened with library adoptions, this derives only the remainder — the inputs not already covered by an adoption.
Quality Gate
Derived proposals are evaluated using layer-specific Bifrost rules. Every proposal then passes a quality gate — deterministic mechanical validator checks plus human review — with per-proposal AI scoring layered on where configured. Library adoption proposals skip the gate — they are pre-validated library items and receive Q:10 automatically. The session opens for review when the gate completes.
Review and Decision
Each proposal requires an explicit decision: accept, edit, or reject. Library adoptions show a gold ᛚ FROM LIBRARY badge. AI-proposed thresholds show a red ⚠ AI PROPOSAL badge. Nothing is written to the project until commit.
Write to Project
Accepted requirements are written as draft project requirements. Fulfils links are created automatically to source requirements. Library adoptions are linked to their library source. The full derivation chain is permanently preserved.
The Library Answers First
Norn is two engines with one governance model, split along a single line: whether a language model is required. Norn Lite answers "has the organisation solved this before?" using retrieval over the requirements library — vector similarity plus graph walks, no LLM, milliseconds, zero tokens. Norn Plus derives what is genuinely new using AI. Retrieval is free, so it runs first and by default; generation is expensive and governed, so it runs on demand — only for what retrieval could not answer.
Reuse Retrieval — LLM-free
Library matching on project Needs, subtree inheritance, pre-derive adoptions in sessions, semantic search. Built on stored semantic vectors and Fulfils/Decompose link walks. Runs everywhere Bifrost runs — including single-box, air-gapped appliance deployments. Degrades gracefully: no embedder means no matches, never an error.
Derivation — LLM
All AI derivation: N→F, F→S, the decompose modes, remainder derivation, the staged merger, and the quality gate. Runs behind a provider abstraction — a commercial LLM API, or a local model running on your own hardware, on-appliance. Configurable and optional: a deployment with no language model at all still has full Norn Lite reuse.
Match Bands — Calibrated, Not Guessed
For a project Need, Norn Lite retrieves the closest library Needs by semantic similarity and classifies each hit: a strong match, a candidate worth reviewing side by side, or silence — nothing returned at all. A margin rule handles ambiguity: a top hit is presented as the match only when it stands clearly apart from the runner-up; otherwise the engineer is shown "one of these". The thresholds are measurements taken from a labelled evaluation harness, not guesses, and they are recalibrated as the library grows.
Subtree Inheritance — Copy-with-Provenance
A matched library Need is rarely valuable alone — its value is the validated chain beneath it. On confirming a match, the engineer sees the full library subtree (Fulfils and Decompose descendants) as a pruning tree, everything selected by default, any branch deselectable — branch consistency enforced server-side. One transaction then binds the project Need to its library source, copies the selected chain into the project as draft requirements each carrying its library provenance, recreates the internal links, and writes an audit record: what matched what, how strongly, who accepted it, and how much was inherited. The project owns its requirements outright — air-gap and per-client isolation require it — while provenance preserves the trace back to the library.
⚠ Never Auto-Commit
No match result is ever committed automatically, however strong it is. This is a deliberate design position: semantic similarity finds requirements that read alike, but it cannot judge whether a value, a direction, or a limit is the right one for this project. A match tells you where to look; only the engineer can confirm the requirement says the right thing. Every inheritance is an explicit request carrying the reviewed selection.
The Embedding Layer
Requirement statements are embedded as semantic vectors by a local embedding model — written in the background as requirements are created, with a catch-up pass for anything missed. Vectors are stored alongside the requirements in the database, one per requirement per model. All similarity queries are scoped — library or single project, never cross-project (organisations reuse requirement text verbatim across product generations). Matching runs directly over the stored vectors, so it keeps working even if the embedder is briefly unavailable. The same layer powers free-text semantic search over project and library requirements.
Standards as a Derivation Input
An ingested standard reaches a project through a chain, never by magic — and only the last step is Norn's. Imposition and adoption are human acts; Norn's role begins once a constraint Function exists with clauses that can govern it.
Where clauses enter
Standards are shown at F→S only. They are excluded from N→F deliberately: standards are full of thresholds, and thresholds are not Function-layer content.
How clauses are chosen
For each parent Function, Norn offers a small set of clauses reached three ways — the clause text resembles the Function; the clause names a system the Function or its architecture node matches; or the clause's whole section topic is the Function's subject.
Product Clauses Only
All three retrieval paths admit product clauses only. A verification clause constrains the test laboratory, not the product, and can never legitimately become a project requirement. Clauses scoped to platform classes the project is not — submarine limits on a ground vehicle — are excluded wherever both sides are known.
A Citation Is Checked, Not Trusted
A Solution Requirement derived from a clause carries a standard threshold source and the clause's exact identifier. That citation is checked against the clauses the call was actually shown: a reference the model was not given is rejected, so a plausible-looking but invented citation cannot survive. Standards therefore extend the threshold hierarchy — a cited clause ranks alongside a contractual Need as a real source, above an AI proposal.
⚠ Coverage Is Reported, Not Assumed
Grounding is silent when it fails: a standard can be imposed, ingested, and still touch nothing while every derivation looks perfectly normal. Norn therefore reports which imposed sections are actually cited by a committed requirement. An uncovered section is a question, not a defect — many sections do not apply to a given platform — but the decision belongs to a human rather than to the silence.
Governance Mechanisms
ᛚ Library Adoptions
When the library already covers a Need or Function, Norn proposes adoption rather than re-derivation — mechanically, via the Norn Lite pre-derive, before any AI call. Adoption proposals appear first in the review list with a gold FROM LIBRARY badge, Q:10 quality score, and the matching evidence in their rationale — which library Need matched, and how closely. On commit, the project requirement is linked to its library source and marked as library-compliant, institutionalising reuse rather than reinvention. After judging the adoptions, the engineer derives the remainder: AI derivation only for what the library did not already cover — and not at all if everything is covered.
ᛚ Project Adoptions
Norn also detects when a requirement already present in the current project covers a newly submitted source item — for example, an existing project Function that already fulfils a freshly added Need. Rather than re-deriving a duplicate, Norn proposes a project adoption: on commit it creates the missing traceability link from the existing requirement to the newly covered source, without creating a new requirement. Like library adoptions, project adoptions skip AI quality evaluation and remain subject to human review — incremental derivation scaling existing project knowledge to new input.
⚠ AI Proposal Threshold Gate
When Norn proposes a Solution Requirement with no contractual or library source for a threshold, it tags the value inline: [AI PROPOSAL: 55–65%]. This tag cannot be removed by the quality gate or the commit process — the engineer must replace it with a validated value. The backend blocks any status change from draft while the tag is present. AI-proposed thresholds are starting points, never verified values.
Budget Allocation Governance
Solution Decompose is governed as an allocation, not a free rewrite. A coverage floor requires every candidate child node to be addressed — either with child requirements or an explicit one-sentence skip reason; silence about a node is treated as an error and corrected. Every child value carries its provenance: sourced from a Need, taken as a share of the parent's own threshold, proposed by the AI and tagged as such, or explicitly not applicable. A deterministic budget-conservation check compares the children's shares against the parent value and surfaces any mismatch for the engineer to judge.
Contractual Need Handling
Needs marked Contractual carry legally binding threshold values. When Norn derives Solution Requirements from a Contractual Need, it extracts the threshold exactly as written and records the contract source in the rationale — "Threshold sourced from contractual Need N-004." The Function layer stays clean: no threshold appears in a Function statement. The contract value is preserved at the correct layer with full traceability.
Staged Merger & Review Queue
Incremental derivation and library reuse both add requirements, so the same capability can end up stated twice in different words. The project-wide staged merger is an on-demand consolidation pass over a single layer's live requirements: exact-text deduplication first, then a similarity shortlist over the stored vectors, then an AI verdict per pair — the same requirement, an adaptation of it, or genuinely distinct. Every merge beyond an exact-text collapse lands in a review queue for a human decision, and a pair carrying conflicting numeric values is never merged automatically. A merge never deletes anything: the superseded requirement is retired with a pointer to its survivor, which absorbs its traceability links.
Role Guard
Access to Norn is enforced by capability, not by hard-coded role names. The system roles are viewer, engineer, architect, and admin, each cumulatively granting the tier below it. Triggering a derivation requires engineer level or above; editing the Domain Knowledge document that steers derivation requires architect level or above. Enforcement sits on every Norn endpoint, so a role change takes effect on the user's next request — no sign-out, no waiting.
What the Engineer Sees
A typical F→S review session for a single Function — three proposal types side by side.
The third proposal cannot progress from draft status until the engineer replaces [AI PROPOSAL: 5–10 minutes] with a validated value from a domain standard, contract, or engineering analysis.
How Norn Was Built
The AI proposes; the engineer decides
Every proposal requires an explicit decision before it enters the project. This is not a limitation — it is the product's fundamental governance model.
Structured output, not text
The AI returns typed JSON — fields, traceability, confidence, threshold sources. The output is data from the moment it is generated.
Quality before the engineer sees it
The quality gate runs before proposals reach the review screen. Engineers review evaluated requirements — not raw AI output.
Nothing enters without a human decision
The commit button is disabled until every proposal has an explicit accept, edit, or reject. No bulk-accept shortcut.
Full provenance, always
Every requirement carries the complete chain: source, AI proposal, quality gate result, engineer decision. Permanent and queryable.
Thresholds are governed, not trusted
AI-proposed thresholds are tagged and gated. Contractual thresholds are sourced and attributed. No threshold reaches production without provenance.
Incremental is natural
Norn runs multiple times on a growing project. Existing requirement context means each session adds to what is already there, not over it.
Agent-ready architecture
The session lifecycle is a REST API with no UI dependencies. Future orchestration can call Norn programmatically without changing backend logic.
The library answers first
Reuse retrieval is free, so it runs before generation, by default, everywhere — including air-gapped. The LLM derives only what the organisation has not already solved. Retrieval thresholds are calibrated measurements, never guesses.
What's Coming
Norn is developed continuously alongside the projects that use it. A few of the directions in flight:
Standards in the Library
Published domain standards brought into the requirements library as first-class content — matched, inherited, and traced by the same reuse machinery your own requirements already use.
Deeper Layer Coverage
Derivation extending further down the NFSI model, carrying the same governance, provenance, and human-review guarantees to every layer of the requirement set.
Guided Correction
Where a proposal falls short of the quality gate, Norn will offer a corrected version ready for the engineer to review — less editing, same final say.
Conversational and Agentic Access
Running a derivation by asking for it, and calling Norn as a governed step inside a larger engineering workflow — with the human review gate intact at every transition.