# ORCEST Context Block (OCB) v0.2 Specification

- Status: Draft reference standard
- Version: v0.2
- Conformance schema: `spec/schemas/ocb.schema.json`
- Last updated: 2026-07-25
- Intended environment: Multi-agent and multi-runtime AI systems

## 1. Purpose

OCB is the portable operating state contract for ORCEST. It carries the authoritative control plane metadata for AI agent work, not every project byte. The design goal is to preserve:

- mission intent,
- authority boundaries,
- policy and budget constraints,
- accepted artifacts and documents,
- provenance and evaluation receipts,
- and evidence of continuity across model, runtime, and provider transitions.

The contract is designed so an agent can be resumed by another runtime without human re-explanation, while preserving hard boundaries and approvals.

## 2. Scope model and containment

OCB uses five nested scopes:

1. `organization`
2. `person`
3. `project`
4. `application`
5. `task`

Scope rules are strict:

- More specific scopes can narrow permissions and budgets.
- A more specific scope MUST NEVER grant authority that is denied by an ancestor scope.
- Organization scope is the trust root for privacy, cost ceilings, and irreversible policy decisions.
- Project scope owns canonical decisions, artifacts, and cross-run continuity context.
- Application scope stores runtime capabilities, defaults, and compatibility notes.
- Task scope owns outcome, acceptance criteria, and execution guardrails.

## 3. OCB object contract

All concrete OCB documents MUST include these required fields:

- `ocb_version` (must be `"0.2"`)
- `id`
- `scope`
- `metadata`
- `intent`
- `authority`
- `policies`
- `context`
- `budget`
- `security`
- `provenance`

Optional extensions are allowed only through schema-defined additional properties.

### 3.1 Required object semantics

- `scope` defines the active authority context and stable reference.
- `metadata` carries version, title, status, and labels.
- `intent` MUST include `goals`, `non_goals`, and `success_criteria`.
- `authority` declares owners, delegates, and signed approval artifacts.
- `policies` defines allow/deny/limit/require controls.
- `context` references supporting docs/artifacts/skills/acknowledgements/decisions through stable IDs.
- `budget` defines hard cost/time/token ceilings.
- `security` defines classification and content logging behavior.
- `provenance` records creation identity, timestamps, ancestry, and integrity marks.

## 4. Deterministic resolution rules

A resolver MUST produce deterministic output when fed identical versioned inputs.

### 4.1 Resolution order

1. Validate input against JSON schema.
2. Canonicalize order-sensitive arrays where required.
3. Merge scopes from `organization` down to `task`.
4. Apply policy conflict semantics:
   - `deny` overrides `allow`
   - `require` overrides `allow/limit` for the same capability
   - tie-breakers use `priority` then declaration order
5. Resolve budgets with minimum-by-default semantics.
6. Freeze immutable ancestor entries.
7. Emit a context fingerprint hash and mark it in the resolved output.

### 4.2 Continuity guarantees

For a new runtime to execute a resumed task, the following MUST happen:

- The compiled context fingerprint is passed and acknowledged.
- Required policies are rechecked in the destination runtime.
- Artifact lineage and decision IDs are verified.
- Output contract is checked against task acceptance criteria.

## 5. Security and compliance requirements

Security rules in OCB are explicit:

- `secret_refs` are pointers only; raw secrets MUST NOT be embedded.
- Unknown or untrusted source references SHOULD include taint metadata in the reference envelope.
- `content_logging` defaults to `false` unless explicitly enabled by policy.
- Export and deletion paths MUST be explicit, testable, and auditable.
- Security classification must be inherited from stricter ancestors.

## 6. Policy and budget behavior for AI-agent systems

For AI agent workloads, policy evaluation is the control plane contract, not an advisory note:

- `deny` is sticky unless a higher-level, named exception exists.
- Capability grants may be scoped to model/runtime type and timebox.
- Policy decisions must carry a `reason`, `scope`, and `effective conditions`.
- Numeric budgets are enforced at run-time:
  - token limits,
  - latency limits,
  - cost limits,
  - and hard run timeouts.

Violating any hard budget is a non-recoverable execution boundary unless the target scope has explicit override authority.

## 7. Interoperability and transport

OCB is transport-agnostic and designed for ecosystem coupling:

- MCP exposure as resource documents.
- A2A message/receipt payload exchange.
- Correlation with OpenTelemetry traces for run identity and policy evaluation.
- No requirement to replace MCP/A2A; ORCEST composes with them.

## 8. AI Agent customization for private/production deployments

OCB supports agent-level customization by using:

- task-level goals and acceptance criteria,
- `authority` delegates for approved sub-agents,
- capability-limited skill references,
- and deterministic policy binding before each model switch.

Implementation note for custom agent stacks:

- `metadata.labels` SHOULD carry namespaced keys for local agent profiles (for example, `agent:goal_profile`, `agent:tooling_profile`).
- `context.skills` SHOULD resolve to versioned skill manifests.
- `context.decisions` SHOULD include machine-readable rationale IDs.
- `provenance.parent_version` SHOULD track lineage for adaptation.

## 9. Evidence and run continuity

Every meaningful run context should produce:

- resolved context hash,
- resolved policy summary,
- execution receipts,
- evaluation outcome references,
- and explicit exception list.

An orchestrator may refuse execution if the receipt set is incomplete for a task marked as critical.

## 10. BRICS strategic goal (dependency reduction)

The specification is intentionally non-vendor-specific. By separating state governance from model execution, ORCEST reduces mandatory dependency on any single LLM provider. This is critical for BRICS members where continuity, local infrastructure compatibility, and data governance constraints are strategic.

## 11. Conformance profiles

- C0 Parse: valid JSON and valid schema.
- C1 Resolve: correct scope merge and policy conflicts.
- C2 Continuity: immutable ancestor handling and fingerprint propagation.
- C3 Evidence: source/decision provenance and receipts attached.
- C4 Execution: budget enforcement and policy re-endorsement before run.
- C5 Interop: MCP/A2A compatible payload mapping.
- C6 Adaptation: gated adaptation with rollback plan and deterministic recompile.

## 12. Reference example

```json
{
  "ocb_version": "0.2",
  "id": "ocb:task:orcest-continuity-beta",
  "scope": { "type": "task", "ref": "task:continuity-beta-demo" },
  "metadata": {
    "title": "ORCEST continuity demo with free beta",
    "version": "1.0.0",
    "status": "active",
    "labels": {
      "agent:profile": "continuity-first",
      "tenant:segment": "brics"
    }
  },
  "intent": {
    "goals": ["Preserve mission state across model providers."],
    "non_goals": ["Store raw private secrets in OCB."],
    "success_criteria": [
      "No task-level re-explanation required after resume.",
      "Provenance and policy fingerprint are preserved."
    ]
  },
  "authority": {
    "owner": { "type": "organization", "id": "org:demo" }
  },
  "policies": [
    { "id": "policy:deny-external-secrets", "effect": "deny", "capability": "export_secret" }
  ],
  "context": {
    "docs": [],
    "artifacts": [],
    "skills": [],
    "acknowledgements": [],
    "decisions": []
  },
  "budget": { "max_input_tokens": 12000, "max_output_tokens": 4000, "max_cost_usd": 9.5 },
  "security": { "classification": "internal", "content_logging": false },
  "provenance": {
    "created_by": { "type": "organization", "id": "org:demo" },
    "created_at": "2026-07-25T00:00:00Z"
  }
}
```

## 13. English reference links

- [OCB specification (public mirror)](https://www.orcest.ai/spec/OCB-SPEC-v0.2.md)
- [GitHub private companion page](https://www.orcest.ai/github.html)
- [Beta registration and API access](https://www.orcest.ai/beta.html)
- [Chinese BRICS page](https://www.orcest.ai/chinese.html)
- [Russian BRICS page](https://www.orcest.ai/russian.html)
- [Brazilian BRICS page](https://www.orcest.ai/brazilian.html)
- [Indian BRICS page](https://www.orcest.ai/indian.html)
- [South Africa BRICS page](https://www.orcest.ai/south-africa.html)

## 14. Status

This is a living specification. It is currently a reference implementation contract and does not itself claim production stability without conformance tests, migration validation, security review, and a live beta control-plane deployment.