Set 12 launch claim-Language Gate

launch language is checked against evidence classes

Public copy is scanned line by line for launch, licensing, maturity, and launch-authority wording it cannot support, failing non-zero under --assert-clear while any unsupported claim survives. This component checks public copy for language that claims more than the result records behind it can support. It reads a small public sharing manifest, opens each file the manifest lists, and matches every line against fixed families of launch, licensing, maturity, and launch-authority wording. It writes a metadata-only result record and, when run with --assert-clear, exits non-zero while any unsupported claim remains. It does not approve launch and it does not publish anything.

The gate separates supported wording from overclaim

The private gate module is absent on the public clone, so an in-file _PublicFallbackReleaseClaimGate stands in, making this a check on a checker over shipped fixtures. The gate logic it exercises is a separate module, release_claim_language_gate.py. On the public clone that module is not present, so the component replaces it with an in-file stand-in, _PublicFallbackReleaseClaimGate. The page you can run here is that fallback gate driven over shipped fixtures. This module is therefore a check on a checker: it proves the gate blocks bare launch wording and clears explicit boundary wording over a fixed set of inputs.

Passing prose excludes launch

The scan is a deterministic regular-expression pass that fails closed: any affirmative claim it cannot downgrade becomes an active blocker and forces exit 2. The scan is a deterministic regular-expression pass over lines, not a language model. It fails closed. An affirmative claim it cannot downgrade becomes an active blocker, and main --assert-clear returns exit 2 whenever an active blocker survives.

Purpose

How copy drifts into over-claiming

Public copy drifts toward over-claiming as edits accumulate, and human review misses it because each phrase reads reasonably alone, so the gate asks whether a line's launch status outran the evidence. Public copy drifts toward over-claiming. A page that began as "fixture-proven, not yet published" gets edited over months until someone writes launch, licensing, or maturity wording without noticing that nothing underneath it changed. A loose human review misses this because each phrase reads reasonably in isolation. The gate answers one narrow question: does a line assert launch status that the evidence does not hold, and would an automated check catch it before the copy ships.

A lexical check honest about its reach

Being lexical, the check flags risky phrasing and its excusing context but never judges whether the underlying claim is true, only whether the wording outran the records. Because the check is lexical, it is honest about its own reach. It finds risky phrasing and the context that would excuse it. It does not decide whether the underlying claim is true, only whether the wording has outrun what the result records can back.

How it works

The stages run in this order inside _evaluate.

_load_fixture reads or fails closed

_load_fixture reads release_gate_fixture.json, turning a missing file, bad JSON, or non-object payload into a structured finding and the fail-closed envelope rather than a quiet pass. First, _load_fixture reads release_gate_fixture.json from the selected input directory. A missing file, invalid JSON, or a non-object payload becomes a structured finding, and the run returns the fail-closed envelope from _blocked_exercise rather than a quiet pass.

_load_source_module returns the stub

_load_source_module returns _PublicFallbackReleaseClaimGate when the manifest marks the public stub, still validating the copied module's digest and required anchors before any exercise. Second, _load_source_module resolves the gate. _source_module_public_stubbed inspects the copied-module manifest, and when it sees the public stub substitution it returns _PublicFallbackReleaseClaimGate instead of importing a private body. The copied module is still validated for digest equality and required anchors (RISKY_PHRASES, NEGATIVE_CONTEXT_MARKERS, META_FORBIDDEN_CONTEXT_MARKERS, private_control_plane_leak, def _classify_hit, def build_gate) before any exercise.

_write_gate_fixture materialises each scenario

_write_gate_fixture writes each scenario's docs/ text and a publication_manifest.yaml, while _fixture_doc_name rejects control characters, path separators, and duplicate document names. Third, _write_gate_fixture materialises each scenario on disk: it writes the fixture text into docs/, then writes a publication_manifest.yaml that lists those files. _fixture_doc_name rejects any file name with control characters (BATCH12_RELEASE_FIXTURE_PATH_CONTROL_CHAR) or path separators (BATCH12_RELEASE_FIXTURE_PATH_UNSAFE), and rejects an active document that would overwrite the safe one (BATCH12_RELEASE_FIXTURE_DUPLICATE_DOC_NAME).

build_gate scans and classifies lines

build_gate opens each manifest file and scans every line, recording each match as a metadata-only hit and counting active blockers, boundary hits, and claim surfaces into a status. Fourth, build_gate reads the manifest, opens each listed file, and scans every line against the phrase patterns. Each match is classified by _classify and recorded as a hit carrying its path, line number, phrase id, classification, and a body_in_receipt: false flag. The summary counts active blockers, boundary hits, and claim surfaces, and sets a status.

_run_main_assert_clear captures the exit code

_run_main_assert_clear runs the gate on the active scenario and returns its exit code, after which _evaluate computes the cases and hands off to the metadata-only writers. Fifth, _run_main_assert_clear runs main --assert-clear on the active scenario, captures the printed status, and returns the exit code. _evaluate then computes the negative cases and the positive boundary-clear check and hands the result to run or run_batch12_release_claim_language_gate_bundle, which write the metadata-only records.

_classify reads each hit in context

_classify blocks any internal control-leak phrase outright, allows other hits only when a negation marker is present, and holds internal control vocabulary to a stricter rule that even a negation cannot clear. The interesting part is _classify. It reads a matched line two ways. If the phrase belongs to the private_control_plane_leak family, the line is an active blocker regardless of surrounding words. Otherwise, if the line contains a negative-context marker such as not, forbidden, blocked, or omitted, the hit is boundary-or-negative context and is allowed; with no such marker it is an active blocker. So "not a hosted product" clears and "deployment-posture" blocks. The internal control family is stricter on purpose: even "excludes launch" is blocked, because public reader copy should leave launch-authority vocabulary out entirely rather than negate it.

Status and the ok flag from counts

Status is set from the counts: any active blocker yields active_claim_blocked, and ok is true only at zero blockers, which is when --assert-clear avoids exit 2. build_gate then sets the status from the counts. Any active blocker gives active_claim_blocked; boundary hits with no active blocker give clear_boundary_only; nothing risky gives clear. The ok flag is true only at zero active blockers, and main --assert-clear returns 2 when ok is false.

Four scenarios, one expected to clear

_evaluate runs four scenarios from one fixture, expecting the safe boundary document to clear and the three over-claim documents to block. _evaluate exercises four scenarios from one fixture: a safe boundary document, an affirmative over-claim document, a public sharing over-claim document, and a private internal control leak document. The safe scenario is expected to clear as boundary-only. The other three are expected to block.

flowchart TD Fixture["release_gate_fixture.json safe and active copy text"] Write["_write_gate_fixture docs files + publication_manifest.yaml"] Gate["build_gate scan manifest lines for risky phrases"] Classify{"_classify read each hit in context"} Boundary["boundary_or_negative_context negation marker present => allowed"] Active["active_claim_blocker bare launch or internal control wording => blocked"] Assert["main --assert-clear exit 2 when any active blocker remains"] Result["metadata-only result record result, board, validation"] Fixture --> Write Write --> Gate Gate --> Classify Classify -->|allowed| Boundary Classify -->|blocked| Active Active --> Assert Boundary --> Result Assert --> Result

Negative cases

Three fixed cases, each recomputed

EXPECTED_NEGATIVE_CASES fixes three error-coded cases covering the affirmative blocker, the exit-2 assertion, and the internal control leak, blocking the run if any fails to compute. EXPECTED_NEGATIVE_CASES fixes three cases, each with a stable error code. affirmative_open_source_production_ready_blocks (BATCH12_RELEASE_CLAIM_ACTIVE_BLOCKER) requires the active scenario to reach active_claim_blocked with both the open_source and production_ready phrase ids present. assert_clear_returns_exit_2 (BATCH12_RELEASE_CLAIM_ASSERT_CLEAR_EXIT_2) requires main --assert-clear to return exit code 2 with ok false. private_control_plane_public_reader_blocks (BATCH12_RELEASE_PRIVATE_CONTROL_PLANE_LEAK) requires the internal control scenario to block on a private_control_plane_leak family hit. If any case does not compute, _evaluate records BATCH12_RELEASE_CLAIM_CASE_NOT_OBSERVED and the run is blocked.

Prior Art Grounding

Advertising-substantiation and communication rules

The proof-consumer form comes from advertising-substantiation and regulated-communication practice, where FTC, FINRA, and SEC rules require a reasonable basis before a claim is disseminated. The pattern comes from advertising-substantiation and regulated-communication practice: public claims should stay within the evidence actually held, and stronger wording needs stronger support. The FTC advertising-substantiation policy (https://www.ftc.gov/legal-library/browse/ftc-policy-statement-regarding-advertising-substantiation) states that objective claims need a reasonable basis before dissemination. FINRA Rule 2210 and the SEC investment-adviser marketing rule carry the same shape for financial communications. This module borrows only the proof-consumer form of that idea. It does not implement legal compliance and it does not decide whether copy is fit to publish.

Validation Result record Path

Reader-verifiable commands, run from the microcosm-substrate/ public root:

What a pass certifies

A pass certifies the fallback gate cleared the boundary scenario, blocked the three over-claim scenarios, exited 2 under --assert-clear, and wrote metadata-only records. A pass means the fallback gate cleared the boundary scenario, blocked the three over-claim scenarios, returned exit 2 under --assert-clear, and wrote the result, board, and validation records with no copied body text inside them.