The useful question is not merely “is this evidence real?” but “are the exact facts it depended on still the facts that govern this decision now?”
The receipt did not lie
Suppose a test produces a digest-bound result on Monday. On Tuesday the repository changes. The Monday receipt still verifies.
There are two tempting reactions:
- Keep trusting it, because the receipt is authentic.
- Discard it as false, because the world moved on.
Both reactions collapse two questions into one.
Did this evidence truthfully describe what happened then? And may this evidence govern what we do now?
The first question is about integrity. The second is about current applicability.
Security made the old evidence stay exactly the same
Security EC1 was designed so the stale object could not quietly mutate during the experiment.
It retained one exact derived projection from the earlier EC0 experiment. Its complete file bytes and projection digest stayed fixed. The projection declared the two exact inputs it had used:
historyDigest
currentSensorSetDigestThen the authoritative source was advanced in three phases.
Phase 1: the dependencies match
The original source and the projection referred to the same history and the same sensor set.
Result:
projection integrity = valid
current dependencies = match
→ APPLICABLEPhase 2: the source is newer, but the facts used by the projection are unchanged
The source envelope changed. Its generation changed. Its file digest changed. But the history and sensor dependencies used by the projection remained byte-identical.
The old projection stayed APPLICABLE.
A newer publication is not enough to prove an older derivation stale.
This is where a simple “generation changed, invalidate everything” rule lost.
Phase 3: one semantic dependency changes
The sensor set remained identical, but the authoritative history changed. The old projection itself was still perfectly intact.
Now the classification changed:
projection integrity = valid
history dependency = changed
sensor dependency = unchanged
→ STALE_NOT_APPLICABLEA fresh projection built from the new history returned APPLICABLE.
Stale is not corrupt
This distinction matters because “invalid” and “stale” imply different repairs.
The same bytes can move from the first row to the second row because the world around the evidence changed.
Age was not the deciding variable
EC1 deliberately did not consult wall-clock age, TTL, Git generation, source-envelope digest, Workspace digest, or a confidence score.
That is not a claim that time never matters. It is a narrower result: for this derivation, the exact dependencies were already known, and those identities were enough to answer the tested question more precisely than age.
A five-minute-old projection can be stale if its dependency changed one second ago. A month-old projection can still be applicable if the exact facts it used remain current and the domain permits that horizon.
When current authority disappeared, the answer became UNKNOWN
EC1 also removed access to the current authoritative source.
The checker still knew that the old projection was internally valid. What it could no longer establish was whether the declared dependencies remained current.
It returned:
projection integrity = valid
current authority = unavailable
→ UNKNOWNIt did not guess “probably fresh” because the receipt was recent. It did not guess “probably stale” because the source might have moved.
This is a useful Agent behavior: preserve what is known, preserve what is not known, and do not let confidence repair a missing owner observation.
World found the same pressure through a network path
World reached the same causal distinction through a very different system.
A previously successful Surfpath capability reference still existed, with exact digests for the capability, path, and observation. Hours later the Workstation owner rejected an attempted use because the observation was far outside its 180-second execution horizon. The historical record remained true: that path had worked. It simply no longer established that the path was usable now.
A new observation produced a new path and a new capability identity. The old evidence was not edited to look young again.
historical capability evidence
≠ current applicability
≠ action authorityThis website has the same problem
Web is a useful mundane example.
A browser test can prove that a project page rendered correctly. A social card can have the correct digest. A publication can be historically accurate. None of those facts makes the page current if the owning repository has since changed its responsibility boundary.
That is why Ordivon Web binds public interpretation to owner revisions and uses visible revised/historical states instead of turning a passing build into product truth.
The browser owns encounter evidence. The repository owner owns the underlying current fact.
Why not build a universal Freshness service?
Because the experiments did not require one.
Security could compare exact derivation dependencies. Workstation could enforce its own path-observation horizon. Web could compare its bound owner source. Each owner had different currentness semantics.
A global “fresh=true” bit would have hidden those differences.
The transferable law is smaller:
Integrity answers whether the evidence is what it claims to be. Current applicability answers whether its declared dependencies still govern the decision being made.
How each owner proves applicability can remain local.
What would reopen this judgment
A generic freshness mechanism becomes more plausible if materially different consumers repeatedly need the same additional fact that exact dependency comparison and owner-native currentness cannot express—for example, bounded leases whose meaning genuinely depends on synchronized time, or a cross-owner revocation contract that cannot be localized.
Until then, the smaller rule is sufficient for the tested worlds.
Evidence does not become false when the world changes. What changes is the question we are still allowed to ask it.
Primary records