Compare replayed populations by content seal instead of by retained object

[MaxGhenis]

Implements Max's 2026-09-17 decision on the transport lane's report §10
question 2 — option (b), replace the object comparison with a content
seal — so the base US financial run stops retaining nineteen detached
populations between the executor's observation and its own replay comparison.

Design authority: docs/us-native-retention-seal.md (this PR).
It answers the four questions the brief asked, in order.

0. The report's proposed mechanism does not hold, and that is the first finding

Report §10 question 2(b) said _population_stamp "already folds everything
same_replayed_population compares except the type assertions". That is
wrong in both directions, and both halves are proved by scripts committed
under experiments/native-retention-seal/:

• _population_stamp is too strict. On a US_SCHEMA population whose
  frame is round-tripped through ContentStore.put_frame/load_frame,
  same_replayed_population accepts (the store zeroes values beneath a
  null mask and NONCANONICAL_NULL_BACKING permits exactly that) while the two
  stamps differ. A stamp-equality seal would turn every resume="require"
  replay red. _population_stamp's own docstring says so.
• _frame_identity is too weak. It misses float64 NaN payload bits,
  quiet-versus-signalling NaN (NATIVE_BITS) and
  DataFrame.flags.allows_duplicate_labels (TABLE_TYPE_OR_FLAGS), because
  _cell spells every NaN null and nothing folds the flags.

So the seal is purpose-built and lives in survey_population_replay.py,
beside the comparison it replaces. The rule it follows: every comparison of
byte strings becomes a comparison of their sha256; every other predicate keeps
the small object it applies to — a dtype, its class, an index class, an axis
name, a WeightKind, a flags value — and applies the identical is/==;
every predicate about one operand is asserted when the seal is built, with the
same refusal code. The record is O(columns), not O(rows).

What is no longer proved

Nothing about the content. Four things change in character, all stated in
§4 of the design note: byte equality becomes sha256 equality; one-sided
assertions fire on arrival rather than at comparison; a one-sided defect now
takes precedence over a two-sided one when a population carries both; and on an
object-dtype axis a difference refuses under AXIS rather than
OBJECT_VALUE, because Index.equals there is an element-wise != over
arbitrary Python objects that no digest reproduces. Every defect is still
refused, so this did not need to go back to the owner.

The battery

test_us_survey_population_replay.py now drives every mutation through the
object comparison and the seal and requires the same verdict with the same
code. That driver found four gaps in the seal's first draft; a separate
adversarial pass over the finished seal found five more, including one in the
dangerous direction (an object axis sealed through pd.Series(index.array) lost
its null-sentinel identity, because pandas 3 re-infers that Series to str).
All nine are fixed and pinned.

An adversarial pass found three real divergences in the seal, and a gate

Six independent review dimensions over the finished head, every finding put to
two independent verifiers whose default answer is REFUTED: 31 findings, 25
survived, five answered in code. Receipt with every claim, both verdicts and
each disposition:
experiments/native-retention-seal/adversarial-verification-receipt.json.

divergence, on an object-dtype or masked axis	direction	now
a value carrying its own __eq__	comparison refuses, seal ACCEPTED	refuses on both, at seal construction
None against float("nan")	comparison accepts, seal REFUSED	accepted by both
a masked-integer axis above 2**53	both refuse; the fold was lossy and the code moved	exact, AXIS on both

The first is the dangerous direction — a run accepting a replay the comparison
refuses — and it was reproduced before being believed. The fix is not a patch
per case: Index.equals over an object axis is an element-wise ==, so the
fold now reproduces the equivalence classes that operator actually has,
measured on this pandas pin rather than read off its source ({None, NaN} is
one class, pd.NA and pd.NaT their own, bool/int/float one numeric class by
exact value, str and bytes their own), and refuses AXIS at seal construction
for the one case a digest cannot represent. A side effect: True against 1
and -0.0 against 0.0 now agree on OBJECT_VALUE, where the seal used to
say AXIS. 124 new battery cases pin all three, and each half of the fix
was reverted to confirm its own cases go red.

This change also broke a gate that passes at the base.
test_us_spine_blindness.py::test_runtime_population_operators_are_source_spine_blind
is a static analyser over a roster survey_population_replay.py has been on
since before this branch — the branch does not touch the test — and it refuses
a statically unresolvable subscript on a name it infers to be a column
container. Every seal record is a positional tuple, so it reported 48 sites
in one module. Verified both ways before changing anything: 1 passed in 223.35s at a64f7b733, red here. The records are now unpacked into named
fields instead of indexed, and the one dynamic getattr over
_comparables reads through a literal reader per name — which is also strictly
more closed, since an unknown comparable now refuses instead of folding None.
No record changed shape, order or repr, so no seal identity moves; the module
is in no stage roster and in none of the inventory's 124 contracts. 1 passed in 217.42s at this head.

Two tests were vacuous and both now fail against the defect they pin: an
executor test whose default-mode arm compared one run's objects against a
different run's, and the dtype census, which asserted the same predicate
twice and never called a seal function.

Four documented mechanisms were not in the code. The design note described
a dtype token of strings and booleans, a _comparables digest and a
repr() fallback, and spent its whole residual-risk paragraph on the fallback.
The code does the opposite of tokenising — it retains the objects — and the
note's own §4(1) had argued a token would be wrong. Both sections now describe
what ships, with the three residual risks that are real.

Fail-closed

Every refusal code that exists today still fires on the same defect — which is
now checked rather than asserted, in both directions, by the battery's
agreement driver and by the 121-case sweep of the measured equality classes.
FINANCIAL_NODE_POPULATION_CHANGED means: for a node whose Population the
run still retains, its in-process stamp differs from the one recorded at
issuance; for every other node, the retained seal record no longer digests to
what it did. Neither arm is vacuous.

Six refusal codes are added, and five now have tests — they had none.
ATOMIC_OBSERVER_RETENTION is still unpinned, and both documents say so,
including that its second conjunct re-derives seal_identity from the record
whose identity it compares against and so cannot fire as written.

Declared consumers. result.financial_population is observed[final_node]
is an identity check, so the base run retains financial.ATTACH_NODE, the
property graph's attach node, and the tax gate when the rebase is enabled —
detached with the executor's own snapshot function — and seals and drops the
rest. The completion host turned out to be a consumer of the base run's whole
roster (graph_survey_completion_host.py:814-816 hands those populations to
_states, which reads their frames), so the recursive base call sets a private
retention flag and that path keeps today's behaviour exactly. Found by test,
not by reading; said plainly in the design note.

An inherited defect, repaired here

survey_population_preparation._spill_roster gained a Path.read_bytes on this
base branch at b6081efcb, which added a resource_accesses entry and left
graph_implementation_inventory.json's declared resource_accesses_sha256
stale. implementation_manifest("authenticated_survey_population_v1") therefore
refused, and SurveyPopulationCreateKernel.implementation_hash calls it —
so no 19-node graph run was possible at the base branch's tip. Bisected:
clean at 5ff889814 and 5307249b3, refusing from baaf4270c onward. The base
branch's report §4 "No committed pin moves" was recomputed before b6081efcb.

The repository had no test over the whole inventory — the one caller built three
of the ten stages — so nothing was red.
test_us_implementation_inventory_contracts.py builds all ten and checks all
124 contracts; reverting the re-pin turns both arms red, verified before
committing.

What moves

experiments/native-retention-seal/implementation-identity-receipt.json:

comparison	roster module digests that move
base branch tip → this PR's US-only commits	none
base branch tip → this PR's head	microcosm.graph/executor.py, in all ten stages

survey_population_replay.py, graph_atomic_survey_financial.py and
survey_atomic_geography.py are in no stage roster; executor.py is in every
one, and the inventory re-pin moves inventory_sha256 in every one. Node keys
and store addresses therefore move, for the reason the base branch's own report
gave: a US stage's implementation hash is over its whole module roster.

packages/microcosm-graph hunks — main-only

Commit 9bef866c5, on its own, is the main-only change. It adds
run_graph(_population_observer_detach=False): an observer that only seals
receives the live admitted population and no snapshot is allocated. Opt-in,
default unchanged, no US import, and the keyword enters no key, no receipt and
no cache record. Four tests in test_graph_executor.py, modelled on
test_absent_observer_allocates_no_snapshot. It is deliberately not called
population_retention: that keyword existed on #893's branch (6c0f24c77,
layer 08) and made the manifest's attached population views lazy, which is a
different target.

file	main-only
packages/microcosm-graph/src/microcosm/graph/executor.py	yes
packages/microcosm-graph/tests/test_graph_executor.py	yes
everything else	no

The main-only change is now two commits, not one, and the split has to
carry both: 9bef866c5, which adds the mode, and the graph-shard hunks of
6e3b3091c, which answer two of the adversarial pass's findings — the
docstring that withdraws both guarantees by name, and the fix to the
executor test whose default-mode arm was vacuous. git log a64f7b733..HEAD -- packages/microcosm-graph/ returns exactly those two, and the whole graph-shard
diff is executor.py +30/−1 and test_graph_executor.py +152. The brief asked
for the mode in its own commit and it is; the two follow-up hunks arrived after
the review that found them.

Runs

Both required runs have run. Records, launchers and measurement JSON are in
experiments/native-retention-seal/; the full write-up is that directory's
out.md. Both measured trees carry packages/*/src byte-identical to this
head — the only packages/ difference is two test files added afterwards,
and no source file references them.

The 1/1000 cold run and its required replay — COMPLETED

	baseline 5ff889814	transport after 5307249b3	this PR	vs after
runner call CPU s	2,026.78	1,907.58	1,714.92	−192.65
financial node loop wall s (19)	277.36	238.33	196.48	−41.85
prefix node loop wall s (9)	55.93	45.49	39.55	−5.94
outside both node loops, wall s	1,712.62	1,692.17	1,473.68	−218.49
required replay CPU s	—	1,664.45	1,566.82	−97.63
whole-process CPU s	2,028.69	3,574.86	3,284.70	−290.16

Regenerated from the three runs' own measurement JSONs by
before_after_table.py, so no cell is transcribed by hand. CPU is
process_time and load-independent; the wall rows are not. −192.65 CPU-s on
the runner call, 1.112×, and the comparison understates it, because this head
also carries the base branch's b6081efcb, which adds work.

The replay proof. Manifest key identical
(a08d5536bcc93e0e065e5756a8453c78c526673b998274523906fd77546c015f), node
roster identical, content_addressed projection identical with
nodes_differing: [], every node a store hit, store bytes identical — 0
paths added, 0 changed — and the cold and warm projection sha256 equal. 5,869
store objects, the same count as the base branch's after-run.

The key is not the base branch's bd511d92…, and the receipt names why:
survey_population_preparation.py (the base branch's own b6081efcb),
inventory_sha256 (this PR's re-pin, forced by that), and
microcosm.graph/executor.py (this PR's observer mode).

Which half moves a key, precisely. The seal and its battery move nothing —
the receipt's base → seal_and_battery row is empty, and
survey_population_replay.py, graph_atomic_survey_financial.py and
survey_atomic_geography.py are in no stage roster. But the US half is not
key-neutral: it carries the inherited-contract re-pin, and inventory_sha256
is in every stage manifest. Exactly one commit moves each of the two things
that move — 9bef866c5 the executor, 43fb39270 the inventory — and
git log a64f7b733..HEAD -- <path> returns a single commit for both.

Peak RSS went up and this PR is not going to spin it. 17.86 GB
whole-process against the base branch's 12.42 GB; by phase, cold
13.16 / 12.42 / 13.49 GB and replay — / 11.71 / 17.83 GB. The retention
this change removes is about 0.31 GiB at 1/1000 — an order of magnitude
below the difference — so the comparison is not evidence about retention in
either direction, and no mechanism is offered for it. Report question 5 asks
whether to chase it with a repeat on a quiet machine.

The 1/15 run — refused, as predicted, before any node

STOPPED_…PREPARATION_ISSUANCE_REFUSED at 605.65 CPU-s and 8.28 GB,
with 0 nodes run. A row-count ceiling did not fire; a byte-budget ceiling
did. A diagnostic re-run with a sys.monitoring RAISE block — no byte of the
measured tree changed — names it: ACSCoverageAuthenticationError: CANONICAL_SIZE from issue_acs_native_coverage, the 1 MiB canonical-JSON cap
on the selected-ACS-SERIALNO list at
acs_native_coverage_binding.py:563-565. Computed from measured inputs, it
refuses above about 4.28% of source — below the 6.10% the base branch
lifted, and it was in no ceiling census. 1/24 fits, 1/20 and everything above
refuses. So this run measures the ceiling, not the seal; the seal's measurement
is the 1/1000 run above.

Refusal codes this PR adds

Six, and until now none had a test. Five now do, and each of the three seal
tests was verified to go red against its own reverted guard.
ATOMIC_OBSERVER_RETENTION is still unpinned, and both the design note and the
report say so — including that its second conjunct re-derives seal_identity
from the record whose identity it compares against, so as written it cannot
fire. Report question 7 asks whether to test the half that can, or cut the half
that cannot.

Scope

Nothing here is a build, a certification or a release artifact; every
measurement carries "release_eligible": false, no gated data was touched and
none left the machine.

Draft, and it stays draft.

🤖 Generated with Claude Code

Reconciled with main (18 September 2026)

This branch was merged level with main (through #946 and #938's split executor) rather than rebased. Main's executor split (run_graph → _execute_graph) left _population_observer_detach referenced inside _execute_graph without being passed in, a NameError on the first detached run; commit 98b698593 threads the flag through the split. Batteries on the merged head, each rc=0 with no failure markers: packages/microcosm-graph/tests and test_us_survey_population_replay.py.

[MaxGhenis]

Closing as superseded: this head (98b6985) is an ancestor of #1011's head (3de7348, branch native-integration-20260923), so nothing here is lost. The branch is kept. Whether the graph-native US line itself continues is decision US-2 in the 2026-10-09 consolidation review.