How work is run

title: How Work Is Run description: The working protocol for changing Adjust360: directives as committed files, close-out reports with the standing header, rulings before fixes, acceptance by target page, the branch model and the security rules. kind: authored status: draft source_memory: [subro-product-catalog, product-manual, adjust360-packaging] source_date: 2026-09-30 tags: [CLAUDE.md, directives, close-out, standing header, fix protocol, TraceContractProgram, credentials]

What it is¶

Adjust360 is built by a three-party loop. VS holds the vision, assigns work and relays rulings. The expert, the process lead in VS's Claude project, writes directives and reviews, and rules on every difference. Claude Code implements, measures and reports, and cannot see the expert's chat. This page records the protocol that keeps that loop honest: how a directive arrives, how work comes back, how a difference is handled, how a page is accepted, and which rules on branches and credentials apply to every commit .

Directives as committed files¶

Every directive, review and ruling is delivered as a file that VS commits to the repository before Claude Code reads it: docs/axa_box_test/directives/ for the subrogation box test and docs/trace_contract/<tool>/ for the trace contract program. A file is never described as "in the repo" until VS has committed it. If a directive names a file that is not in the repository, the implementer stops and says so rather than proceeding from memory of it. When a directive and the standing rules disagree, the implementer stops and reports the conflict; it does not choose.

Directives are clean, prescriptive and standards-enforcing. They name the artifact expected at close-out, and they do not grow: once an acceptance target exists, review documents are the implementer's engineering checklist, not reading for VS.

One directive at a time¶

VS reviews and holds the vision; Claude Code executes one directive and returns the work for green-lighting; the work is documented along the way for this manual. Nothing starts on the next directive until the current one is accepted or explicitly parked. During a renderer track the engine and corpus are frozen, and engine findings discovered under the freeze are logged for fixing after the track closes rather than fixed in place.

Close-out reports and the standing header¶

Work comes back as a close-out report titled with the directive name and a sequence number (Close-out 1, Close-out 2). Every report opens with the standing header, five commands in this order with their verbatim output:

check_subro_corpus_drift.py
check_corpus_coverage.py
fuzz_subro.py --n 500
generate_idp_manifest.py --profile carrier_structured --diff
run_conformance.py

Then the tool-specific checks: assertions, renders, schema validation. A report that opens with any other set of commands is rejected unread. After the header comes what changed (file, line, before, after), then results, then differences as proposed rulings, then debts and open items. Command output is quoted, not summarised. A partial result is reported as "not done", never marked complete. Once the canonical intake schema lands, item 4 is replaced by generate_intake_schema.py --diff; until then the list above is verbatim. See Harness Modes and Standing Checks.

Rulings before fixes¶

A difference between expected and actual output is a ruling before it is a fix. The report carries the seed, the expected value and its source, the actual value and its trace path, and a proposed classification (engine defect, corpus defect, wrong expectation, jurisdiction gap). The implementer holds. Expectations, seeds, corpus records and field guides are never edited inside the run that fails against them; an expectation change is its own commit under an explicit ruling. Corpus and spec changes go through the recorded path with an audit entry naming the ruling, and the seed script, the database and the signed snapshot must agree afterwards, which the drift check proves. The full protocol is in Principles and Rulings.

Reviews carry a verdict. CHANGES_REQUIRED and NOT ACCEPTED are used plainly; accepted items are listed separately from owed ones so that the next close-out can be checked against the list.

Acceptance by target page¶

For a rendered page the acceptance test is a target page the expert writes first, written as the page should read. For the subrogation brief it is A22_Morales_Brief_Target.md: the Morales worked example with its determination, what it rests on, inputs considered with Stated and Not supplied, other theories with the missing attribute named, what could defeat it, money, one deadline, what would change it, and provenance . The renderer is made to produce that page from the record through templates, sentence by sentence; where the template differs, the template changes. Only then do the other seeds render under the same templates. The close-out for a page is the HTML and PDF from one run and nothing else, and the sentence-by-sentence diff against the target is reported, not asserted.

The branch model¶

The trace contract program runs on a feature branch, TraceContractProgram. The testing team keeps testing on main without being impacted. The gate for every change on the program branch is that the subrogation module downstream is not broken and is made better. The box test's own work ran on feature/sl-fnol-semantic.

Security rules¶

No credentials anywhere in code or config; environment variables only. The rule was enforced after a review found a live database connection string with its password printed in a delivery document, and the audit had already found root database credentials in a committed .env and in AutoSubrogationScreenerGKR.py:43. The response is fixed: the credential purge from the repository and its history is the first commit of the close-out; a pre-commit check refuses any commit containing a connection string; and rotation of the exposed credential is the owner's action, not the implementer's.

No direct database access from a tool, and a tenant is written only by the bundle loader. See Seed Bundle and Tenant Install.

Internal material never leaves the team. The domain guide, seeds, corpus, rulings, registry, evaluator, templates and evaluation kit are never shared with a carrier. A carrier receives the format guide, the receipt, the brief in HTML and PDF, the thesis JSON, the glossary and the scoring addendum. The intake schema is an interface, not intellectual property, and may be shared.

Open items¶

The standing header's fourth item changes to generate_intake_schema.py --diff when the canonical intake schema lands; the header text in the standing rules must change in the same commit.
Reference documents still in VS's hands and not yet committed to the directives folder at the time of the source: Subro_Module_Handover.md, Subrogation_Domain_Guide.md, Governed_Tool_Evaluation_Method.md, Baseline_Correction_and_Fixture_Freeze_Directive.md, Baseline_and_Scenario_Authoring_Directive.md.