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. The AI receives the full N→F→S traceability chain, the child architecture node definitions (with descriptions), library Solutions, and any bound Design Decisions. Each proposed child requirement is allocated to a specific architecture node on commit. The engineer selects which Solution Requirement to decompose; the architecture tree defines the decomposition structure. This mode still runs on the legacy single-call path — it is Anthropic-only and not yet covered by the local provider.
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 directly in reviewing; if the library is silent, the classic flow proceeds unchanged.
AI Derivation
The selected inputs are handed to Norn's modular fan-out derivation engine — separate N→F, F→S, and decompose lanes that drive the configured LLM provider (the Anthropic API, or a local Ollama endpoint running qwen3:14b) with structured, schema-constrained prompts encoding the Bifrost NFSI model rules. A validator stage checks every proposal and issues conversational correction retries; the F→S lane runs a per-parent dimension sweep for broad constraint coverage. The engine returns structured JSON — not free text — with proposed requirements, rationale, confidence, and traceability links. Derivation runs off the request thread: the session moves to deriving and the client polls; an unreachable generator or engine error moves it to a terminal but retryable failed status. For sessions that opened with library adoptions, this runs as derive-remainder — AI derivation only for the inputs not covered by a non-rejected adoption.
Quality Gate
Derived proposals are evaluated using layer-specific Bifrost rules. The AI scoring gate is provider-aware: per-proposal AI evaluation on the Anthropic (cloud) provider, while a local/Ollama box relies on the deterministic mechanical validator checks plus human review. Library adoption proposals skip the gate — they are pre-validated library items and receive Q:10 automatically. Session status flips to reviewing when complete.
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
Since v0.3, 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 BGE-M3 embeddings 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, derive-remainder, the staged merger, and the quality gate. Runs behind a provider abstraction (NORN_PLUS_PROVIDER) — the Anthropic API, or a local Ollama endpoint running qwen3:14b on-appliance. Configurable and optional: a deployment without an LLM (or with GENERATION_ENABLED=false) still has full Norn Lite reuse.
Match Bands — Calibrated, Not Guessed
For a project Need, Norn Lite retrieves the closest library Needs by cosine distance over stored vectors and classifies each hit: strong (distance < 0.20 — zero false positives in calibration), candidate (< 0.40 — shown for side-by-side review), or silence (not returned at all). A margin rule handles ambiguity: a strong top hit is presented as the match only when the runner-up is at least 0.05 farther — otherwise "one of these". The thresholds are measurements from a labelled evaluation harness (recall@1 19/20 on paraphrases, 4/4 on adaptations), recalibrated whenever the embedding model changes or 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 library_source_id provenance, recreates the internal links, and writes an audit record (norn_match_audits): what matched what, at what distance and band, who accepted it, 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, regardless of band. This is a measured limitation, not caution for its own sake: embedding distance cannot see requirement polarity — in calibration, a library Need with a flipped threshold value still scored 0.26, comfortably inside the candidate band. 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 with BGE-M3 (1024 dimensions) via a local Ollama instance — embed-on-write in the background, best-effort with a circuit breaker, plus a backfill command for catch-up. Vectors live in a dedicated requirement_embeddings table (pgvector), one row 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 as pure SQL over stored vectors, so it keeps working even while the embedder is down. The same layer powers free-text semantic search over project and library requirements.
Governance Mechanisms
ᛚ Library Adoptions
When the library already covers a Need or Function, Norn proposes adoption rather than re-derivation — since v0.3, mechanically via the Norn Lite pre-derive, before any LLM call. Adoption proposals appear first in the review list with a gold FROM LIBRARY badge, Q:10 quality score, and the anchor evidence in their rationale (which library Need matched, at what distance). On commit, the project requirement is linked to its library source with library_status: compliant — institutionalising reuse rather than reinvention. After judging the adoptions, the engineer triggers derive-remainder: AI derivation only for what the library did not cover — once per session, 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 (proposal_type: 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.
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 Shipped
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: normalised exact-text dedup, then a cosine-similarity shortlist over stored vectors, then an LLM verdict — same / adapt / distinct — per pair. Auto-apply is off by default, so every merge beyond exact-text collapse lands in the norn_merge_reviews queue for a human decision, and a pair carrying conflicting numeric values is never auto-merged. A merge never deletes a row: the loser is retired with a merged_into pointer and its traceability links are absorbed by the survivor.
Role Guard Shipped
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 derivation requires the trigger-norn capability (engineer and above); editing the Domain Knowledge document requires edit-domain-knowledge (architect and above). Enforcement is a require_capability() dependency on the Norn endpoints, so a role change takes effect on the user's next request without a new token.
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.
The Prompt Reference
Norn's four derivation modes are each driven by a dedicated system prompt in the backend service. This reference is the implementation as built — auto-generated from norn_service.py and read against the methodology to catch drift: every rule the prompts enforce should trace to a documented mechanism, and vice-versa. Each mode calls the model with structured-JSON output, batches its inputs, and carries conversation history across batches.
Needs → Functions
Derives a complete set of Functions that fulfil each Stakeholder Need. Enforces the core rule that one Need almost always yields multiple Functions — splitting on independently achievable capabilities — and keeps output technology-independent in verb + noun form.
derive_functions_fast() · NORN_SYSTEM_PROMPTmax_tokens 6000 · NF_BATCH_SIZE = 4
Functions → Solution Requirements
Derives the logical constraints on each Function — one constraint per requirement, quantified where measurable. Applies the strict threshold hierarchy (contractual value → rationale evidence tagged [AI PROPOSAL]) and keeps V&V activities out of the requirement set.
derive_solutions_fast() · NORN_FS_SYSTEM_PROMPTmax_tokens 6000 · FS_BATCH_SIZE = 4
Function Decomposition
Vertical, within-layer partitioning of a system-level Function into subsystem-level children that collectively cover it. Follows the resolution hierarchy Design Decision → Library → AI-only, tagging unvalidated decomposition structure [AI PROPOSAL].
derive_decompose_fast() · NORN_DECOMPOSE_SYSTEM_PROMPTmax_tokens 6000
Solution Decomposition
Allocates a system-level Solution Requirement across child architecture nodes, scoping each child to one node. Carries thresholds from the parent and follows the four-level resolution hierarchy down to [AI PROPOSAL] where no source exists.
derive_solution_decompose_fast() · NORN_SOLUTION_DECOMPOSE_SYSTEM_PROMPTmax_tokens 6000
The verbatim system prompts, context-assembly code, and user-message templates for all four modes are reproduced in full in norn-methodology.md (Appendix A) and its generated PDF. That section is auto-generated — edit the prompts in the service and re-run the generator, never by hand.
What's Next
Decompose-Lane Norn Lite
Migrate the Function and Solution Decompose modes to the pre-derive mechanism, removing library items from their AI context — the same surgery already performed on N→F and F→S.
Standards as Library Content
Sealed standard bundles extracted by Mimir imported into the library with origin: standard — matched and inherited by the same Norn Lite machinery, giving projects standards coverage through the ordinary reuse flow.
S→I Derivation
Derive Implementation Requirements from Solution Requirements. Requires platform and technology input — depends on Mimir's knowledge layer for meaningful output.
Quality-Gate Auto-Improve
For proposals that fail the quality gate, Norn produces a corrected version pre-populated for engineer review — reducing the edit burden on low-scoring proposals.
Mimir Integration
When Mimir has extracted domain requirements from ingested documents, these become additional context for Norn — richer reuse candidates from project-specific knowledge.
Agent Orchestration
Norn called programmatically as part of an AI agent workflow — derivation as a step in a larger automated SE pipeline, with human review gates at each transition.
MCP Integration
The Bifrost MCP server exposes the requirements database as tool-callable endpoints. Future Norn sessions will be initiatable from the conversational agent — an engineer asks the agent to run a derivation, the agent calls Norn programmatically, and results surface in the Workbench for review.