QICR / Plane 2

QICR Plane 2

Plane 2 is the soft field: a content-addressed adapter registry with deterministic selection and sealed ADAPTER_SELECTION records. Plane 1 remains the only permission layer.

Mechanism adapter registry

Plane 2 manifests are hashed with SHA-256 over canonical JSON and looked up deterministically by horizon, route, and policy version.

Boundary Plane 1 only

The adapter selection is sealed into the chain before CANDIDATE_ACTION. evaluateQicrCandidate is unchanged and remains the only verdict path.

Evidence sealed selection

ADAPTER_SELECTION records sit alongside CANDIDATE_ACTION, IMMACULATE_DECISION, ACTION_COMPLETE, and TAMPER_CHECK. Tampering localizes at the altered record.

Route governed

What Plane 2 Adds Publicly

Plane 2 narrows the candidate distribution Q emits, conditioned on a content-addressed adapter manifest. The selection is auditable, not authoritative. The thesis (QICR design v0.2, June 2026) names this as the 'governed processor lanes' framing for the soft field.

  • Manifests are SHA-256 content-addressed; same logical manifest re-exported with different key order has the same hash.
  • Selection rule in v0 is closed: deterministic-first-match over a lex-sorted manifest list.
  • No matching manifest returns a null selection (no-bias fallback) — the runtime never crashes on a missing adapter.

Route governed

What Plane 2 Does Not Do

Plane 2 cannot loosen a Plane 1 DENY. The two-plane separation is enforced architecturally, not by convention. A bias-toward-grant adapter cannot turn an unregistered-route DENY into an ALLOW. The selection record is sealed so a verifier can prove which conditioning was active for any decision.

  • Plane 2 changes the proposal distribution; it does not vote on the verdict.
  • Bias vector values are not sealed — only the manifest hash and lookup tuple are recorded.
  • Operator authors manifests in the Immaculate harness under apps/harness/adapters/ and supplies them per-call via plane2Manifests.

Route governed

Related

The QICR runtime has three public surfaces. The other two are:

  • QICR overview (/qicr): the two-plane separation, the sealed chain, and the public commitment.
  • Verifiable Rewards (/qicr/verifiable-rewards): governance-decision records as a training signal (Goodhart / coverage / sparsity).

Route governed

What You Can Do Now

Plane 2 v0 ships the registry, the sealed-selection record, the bias-vector consumer, the activation-budget machinery, and the cross-host chain-anchor substrate. Operators can author manifests under apps/harness/adapters/ and supply them per-call via the plane2Manifests field when orchestrating against the QICR runtime (provisioned through Aura Genesis at https://aura-genesis.org/qicr — not hosted on this IORCH surface). The selector is deterministic, the bias application is provably a function of the sealed manifest, and the Phase 4 replicated verifier lets a peer re-verify a chain from the custody lane without trusting the original host.

  • Author a manifest: copy apps/harness/adapters/q-read-base.adapter.json, set adapterId / routeId / horizons / policyVersions / purpose, and add an optional biasVector + activationBudget.
  • Wire a runQicrCycle call: pass plane2Registry: [manifest, ...] to the harness and the runtime seals ADAPTER_SELECTION + BIAS_APPLICATION for each candidate.
  • Promote: ADAPTER_SELECTION.rationale='aggregate_budget_exhausted' is the canonical evidence for 'this adapter was active for this goal, then the budget hit'. The BIAS_APPLICATION.skipped field now mirrors the budget reason so the bias record itself is self-describing.
  • Verify cross-host: publish anchors via FileSystemQicrCustodyStore (local) or CloudflareR2QicrCustodyStore (production), then run verifyQicrChainFromCustody on a peer's chain.