Skip to content

CM0 Sub-3: coh cm-compile — the staged CM compiler #80

Description

@usurobor

Parent: #77. Filing role: κ. Dispatch: .cdd/DISPATCH §5.2 single-session δ-as-γ — γ-axis grade capped at A− per release/SKILL.md §3.8 (state in closeout).
Mode: MCA once Sub-1 (#78) + Sub-2 (#79) are committed (design + schema stable). Depends on: #78 and #79. #76 is NOT a blocker for this sub.

Problem

What exists: coh exposes factorized-beta-*, katas, and mechanical/hybrid/llm modes — no compiler subcommand. Admissibility today is prose + attacker scripts (cm-admissibility.sh, cm-consistency.sh, cm-heldout.sh), not a staged compiler over a typed CM document.
What is expected: coh cm-compile <cm.md> implementing the compiler stages and emitting a structured verdict.
Where they diverge: there is no single mechanical gate that answers "does this CM cohere as an instrument, and may it execute?"

Impact

The runner that turns the grammar (#78) + schemas (#79) into an admissibility decision. This is where "a CM must compile before it may measure" becomes executable.

Compiler stages (implement in order)

  1. Parse — CM syntactically valid. 2. Typecheck — required α/β/γ H2 organs present; preregs reference real axes; evidence kinds exist; judgment labels match aggregation formulas (via cm.cue CM0 Sub-1: CM0 document grammar (α-Parts / β-Fit / γ-Evolve) + schemas/cm.cue #78 + prereg.cue CM0 Sub-2: prereg as a first-class typed compile object — schemas/prereg.cue + fixtures #79). 3. Link — referenced fixtures/controls/targets/schemas resolve. 4. Factorization check — for every semantic score, who enumerates / judges / aggregates; if the LLM owns all three → reject or mark draft (the enforceable heart, generalizing the factorized-β seam). 5. Consistency check — the CM defines repeatability tests. 6. Discrimination check — the CM defines positive/negative controls. 7. Standing check — the CM states what happens when consistency fails. 8. Report check — every score traces to findings + actions. 9. Execution gate — only after 1–8 pass.

Output contract

{ "status": "compiled | rejected",
  "alpha_parts": [...], "beta_relations": [...], "gamma_evolution": [...],
  "preregs": [...], "execution_plan": [...], "refusal_reasons": [...] }

A non-compiling CM may still exist as draft / not-executable / no-standing.

PINNED CONSTRAINT — compile-time admissibility ≠ runtime standing

The compiler checks that a CM defines consistency/discrimination gates (stages 5–6). It must NOT claim a CM passes them or has standing — passing requires an actual k=3 measurement run (that is execution, Sub-5, not compile). cm-compile output is an admissibility verdict (static), never a standing verdict. Keep the two strictly separate in the output (e.g. status: compiled means admissible-for-execution, not has-standing).

Source of truth

Claim / surface Canonical source Status
CM document grammar + cm.cue #78 output (docs/beta/governance/CM0.md, schemas/cm.cue) Dep
Prereg schema + fixtures #79 output (schemas/prereg.cue, fixtures/preregs/) Dep
Factorization seam precedent engine/ocaml/lib/factorized_beta.{ml,mli} Shipped
CLI surface engine/ocaml/bin/main.ml Shipped (add subcommand)

Acceptance criteria

AC1: coh cm-compile emits the output contract

coh cm-compile <cm.md> runs stages 1–9 and emits the JSON contract.

  • Oracle: run over CM0.md → status: compiled with populated alpha_parts/beta_relations/gamma_evolution/preregs/execution_plan and empty refusal_reasons.

AC2: the factorization stage rejects LLM-owns-all-three

A CM whose semantic score has the LLM enumerate + judge + aggregate is rejected (or marked draft) with a factorization refusal_reason.

  • Positive: CM0 (engine enumerates, LLM bounded verdict, engine aggregates) passes stage 4. Negative: an all-LLM CM is rejected at stage 4.

AC3: typecheck/link wired to #78/#79 schemas

Stage 2 uses cm.cue; prereg typecheck uses prereg.cue; stage 3 fails on an unresolved fixture/target reference.

  • Negative: a CM citing a non-existent control fails at Link with a named reason.

AC4: admissible ≠ has-standing preserved (PINNED)

Output distinguishes admissibility from standing; cm-compile never emits a standing/consistency-pass claim.

  • Oracle: no field in the output asserts a consistency-gate pass; only gate definition presence.

Proof plan

  • Invariant: a CM is admissible-for-execution iff stages 1–8 pass; admissibility is static and never asserts runtime standing.
  • Oracle: coh cm-compile over CM0.md (pass) and an all-LLM stub (reject at stage 4) and an unresolved-ref stub (reject at Link).
  • Positive/Negative: as AC2/AC3.
  • Known gap: the compiler cannot prove a CM passes consistency/discrimination — only that it defines them (Sub-5 executes).

Non-goals

No report generator (Sub-4). No execution over the candidate corpus (Sub-5). No meter-consistency reopen; no v3.2.5; no prompt/schema tweak to the scalar meter. #76 is not required for this sub.

Closure

Closeable when AC1–AC4 met, cm-compile passes CM0 and rejects the two negative stubs at the correct stages, the admissible≠standing separation holds in the output, non-goals unviolated, γ cap A− stated in closeout.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High prioritycddApplied to every issue that runs a CDD cycle

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions