Canon / Morning After
Correction-only continuity
A data licence expires. The answers an agent already handed around stay in use. Can the customer still receive a signed warning that a source behind one of those answers was corrected, without getting access back to the licensed data? This page holds a runnable synthetic proof that says yes, inside strict bounds.
The question
What happens the morning after a correction
Providers correct data. Customers keep records of what their agents answered with it. When access ends, the usual answer is silence: the old answers keep circulating with nothing attached. The hypothesis tested here: the provider can still deliver a signed correction notice, the customer can match it locally against recorded answers, and the notice itself discloses nothing new about the licensed data.
This is a composition of pieces the Canon already publishes: authority revocation, correction and supersession, knowledge timestamps and veiled proofs. It is not a new receipt type. If the bounds below cannot hold for a real case, the honest answer is to reuse the existing signed-notice and lineage tools instead of adding anything.
What the proof shows
Six claims, each with signed evidence
Reads work before expiry
A read at 14:01 UTC returns a signed result while the licence is active.
Reads fail after expiry
At 19:00 UTC, two hours after the 17:00 cut-off, the same read is denied, and the denial itself is a signed record.
The notice still arrives
A signed correction notice sent after expiry is accepted, on a notice right that outlives the read right.
No replacement data leaks
The notice, its delivery states, the local match report and the denial carry no replacement value, version or payload.
Only recorded answers flag
Local matching flags exactly the two answers recorded against the corrected source, D1 and D2. D3, whose reliance was never recorded, stays unflagged.
Keys verify after expiry
Every post-expiry record verifies against retained public keys. No private keys and no live access sit inside the bundle.
Offline verification confirms the full bundle, and rejects both tampered variants: one with an altered signature, one where replacement data was smuggled into the notice.
Honest limits
What this does not prove
Nothing is live
No provider, exchange or customer ran this. It is synthetic data with generated keys. It does not exercise any live connector or entitlement system.
Unrecorded reliance stays dark
If an answer was never recorded with its source links, no notice can find it. Unknown reliance stays unknown by design.
The notice never reopens access
The customer learns that a correction exists and which recorded answers it touches. To see the corrected data they need a live licence, exactly as before.
It is not a new primitive
The behaviour comes from composing existing receipts. Where a simpler signed notice plus lineage tooling already does the job, use that.
Sequence
The timeline the bundle records
| UTC time | Event | Outcome |
|---|---|---|
| 2026-10-22 14:01 | Customer agent reads a licensed source value | Allowed. Signed read result recorded. |
| 2026-10-22 17:00 | Read right expires. The correction-notice right runs until 23:59:59. | Access ends. Keys are retained. |
| 2026-10-22 19:00 | Agent retries the read | Denied. The denial is itself a signed record. |
| 2026-10-22 19:05 | Provider corrects the source | Signed correction notice issued. No replacement data inside. |
| 2026-10-22 19:07 | Notice delivered and accepted after expiry | Notice states recorded by both sides. |
| 2026-10-22 19:08 | Customer matches the notice locally against recorded answers | D1 and D2 flagged. Nothing else. |
Times are fixed by the generator so the proof is deterministic and reproducible by anyone.
Runnable reference
Verify it yourself, offline
Download the package, run the suite. Everything happens on your machine against the files in front of you. Nothing you check leaves your machine.
unzip -d correction-only-continuity-proof correction-only-continuity-proof.zip cd correction-only-continuity-proof npm install # dev dependency for key generation npm run proof # regenerate records and run the full suite node src/verify.mjs artifacts/latest/bundle.json artifacts/latest/trust.json
Intact bundle: exit code 0. Either tampered variant: exit code 1. Requires Node 18 or newer.
Composition
Built from entries already in the Canon
Each behaviour above is an existing, separately published receipt doing its job. The continuity comes from the join.
Data handling. The downloads above are static files served to your browser. Verification runs locally in Node. Nothing you check leaves your machine. This page records an anonymous visit count, like every Hive page.
Test it against one of your own corrections
Pick one expired-access scenario and one real correction. Agree the success criteria first, then run the same six checks on synthetic records shaped like yours.