kanaria007 PRO

Yes, if the only input is a missed-path incident, then I agree. That is not true leading detection. It is fast, honest attribution after the detector envelope already failed.

So I would separate two cases.

A missed-path incident is a lagging signal. It proves that the detector coverage claim was too broad for the reliance being placed on it, but it arrives after some reliance has already failed.

But coverage audit should not be limited to missed incidents. It should also have leading or pre-reliance signals:

• live traffic moving outside the declared probe envelope;
• new or growing long-tail retrieval paths;
• query/path clusters with no golden coverage;
• probe or freshness-check expiry;
• retrieval index churn or rebuild age;
• tool/policy/schema surface changes;
• shadow or dual-run divergence before commit;
• active sampling of unprobed paths;
• synthetic or mutation probes generated from live-distribution deltas.

Those do not prove application drift either. They produce a weaker object first: coverage-staleness suspect / narrowed detector reliance. In other words, “the canary may no longer represent the surface,” even before a user-visible failure.

So I would not say Chronia magically sees every new drift before contact. If there is no observation, no traffic, no sample, no surface change, no shadow path, and no synthetic probe touching that region, then no protocol can detect it ahead of first contact. That is the irreducible limit.

The engineering move is to make first contact low-blast-radius: shadow, dual-run, review-only, hold-commit, sampled exploration, or narrow-scope reliance until coverage is refreshed.

So: missed-path incidents are attribution. Coverage audits can surface risk before user-visible or high-reliance incidents when they use live-distribution movement, expiry, shadow divergence, and active probe expansion. Chronia’s role is to keep both cases honest: pre-incident narrowing when coverage evidence weakens, and post-incident attribution when the first observable signal really is a break.

The SI mechanism here is not omniscient detection. It is reliance discipline. A detector profile is treated as a scoped, expiring claim with declared coverage, out-of-scope regions, and non-claims. When coverage evidence weakens, reliance narrows even before application drift is confirmed. When recalibration happens, it re-establishes only scoped and expiring reliance, not global trust in the canary.

Compressed: not every new drift should have to draw blood. But if no mechanism has observed, sampled, shadowed, or probed the new region, then first contact may indeed be the first evidence. The design goal is to make that first contact low-reliance and low-blast-radius.

Yes. That is the exact failure mode I am trying to separate.

Replaying the probe set itself is useful, but it is not enough, because replaying stale probes can only prove that old probes still behave like old probes. It does not prove that the live surface is still represented.

So the stronger object is a coverage audit, not just a probe replay.

In the updated 189 framing, the probe suite has to carry a detector profile: declared scope, sampling window, coverage envelope, known out-of-scope paths, expiry, and non-claims. Then the audit asks whether that profile still matches the live distribution it claims to watch.

The inputs are not only replay results. They include things like:

• live traffic / route samples versus the declared probe envelope;
• missed-path incidents;
• long-tail or newly emerged path sampling;
• retrieval/tool/policy surface changes;
• probe expiry;
• contradiction or reliance failures that appeared outside the golden set.

So the answer to “who drifts the canaries?” is: the coverage audit surfaces it, using live-distribution evidence, missed-path evidence, expiry, and contradiction/reliance failures outside the golden set.

If those show that the live surface moved beyond the probe envelope, the result is not “application drift confirmed” yet. It is a probe_coverage_staleness_receipt: evidence that the detector’s own coverage claim is stale.

Then a detector_recalibration_receipt records the reentry: added probe paths, retired or narrowed stale probes, updated coverage scope, remaining out-of-scope paths, expiry, and next-review triggers.

So, compressed:

You do replay-test probes, but that only tests probe behavior.
You audit coverage by comparing the probe envelope against live distribution and missed-path evidence.
If the envelope no longer fits, canary green is narrowed, not trusted globally.

The canary does not get to certify itself. Its coverage claim expires, gets contradicted, or gets narrowed by coverage evidence.

Yes, that recursion is real. A detector is not outside Chronia just because it detects Chronia-relevant drift.

I updated art-60-189 to make this explicit: the detection layer is not assumed fixed. A green canary, frozen replay, or golden suite is only a scoped claim under a detector profile, probe set, coverage envelope, sampling window, and declared non-claims. It is not proof that the live distribution remains covered.

So if a failure appears on an unprobed retrieval path, the answer should not be “the canary was green.” The missed path becomes evidence against the detector’s coverage claim.

Who recalibrates the canaries? Not Chronia as a magic oracle. The responsible surface does: the detector owner, evaluation ops, retrieval ops, or release-review surface, depending on the system. Chronia’s role here is to make that recalibration receiptable, scoped, expiring, and tied to review triggers.

In a concrete deployment, that owner should be declared in the detector profile or recalibration receipt; otherwise the system has only moved the blind spot into an unnamed operations layer.

The updated note adds two illustrative article-local helper receipts:

• probe_coverage_staleness_receipt: records that the detector/golden set no longer covers the live distribution it claimed to monitor.
• detector_recalibration_receipt: records the updated detector profile, added/retired probe paths, updated scope, remaining out-of-scope paths, expiry, and next-review triggers.

That does not remove the recursion. It bounds it.

Compressed: Chronia should not treat detector green as global continuity. Probe coverage can drift too, and detector recalibration should itself be receipted, scoped, expiring, and non-global.

There is no final detector outside drift. Engineering does not remove that recursion; it bounds it with scope, expiry, ownership, review triggers, and degraded reliance when the boundary is no longer supported.

Yes, that is exactly the hard half.

Chronia should not treat a declared version, policy epoch, or vendor/tool manifest as proof that meaning stayed fixed. Those are claims, not continuity evidence. A clean ledger proves the record was kept; it does not prove the semantic surface did not move.

So no, an epoch does not have to be declared before it can be receipted. If frozen replay, semantic canaries, golden probes, calibration residuals, retrieval freshness checks, tool-contract probes, or coverage/contradiction signals diverge from the pinned context, the first object should be a drift-suspect / narrowed-continuity receipt — not a clean confirmed epoch.

From there, affected reliance should degrade: review-only, epoch-fit review, recalibration, safe-mode, or a new confirmed epoch/adaptation receipt if the boundary is validated.

That is also why Chronia is not the whole detection story. Chronia is the temporal-continuity and adaptation layer; it consumes drift evidence from other surfaces rather than trusting declarations alone. The detection surfaces live across evaluator/calibration drift, tool/connector semantic drift, policy-epoch migration checks, canary/shadow/dual-run divergence evidence, and operational evidence-surface drift.

In short: a pinned version string is not a meaning lock. Behavioral divergence can create a receiptable drift boundary first; the confirmed epoch comes only after the boundary is validated.

Related art-60 surfaces: 120, 131, 358, 598, 599.