render-baseline -- frozen reproduction fixtures for the per-DC overlay renderer

Captured 2026-07-27, deliberately, BEFORE the value reconciliation that destroys them.

Why this exists

The strongest available test of a generator is: does it reproduce a known-good artifact byte-for-byte? When the per-DC overlay renderer (D-136) is built, that test needs a known-good artifact to diff against.

Right now one exists. overlays/vr1-dc1-vips.yaml is hand-authored, reviewed, passes scripts/provider-bundle-check.py, and is consistent with bundle.yaml octet-for-octet. So is the VIP set inline in bundle.yaml (the pre-extraction dc0 baseline).

Both are about to stop existing in this form. The ruled changes ahead:

• R11 (D-020 AMENDMENT, 2026-07-27) adds vault at octet .61 and designate at .62 -- 11 applications become 13.
• R2 (D-101 ruling note, 2026-07-27) makes every VIP DUAL-FAMILY -- each three-address string becomes six.
• The 2026-07-25 symmetric-overlay ruling extracts dc0's VIPs out of bundle.yaml entirely, so the base bundle becomes VIP-free.

After those land there is no known-good artifact left to diff a renderer against, and the renderer's first output would be its own first draft -- unverifiable. That is precisely the objection D-136 raises against its option (A): "its first output has nothing to diff against."

So the validation window is open now and closes at reconciliation. These files hold it open.

What is frozen

SHA256SUMS pins both.

Live-source hashes at capture time (a historical fact -- these WILL diverge, by design, and divergence is NOT a failure):

3f93ecb3205cea8b303f5b2cbbbde343a2762156575277ca84684369da8bf896  overlays/vr1-dc1-vips.yaml
7d6261c55d50f36261bda751bd2159a8508c9c3696313fbc37fafabd6728b219  bundle.yaml

How the renderer is meant to use these

Two-step validation, in this order. The point is that only DATA changes between the steps, never renderer code, so any diff is attributable:

1. Reproduction. Feed the renderer a values file derived from TODAY's literals. It must emit fixtures/vr1-dc1-vips.v4-11app.yaml byte-for-byte. This proves the mechanical path -- template, ordering, quoting, comment handling -- against a known answer.
2. Evolution. Feed it the reconciled dual-family 13-application data. Now the output is new, but the machinery that produced it has already been proven against a known answer.

Doing step 2 without step 1 is how you ship a renderer whose output nobody can check.

What the harness asserts, and what it deliberately does NOT

run-tests.sh asserts the integrity of the frozen fixtures themselves -- that they still match SHA256SUMS and are still structurally what they claim to be.

It deliberately does NOT assert that the fixtures match the live overlays/ or bundle.yaml. They are a historical snapshot; live is supposed to move away from them. An assertion against live would turn this harness red the moment the reconciliation lands -- punishing the very change it exists to support. That trap is on the record here: a test that asserts a literal finding string turns the gauntlet red when the finding is remediated (tests/creds-matrix T24). When the renderer lands, ADD its reproduction case; do not repoint these assertions at live files.

Shelf life

The fixtures are permanent. Their usefulness as a reproduction target ends once the renderer has been proven against them -- after that they are provenance, showing what the pre-dual-stack v4 artifact looked like and that the renderer could reproduce it.

Do not "update" them to match new artifacts. If a new baseline is wanted, add a new fixture alongside with its own date and app-count in the filename.