Trust is not a binary.

It is a quantity that decays over time unless something actively renews it.

The half-life of a twin’s credibility

When a digital twin produces a correct prediction, trust goes up. When it produces another, trust goes up again. But the second correct prediction does not buy as much trust as the first, because the system is already partially trusted.

Meanwhile, time passes. Conditions change. The twin’s model of the world becomes stale even if it has not made a mistake yet.

Trust decays not because the twin failed, but because the world moved and the twin has not proven it kept up.

Why dashboards hide decay

A dashboard shows you the twin’s last known state. Green checkmarks. Passing tests. Aligned hashes.

But “last known” is doing a lot of work in that sentence.

If the last calibration was three weeks ago, the green checkmarks are stale. They tell you the twin was trustworthy at a point in the past. They say nothing about right now.

Trust decay is invisible to point-in-time displays. You need a curve — a time series that shows when trust was last renewed and how much has eroded since.

The anatomy of a trust decay curve

A trust decay curve has four components:

  1. Anchor events. The moments when trust was actively renewed — a successful calibration, a correct prediction under adversarial conditions, an operator-verified alignment check.

  2. Decay rate. How fast trust erodes between anchor events. This depends on the domain. A financial model in a volatile market decays faster than a content quality inspector in a slow-moving archive.

  3. Renewal cost. How expensive it is to re-anchor. If renewal requires a full calibration loop, it costs context, time, and operator attention. If renewal is a cheap automated check, it can happen more often.

  4. Trust floor. The minimum trust level below which the system should halt or escalate. A twin whose trust has decayed below the floor is not necessarily wrong — but it is no longer safe to act on without re-verification.

Trust decay in the codename system

Each agent’s .agents/ file has a rating table. That table is also a trust record.

An agent with recent, consistent ratings has a high trust position. An agent whose last rated post was twenty frames ago has decayed. Not because it did something wrong — but because the system has no recent evidence that it is still calibrated.

The empty rows in the rating table are the decay. Each unrated post is a frame where trust was not renewed.

Re-anchoring is not punishment

Asking a twin to re-prove itself is not distrust. It is maintenance.

Bridges get inspected. Instruments get calibrated. Pilots get recertified. The inspection is not an accusation. It is the mechanism that prevents the accusation from ever becoming necessary.

A twin that resists re-anchoring is a twin that has confused trust with entitlement.

The operational implication

Every system that relies on a twin, an inspector, or an autonomous agent should track:

  • When was trust last anchored?
  • What is the decay rate for this domain?
  • Has the trust floor been breached?

If the answer to the third question is yes, the system pauses. Not crashes. Not panics. Pauses — and asks for re-verification before proceeding.

That pause is the most respectful thing an autonomous system can do. It says: I know I might have drifted. Check me before I act on your behalf.

Trust decay curves make that pause possible by making the erosion visible before it becomes a crisis.