Freshness Is Part of a Software Fact

A dependency report may have been correct yesterday. A source-map plan may have matched the previous donor. A test selection may have described the repository before an engineer edited one import. A pull-request snapshot may have preceded the final review.

The report did not become retroactively false. It became stale for the decision now being made.

Existence is weaker than freshness

Software workflows often check whether an artifact exists:

• baseline file found;
• scan report present;
• build cache available;
• context packet generated;
• parity screenshot on disk.

Presence says nothing about whether its inputs still match.

A trustworthy artifact should identify the state axes that produced it, such as:

• donor or capture root;
• candidate source hash;
• repository commit and dirty-worktree fingerprint;
• configuration digest;
• tool and schema version;
• environment class;
• selected routes, symbols, or files;
• upstream evidence roots.

Different facts have different invalidation rules

A CSS edit may invalidate visual evidence without changing the dependency inventory. A donor refresh may invalidate source maps, runtime fingerprints, and parity baselines while leaving an operator’s authorization decision intact. A changed package configuration may invalidate module resolution without changing captured bytes.

Freshness should follow dependencies rather than one global timestamp.

This makes recomputation proportional. The system can preserve unaffected facts and reacquire only the claims whose inputs changed.

Unknown is not fresh

Legacy artifacts may lack the provenance needed to decide whether they match the current state.

Calling them stale may overstate what we know; calling them fresh is dangerous. The honest status is unknown.

Unknown evidence can still help an engineer investigate, but it should not authorize automatic mutation or a high-confidence verdict.

Schemas carry semantic freshness

An artifact can parse under the same JSON shape while the meaning of a field has changed. A serializer may adopt new identity rules. A coverage report may strengthen how readiness is measured. An archive may add an authority receipt the older format never contained.

Support and schema versions let consumers reject evidence whose semantics are no longer strong enough. A compatibility reader is not always desirable: accepting an older artifact can silently weaken a newer decision contract.

Advice should be freshness-bound

Agent instructions, cleanup plans, next-action lists, and context packets are especially vulnerable to staleness. They often sound plausible even after their preconditions disappear.

A system can latch advice when its evidence becomes stale and explain what must be refreshed. That is safer than allowing a model to reconstruct current state from old prose.

Archives preserve the time axis

Freshness does not make old evidence useless. Historical evidence is essential for understanding how software changed.

The key is to label its temporal authority. An archived issue or build result can be exact for a past revision while being inappropriate as a current gate.

This distinction is central to KodeAtlas: preservation and verification establish what was recorded; context systems must still connect that history to the code and decision in front of the agent.

A better question

Instead of asking “do we have a report?”, ask:

Which exact state does this report describe, and what changed since then?

Kalu Kode’s products use different evidence, but they share this principle. A software fact is not only a value. It is a value plus the authority, scope, and state for which that value remains valid.