core/docs/decisions/ADR-0113-rename-expert-demo-to-audit-passed.md
Shay 696f62abdd feat: ADR-0113 rename expert-demoaudit-passed; reserve expert namespace (ADR-0114 GSM8K roadmap)
The word "expert" in the previous status name implied raw-capability parity
with frontier LLMs on the same benchmark — which the gate does NOT verify.
What the gate actually verifies is CORE *claim-shape compliance*:

  * signed digest (replay-reproducible from on-disk lane results)
  * replay determinism (same inputs → byte-equal trace_hash)
  * typed refusal (fabrication refused, not paraphrased)
  * exact recall (no ANN, no cosine, no attention bottleneck)
  * grounding-source provenance

These are claim shapes a transformer LLM cannot structurally produce
regardless of raw accuracy. A frontier LLM might score higher on the
same benchmark but cannot pass this contract.

Rename scope (semantics only, per ADR-0113):

  status string         "expert-demo"        → "audit-passed"
  predicate key         predicates.expert_demo → predicates.audit_passed
  reason key            expert_demo_reason   → audit_passed_reason
  YAML key              expert_demo_claims   → audit_passed_claims
  CLI command           core demo expert     → core demo audit-passed
  output dir            evals/expert_demos/  → evals/audit_passed/
  artifact filenames    expert_demo.{json,html} → audit_passed.{json,html}
  HTML title            CORE Expert-Demo: X  → CORE Audit-Passed: X

Internal Python identifiers (module/file/function/class names like
`expert_demo.py`, `evaluate_expert_demo`, `ExpertDemoClaim`,
`expert_demo_claim_for`) are deliberately kept to minimize churn. ADR
file titles (ADR-0106..0112) preserved as historical record.

`expert` namespace reserved for ADR-0114+: an actual capability tier
above `audit-passed` backed by a public benchmark with a stated
threshold. ADR-0114 proposes the first such target — GSM8K-math —
laying out a falsifiable 7-phase arc (parser → solver → verifier →
stepped-realizer → eval lane → first `expert` ledger tier promotion).

Tests: 184 directly-affected tests green (140 capability/expert-demo
suite + 34 demo/audit-tour + 10 correction-cue). Smoke suite 67/67.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-22 15:36:10 -07:00

7.7 KiB

ADR-0113 — Rename expert-demoaudit-passed; Reserve expert for Future Capability Tier

Status: Accepted Date: 2026-05-22 Author: CORE agents + reviewers Depends on: ADR-0106, ADR-0109, ADR-0110, ADR-0111, ADR-0112


Context

ADR-0106 introduced the expert-demo ledger status as a contract-gated promotion above reasoning-capable. ADR-0110 / ADR-0111 promoted mathematics_logic and physics to that status. ADR-0112 added a runnable per-domain showcase (core demo expert --domain <id>).

The word "expert" carried an unintended implication: that a domain at expert-demo had been demonstrated at expert-level capability (i.e. raw task performance comparable to a human domain expert). The gate does not verify that. The gate verifies that a domain has cleared the CORE claim contract:

  1. Domain Pack Contract v1 — all nine ADR-0091 predicates pass.
  2. A reviewer-signed evidence-bundle SHA-256 reproduces byte-for-byte from on-disk lane result files (ADR-0106 §1.5).
  3. The lane outputs satisfy CORE-specific claim shapes:
    • signed digest — every claim reproduces from disk
    • replay determinism — same inputs → byte-equal trace_hash
    • typed refusal — fabrication is refused, not paraphrased
    • exact recall — no ANN, no cosine, no attention-bottleneck
    • grounding-source provenance — every surface tags its origin

These are claim shapes a transformer-based LLM structurally cannot produce, regardless of how high its raw accuracy is on the same benchmark. A frontier LLM might score higher on the raw answers but cannot pass this contract because it cannot produce a digest that re-derives, cannot guarantee typed refusal, cannot emit a trace hash bound to a deterministic execution, cannot replay byte-equal.

That is the load-bearing claim. "Expert-demo" obscured it. "Audit-passed" names it.

The framing is due to Codex's review (see PR #125 thread): the real story is not "this domain is expert-level" — it is "this domain's results have been audited against the CORE claim contract, signed, and are replay-reproducible."


Decision

Rename (semantics-only scope)

The following user-visible identifiers are renamed:

Surface Before After
Ledger status string "expert-demo" "audit-passed"
Predicate key on ledger row predicates.expert_demo predicates.audit_passed
Reason key on ledger row expert_demo_reason audit_passed_reason
docs/reviewers.yaml top-level key expert_demo_claims audit_passed_claims
CLI demo target core demo expert --domain X core demo audit-passed --domain X
Generated artifact JSON name expert_demo.json audit_passed.json
Generated artifact HTML name expert_demo.html audit_passed.html
Default output directory evals/expert_demos/<id>/ evals/audit_passed/<id>/
HTML title CORE Expert-Demo: <id> CORE Audit-Passed: <id>

Kept (internal Python identifiers, not user-facing)

The following internal names are deliberately unchanged to minimize churn under this ADR's "semantics-only" scope:

  • Module names: core/capability/expert_demo.py, core/demos/expert_demo.py
  • Function names: evaluate_expert_demo, derive_evidence_digest, build_expert_demo, run_expert_demo, _load_registry_for_expert_demo
  • Class names: ExpertDemoClaim, ExpertDemoVerdict
  • Method names on ReviewerRegistry: expert_demo_claim_for
  • Dataclass field names: ReviewerRegistry.expert_demo_claims
  • ADR file titles: ADR-0106 / ADR-0107 / ADR-0110 / ADR-0111 / ADR-0112 retain their "expert-demo" titles as historical records
  • Test class/method names that include "expert_demo": Python identifiers, retained

A future ADR may rename these internal identifiers if desired; that is explicitly out of scope here.

Future expert namespace reserved

The word expert (and any "expert" ledger status string above "audit-passed") is reserved for an actual raw-capability claim backed by a domain-specific capability lane with a human-expert-calibrated threshold. The current ADR establishes no such tier and no such gate. ADR-0114+ may define it when there is evidence to gate on.

The status ordering remains a 5-tuple:

blocked → seeded → grounded → reasoning-capable → audit-passed

A future expert tier would extend this to 6 entries; that extension requires its own ADR and is out of scope here.


Invariants

adr_0113_ledger_status_string_is_audit_passed

ledger_report() reports "audit-passed" (not "expert-demo") for every domain whose contract gate passes. Pinned by every existing ADR-0110 / ADR-0111 / capability-reports test that was updated to the new vocabulary.

adr_0113_yaml_key_is_audit_passed_claims

load_reviewer_registry reads from the audit_passed_claims YAML key. The legacy expert_demo_claims key is not accepted (hard cut, no backwards-compat read). Tested by test_reviewer_registry.py.

adr_0113_audit_passed_does_not_imply_capability

The audit-passed status string carries no claim about raw task performance vs. external benchmarks. It is a CORE-claim-contract compliance status. This invariant is documentary (enforced by the README + ADR text, not by code).

adr_0113_expert_namespace_reserved

No ledger row carries predicates.expert and no "expert" status string is emitted by ledger_report(). Tested by the existence of exactly five statuses in _EXPERT_DOMAIN_STATUSES.


Acceptance evidence

Accepted when:

  • _EXPERT_DOMAIN_STATUSES[-1] == "audit-passed" in core/capability/reporting.py
  • predicates.audit_passed (not expert_demo) is the key on every ledger row
  • docs/reviewers.yaml top-level key is audit_passed_claims
  • core demo audit-passed --domain mathematics_logic and --domain physics both produce all_claims_supported=True with digest match
  • All test suites that previously asserted the old strings now assert the new strings (or accept both in transitional cases like the historical ratification tests)
  • README, ADR-0091..0112 narrative refs, runtime_contracts, capability_roadmap updated to the new vocabulary (with explicit gloss on what audit-passed actually means)
  • Generated artifacts are renamed (audit_passed.{json,html}); the default output directory is evals/audit_passed/<id>/

Consequences

  • The ledger now tells the honest story. audit-passed accurately names the load-bearing CORE-vs-LLM claim (audit-shape compliance) and reserves "expert" for an actual capability claim if/when one ever lands.
  • External readers can no longer infer "this domain is expert-level" from the status string. They must read the gloss: audit-passed = signed digest + replay determinism + typed refusal + exact recall — claim shapes a transformer cannot structurally produce.
  • The future expert tier has clean namespace. ADR-0114 may define it paired with a domain-specific capability lane (e.g. GSM8K for math).
  • ADR-0106 + ADR-0109 contract bodies are unchanged. The gate's mechanics are identical; only the names move.
  • Generated artifacts under evals/audit_passed/<id>/ are still gitignored per ADR-0112.

Out of scope

  • Renaming internal Python identifiers (module / function / class names). A separate ADR may do that.
  • Defining the expert tier above audit-passed. ADR-0114+.
  • Backward-compatibility reading of the old expert_demo_claims YAML key. Hard cut. The repo is the single source of truth and ships with the new key.
  • Re-rendering the ADR-0099 public showcase. That demo composes pre-existing scene adapters and is unaffected.
  • The core demo expert CLI command. Replaced by core demo audit-passed. No alias.