docs(adr-013): #133 — Amendment A2 for run maturity, drafted and not in force - #226
Merged
Merged
Conversation
…in force #133 asked for three declared fields and said the historical artifact is not co-delivered. Measured before implementing, because implementing it as written meant a contract_version bump — which lives inside the header bytes §10 pins — and so a golden-fixture rebuild and a three-repo re-vendor. Two of the three already ship: - `source` is `provenance.ensemble`, and views-faoapi reads exactly that key. - the schema version is `contract_version`, on the run manifest and every shard header. The third is real but is not ours to stamp. Maturity belongs in `provenance`, which §2.1 closes, so admitting it is an amendment. And Hop-B shard headers are the Hop-A headers re-embedded untouched (contract/wire/sink.py) — this repo forwards provenance, does not compose it, and does not know a run's maturity. Synthesising one here would be a producer guessing at a fact nobody told it. The stamp belongs to views-models; our part is to forward it, which needs no code once the key is admitted. ADR-013 §2.2a records that as Amendment A2: the field, why it is an amendment and not a free addition, what adoption costs, who can stamp it, and a named trigger — adopt when the next fixture re-vendor happens for another reason, C-72/#174 being the one expected. Numbered A2 because A1 was taken (§7a, 2026-07-19). The issue's fourth claim is false: `_save_contract` DOES upload the historical artifact, category="historical", under the same interlock as the forecast. faoapi's C-169 decision has no premise, so there is nothing for the maintainer to decide. test_s2_2a_is_not_secretly_in_force guards the amendment bidirectionally — the risk is not only that A2 ships unrecorded but that it ships while §2.2a still says it has not, leaving three repos believing a re-vendor is still owed. Mutation-proven both ways. New C-85 (Tier 3): a cross-repo ask adopted on its stated terms without measuring current state. Filed in good faith, wrong because it named the run manifest while the consumer reads the shard header — vocabulary is what does not survive the trip between repos. No guard proposed; a checklist would be theatre. Register 84/11/73 -> 85/12/73. Suite 361 passed / 40 xfailed; ruff clean. No delivered byte changes; contract_version stays 1.5. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses #133. Registers C-85. No delivered byte changes —
contract_versionstays 1.5.Why this PR is mostly measurement
#133 asked for three declared fields on the run manifest and stated that the global historical artifact is not co-delivered. Implementing it as written meant bumping
contract_version— which is written inside the header bytes that §10 pins — and therefore rebuilding the golden fixture and re-vendoring it across all three implementing repos.That cost justified measuring the ask first. Two of the three fields already ship, and the fourth claim is false.
source; "source="unknown"is live today"provenance.ensemble— anddataset_service.py:793reads exactly that keycontract_version, on the run manifest and in every shard headermaturityon the run manifest_save_contractuploads it,category="historical", under the same interlock as the forecastAlso worth knowing: faoapi treats maturity as informational and explicitly never a serving gate (
dataset_service.py:788), and epic #244 is closed. The consumer side is built. The urgency implied by the issue body is not there.What is actually owed, and by whom
Maturity belongs in
provenance, which §2.1 clause 1 closes — so admitting a key is an amendment, not a free addition.And it is not this repository's to stamp. Hop-B shard headers are the Hop-A headers re-embedded untouched (
contract/wire/sink.py:110). This repo forwards provenance; it does not compose it and does not know a run's maturity. Synthesising one here would be a producer guessing at a fact nobody told it — the inference declare-don't-infer exists to forbid. The stamp belongs to views-models. Our part is to forward it, which needs no code once the key is admitted.ADR-013 §2.2a — Amendment A2
Records the field, why it is an amendment, what adoption costs, who can stamp it, and a named trigger (ADR-014 §4): adopt when the next §10 re-vendor happens for another reason — C-72/#174 (pyarrow) being the one expected, since it also changes delivered bytes and also needs three repos to move together. Riding along costs nothing extra; going alone costs a full coordination for one optional field.
Numbered A2 because A1 was already taken (§7a, 2026-07-19). Caught after writing; renaming rather than colliding.
The guard is bidirectional, and that is the point
test_s2_2a_is_not_secretly_in_force. The obvious risk is that A2 ships without the ADR noticing. The worse one is the reverse — A2 ships,contract_versiongoes to 1.6, and §2.2a still says "NOT YET IN FORCE", leaving three repos believing a re-vendor is still owed. So the test asserts the code agrees with the prose, and skips with an instruction to rewrite it (not delete it) if the section is ever rewritten on adoption.Mutation-proven both directions: adding
statusto_PROVENANCE_KEYSfails it; bumpingCONTRACT_VERSIONto 1.6 fails it.C-85 (new, Tier 3)
A cross-repo ask adopted on its stated terms without anyone measuring current state.
It was not careless. It was written against the run manifest — the artifact whose name suggests it carries run-level facts — while the consumer reads them from the shard header's
provenance, because that is where the producing pipeline's identity travels. Both seats described a real need; neither described the same object. A cross-repo ask names an artifact in the other repo's vocabulary, and vocabulary is what does not survive the trip.No guard proposed, deliberately: there is no mechanical check for "is this request still true", and a template or checklist field would decay into an unread heading. What worked was reading the consumer's source before writing any.
Verification
Register 84/11/73 → 85/12/73.
🤖 Generated with Claude Code