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