Context Nexus
The Framework
Context Nexus organized into four registers, linked by inheritance and consumed by AI agents in four distinct modes.
What is Context Nexus?
It distinguishes itself from classic documentation on two points. First, it is oriented toward the future as much as the past: it captures intent (what we want to build) as much as memory (what has been decided). Second, it is not frozen: it is cultivated and refined at each iteration, fed by human contributions and by agents' observations in run, test, and discovery.
Two actors, two modes of interaction
Conceptualize and feed by intention: specs, architecture decisions, quality contracts, procedures. Intent and Contracts are always authored by humans.
Exploit and enrich by observation: they consume context to produce, return observations to refine the registers.
The four registers
Click any register to explore it in depth.
Domain knowledge, architecture, past decisions, conventions. The memory agents anchor on to avoid hallucinating and produce consistent code.
Specs, Decision Directives, roadmap, product hypotheses. The precise instructions agents execute to generate code, tests, and components.
Verifiable assertions with thresholds: quality gates, performance SLAs, accessibility standards, data rules. Agents validate their own output against them.
Runbooks, playbooks, deployment procedures, incident protocols. Workflows agents execute autonomously when conditions are met.
The registers feed each other.
The four registers are not independent: they nourish each other in a circular logic:
Knowledge → Intent: domain knowledge constrains and refines intentions before an agent begins to produce.
Intent → Contracts: specs and product hypotheses determine the quality contract: acceptance criteria become verifiable assertions, SLAs are refined as intentions sharpen.
Contracts → Operations: contracts produce runbooks, incident playbooks, and protocols that operationalize requirements.
Operations → Knowledge: each resolved incident, each executed procedure becomes collective knowledge capitalized in the Knowledge register.
AI feedback loops
Beyond register loops, AI agents enrich Context Nexus continuously through their observations, in test, in run, and in discovery:
In test (Ship): the agent observes mutation scoring results. An insufficient score bubbles up into Contracts and Knowledge.
In run (Sync): the agent observes production metrics: latency, anomalies, usage patterns. Observations feed Knowledge, Operations, and Contracts.
In discovery (Shape): the agent analyzes user feedback and usage data. Signals feed Intent: specs and product hypotheses update based on what reality teaches the team.
Four ways to consume knowledge.
Injected at agent initialization. Always active, always true. Low volume, high density, zero ambiguity. What the agent must know before beginning to work.
Retrieved on demand by semantic similarity. The right mode for large knowledge bases where only a fraction is relevant per task. Requires careful chunking and rich metadata.
Assembled and passed explicitly for a specific task. Neither too early (system prompt), nor on demand (RAG), the mission context: the current spec, applicable Decision Directives for this ticket.
Callable procedures. The agent doesn't read a runbook — it executes it. The quality gate isn't just a known rule, it's a function that returns pass/fail.
Register × Mode mapping
| Register | System | RAG | Context | Skills |
|---|---|---|---|---|
| Knowledge | Conventions, anti-patterns | Domain knowledge, Decision Contexts | — | — |
| Intent | Universal Decision Directives | — | Spec, task-specific directives | — |
| Contracts | All assertions | — | — | Verification tools |
| Operations | — | Incident search | — | Runbooks, playbooks |
N levels, one inheritance logic.
A two pizza team never operates directly under an organization. It sits within a BU, a program, a particular product context. Context Nexus reflects this reality with a configurable N-level inheritance model.
The default three-level structure: Nexus Org (root: non-negotiables) → Nexus Intermediate (BU / Tribe / Programme, optional) → Nexus Team (leaf node, where Intent lives exclusively).
Each level inherits from its parent and can extend it. It can never replace it. A team cannot replace an intermediate or org contract: it can only extend it or, under explicit conditions, declare an exception.
Nexus Org (root)
└── Nexus Intermediate (BU / Tribe / Programme / Value Stream)
└── Nexus Team (two pizza team)Enforcement mechanism
Each contract carries an optional exception-to field. Without it: pure extension (always allowed). With it: a declared exception, requiring an exception-approved-by field validated by the parent level owner. The Context Assembler blocks any silent bypass.
---
register: contracts
level: team
exception-to: null # pure extension — always allowed
exception-approved-by: null
---
---
register: contracts
level: team
exception-to: org/contracts/security.md # declared exception
exception-approved-by: security-guild # validated by org owner
---Update as the path of least resistance.
Every knowledge base dies the same way: contributions become voluntary, owners change roles, content silently drifts. Context Nexus governance is designed so that updating is the path of least resistance, not an additional discipline.
Each artifact carries lifecycle metadata: draft → active → stale → deprecated / superseded. A stale artifact is flagged but not deleted: it is excluded from system prompts and RAG beyond a configurable threshold.
draft → active → stale → deprecated / superseded Start on day one.
A few rules.md and contracts.md files. No RAG, no MCP. Context passed manually in prompts. Enough to structure first intentions and conventions.
Knowledge is indexed. Agents automatically retrieve Decision Contexts. Specs in Intent are structured as task briefs. The Context Assembler is a simple function.
Repeatable runbooks are encapsulated as MCP tools. Quality gates are executable (not just known). The org skills registry is populated.
The Context Assembler is itself an agent. Agent cards (A2A protocol) enable dynamic skill discovery. AI feedback loops (ship, sync, discovery) automatically feed the registers.