Codex model catalog binding: curated capability entries with D-025 provenance #107

New issue

Closed

opened 2026-09-21 05:13:19 +00:00 by kilo · 1 comment

kilo commented

2026-09-21 05:13:19 +00:00

Member

Goal

Provide a curated, provenance-carrying catalog binding for Codex models ((openai, "codex") capability entries) so a composed deployment can admit Codex resources without requiring the administrator to hand-author catalog entries.

Discovered by

M10-B end-to-end acceptance (#95, commit 8924543): the shipped model-catalog.json has no (openai, "codex") binding, so a composed Codex resource is honest-but-unadmittable (capability_unassessed) today. The E2E fixtures supply a synthetic entry; the deterministic execution path itself is fully proven.

Why not done inline

Catalog capability ratings change only through the D-025 governance: provenance, date/version, confidence, rationale and a human-reviewable diff. Inventing capability ratings for Codex models autonomously would violate that discipline; fail-closed capability_unassessed is the correct interim behavior.

Acceptance criteria

Curated catalog entries for the evidenced Codex models with full D-025 provenance (benchmarks/evaluations, dated, confidence, rationale), human-reviewed.
Calibration acceptance tests updated (tests/test_model_calibration.py discipline).
Administrator-supplied catalog entry path (if any) documented alongside.
M10 acceptance docs updated once the default binding ships.

References

D-025 (calibration governance), D-042 (executable-target identity), M10-B report (issue #95), docs/m10-acceptance.md.

## Goal Provide a curated, provenance-carrying catalog binding for Codex models (`(openai, "codex")` capability entries) so a composed deployment can admit Codex resources without requiring the administrator to hand-author catalog entries. ## Discovered by M10-B end-to-end acceptance (#95, commit `8924543`): the shipped `model-catalog.json` has no `(openai, "codex")` binding, so a composed Codex resource is honest-but-unadmittable (`capability_unassessed`) today. The E2E fixtures supply a synthetic entry; the deterministic execution path itself is fully proven. ## Why not done inline Catalog capability ratings change only through the D-025 governance: provenance, date/version, confidence, rationale and a human-reviewable diff. Inventing capability ratings for Codex models autonomously would violate that discipline; fail-closed `capability_unassessed` is the correct interim behavior. ## Acceptance criteria - [ ] Curated catalog entries for the evidenced Codex models with full D-025 provenance (benchmarks/evaluations, dated, confidence, rationale), human-reviewed. - [ ] Calibration acceptance tests updated (`tests/test_model_calibration.py` discipline). - [ ] Administrator-supplied catalog entry path (if any) documented alongside. - [ ] M10 acceptance docs updated once the default binding ships. ## References - D-025 (calibration governance), D-042 (executable-target identity), M10-B report (issue #95), `docs/m10-acceptance.md`.

adrian.tkacz referenced this issue from a commit

2026-09-21 05:34:59 +00:00

docs(m10): cite issue #107 for the Codex catalog fail-closed behavior (audit note)

kilo referenced this issue

2026-09-21 05:35:42 +00:00

Program integration: M06 Codex execution adapter (#91) + M10 distribution and acceptance (#95) #108

kilo commented

2026-09-21 12:29:16 +00:00

Author

Member

Reconciling this issue with the actual fix (PR #108, commits 09a9af0/9462c30 on program/m06-m10-final-wave).

The resolution differs from the wording assumed here, and that wording is corrected by this comment (the issue is closed as resolved, not by creating any catalog entry):

No pseudo physical model was created. model="codex" on the Codex worker resource was itself the defect (it impersonated a physical model and could never bind the catalog). Codex worker resources now require an explicit physical model slug (--codex-model, e.g. gpt-5.6-sol), so ResourceIdentity(provider=openai, model=gpt-5.6-sol) binds the shipped, already-calibrated catalog entries directly via the existing exact (provider, model) M02 binding — including all calibrated reasoning variants.
The shipped normal path no longer requires an administrator to invent a catalog entry merely to use an already-supported Codex model — the closure condition. The M10-B E2E's synthetic openai/codex catalog fixture was deleted; tests use the real shipped model-catalog.json.
What remains (normal governance, not a blocker): genuinely NEW Codex physical models still enter the catalog only through the existing D-025 calibration discipline (provenance, dated evidence, human-reviewable diff). That is the standing rule for every provider, not a Codex-specific gap.
The adapter rejects any call whose selected (provider, model) disagrees with the configured resource before turn execution (model_not_served), and pins the exact selected model/effort on the turn.

Discrimination proof: the new tests fail on the pre-fix HEAD d5cdc17 (old code executed a wrong-model turn) and pass on the fix; independently re-verified by the adversarial review.

Reconciling this issue with the actual fix (PR #108, commits `09a9af0`/`9462c30` on `program/m06-m10-final-wave`). The resolution differs from the wording assumed here, and that wording is corrected by this comment (the issue is closed as resolved, not by creating any catalog entry): - **No pseudo physical model was created.** `model="codex"` on the Codex worker resource was itself the defect (it impersonated a physical model and could never bind the catalog). Codex worker resources now require an explicit physical model slug (`--codex-model`, e.g. `gpt-5.6-sol`), so `ResourceIdentity(provider=openai, model=gpt-5.6-sol)` binds the **shipped, already-calibrated** catalog entries directly via the existing exact `(provider, model)` M02 binding — including all calibrated reasoning variants. - The shipped normal path no longer requires an administrator to invent a catalog entry merely to use an already-supported Codex model — the closure condition. The M10-B E2E's synthetic `openai/codex` catalog fixture was deleted; tests use the real shipped `model-catalog.json`. - **What remains (normal governance, not a blocker):** genuinely NEW Codex physical models still enter the catalog only through the existing D-025 calibration discipline (provenance, dated evidence, human-reviewable diff). That is the standing rule for every provider, not a Codex-specific gap. - The adapter rejects any call whose selected `(provider, model)` disagrees with the configured resource before turn execution (`model_not_served`), and pins the exact selected model/effort on the turn. Discrimination proof: the new tests fail on the pre-fix HEAD `d5cdc17` (old code executed a wrong-model turn) and pass on the fix; independently re-verified by the adversarial review.

kilo closed this issue

2026-09-21 12:29:27 +00:00

adrian.tkacz referenced this issue from a commit

2026-09-21 12:29:30 +00:00

docs(program): record the Codex physical-model binding and composed-matrix wiring

kilo referenced this issue

2026-09-21 12:29:54 +00:00

Program integration: M06 Codex execution adapter (#91) + M10 distribution and acceptance (#95) #108

kilo referenced this issue

2026-09-21 15:23:02 +00:00

Program integration: M06 Codex execution adapter (#91) + M10 distribution and acceptance (#95) #108