ContextOS Research Synthesis
A traceable evidence-to-spec crosswalk showing how all 108 ContextOS research essays evolve the five-plane runtime without creating competing contracts.
This page records how the complete ContextOS blog corpus was absorbed into the documentation. The snapshot covers 108 essays published through 2026-08-24. It is both a research index and a change-control boundary: each essay has a canonical destination, while proposals that are not yet runtime contracts remain visibly non-canonical.
The result is not a sixth plane and not a second specification. It is a traceable promotion path from observations and experiments into the existing five-plane model.
Evidence-to-spec promotion rule
Blog language is promoted at one of three levels:
| Level | Meaning | Documentation treatment |
|---|---|---|
| Canonical contract | Implemented and represented by the typed runtime contract. | Use the exact type and field names from src/lib/contextos/types.ts and the schema reference. |
| Documented protocol | A durable operating pattern composed from canonical contracts. | Specify the invariants, evidence, gates, and metrics without pretending it is a new runtime type. |
| Candidate extension | A useful proposal whose schema or semantics are not yet settled. | Name it as a candidate, state which existing contracts bound it, and require an ADR plus conformance tests before promotion. |
This distinction matters. A “release manifest” is currently a documented aggregate of pinned versions and evidence already carried across RunContext, CompiledContext, tool envelopes, traces, and the DecisionRecord; it is not a new core interface. “Autonomy budget,” “irreversibility budget,” and “reversal spec” remain candidate policy or effect-protocol extensions. The canonical controls today are RunBudget, ActionRisk, policy decisions, approvals, idempotency, postconditions, and compensation receipts.
Integrated construct ledger
The corpus adds the following durable requirements to the existing model:
| Construct | Status | Canonical home | Required outcome |
|---|---|---|---|
| Complete release tuple | Documented protocol | Harness Engineering | Every run can identify code, model route, prompts, packs, policies, skills, tools, evaluators, and environment. |
| Proof-carrying execution | Documented protocol | Harness Engineering | A terminal claim is backed by identity, authority, evidence, effects, postconditions, and recovery receipts. |
| Portable trajectory evidence | Documented protocol | Evaluation and Observability | Evals inspect observable decisions, calls, results, state diffs, and verdicts without requiring hidden chain-of-thought. |
| Paired Skill Lift | Documented protocol | Adapter Mesh and Evaluation | A skill ships only when it adds measurable value over a no-skill baseline without unacceptable safety, cost, or latency regression. |
| Lifecycle security | Documented protocol | Harness Engineering | Security gates cover configuration, extension, runtime, persistence, action, and recovery phases. |
| Authority non-escalation | Canonical invariant | Governance | Context, memory, tool metadata, and agent messages may inform a decision but cannot grant themselves authority. |
| Effective authority graph | Documented control view | Identity Layer | Operators can resolve and revoke the actual identity → delegation → capability → resource path. |
| Recall-time memory reconstruction | Documented protocol | Memory Model | Stored material is recompiled under current evidence, policy, authority, freshness, and contradiction state before use. |
| Independent multi-agent certification | Documented protocol | Orchestration | Consensus never substitutes for external evidence, verifier independence, or one accountable runtime owner. |
| Risk-weighted human oversight | Documented protocol | Evaluation and Observability | Audit allocation combines deterministic risk gates with stratified random coverage and reviewer-quality measurement. |
| Effect and recovery receipts | Canonical composition | Adapter Mesh | External action is normalized, idempotent, postcondition-checked, and paired with rollback or compensation evidence where applicable. |
| Cost per trusted outcome | Canonical metric alias | Metrics Glossary | Total inference, tool, retry, evaluation, observability, infrastructure, and review cost rolls up to contextos.budget.cost_per_verified_success. |
| Execution / evaluation / improvement separation | Canonical invariant | Improvement Loop | The system being optimized cannot define or waive its own release gate. |
| Evaluated prompt contract | Documented protocol | Agentic Context Engineering | Prompts declare trust, authority, tools, output, failure, and stopping behavior and are released with pinned dependencies. |
Corpus crosswalk
Each essay below appears once. “Promoted into” names the primary canonical destination; an essay may also inform adjacent pages.
Harness architecture and release engineering
Evaluation, replay, security evaluation, and improvement
Context compilation, prompts, knowledge, and memory
Decisions, orchestration, and multi-agent systems
| Research essay | Promoted construct | Promoted into |
|---|---|---|
| AI Agent Accountability Matrix | One owner per failed decision and control surface | Orchestration |
| Graph Engineering for Agent Workflows | Typed graph states, guards, and recoverable transitions | Orchestration |
| Multi-Agent Consensus Is Not Correctness | Independent evidence, minority preservation, external certification | Orchestration |
| Passive Awareness with AgentRadio | Bounded asynchronous evidence channel | Orchestration |
| PM Multi-Agent Control Tower | Fleet ownership and visible coordination state | Orchestration |
| Stop Building Multi-Agent Systems Until Replay | Replay before fleet scale | Orchestration |
| The Critic: Verify, Score, Consolidate | Bounded critic contract | Orchestration |
Action, identity, governance, and security
| Research essay | Promoted construct | Promoted into |
|---|---|---|
| AI Agent Access Graph | Effective authority graph, drift, and graph revocation | Identity Layer |
| AI Agent Security Threat Model | Threats mapped to deterministic boundaries | Security and Compliance |
| Agent Identity Is the Trust Boundary | Workload identity and principal chain | Identity Layer |
| Approval Gates in Code | Frozen evidence and resumable typed interrupt | Governance |
| Approval Mode Tiers | Compatibility taxonomy bounded by ActionRisk | Governance |
| Autonomy Budget | Composite policy envelope, not a scalar permission | Governance |
| Build the Tool Gateway | Single mediated path to external effect | Adapter Mesh |
| Identity Layer for Agent Runs | Signed identity claims and credential exchange | Identity Layer |
| MCP Adapters in Production | Protocol normalization behind the gateway | MCP Standard |
| Prompt Injection Is a Boundary Problem | Information cannot grant authority | Governance |
| Reversibility Is the Missing Safety Primitive | Effect postconditions, compensation, and candidate reversal contract | Governance |
| Secure MCP Tool Supply Chain | Admission, runtime validation, release, kill switch | Adapter Mesh |
| The Glass Runtime | Human agency through inspectable control and receipts | Governance |
Product contracts, operating models, and domain patterns
External platform and research maps
These essays are evidence about the surrounding field. They update interoperability, model-routing, security, and adoption assumptions; they do not define ContextOS contracts by vendor analogy.
Conflicts and non-canonical proposals
The synthesis found useful terms that must not be blended into the contract silently:
ApprovalModeversusActionRisk:ApprovalModeremains the v1 compatibility projection. New reasoning uses the independentActionRiskdimensions. Neither becomes a single numeric “risk score.”- Release manifest: required as an immutable aggregate for attribution and replay, but not yet a core interface. Implementations may materialize one if it is derived from and consistent with the canonical pins.
- Trajectory / protocol card: required evaluation evidence shape, but not hidden chain-of-thought and not yet a core TypeScript type. Store observable envelopes, results, diffs, metrics, and grader provenance.
- Autonomy and irreversibility budgets: useful policy composition ideas. They do not supersede
RunBudget,ActionRisk, approval gates, or deterministic policy checks. - Reversal specification: an effect protocol may declare verification, rollback, or compensation. A new
ReversalSpecschema requires a separate ADR and compatibility tests. - Vendor constructs: provider APIs, model families, and managed-agent products are evidence inputs. They remain behind ContextOS model profiles, adapters, and policy boundaries.
Maintenance contract
When a new research essay is published:
- Add it once to this crosswalk and name its primary canonical destination.
- Classify the promoted idea as a canonical contract, documented protocol, or candidate extension.
- Update the smallest coupled documentation surface; do not create a parallel plane or synonym for an existing type.
- If the proposal changes a runtime contract, require an ADR, types/schema updates, examples, migration notes, and conformance tests together.
- Record the evaluation, security, replay, and rollback evidence needed to promote it.
The documentation evolves when evidence improves the operating model—not merely because a new term is memorable.