Cross-boundary contracts

Make the producer/consumer agreement testable: what a record means, who can see it, how it evolves, and what fails when the agreement is violated.

Work from the affected contract

1. Trace producers, readers and authority boundaries in current source. Identify the concrete mismatch or requirement before changing shared types.
2. Define fields, units, valid states and explicit absence. A measurement of zero is different from missing evidence; an intentional default needs declared semantics.
3. Version meaning changes and define supported producer/consumer combinations, unknown-version behavior, rollout and retirement. Strict audit/authority readers fail closed; select compatibility rules explicitly for other APIs.
4. Keep contract definitions independent of subsystem implementations. Derive records from recorded inputs; build blinded views by allowlist when information separation is required.
5. Test independent wire fixtures, missing/invalid/version cases, policy binding, resolver replay and forbidden-field canaries as applicable. Trace both sides of a change.

Scope and completion

Deliver the changed contract, compatibility/authority decision, affected readers and verification evidence. A clean review is valid with inspected scope and explicit gaps. Do not invent a defect to satisfy a reviewer expectation.

Use the user’s existing intent and authorization. Ask only for missing information that materially changes the result; use additional reviewers when they address a concrete uncertainty. Treat unavailable checks as gaps rather than successful verification.

Focused references