C0 ordered-many context-strategy provider contract

Contract status: Accepted. C0 was accepted after independent architecture review and correction closure.

Implementation status: Not started. This document does not implement a context strategy, provider substrate, schema, migration, registry, rollout, or runtime route.

C0 specializes the accepted D1 kernel invariants and provider control-plane contract for bounded model context. It preserves ARCH-29: Tyrum's native runtime remains the only turn executor, and the kernel retains final prompt authority. Context strategies can return typed material or one compaction proposal; they cannot assemble, render, send, or commit model context.

Quick orientation

• Read this if: you are reviewing ordered context composition, strategy selection, contribution metadata, budget allocation, or the compaction proposal boundary.
• Skip this if: you need current runtime mechanics; use Context, Compaction, and Pruning and Transcript, Conversation State, and Prompt Context.
• Go deeper: use D1 for common provider identity, trust, lifecycle, health, binding, and conformance semantics. D1 and I0 are Accepted and are not reopened here.

The diagram is the proposed C0 contract, not implemented runtime flow.

Decision summary

C0 defines one provider kind with ordered-many cardinality. The kernel resolves exactly one effective operator-authored context profile for an agent, freezes its ordered positions into a binding snapshot for a canonical turn, invokes eligible strategies independently, and merges accepted contributions only in configured order. Completion timing, discovery order, provider priority, and response order never affect the result order.

Strategies return bounded UTF-8 text contributions with source provenance, freshness inputs, sensitivity, and a constrained authority class. One configured strategy may additionally propose a typed conversation checkpoint. The kernel owns identity, authorization, policy, immutable bindings, budget allocation, duplicate and conflict outcomes, authority clamping, redaction, final rendering, tool exposure, transcript truth, compaction commit, canonical outcomes, context reports, and audit.

Current truth

The current implementation is concrete kernel code, not C0:

• prepareTurn resolves agent/workspace/conversation identity, the effective agent configuration, model, policy-filtered tools, effective skills, WorkBoard focus, pre-turn MCP hydration, sandbox state, automation context, and attachment handling before building the system and current-turn content.
• System content is assembled in a fixed order: identity, prompt contract, runtime, data-tag safety, sandbox posture, skill guidance, tool guidance, work-orchestration guidance, and memory guidance.
• Current-turn content contains conversation state, a WorkBoard focus digest, ordered pre-turn recall, automation material, the user request, and native or helper-analyzed attachments.
• Prompt-visible history is the retained conversation-state checkpoint plus pending state and recent transcript tail. The durable transcript remains retained when prompt-visible history is compacted.
• Tool schemas are supplied separately to the model and count toward the context window. Governed tool results, including fs.read workspace-file results, enter the active message stream and context report; the runtime does not pre-inject arbitrary workspace files.
• Tool-result pruning is deterministic. It prunes older tool calls/results and then caps messages while preserving the prompt head and current tail.
• Auto-compaction derives a model limit, reserves output/input capacity, summarizes dropped messages into a typed checkpoint, audits critical identifiers, and commits conversation state in the kernel. A deterministic fallback checkpoint is used when model summarization fails. Pending approvals and pending tool state are reconstructed separately.
• Context reports account for system sections, user parts, selected tools and schemas, loaded/enabled skills, pre-turn tools, memory counts, tool results, and injected files.
• No context-strategy provider kind, context profile revision, ordered binding snapshot, external strategy protocol, or C0 conformance suite exists.

C0 must preserve that current truth during later adoption. A target contract is not implementation evidence.

Goals

• define one narrow ordered-many context-strategy contract rather than a universal provider operation;
• preserve the native turn executor, model-facing context behavior, transcript truth, tool governance, and context-report ownership;
• make profile selection exact, operator-controlled, agent-scoped, and immutable for a canonical turn;
• make contribution order, budgets, duplicate handling, conflicts, freshness, sensitivity, authority, degradation, and truncation deterministic;
• let replaceable strategies supply bounded context without granting them prompt roles or system authority;
• allow replaceable compaction summarization without granting transcript or conversation-state mutation;
• keep built-in and external implementations on the same C0 admission and conformance path when a real strategy boundary is adopted;
• expose requirements for later shared-substrate analysis without authorizing S0; after M0 and C0 acceptance, S0 is dependency-eligible but remains separately scoped.

Non-goals

• no runtime/provider implementation, provider framework, universal Provider method, or alternate turn executor;
• no runtime configuration, status, context-report, or model-facing schema selected by this contract;
• no database table, migration, provider registry service, marketplace, hot reload, or rollout;
• no provider-owned identity, authorization, policy, approval, tool exposure, prompt role, token policy, audit authority, or canonical state;
• no model-selected strategy, order, budget, fallback, freshness waiver, authority, or sensitivity downgrade;
• no provider mutation of transcript, conversation state, memory, WorkBoard, tools, attachments, workspace files, or final prompt;
• no automatic semantic reconciliation of contradictory context;
• no requirement to convert every current prompt section into a strategy;
• no reopening of Accepted D1, I0, or M0; primary-memory recall remains on M0's accepted kernel-owned boundary.

Normative boundary

The terms must, must not, should, and may are normative within this contract. C0 adds provider-kind semantics to D1; where C0 is silent, D1 remains authoritative. Acceptance of C0 authorizes contract design only, not implementation or rollout.

Contract terms

Term	Meaning
Context profile	One immutable operator-authored effective selection/configuration revision for the context-strategy kind at one agent selection scope.
Position	A unique positive integer in a context profile. Position is the only strategy precedence and merge-order key.
Binding snapshot	The kernel-issued immutable ordered list of exact D1 provider bindings and C0 position rules fixed for one canonical turn.
Context assembly	One kernel-owned construction of model input under a binding snapshot, including an initial call, tool-loop step, approval resume, or bounded retry.
Contribution	A bounded typed, attributed text payload that is evidence for the kernel to consider; never a model message or prompt mutation.
Effective authority	The kernel-derived interpretation class controlling how a contribution can be wrapped and used.
Compaction proposal	A non-canonical typed candidate checkpoint derived from an exact kernel-projected transcript range.
Required position	A position whose valid contribution is necessary for the named operation to continue.
Optional position	A position whose declared failure rule permits an attributed skip or an explicitly admitted stale cache result.

Scope, identity, selection, and ordered binding

C0 defines ProviderKindId tyrum.provider.context-strategy at an initial ProviderContractVersion selected under D1. The kind's cardinality is ordered-many. A profile contains zero or more unique ordered positions; each enabled position resolves exactly one implementation release and one ProviderBindingId.

C0 v1 admits exactly one selection scope. The kernel-owned lookup key is (DeploymentConfigurationRevision, TenantId, AgentId, ProviderKindId). The deployment revision supplies defaults; the tenant and agent identify the one effective operator-authored agent context profile. Workspace, conversation, channel, thread, turn, model input, provider discovery, and model-supplied values are invocation context, not a selection scope. They cannot select another profile or reorder it.

Exactly one immutable ContextProfileRevisionId must resolve for the lookup key before a turn snapshot is created. Zero active revisions, multiple active revisions, duplicate revision identities with different content, duplicate positions, or conflicting implementation mappings fail closed. During compatibility adoption, the kernel may deterministically materialize one effective compatibility revision from the existing deployment defaults and effective agent configuration, but an explicit and synthesized revision cannot both be active. This rule does not select a storage schema; S0 remains responsible for shared persistence design after the anchor contracts are accepted.

The model cannot select or influence strategy identity, release, position, required/optional class, allowed slot, budget, freshness policy, authority ceiling, sensitivity policy, cache policy, retry policy, deployment mode, or compaction proposer. None may be added to model-supplied tool or turn arguments.

Before the first strategy invocation for a canonical turn, the kernel creates an immutable ordered ContextStrategyBindingSnapshot. The snapshot records:

• ContextStrategyBindingSnapshotId, canonical turn ID, profile revision, selection-scope identity, and creation time;
• ordered position and exact D1 ProviderBindingId for every enabled strategy;
• exact contract, implementation, implementation version, ProviderReleaseId, configuration revision, conformance evidence, trust/deployment posture, and authenticated peer where applicable;
• allowed operations and target slots, required/optional class, per-position budget/minimum, freshness and cache rules, retry/deadline policy, and authority ceiling;
• the kernel budget-policy revision, token-estimator identity/version, redaction-policy revision, and final-assembly policy revision.

A durable turn records the snapshot identity and exact binding tuple at D1's write-ahead point before provider output or a model call can affect the turn. Initial assembly, tool-loop steps, approval resume, and a bounded same-turn model retry use the same ordered snapshot. A new canonical turn resolves a new snapshot. A separately triggered compaction operation records its own operation identity but uses the profile revision pinned to the affected turn; it does not select the currently preferred profile.

Before each context assembly, the kernel also creates an immutable ContextAssemblyPlan under that binding snapshot. The plan records request-specific input digests, actual position allocations, absolute deadlines, retry schedules, and model/final-assembly limits. A later tool-loop step receives a new plan without changing the selected strategies or their order.

Installing a provider, changing health, changing configuration, discovering a new release, or restarting an activation cannot rewrite a snapshot. Discovery order never affects a position. Provider self-priority, display name, registration time, response speed, payload metadata, or a claimed urgency value is ignored and must not exist as a selector. A strategy cannot add, remove, reorder, replace, or invoke another strategy.

Kernel and strategy ownership

The Tyrum kernel owns and enforces:

• tenant, actor, agent, workspace, conversation, turn, assembly, transcript, message, attachment, tool-call, profile, snapshot, binding, and correlation identity;
• authorization, policy, approvals, identity propagation, secret exclusion/projection, and selection eligibility;
• operator profile resolution, exact ordered binding, and every effective authority decision;
• tool exposure, tool schemas, prompt-contract and safety instructions, model selection, and native turn execution;
• source precedence, token and byte budget policy, per-position allocation, and reserves;
• canonical conversation state, append-only transcript truth, pending approvals, pending tool state, WorkBoard truth, and primary-memory boundaries;
• duplicate/conflict normalization, freshness derivation, sensitivity enforcement, redaction, and safe data wrapping;
• final assembly, prompt roles, message conversion, rendering, pruning, compaction trigger, truncation, overflow handling, and model dispatch;
• validation and acceptance of a compaction proposal and the only commit of a conversation-state checkpoint;
• canonical success, degraded, failed, cancelled, timeout, overflow, and protocol outcomes;
• context-report construction, canonical state transitions, canonical audit events, and operator-visible safe reasons.

An admitted strategy owns only its specialized read/derive mechanism:

• consume the exact bounded input projection supplied by the kernel under one binding and request identity;
• retrieve or derive only the context classes declared by its descriptor and profile position;
• return a typed bounded contribution result, or the one designated compaction proposal when admitted;
• attach truthful source, revision, time, sensitivity, and authority-claim metadata;
• honor request bounds, deadline, cancellation, idempotency, protocol, and lifecycle obligations;
• release provider-owned ephemeral resources within its bound lifecycle and return safe diagnostics.

A strategy must not mutate or append transcript, conversation state, pending approvals, pending tool state, policy, approval, tool exposure, tool schemas, memory, WorkBoard, attachments, workspace files, system authority, model messages, context reports, audit records, or the final prompt. It cannot create a system/developer/user/tool role, grant a tool, turn retrieved text into instructions, change source precedence, allocate its own budget, redact less than the kernel requires, or commit compaction state. Provider reports are evidence, not canonical outcomes.

Typed contribution operation

C0 defines one required read-only domain operation, contribute, and one optional read-only operation, proposeCompaction. They are not model tools and are not universal control-plane methods.

contribute request

The kernel-issued ContextContributionRequest contains only:

Field	Contract
Identity	Exact ContextAssemblyId, canonical turn ID, ContextStrategyBindingSnapshotId, position, ProviderBindingId, request ID, and correlation ID.
Scope	Kernel-issued tenant, agent, workspace, conversation, channel/thread, and actor references needed by this position; references convey no broader authorization.
Input projection	Ordered kernel-labeled cues explicitly allowed by the profile, each with provenance, sensitivity, effective authority, digest, and size. No ambient transcript or filesystem access is implied.
Output contract	Allowed target_slot values, source classes/namespaces, authority ceiling, sensitivity policy, maximum items, UTF-8 bytes, estimated tokens, and per-item size.
Time	Kernel snapshot time, absolute deadline, fixed retry identity/schedule, and cancellation signal/reference.
Policy references	Immutable budget, freshness, redaction, profile, and assembly-policy revision identities without provider authority over them.

contribute is side-effect-free and idempotent for the exact binding, request ID, input digest set, snapshot time, and bounds. It may read its admitted source, but it must not write canonical or external domain state, refresh a subscription, promote memory, mutate a cache with externally visible semantics, or trigger another tool/provider. A duplicate identical request returns the same accepted result digest or an explicit replay record. A mismatched duplicate is a protocol violation.

The kernel may invoke independent positions concurrently. Concurrency is an execution optimization only: accepted results are always processed by configured position and contribution order, never completion order.

The output contract is bounded in items, bytes, and tokens before invocation. The v1 target_slot vocabulary is closed: skill_guidance, work_context, attachment_context, automation_context, and supplemental_context. A new slot requires a contract-version change with an accepted kernel wrapper, authority mapping, and compatibility rule. Primary-memory recall is kernel-owned context under M0 and is not a C0 target slot.

Contribution result

A successful result contains a bounded ordered list of ContextContribution objects plus safe provider diagnostics. An empty list is valid only when the position profile permits empty success.

Field	Required meaning
ContextContributionId	Stable within the exact request; unique across that result and replay.
ContextAssemblyId	Exact kernel assembly identity from the request.
ProviderBindingId	Exact bound strategy; a mismatch rejects the result.
payload	Bounded UTF-8 text payload only in v1. It is data/guidance material, not a rendered message.
payload_digest	Digest of canonical UTF-8 payload bytes and payload type.
source	Typed origin class plus stable source identifier or opaque kernel-safe reference.
source_revision	Immutable revision, cursor, version, ETag, digest, or explicit unknown; never inferred from retrieval order.
observed_at	Source event/validity observation time when known.
retrieved_at	Provider retrieval time under the kernel snapshot clock contract.
valid_until	Optional source validity bound; absence does not imply fresh forever.
sensitivity	One of existing Tyrum values public, private, or sensitive; omission rejects the contribution.
authority	Provider claim workflow_guidance, context_data, or untrusted_data; it is only an input to kernel clamping.
target_slot	One slot from the closed v1 vocabulary in the request; never a prompt role.
ordinal	Unique zero-based contribution order within the result; gaps or duplicates reject the result.

The result envelope reports canonical UTF-8 byte count and item count. The kernel recomputes digests, bytes, token estimate, metadata validity, and bounds. A provider result exceeding hard envelope bytes/items, using an unallowed slot/authority, carrying malformed times, or referencing another scope/binding is context_strategy_protocol_violation and is not partially trusted.

Ordered merge, duplicates, freshness, and authority

The kernel validates all completed results, then processes them by configured position and contribution order: position ascending, followed by provider ordinal ascending. No strategy can observe another strategy's output in v1. No reordering occurs after timeout, failure, empty output, cache use, or cancellation; a skipped position leaves an attributed gap rather than promoting later material.

Duplicate and conflict rules are exact:

1. A repeated ContextContributionId in one result rejects that result. Reuse across bindings is not identity equivalence.
2. The kernel validates each claimed source against the exact source classes, namespaces, stable-identifier shape, scope, and proof admitted for that position. An unauthorized or unverifiable source claim rejects only the offending position result before duplicate comparison; it cannot suppress another position.
3. The kernel—not the provider—derives ContextDedupeIdentity from the validated source class, namespace, stable logical-source identifier, and profile's versioned equivalence mapping. Provider-authored keys are not accepted. Cross-position equivalence exists only when both positions were independently authorized and validated for the same logical-source namespace.
4. The first accepted contribution for a kernel-derived ContextDedupeIdentity establishes its payload_digest.
5. A later contribution with the same derived identity and identical digest is recorded as an exact duplicate and omitted; first configured position wins only for identical bytes.
6. The same derived identity with a different digest is a conflict only after both source claims passed independent validation. The kernel omits every contribution for that identity. If any affected position is required, assembly fails closed; otherwise the assembly is degraded and safe conflict metadata is reported.
7. Different derived identities that appear semantically contradictory are not silently reconciled. C0 performs no automatic semantic merge, last-write-wins inference, or provider-authored supersession. Both remain separately attributed context unless an independent kernel-owned canonical source makes one inadmissible.
8. Kernel canonical state, user input, policy, tool state, and operator configuration always outrank strategy material. A contribution cannot override them even if its identity or text resembles them.

The provider supplies source times and revisions; the kernel derives effective freshness as fresh, stale, or unknown against the profile's immutable maximum age, required revision/cursor, valid_until, snapshot time, and clock-skew bound. Missing or contradictory metadata is unknown, not fresh. A required position whose policy requires fresh material fails closed on stale/unknown data. An optional position follows only its declared skip, accept_attributed_stale, or accepted_cache degradation rule.

kernel_instruction/system authority and user_request authority are reserved to kernel-owned sources and cannot occur in a contribution. The kernel clamps effective authority to the least authoritative of the provider claim, profile ceiling, verified source class, freshness outcome, and sensitivity/policy result. A provider cannot raise authority by labeling retrieved content as workflow guidance. Untrusted or externally derived payloads are rendered through the kernel's data-isolation wrapper and remain non-instructional.

Budgeting, rendering, and final truncation

Budgeting is deterministic and performed before provider invocation. All sizes use canonical UTF-8 bytes and one kernel-selected token estimator/version recorded in the snapshot. Provider token counts are diagnostics only.

For each assembly, the kernel:

1. derives one hard input ceiling from the exact selected model candidates and the applicable model input/context limits;
2. subtracts the configured output reserve, protocol/serialization reserve, selected tool schema budget, native attachment admission, and the kernel-mandatory reserve for identity/safety/policy, current user content, conversation checkpoint, pending approvals/tool state, and minimum recent transcript continuity;
3. fails with canonical context_budget_unavailable before provider invocation if those non-strategy requirements cannot fit safely;
4. treats the remainder as the strategy pool;
5. sums every required position's configured minimum independently for item, UTF-8 byte, and estimated-token dimensions and fails with context_budget_unavailable before any position allocation or invocation when any required reserve exceeds its strategy-pool dimension;
6. reserves each required position's minimum in every dimension first. Optional positions have no required reserve and therefore cannot consume capacity needed by any required position;
7. visits positions in configured order and allocates remaining capacity in each dimension up to that position's configured cap after subtracting its existing required reserve;
8. fixes every allocation in the immutable assembly plan and request before any result is observed. Unused or failed-position allocation is not redistributed to later positions in C0 v1; an optional zero allocation is an attributed budget skip.

Each allocation has item, UTF-8 byte, estimated-token, and per-item limits. A strategy must return a complete bounded result; it must not choose final prompt truncation. A result that exceeds its allocation after kernel recomputation is a position protocol violation and follows that position's required/optional rule. C0 v1 does not truncate a contribution or define provider-authored structural boundaries.

Final rendering maps semantic slots to kernel-owned wrappers and prompt roles. The mapping is versioned and recorded; target_slot is not a role request. The kernel applies redaction and authority wrappers before model use, then recomputes final serialized size.

If the final representation is still over its ceiling, the kernel applies the recorded final-truncation policy in this order:

1. run existing deterministic old tool-result pruning without changing the durable transcript;
2. omit whole optional strategy contributions from the last configured position and last ordinal backward;
3. reduce only the oldest non-protected prompt-visible transcript tail while preserving the checkpoint and most recent coherent user/assistant boundary;
4. trigger kernel-owned compaction when its preconditions and deadline allow, then rebuild under the same turn profile snapshot;
5. return canonical context overflow if required strategy contributions, kernel authority, selected tool schemas, current user content, pending safety state, and required minimum recent transcript still cannot fit.

Required strategy contributions, kernel authority, current user text, pending approvals/tool state, and the minimum recent transcript are protected. Native attachments are admitted or helper-summarized before assembly under existing size policy. Every whole-contribution omission and kernel-owned transcript pruning action records source, original/accepted size, reason, position, and payload digest where applicable in the kernel-owned context outcome.

Deadlines, cancellation, failure, and recovery

The parent turn supplies one absolute settlement deadline. Each immutable assembly plan gives every position an absolute invocation deadline no later than that parent deadline and reserves kernel assembly/model time. A provider cannot extend either deadline. Independent positions may start concurrently; result ordering remains configured order.

The kernel propagates parent cancellation immediately, stops accepting new results, and terminates the assembly with the canonical cancelled outcome. Parent cancellation is never converted into an optional skip or required-context failure. Providers acknowledge cancellation and release ephemeral work within their declared lifecycle bound. Late output is discarded and recorded safely. At the parent settlement deadline, the kernel stops waiting and creates the canonical outcome; provider activity cannot hold the turn open.

Each position declares one requirement class for contribute:

• required: missing eligibility, startup failure, unhealthy/unavailable capability, timeout, a position-local cancellation while the parent remains active, invalid result, empty result when disallowed, freshness failure, conflict, or cache failure makes the assembly fail closed;
• optional: the same event produces only the profile-declared attributed skip, accepted stale-cache outcome, or degraded empty contribution. It never silently becomes required and never changes position;

Independently, at most one position may be designated as the compaction proposer with a proposal_required or proposal_optional rule. Designation does not change that position's contribute requirement class.

Position-local failure, timeout, cancellation while the parent remains active, or an empty result must not reorder positions, transfer budget, promote authority, or invoke an alternate provider. C0 v1 has no provider fallback list and no rebind after snapshot creation. A provider cannot nominate a fallback. A required strategy's failure cannot be converted to the output of a lower-priority implementation.

A transport retry is allowed only when the snapshot contains an exact finite retry count and backoff schedule, the parent deadline still permits it, and the provider proves contribute/proposeCompaction idempotency. It uses the same binding, request ID, snapshot time, input digests, and bounds. It does not create a new binding or refresh source time. The kernel owns retryability; provider retry hints are non-authoritative.

No shared cache is required by C0. If a later implementation uses one, it stores a kernel-normalized CachedContextResult, not a reusable ContextContribution envelope. The result contains an ordered list of CachedContextPayload records and preserves each record's validated ordinal and the exact accepted result digest; cache storage or retrieval order has no authority. The cache key contains at minimum provider kind, exact binding, implementation release, configuration revision, profile revision/position, operation, input digest set, scope, redaction-policy revision, and output-contract digest. Each normalized payload record omits prior request, assembly, and contribution identities while retaining its validated ordinal, payload, provenance, source revision, freshness inputs, sensitivity, authority claim, target slot, payload digest, and creation time. Tenant/agent/workspace isolation and encryption/retention policy apply. Secret-bearing raw content is not cacheable.

A cache hit is accepted only when the profile explicitly permits it and the kernel revalidates binding, scope, result digest, complete ordinal sequence, per-payload digest, freshness, sensitivity, authority, target slot, and current policy. The kernel then creates fresh contribution envelopes with the current ContextAssemblyId, request identity, binding identity, contribution identities, and recomputed digest/size evidence while retaining the exact validated ordinal sequence. Missing, duplicate, reordered, or conflicting cached ordinals reject the cached result. Stale cache use is always attributed as stale in context reports and model wrapping; it cannot satisfy a fresh-required position. Cache miss/corruption follows the position's existing required/optional rule. Cache never authorizes fallback, reordering, extra budget, or a new source of truth.

For durable-turn recovery, the kernel uses the exact recorded snapshot. It may replay a previously accepted result digest under its retention policy or repeat the same idempotent request through the exact binding. It never reruns current selection. If an exact release/configuration/peer or retained required result is unavailable, recovery reports binding unavailable or required-context failure. A new ProviderActivationId may serve the same immutable ProviderBindingId under D1; provider activation identity never rewrites strategy selection.

Compaction proposal boundary

C0 permits at most one profile position to declare compaction_proposer for a turn. Multiple designated proposers are a profile conflict and fail before binding. Compaction is not ordered merging of competing summaries; this restriction avoids turning position order into transcript truth.

The kernel creates a separate ContextCompactionOperationId and supplies the designated proposer only:

• exact binding/snapshot/profile identities and an idempotent request identity;
• the previous typed checkpoint, if any;
• the exact ordered dropped message IDs and a bounded redacted projection of those messages;
• kernel-extracted critical identifiers and relevant-file candidates that must be accounted for;
• required checkpoint fields, output bounds, snapshot time, absolute deadline, and cancellation;
• source provenance/sensitivity/authority labels for every projected input.

The previous checkpoint and dropped message range are therefore explicit, bounded request inputs rather than provider-selected history.

Pending approvals and pending tool state remain kernel-owned and are not entrusted to a summary for preservation. The kernel independently reconstructs and carries them forward. The strategy cannot call memory write, perform a pre-compaction flush, choose dropped/kept boundaries, change recent-message IDs, or delete transcript.

proposeCompaction returns one typed CheckpointProposal with every current checkpoint field, exact covered message IDs, proposal digest, source references for critical claims, and safe diagnostics. The provider proposal is not canonical conversation state. The kernel validates schema, exact coverage, critical identifiers, unsupported additions, size, redaction, binding, and deadline. It may reject or audit-retry the same idempotent request only under the fixed retry rule.

Only the kernel can commit the accepted checkpoint, compacted-through message ID, recent-message IDs, pending approvals, pending tool state, update timestamp, canonical result, context report, and audit event. Compaction changes prompt visibility; it does not delete or rewrite the append-only retained transcript.

The current deterministic fallback checkpoint remains kernel-owned. Under the default compatibility profile it may be used when the optional proposer is absent, times out, fails, or returns an invalid proposal, with reason=fallback recorded. A future profile that requires an accepted proposer must fail closed without advancing compaction state. Fallback cannot invent approval/tool state, promote memory, or become a silent provider substitution.

Privacy, redaction, and observability

Every request uses least-privilege input projection. The kernel authorizes each source and field for the exact tenant, agent, workspace, conversation, turn, binding, deployment mode, and target model before projection. A context strategy receives no ambient database, transcript, filesystem, network, environment, credential, tool, attachment-store, memory, or WorkBoard authority by virtue of registration. In-process trust does not weaken the logical contract; out-of-process modes also satisfy all D1 authentication, channel, replay, correlation, cancellation, and message-bound requirements.

Secret values must not enter descriptors, profiles, snapshots, contributions, caches, status, health, metrics, provider logs, provider-native errors, context reports, or audit. C0 has no secret slots by default. A later strategy-specific need would require an explicit named slot, kernel resolution after governance/binding, and proof that no returned payload or diagnostics can disclose it; this contract authorizes none.

The kernel treats provider payload as untrusted until shape, scope, digest, provenance, freshness, sensitivity, authority, and bounds pass. Existing redaction applies before cache, persistence, provider-trust-boundary crossing where required, model use, operator display, diagnostics, and canonical audit. sensitive material is admitted only when policy and the target model boundary permit it. A provider cannot lower sensitivity; the kernel may raise it from source evidence or reject an inconsistent claim.

Canonical context reports record, per snapshot/position/contribution, only safe identities and metadata: selected binding/release/profile, outcome, provenance reference, freshness result, sensitivity, effective authority, target slot, original/accepted size, duplicate/conflict, cache status, deadline/cancellation, truncation, and omission reason. Existing system/user/tool-schema/injected-file accounting remains kernel-owned. Raw private/sensitive payload, raw provider errors, credentials, and stack traces do not enter canonical audit. Providers may emit bounded telemetry, but the kernel creates every canonical event after validation and redaction.

Health, lifecycle, and conformance

A C0 descriptor declares kind-specific capabilities without claiming current health:

• contribute_text and the exact supported target slots;
• optional propose_compaction;
• maximum request/input/output bytes, items, and concurrency;
• source revision/freshness evidence classes;
• supported sensitivity and authority-claim classes;
• idempotent replay, cancellation, and optional cache behavior;
• admitted D1 trust/deployment/protocol modes.

Registered, configured, compatible, conforming, ready, healthy, and capable remain independent D1 axes. Runtime capability is evaluated per operation/slot and exact profile bounds. A required new turn may bind only when every required position is eligible. An optional position may bind while degraded only when its profile explicitly permits the resulting operation and attributed degradation. Unknown/stale health never silently satisfies a fresh-required capability.

Health changes must not rewrite an active snapshot. After binding, the kernel waits, cancels, skips, uses an admitted cache result, or fails according to the pinned position rule. It does not rebind or move a contribution. Gateway shutdown rejects new snapshots, cancels/drains active requests within bounded deadlines, stops activations under D1 reference accounting, and records unsettled provider cleanup truthfully. A strategy must not create untracked durable subscriptions, processes, or remote resources.

Built-in and external implementations run the same common D1 suite and C0 provider-kind suite. Delivery-specific fixtures may add checks but cannot remove outcomes. Exact-release conformance is bound to implementation ID/version, contract version, descriptor, ProviderReleaseId, configuration schema, admitted deployment/protocol mode, and suite version; provider self-report is insufficient.

C0 conformance covers deadline, cancellation, and failure behavior as first-class outcomes. It must prove at least:

• agent-profile scope resolution, duplicate/missing profile rejection, exact ordered snapshot, and model exclusion;
• discovery/registration/response-order permutations do not alter ordering;
• provider self-priority, attempted reordering, cross-position observation, and alternate-provider fallback are rejected;
• strict request/result schemas, scope isolation, digest validation, provenance, freshness, sensitivity, authority clamping, and data wrapping;
• duplicate ID, kernel-derived dedupe identity, unauthorized-source isolation, identical duplicate, conflicting duplicate, semantic non-merge, and required/optional conflict outcomes;
• deterministic required-minimum reservation without optional starvation, no redistribution, byte/token estimator versioning, whole optional omission, no required-contribution truncation, final overflow, and context-report evidence;
• deadline, cancellation, late output, finite same-binding idempotent retry, optional degradation, required fail-closed behavior, cache isolation, stale attribution, and exact recovery;
• mutation attempts against transcript, conversation state, policy, approvals, memory, WorkBoard, tool exposure/schema, system authority, final prompt, report, or audit have no effect and are rejected;
• compaction coverage, unsupported fact detection, critical-identifier audit, no canonical commit by the provider, pending-state preservation, deterministic fallback, and retained transcript truth;
• built-in and external fixtures produce equivalent canonical outcomes for the same typed inputs.

Error specialization

C0 specializes D1 with safe kind-specific reasons:

Code	Meaning
context_profile_invalid	No single valid effective agent context profile or ordered position map exists.
context_strategy_required_unavailable	A required position is not eligible or cannot provide its required minimum.
context_strategy_protocol_violation	A strategy violated binding, schema, scope, digest, order, bounds, replay, or authority rules.
context_strategy_deadline_exceeded	The position did not return a valid result by its absolute deadline.
context_strategy_cancelled	The kernel cancelled the request; later output is inadmissible.
context_contribution_conflict	Equal kernel-derived ContextDedupeIdentity values carried different payload digests.
context_contribution_stale	Freshness policy rejected stale or unknown material.
context_budget_unavailable	Kernel-mandatory material or a required position minimum cannot fit.
context_compaction_proposal_invalid	Proposal schema, coverage, support, bounds, or critical-identifier audit failed.
context_strategy_cache_unavailable	An explicitly admitted cache path could not supply a valid bound result.
context_strategy_binding_unavailable	Exact snapshot/binding recovery cannot restore required strategy identity.

Provider-native diagnostics cannot determine retryability, fallback, authority, prompt text, or user-visible error. The kernel normalizes and redacts them.

Built-in parity and compatibility

C0 does not assume that every current source is a provider seam. C1 may introduce built-in adapters only where a replaceable read/derive boundary is real and conformance can preserve behavior.

Conversation state and the recent transcript tail remain kernel-owned. Tool exposure and every tool schema remain kernel-owned as well.

Current context behavior	C0 ownership and compatibility rule
Identity/persona, prompt contract, runtime facts, data-tag safety, and sandbox posture	Remain kernel-owned system prompt authority. They are not strategy contributions.
Policy-filtered tool exposure, tool schemas, tool guidance, approval state, and guardian mode	Remain kernel-owned. A strategy cannot add, remove, describe around, or grant a tool.
Conversation-state checkpoint, pending state, recent transcript tail, current user request, and native attachments	Remain kernel-owned canonical/input material. A strategy never becomes transcript or user authority.
Skill loading and effective-tool filtering	A candidate built-in skill_guidance strategy only if C1 preserves source provenance, workspace-trust filtering, effective-tool filtering, labels, authority clamp, and section order. Otherwise it remains kernel code.
Ordered pre-turn memory recall	Remains kernel-owned context material produced from an admitted M0 query. C0 does not route it through a pass-through strategy. A later distinct transformation boundary requires its own accepted contract change. MCP metadata remains transport/capability metadata, not C0 admission.
WorkBoard focus digest	A candidate work_context strategy. WorkBoard records and status truth remain kernel-owned; failure preserves the current attributed unavailable behavior.
Attachment helper analysis	A candidate attachment_context strategy. Upload admission, artifact authorization, native file parts, download limits, history rewriting, and final model input remain kernel-owned.
Automation digest	A candidate automation_context strategy. Operator schedule identity/directive and delivery semantics remain kernel-owned.
Governed tool results and fs.read workspace-file injection	Remain kernel-owned message/tool context and context-report evidence. C0 grants no ambient workspace scan or hidden file injection.
Deterministic tool-result pruning and message capping	Remain kernel-owned final assembly/truncation behavior, not a provider strategy.
Model-generated checkpoint summary	A candidate built-in compaction proposer. Dropped/kept boundaries, validation, deterministic fallback, checkpoint commit, recent IDs, pending state, transcript retention, and audit remain kernel-owned.
Context reports	Remain canonical kernel outcomes. Provider telemetry is input evidence only.

The first compatibility profile must preserve existing effective agent configuration, fixed prompt section labels/order, model-facing prompt roles, tool IDs and schemas, conversation identity, checkpoint and recent-tail behavior, memory/work/attachment semantics, context-pruning behavior, context-report visibility, and current failure posture unless a separate contract change is accepted. Strategy identity, bindings, profile fields, provider diagnostics, and ordering controls are not added to model-facing requests or tool results.

Built-in and external strategies use the same registration, compatibility, configuration, selection, ordered binding, lifecycle, health, budget, privacy, and C0 conformance path. “Built-in” supplies delivery provenance only. A built-in cannot bypass authority clamping, bounds, duplicate/conflict handling, cancellation, or exact-release evidence.

Contract/implementation versions follow D1 semantic-version rules. Incompatible releases remain visible as unavailable and never bind. A profile revision pins exact releases. Configuration changes apply only to new turn snapshots; dynamic hot reload into an active snapshot is forbidden. Rollback may select a previously admitted compatibility profile only for new turns. It cannot rewrite an in-flight or recovered turn snapshot or silently remove a required position.

This contract creates no schema or migration, no registry service, no marketplace, no hot reload, no rollout, and no provider code. Existing runtime behavior remains the only implemented default until separately accepted C1/C2 work proves compatibility.

Accepted decisions and adoption boundary

C0 acceptance confirms that:

• ordered-many selection has one exact agent profile scope and immutable kernel-owned position snapshot;
• every contribution has bounded typed payload, provenance, source revision, freshness inputs, sensitivity, authority claim, slot, digest, and deterministic duplicate/conflict behavior;
• budgets, merge order, rendering, pruning, truncation, deadline, cancellation, failure, cache, and recovery cannot be influenced by provider timing or priority;
• system authority, tools, transcript truth, current user input, conversation state, compaction commit, canonical outcomes, reports, and audit remain kernel-owned;
• optional degradation is explicit and required positions fail closed without fallback or reordering;
• built-in parity preserves current model-facing behavior without forcing false strategy boundaries;
• no provider substrate, persistence mechanism, schema, migration, registry, marketplace, hot reload, or rollout has entered scope.

No material C0 semantic rule is left to implementation convention. Two implementation boundaries remain outside this contract's authorization:

1. M0 defines the primary-memory recall envelope, consistency, and freshness evidence. The kernel admits that recall directly as kernel-owned context; C0 does not introduce a pass-through strategy boundary. A later distinct transformation requires a contract change.
2. C1 evidence must decide which candidates (skill_guidance, work_context, attachment_context, automation_context, supplemental_context, and model compaction proposal) are real strategy adapters. Identity/system authority, tools, canonical conversation material, primary-memory recall, native attachments, pruning, final assembly, and checkpoint commit are not candidates.

These accepted boundaries do not authorize S0 or implementation. ARCH-29 records C0 as Accepted. With I0, M0, and C0 accepted, S0 is dependency-eligible but remains Planned and Not started until separately scoped and accepted. D1, I0, and M0 remain Accepted and are not changed here.

Related docs

• ARCH-29 policy-owning provider microkernel
• D1 kernel invariants and provider control-plane contract
• I0 typed isolation-provider contract
• Context, Compaction, and Pruning
• Transcript, Conversation State, and Prompt Context
• Memory
• Work board and delegated execution
• Sandbox and policy