Harness modes and standing checks

What it is

adjust360_harness.py is the single entry point that runs a claim through the pipeline. On the carrier path it has two modes that matter to the subrogation module: receipt, which tells the sender what its payload contains before anything is decided, and subro, which produces the thesis. Both are run from the command line, the API sits behind the harness, and no tool touches a database directly .

The harness also scaffolds vendor switching: --idp takes native, reducto or databricks, and the latter two require --manifest, so a vendor path is a switch rather than a rewrite. For the subrogation module the profile is carrier_structured.

Receipt mode

The exact invocation is:

adjust360_harness.py --mode receipt --idp carrier_structured --profile subro --in payload --out dir

The mode validates the payload through the normalizer, collecting every error rather than stopping at the first, and exits 2 on failure. It then builds a receipt record and renders receipt.json and receipt.html from receipt_sentence_templates, with data-trace on every rendered element. It runs no tool .

The receipt record holds:

• every field of the declared analysis profile as stated, not stated or not supplied, grouped by tier (decisive, supporting, optional) with needed_by naming the rule that reads it;
• fields sent that are outside the profile, listed on the receipt rather than discarded silently;
• jurisdiction_readiness per section, with the section's curation and verification status, and whether the state section is published;
• which deadlines are computable from the anchors supplied and which are not;
• a notice.

Five assertions hold on every receipt run :

Assertion	What it checks
R1	The payload hash equals the hash the subro mode computes for the same payload
R2	The receipt predicts the thesis completeness ledger exactly
R3	A present, absent or unknown vocabulary is rejected
R4	A draft state section shows published false
R5	No determination words appear on the receipt

Before this mode existed no production path produced a receipt; the one shipped with an early close-out came from a hand-made fixture carrying sha256:demo-fixture. That fixture was deleted and the receipt regenerated from scenario card AXA-RECEIPT-001, and rendering a receipt from a fixture is on the list of mistakes not to repeat. The pre-check screen in the user interface calls this mode; the interface itself has no direct database access.

Subro mode

--mode subro runs the carrier path: normalizer, JurisdictionResolverGKR, SensitiveIndicatorDetectorGKR Phase B or detector_not_run, SubrogationScreenerGKR, with liability and coverage recorded as not run. It emits the thesis record and trace, and the renderer produces the brief from the record alone. The full argument list beyond the mode flag is not yet documented.

The two modes share payload_hash. The hash is in the thesis header alongside the spec versions and ruleset hash, so a receipt and a thesis for one payload can be tied together, and a record and a render are only reported together when they carry the same run_id.

The LLM-count assertion

The harness asserts llm_construction_count == 0 per run for every rules tool . This is the mechanical form of the rule that no language model sits on a rules path. It is an assertion, not a review item, because a review of code has passed before while the thing it reviewed was not what ran.

The standing five

Every report on a commit that changes behaviour opens with these five commands, verbatim output, in this order :

1. check_subro_corpus_drift.py
2. check_corpus_coverage.py
3. fuzz_subro.py --n 500
4. generate_idp_manifest.py --profile carrier_structured --diff
5. run_conformance.py

Tool-specific checks (assertions, renders, schema validation) follow. A report that opens with any other set of commands is rejected unread. The commands are not renamed, reordered or substituted, and an implementer's own checks are never described as "the five checks". The rule exists because the substitution happened four times, the last as five fix confirmations labelled "Five standing verbatim"; the report was accepted only because the receipt itself had verified the content, and the next such report is rejected unread.

Item 4 is replaced by generate_intake_schema.py --diff once the canonical intake schema lands on the Trace Contract Program branch. Until then the manifest diff is the CI drift gate for the field contract: external_idp_manifest is never edited directly, and drift between the record and its artifacts fails the build rather than being discovered at integration.

The baseline these commands hold as of the freeze: conformance 53 of 53 on the carrier_structured path, corpus snapshot v1.2.0, drift clean, fuzz 500 payloads with zero violations, coverage with two known pendings.

Drift checks

The drift check proves that the seed script, the database and the signed snapshot agree after any corpus or spec change. Named checks in the sources :

• J1 and J2 cover the jurisdiction section records and were extended when the AUTO subrogation payload loaded as snapshot v1.3.0.
• T1 covers the brief sentence templates and glossary records, which enter the snapshot at v1.3.0 so that rendering vocabulary is governed the same way as corpus.

A spec version moving ahead of the baseline (v1.2.2 against v1.2.0 during the renderer track) is reported with the drift output and snapshot version before any acceptance.

Coverage checks

The coverage check walks the record graph of corpus, spec and seeds statically, without running a claim, so that an unresolvable trigger reference or an unreachable record is found before a run. Named checks in the sources :

• C3 and C6 were extended to the per-head no-fault trigger references and to a whole-seed walk.
• C7 reports two pendings: AUTO-005 activation after governmental notice curation, and the P14 sovereign immunity seed after the immunity section's fields are reported.

The remaining checks in the C1 to C10 set are not yet documented in the sources; their definitions belong on the generated page for the script.

The point of the coverage walk is a defect class seen three times: a chunk id that does not resolve silently dropped, an empty exclusion catalogue reading as no exclusions applying, and "no triggers declared anywhere" reported as a clean audit. Absence of a control must fail the check, not pass it.

Fuzz and conformance

fuzz_subro.py --n 500 generates payloads and asserts the invariants hold on every one; the standing result is zero violations. run_conformance.py runs the signed seeds and scores each on ten criteria with no aggregate. Both are described with the evaluation kit.

Open items

• The full argument list of --mode subro and of the render step is not yet documented.
• Definitions of C1, C2, C4, C5, C8, C9 and C10 are not yet documented.
• The standing five were absent from two recent close-outs; the reports remain owed with them.