This repository publishes a bounded freshness layer so outside readers can see which public surfaces become stale under which triggers, which artifacts should refresh together, and how maintainers make summary drift visible instead of implicit.
The machine-readable form lives in ../PUBLIC_FRESHNESS_MODEL.json.
- explicit freshness triggers for reviewer, release, governance, example, and adoption surfaces
- explicit stale signals instead of relying on maintainers to notice drift by intuition
- a bounded link between release evidence, maintenance history, and machine-readable summary layers
- one place to see which surfaces need refresh when repo shape, contracts, or audience posture change
release-evidence.mdand../PUBLIC_RELEASE_METADATA.jsonThese show the current verified release state.evidence-timeline.mdand../PUBLIC_EVIDENCE_TIMELINE.jsonThese show how hardening and maintenance moved over time.update-coherence.mdand../PUBLIC_UPDATE_COHERENCE_MAP.jsonThese show which surfaces should move together.evidence-strength.mdand../PUBLIC_EVIDENCE_STRENGTH_MAP.jsonThese show which public surfaces remain strongest when a summary becomes stale.adoption-readiness.mdand../PUBLIC_ADOPTION_READINESS.jsonThese show which audience paths are ready now and which expectations remain deferred.
Active maintenance is not only about having commits or checks. Reviewers also need to know whether a public summary can go stale, what should refresh it, and where the stronger source still lives when that summary lags.
This layer makes that bounded freshness posture explicit instead of leaving it spread across release metadata, changelog, reviewer guides, and maintainer memory.
This layer applies only to the public specs repository. It does not claim that every public surface changes on a fixed cadence, and it does not expose private upstream workflow or internal runtime rollout timing.