The engineering-invariant problem
When an autonomous agent works on a software task, the output is a code change, a test result, a document. The engineering chain that should accompany it — which requirement is being addressed, which architecture decision applies, which trace, which evidence — is usually missing or, under pressure, fabricated. A week later, when the change needs review, debugging, or regulatory defence, that chain is not there.
Training LLMs to follow engineering discipline through instruction tuning and RLHF improves average behaviour but does not enforce invariants. Engineering invariants — traced requirements, justified architecture, evidenced deliveries — cannot reliably be maintained as learned behaviour. They have to be enforced by a mechanism external to the proposer. You do not train a compiler to reject type errors; you build a type checker.
Nidus: a governance runtime for AI-assisted engineering
Nidus mechanises the V-model for AI-assisted software delivery. The engineering methodology — requirements, architecture, design, traceability, proof obligations, evidence — is externalised into a single decidable artefact: the living specification. Every mutation proposed by any agent is verified against the active proof-obligation set before it is persisted. The repository contains only states that have passed verification.
Organisational standards compile into reusable guidebooks: constraint libraries that any governed project imports. A new project picks up the inherited constraints automatically; the methodology lives in the environment, not in the agent.
Public-level properties:
- Living specification covering requirements → architecture → design → traces → proofs → evidence as one structured artefact.
- Decidable verification gate on every mutation; commits are accepted only after passing all active obligations.
- Reusable guidebooks let organisational standards propagate across projects by inheritance.
- Recursive self-governance: rules governing the artefact live inside the artefact itself, subject to the same gate.
- The git history of a Nidus artefact is a sequence of verified states. The audit trail is a structural property of the artefact, not a separate process.
For AI-assisted engineering teams, and for regulated deployments that must defend every machine-made decision, this moves engineering discipline from a behavioural property of the model to a structural property of the system.
Self-hosting reference deployment
Nidus governed its own construction. Three LLM families (Claude, Gemini, Codex) delivered a 100,000-line reference implementation under the same proof-obligation set used to govern the artefact itself. Detailed deployment metrics, latency tables, the empirical lesion study, and the friction model are in the public preprint.
Preprint
Nidus: Externalised Reasoning for AI-Assisted Engineering — arXiv:2604.05080.
Related research
- Technical notes on knowledge systems — thermodynamic framing of knowledge amplification; context for externalised methodology as a knowledge substrate.
- Research index — Gentian architecture, Nidus governance, technical notes.