Stamp determinism: compile twice, get the same answer

How do you know that two intelligence pictures are the same? Not by comparing every cell in every channel — the surface is too large and too noisy. ASSAY's answer is the content stamp: a SHA-256 hash over the compile's inputs (consumed knowledge refs, vignette config, engine version), not over the output surface. Two compiles that read the same knowledge produce the same stamp, regardless of ordering, timing, or platform.

Same inputs, same stamp

Compile the Meridian BASE knowledge twice. The stamp is byte-identical — because the inputs are the same, and the stamp hashes inputs, not the dense channel grid.

Change one item, watch the stamp shift

Now supersede K2 (causeway capacity) with a revised band. The stamp changes — because the consumed refs changed. The channel trace component shows exactly which channels moved and why: every channel value traces back to named knowledge via compiled_into + source edges (G3).

Illustrative widget, fixture data. The stamps are representative SHA-256 prefixes from the shipped compile service running over Meridian fixtures. The sparse channel representation means no dense cell grid is ever stored or hashed — determinism (G1) is independent of representation. Frozen as shipped on 2026-07-12.

Why it matters

Stamp determinism (G1) is how ASSAY answers "has anything changed?" without comparing surfaces. The scorer checks stamps before scoring: a stamp_mismatch refuses the score (the comparability guard), because scoring a world compiled from different knowledge than the one you think you're scoring is a silent lie. The stamp makes that impossible.

And because channels are sparse — a per-channel default band plus named RegionOverrides with sources — the stamp doesn't depend on how many cells the grid could theoretically have. The dense-world benchmarks (research note 00 §3) confirmed this scales; the sparse representation (research note 02) retired the dense model entirely.