Published schemas
Inspect the versioned interfaces for context, invocation, tool envelopes, decision records, and replay.
Browse the contractsThe ContextOS architecture
A clear contract.
From request
to result.
Keep the model and runtime you use. Define what enters a run, what it may change, and what evidence makes the result acceptable.
Compatible core · Exact control profiles · Deterministic reference
One workflow / explicit boundaries
01 / RequestIntent + identity + limits
Your agent runtimeModel + tools
Intelligence / scoped knowledge + identity
ContextAdmit evidence
DecisionWork within bounds
ActionAuthorize effects
Trust / policy, approvals, evaluation
02 / OutcomeObserved result + retained evidence
01 / Where it fits
Keep your runtime.
Know who owns each boundary.
ContextOS supplies an open specification and executable reference. Your application and infrastructure implement the controls. A managed runtime can supply parts of the system; ownership still needs to be explicit.
Application-owned runtime
Your team implements the loop and its enforcement boundaries. Use the contracts to make those responsibilities inspectable.
Session & execution
Implementation owner
Your runtime + protected stores
Evidence to require
Resume revalidates current controls and preserves used/reserved budgets, operation identity, unknown effects, and fenced ownership.
Context & evidence
Implementation owner
Your application + data owners
Evidence to require
Eligible sources, missing evidence, nine-stage data obligations, and owned memory/copy receipts are inspectable.
Identity & authorization
Implementation owner
Your gateway + identity system
Evidence to require
Every reachable effect checks current owned authority and ancestors, full action/approval quorum, active containment, and brokered credentials.
Outcome & operations
Implementation owner
Your application + operators
Evidence to require
Atomic claims and shared reservations precede fenced dispatch. Verify postconditions, reconcile unknown effects, and retain scoped positive/negative/utility/fault evidence.
The enforcement path must be unavoidable. Instructions to the model cannot substitute for scoped credentials and checks at the tool boundary.
02 / The five planes
Five responsibilities.
One connected system.
Use the planes to assign ownership and inspect handoffs. They are logical responsibilities: one application can implement several. Add memory, graph retrieval, or specialist agents when a measured need justifies them.
01
Intelligence
What can the system know?
Give evidence, identity, and retained knowledge a source and a scope. Promote memory only through the required review.
Evidence + memory proposals
02
Context
What should this run see?
Select and compile relevant evidence within a budget. Keep provenance, conflicts, and omissions visible.
ContextPack → CompiledContext
03
Decision
What counts as accepted work?
Bind work to declared outcomes. Plan, verify, and score within limits, then emit an evidence-linked decision record.
DecisionSpec → DecisionRecord
04
Action
What may actually change?
Check owned/ancestor authority, full exact approval/quorum, active boundaries/data and external preconditions. Reconcile unknown effects.
ToolEnvelope + tool evidence
05
Trust
Across all fourHow is the whole run controlled?
Apply policy, evaluation, trace, and replay requirements across the other four planes. Keep enforcement outside model judgment.
Policy decisions + replay
Inspect the execution contract
This non-executable flow connects the actual reference compiler API to deployment-owned services. Planner, executor and critic name responsibilities; no runtime loop, credential broker, sandbox or protected database is supplied by this page.
trusted ingress binds request, RunContext and ExecutionContractEnvelope
-> resolve pack refs, tenant, identity, intent, safety mode
-> negotiate exact profile/control versions and required feature support
-> verify current owned authority and all ancestor restrictions/revocation
-> new ContextPackCompiler(pack).compile(request, run_context, deps)
caller supplies eligible evidence and promoted_memory
applicable policy-expression errors stop with structured diagnostics
-> bind DecisionSpec
-> route model judgment through AI Gateway / LLM Router
-> runtime-owned planner proposes actual next action
-> independent plan review: ok | replan | reject | escalate
-> independently validate full action/evidence/pins and current approval/quorum
-> verify native risk, guardrails, active boundary/credentials/data, preconditions
-> atomically claim operation and reserve original shared capacity
-> fenced owner dispatches under verified provider semantics
-> preserve unknown effects/reservations; reconcile before unsafe retry
-> assess actual postconditions and current evidence
-> emit DecisionRecord with honest lifecycle, effects, usage and limitations
-> emit replay packet and scorecard
-> offline replay compares declared artifacts/properties, never live effectsPin the context used by a run, such as ctxpack.support@5.2.0, and retain its evidence and policy lineage. Audit replay uses recorded tool results with live effects disabled.
03 / Open engineering assets
Start with something
you can inspect.
The repository publishes the contracts, a context compiler reference, and tests. Production identity, execution, storage, tool enforcement, and outcome verification belong to your deployment.
Compiler reference
Inspect deterministic compilation plus authority, boundary, durable operation, exact budget and conformance validators.
Inspect the implementationFixtures and tests
Inspect positive, denial and fault fixtures. Synthetic reference checks are distinct from independent deployed-control evidence.
Read the checksSchema validation checks structure. Your deployment authenticates observations and enforces actual boundaries, atomic stores, leases and generation fences. Original shared spent/reserved capacity includes children, reviews, retries and repair; cancellation does not erase unknown provider outcomes or usage. All nine data stages and derived copies need current processor/purpose/retention controls and correction/deletion receipts.
04 / Your first release
One workflow.
A defensible first step.
Choose a valuable task with a clear owner. Define success, prohibited effects, and required evidence before expanding the agent’s authority.
Begin with the controls the task needs. Evaluate the whole release, and remove complexity that no longer improves the result.
Follow the adoption guideEvidence to collect before expanding
Accepted outcome
The observed system state satisfies the workflow’s declared success criteria.
Denied action
A forbidden or expired request is stopped before a tool changes anything.
Uncertain result
A lost response is reconciled before retrying an operation that may have completed.
Release evidence
Fresh evaluation cases include failures, human effort, latency, and full cost.
Set thresholds for your workflow. Keep a release owner and tested current recovery path. Freeze candidates before bounded independent final checks; a kill switch cannot reverse effects already accepted by a provider.
Already running agents?Assess the controls and evidence around a specific release.