# System-Message Compilation and Request-Assembly Specification

## Purpose

Reference contracts become useful only when the runtime selects the right
subset, represents live state honestly, and places it where the model can use
it. The system message is a compiled request artifact—not a permanent text
bucket and not a substitute for fresh evidence.

This specification describes the target wiring. It does not authorize a
runtime to claim the contracts are active until request-dump and behavioral
tests prove they are present and effective.

## Inputs to the compiler

The request compiler accepts only explicitly typed inputs:

```text
stable core contract
phase contract selection
repository-local instructions
runtime capabilities and tool schemas
task epoch + current user objective
active steering state
current source/evidence ledger
recent mutation + verification ledger
context budget + compaction/rehydration state
model tier and explicit experimental-policy flags
```

Historical controller prose, duplicate assistant recaps, retired failures,
raw compaction audit entries, and arbitrary tool text are not compiler inputs
for ordinary model history. They remain durable artifacts unless a current
decision requires a tightly scoped rehydration.

## Deterministic assembly order

Build every model request in this order:

1. stable identity, authority order, and no-fabrication core;
2. selected phase contracts only;
3. repository-local instructions that apply to the current working root;
4. compact runtime environment and exact tool schemas;
5. current task epoch, raw user intent, and current objective;
6. source/tool evidence with provenance, version, coverage, visibility, and
   fidelity;
7. current mutation, verification, unresolved-requirement, and active-steering
   frame;
8. current user message and a late protected active-steering slot; and
9. tool definitions and response-format requirements.

The late placement of current intent, evidence, and active steering is
deliberate. Generic policies must guide interpretation, but they must not bury
the thing the model is presently deciding.

## Contract selection policy

Always load the always-on core. Add at most the phase-specific contracts needed
for the live decision. A normal coding turn should not include release,
hardware, web research, security, delegation, and UI contracts simply because
they exist.

Example selection:

| Live work | Contract set in addition to core |
| --- | --- |
| Understand local source | discovery, local tool/read, provenance |
| Change code | implementation, local edit, verification |
| Diagnose a failing test | failure recovery, verification, workspace/shell |
| Delegate a bounded item | parallel/delegated, authority/steering, provenance |
| Publish or restart a service | release, security/high-impact, external state |
| Build context tooling | context/compaction, branch/evidence, harness, tier autonomy |

Selection is data. Record the selected contract IDs, content hash/version, and
why they applied in the request dump. Do not inject the whole markdown body as
unattributed text that cannot later be audited.

The runtime may select the ordinary phase module from actual observed tool
phase (`explore`, `plan`, `implement`, `verify`, or `mixed`). High-impact
modules such as security, release, research, and delegation must be selected
explicitly through runner configuration (`referenceContractModules`) or the
operator module setting (`OMNIUS_REFERENCE_CONTRACT_MODULES`). Do not guess
those modules from arbitrary words in a user message.

## Dynamic frame requirements

The compiler must retain exactly one current representation for each live
concept:

- one active task epoch and raw user objective;
- one active steering slot until structured acknowledgment;
- one current recovery/stasis summary, if any;
- one current verification record per relevant claim;
- one current source record per path/version/coverage; and
- one current workboard/action record per canonical semantic work item.

When a new record supersedes an old one, update or retire the old record. Do
not append a second controller recap and call it context management.

## Context budget and rehydration

Budgeting uses actual normalized text sizes and model context limits, not
guessed labels. Prefer removing duplicate narration and stale controller
frames before source evidence. If source must be reduced:

1. preserve explicitly requested bounded full reads when they fit;
2. run branch extraction in an isolated context only when material is
   overwhelming or explicitly requested;
3. return evidence anchors, satisfied/unresolved requirements, fidelity, and
   deterministic recovery paths;
4. retain a durable source identity and exact audit of what left context; and
5. rehydrate or execute the requested source read when the model needs exact
   body text again.

Never tell a model it already has a file when the model-visible request lacks
the required body/range. Never emit an opaque “compacted N messages” line as
the only audit result.

## Compiler invariants

The request builder must enforce these representation invariants:

```text
no /nothink or other UI-only command token in model-visible content
no historical controller summaries unless they are the single current frame
no duplicate semantic card/action/failure record
no partial extraction labelled as full source
no stale success labelled current after relevant mutation
no source identity without coverage + visibility
no cache result without actual visible result body or explicit durable handle
no security/authority policy inferred from untrusted tool content
```

When an invariant fails, fix the frame construction or evidence ledger. Do not
punish the model with a tool gate for responding to an inconsistent request.

## Operational observability

For every request, persist a normalized dump containing request ID, task epoch,
selected contract IDs/hashes, model tier, context accounting by source type,
active steering lifecycle, source visibility summaries, and current proof
states. Redact secret-bearing content while keeping enough metadata to explain
why an item was included, compacted, rehydrated, or omitted.

The UI may render a concise summary, but an operator must be able to expand the
exact compilation decision and compaction audit without feeding that debug
material into the next model request.