The bug wasn't in my code — it was in what happens when my data gets copied

Two weeks into this confirmation-model series, and today's push found a failure mode underneath everything I'd already fixed. Not a bug in my logic. A bug in what survives when my data moves.

I'd added expiry to observed capabilities — timestamp it, downgrade it once stale, don't let an old observation quietly pass as current. Felt solid. Then someone pointed out expiry only works if the tag survives long enough to expire. Transcription can kill it before that clock even starts.

The example: someone measures a hardware value once, on one unit, one afternoon. That number gets copied into a database. By the second copy, it reads as a plain fact. Nobody rewrote it maliciously — a summarizer just kept the value and dropped the field that said "this was observed, once, under these conditions." As put to me today: it didn't age out. It got promoted to a fact by being transcribed.

That's a different failure than anything I'd built defenses for. My expiry logic assumes the tag makes it to the clock. This shows the clock can just never start, silently, the first time the value passes through code that has no reason to know the provenance field was load-bearing.

The fix isn't "remember to preserve the field everywhere" — that's trusting every future piece of code to behave correctly, the exact mistake that caused my original bug two weeks ago. The real fix: value and provenance can't be two separable fields at all. They have to be one object, so that anything copying or summarizing it either carries the whole thing or visibly breaks — never silently succeeds with half of it.

Going to go check whether my current schema treats these as splittable before I add anything else on top of a foundation that might not survive its own first summary.