Make profile runtime readiness explicit

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0233b-178d-7162-b92f-31a31ea8ca9b

docs/execution-profiles.md

@@ -20,7 +20,10 @@ ExecutionEvidence -> assignment/audit consumers
 
 Each YAML document under `profiles/` declares:
 
-- stable `id`, semantic `version`, exact `contract_version`, and status;
+- stable `id`, semantic `version`, exact `contract_version`, and catalog
+  enablement status;
+- typed operational readiness (`ready`, `unverified`, or `blocked`) with its
+  reason, owner, and evidence reference;
 - rein registry ID and required capabilities;
 - sand-boxer `sandbox_profile`;
 - rein-enforced `tool_profile`;
@@ -35,6 +38,20 @@ enabled revision exists. Inline secrets and token-looking values are refused.
 
 Use `glas-harness profiles` as the catalog/packaging validation command.
 
+Catalog enablement and operational readiness answer different questions:
+
+- `status: enabled` permits deterministic selection after schema and rein
+  compatibility checks;
+- `operational_readiness.status: ready` requires a positive `evidence_ref`;
+- `unverified` permits a bounded proof attempt but is carried into execution
+  evidence and must not be described as ready; and
+- `blocked` requires an owner plus evidence reference and is refused during
+  resolution, before sandbox creation.
+
+Profiles that predate the field default conservatively to `unverified`. The
+catalog command lists all enabled profiles and labels readiness; it does not
+filter blocked profiles or call them executable.
+
 Catalog validation proves schema/compatibility, not transport installation. An
 execution host must install `glas-harness` with sand-boxer support and make each
 selected rein plus its dependencies available *inside* the sandbox transport,
@@ -44,6 +61,11 @@ also needs its documented `rein-aharness[llm]`/sibling `llm-connect` adapter
 dependency in that environment. Missing runtime dependencies fail closed at
 session start and still trigger sandbox teardown.
 
+The committed local profiles are currently declared `blocked` by
+`GLAS-IN-0002`. The remote profile is `unverified` because there is no positive
+post-hardening execution proof. There is currently no committed `ready`
+profile.
+
 ## Consumer request
 
 See `examples/execution-request.json`. Consumers know only a profile reference,
@@ -59,7 +81,7 @@ The current exact-profile path does not interpret resource envelopes or choose
 profiles from requirements. A future requirements resolver belongs at this
 Glas boundary, must be deterministic and explainable, and must refuse ambiguity.
 
-## Two equivalent selections
+## Two parallel local selections
 
 For the same task and organizational references, switch only:
 
@@ -71,9 +93,11 @@ harness.agent-dev-openweights-local@1.0.0
   -> rein-openweights / qwen/qwen-2.5-72b-instruct / profile.bwrap-local
 ```
 
-Both use `green-commit-only` and return `GatewayResult` / `ExecutionEvidence`.
-This proves interchangeability at the Glas boundary; it does not claim the
-models have identical quality, price, or provider behavior.
+Both declare `green-commit-only` and the same outer `GatewayResult` /
+`ExecutionEvidence` contract. They are interchangeable as catalog shapes, but
+both are currently operationally blocked and refused before sandbox creation.
+This does not claim current runtime availability or identical model quality,
+price, or provider behavior.
 
 ## Ownership handoff
 

docs/harness-contract.md

@@ -32,6 +32,13 @@ The gateway returns `GatewayResult` with:
 Raw prompts, model output, tool output, and credential material are excluded
 from the State Hub detail.
 
+`HarnessProfile.status` governs catalog selection. The separate
+`OperationalReadiness` model records runtime status, a reason, its owner, and
+an evidence reference. `ready` requires positive evidence; `blocked` requires
+an owner and evidence and is refused during resolution before sandbox
+creation; `unverified` permits only a labeled proof attempt. The selected state
+is copied into `ResolvedExecutionContext` and `ExecutionEvidence`.
+
 ## Rein lifecycle
 
 ```python
@@ -99,7 +106,8 @@ remain rein-local under ADR-002.
 
 The gateway returns evidence for every normal refusal/failure path:
 
-- `resolution`: unknown, disabled, ambiguous, incompatible, or unsafe profile;
+- `resolution`: unknown, disabled, ambiguous, incompatible, operationally
+  blocked, or unsafe profile;
 - `sandbox_create`;
 - `session_start`;
 - `execution` (including a rein-declared unsuccessful result);

docs/intakes/residuals.md

@@ -147,7 +147,7 @@ id: GLAS-IN-0005
 kind: intake
 title: "Separate profile selection enablement from runtime readiness"
 lane: red
-status: todo
+status: done
 priority: high
 owner: glas-harness
 repo: glas-harness
@@ -168,3 +168,9 @@ description: |
   fallback or claim readiness from lifecycle-only proof.
 state_hub_intake_id: "01a02dce-b761-75e6-861a-8abf8b8e0072"
 ```
+
+Completed by `GLAS-WP-0008` on 2026-08-23. Catalog enablement is now separate
+from typed operational readiness. Both local profiles are `blocked` by
+`GLAS-IN-0002` and refuse before sandbox creation; the remote profile is
+`unverified` and may be used only for a labeled bounded proof attempt. Catalog
+and execution evidence expose the state, and no host fallback was added.