core/docs/decisions/ADR-0169.1-math-compositionclaim-proposal-adapter.md

ADR-0169.1 — MathCompositionClaimProposal Adapter

Status: Proposed (design bridge; no runtime CompositionClaim admission in this PR) Date: 2026-05-27 Author: Shay Parent: ADR-0169 Related: ADR-0057, ADR-0163, ADR-0164, ADR-0166, ADR-0167, ADR-0168, ADR-0168.1, ADR-0172

---

Context

ADR-0169 identified a required compatibility bridge before any CompositionClaim implementation can land.

ADR-0057 ordinary TeachingChainProposal eligibility requires a reviewed source="corpus" evidence pointer. That is correct for cognition teaching chains, where the claim is grounded in reviewed teaching-corpus material.

Math-domain CompositionClaims originate elsewhere:

MathReaderRefusalEvidence / audit rows

— specifically the 20 rows in evals/gsm8k_math/train_sample/v1/audit_brief_11.json under refusal_reason="incomplete_operation" with missing_operator in {"quantity_extraction", "multi_quantity_composition"}.

Those rows are legitimate evidence of a teachable composition gap, but they are not cognition corpus evidence and must never be laundered into cognition corpus pointers.

Therefore CompositionClaim cannot simply reuse ordinary TeachingChainProposal as-is without either:

1. weakening ADR-0057's reviewed-evidence floor, or
2. falsely treating audit evidence as cognition corpus evidence.

Both are forbidden.

This ADR is structurally analogous to ADR-0168.1 (MathFrameClaimProposal). The same bridge logic applies, with the data shape and evidence floor specialized to composition.

---

Decision

Choose a math-specific proposal/ratification adapter:

MathCompositionClaimProposal

instead of creating a reviewed math corpus artifact first.

This adapter preserves ADR-0057's discipline:

• append-only proposal log
• replay-equivalence/admissibility as precondition, not permission
• explicit operator review before mutation
• no deletion
• no auto-accept
• no active-pack mutation during replay

but gives math-domain audit evidence its own honest evidence floor.

---

Why not a reviewed math corpus first?

A reviewed math corpus may eventually be useful, but it is premature for the second math sub-type bridge (FrameClaim is the first; see ADR-0168.1).

Creating it now would require deciding:

• corpus schema
• corpus lifecycle
• corpus indexing semantics
• corpus replay integration
• whether frame evidence, slot evidence, composition evidence, and reference evidence share one corpus or separate corpora
• how accepted math evidence relates to pack manifests

That is a larger substrate decision than CompositionClaim needs.

The adapter remains narrower:

one claim type
one proposal surface
one replay gate
one operator acceptance boundary

It keeps the capability path moving without inventing a new corpus family before the need is proven across at least two sub-types (FrameClaim and CompositionClaim) and converged.

When (and only when) the third or fourth math sub-type adapter is needed, the case for collapsing them into a reviewed math corpus becomes load-bearing. Not yet.

---

Data shape

A future implementation should define a frozen, canonicalizable data shape similar to:

@dataclass(frozen=True, slots=True)
class MathCompositionClaimProposal:
    proposal_id: str
    claim_signature: str
    surface_pattern: str  # normalized structural pattern over bound slots
    composition_category: str  # must be in SAFE_COMPOSITION_CATEGORIES
    polarity: Literal["affirms", "falsifies"]
    evidence: tuple[MathReaderRefusalEvidence, ...]
    replay_evidence: AdmissibilityReplayEvidence | None
    review_state: Literal["pending", "accepted", "rejected", "withdrawn"]
    operator_note: str
    provenance: MathProposalProvenance | None

Mirror the structure of MathFrameClaimProposal (ADR-0168.1) exactly, swapping surface_form / frame_category for surface_pattern / composition_category.

This is deliberately not a TeachingChainProposal because its evidence floor is not cognition corpus evidence.

It is also deliberately not a runtime composition registry entry. It is a proposal.

---

Evidence floor

A MathCompositionClaimProposal is eligible only if it has:

1. at least one audit/refusal evidence pointer,
2. a deterministic audit-row digest,
3. a normalized claim signature,
4. a known missing_operator subtype mapping to CompositionClaim (i.e. quantity_extraction or multi_quantity_composition),
5. an allowlisted composition_category (one of SAFE_COMPOSITION_CATEGORIES from ADR-0169),
6. boundary_clean=True, and
7. polarity in {"affirms", "falsifies"}.

Audit evidence must include enough provenance to replay the claim:

• case id
• sentence index
• frame index when available
• bound-slot tuple digest (the slot shape over which the composition pattern is asserted)
• missing operator
• refusal reason (incomplete_operation) and refusal detail
• recognized terms digest
• audit row canonical digest

The evidence pointer source must be a math-specific value such as:

source="math_audit"

It must not be source="corpus" unless and until a real reviewed math corpus exists. This is the no-laundering trip-wire shared with ADR-0168.1.

---

Replay gate

The adapter uses the math-domain replay gate:

run_admissibility_replay_gate

(the same gate used by MathFrameClaimProposal), parameterized by the composition-pattern target artifact rather than the frame target artifact.

Replay remains a precondition, not permission.

If replay regresses any protected metric (wrong == 0, refusal stability, partition, determinism), the proposal auto-transitions to rejected with an auto_rollback_regression note.

If replay passes, the proposal remains pending until explicit operator review. This preserves ADR-0057's "replay is precondition, not permission" rule.

---

Accepted proposal effect

Accepting a MathCompositionClaimProposal may only append (or propose append) to a reviewed composition-pattern artifact:

language_packs/data/en_core_math_v1/compositions/{category}.jsonl

where {category} is one of the entries in SAFE_COMPOSITION_CATEGORIES.

It must not directly mutate:

• active runtime state
• solver code
• parser code
• decomposer code (heuristic changes are their own reviewed PR)
• graph verifier code
• arithmetic semantics
• frame-opener registries (FrameClaim's surface)
• lexical registries (LexicalClaim's surface)
• cognition corpus
• cognition packs

Acceptance should produce an append-only provenance record linking:

proposal_id -> claim_signature -> target artifact row -> reviewer

---

Idempotency

proposal_id must derive from canonical claim identity, not clock time.

Recommended identity:

sha256(
    domain
  | subtype             # "composition_claim"
  | surface_pattern     # normalized bound-slot shape
  | composition_category
  | polarity
  | evidence_digest_set
)

Equivalent evidence should deduplicate. Adding a second audit row for the same claim may either:

1. append evidence to the existing proposal record, or
2. create a new event referencing the existing proposal id.

It must not create a second independent mutation opportunity for the same claim.

Calling apply_composition_claim() a second time on an already-ratified proposal must raise AlreadyRatified (mirror teaching/math_frame_ratification.py semantics).

---

Partition guarantees

The adapter is math-domain only.

It must not:

• consume cognition corpus evidence,
• emit cognition TeachingChainProposal records,
• append to cognition chains,
• read cognition semantic-domain classifiers,
• use cognition replay gates,
• be visible to cognition contemplation/proposal flows.

It may share infrastructure patterns from ADR-0057 and from MathFrameClaimProposal (ADR-0168.1), but not evidence identity.

The partition test in the implementation PR (tests/test_math_composition_ratification.py::test_partition_cognition_proposals_not_seen) must mechanically pin that cognition TeachingChainProposal records do not flow into the math composition handler and vice versa.

---

Trip-wires that close the ADR-0057 compatibility gap

The implementation PR must mechanically prove each of:

1. No corpus laundering. The adapter emits source="math_audit" and never source="corpus". Pinned by test_audit_evidence_not_laundered_as_corpus.
2. Append-only proposal log. No deletion path; rejected/withdrawn states are transitions, not removals.
3. Replay is precondition, not permission. Replay pass leaves the proposal pending. Operator accept is required for mutation.
4. Replay regression auto-rejects. Any regression in wrong, refusal stability, partition, or determinism flips the proposal to rejected with an auto_rollback_regression note.
5. Deterministic proposal id. proposal_id is derived from canonical claim identity; equivalent evidence produces equivalent ids across processes.
6. Active-pack bytes unchanged during replay. The replay gate must not mutate language_packs/data/en_core_math_v1/** byte content until operator accept lands.
7. No cross-domain emission. The handler does not produce cognition-domain artifacts.
8. Allowlist enforcement. A composition_category outside SAFE_COMPOSITION_CATEGORIES raises WrongCompositionCategory before any provenance is written.

---

Acceptance gates for implementation

A future implementation PR must prove:

• deterministic claim signature
• deterministic proposal id
• duplicate evidence deduplication
• append-only proposal log behavior
• replay-gate selection = math admissibility replay
• replay pass leaves proposal pending, not accepted
• replay regression auto-rejects
• operator accept is required for mutation
• accept writes only the reviewed math composition target artifact
• active corpus and active pack bytes are unchanged during replay
• audit evidence is never serialized as cognition corpus evidence
• case 0050 remains safe under any synthetic ratification in the initial allowlist
• recognized-but-uninjectable remains refused unless fully admitted correctly
• multi-quantity initial-state cases (e.g. case 0042 with 3 quantities) do not silently collapse under an unproven aggregation
• subtractive composition does not silently swap minuend and subtrahend

---

Non-goals

This ADR does not implement:

• CompositionClaim runtime admission
• composition-pattern artifact schema (deferred to the implementation PR; the JSONL layout under language_packs/data/en_core_math_v1/compositions/ is the artifact target but its row schema is not fixed here)
• workbench rendering
• ReferenceClaim
• SlotClaim
• reviewed math corpus substrate
• automatic acceptance
• additional composition categories beyond the ADR-0169 initial allowlist

This is only the bridge decision that makes future CompositionClaim implementation compatible with ADR-0057.

---

Decision summary

Use a dedicated MathCompositionClaimProposal adapter for math-domain CompositionClaim evidence. Preserve ADR-0057's replay/review discipline, but do not impersonate ADR-0057's cognition corpus evidence floor. Audit evidence stays audit evidence; operator-reviewed accepted proposals may later append to a reviewed math composition artifact under deterministic replay gates, scoped to the SAFE_COMPOSITION_CATEGORIES allowlist defined in ADR-0169.