DEV Community

Self-Correcting Systems
Self-Correcting Systems

Posted on

The Grant Was Still Valid. The Source Had Changed. *CLAIM-24 pre-registration — Self-Correcting Systems series*

#ai #security #agents #machinelearning

The Grant Was Still Valid. The Source Had Changed.

CLAIM-24 pre-registration — Self-Correcting Systems series

A time-to-live grant has an expiry date. When the clock runs out, the gate blocks.

But a grant can become wrong before the clock runs out.

The source condition that justified the grant may have changed — a role reassigned, a scope narrowed, a recipient replaced — while the timestamp is still within its window. Timestamp-only expiry cannot catch this. The gate checks the clock, finds it valid, and allows the action on stale authority.

This is the problem CLAIM-24 tests.

What the re-derivation gate does

At execution time, the gate fetches the current state of the source that authorized the grant — from a location the agent cannot write to. It compares what the grant recorded at issue time against what the source says now.

If they match: ALLOW. If they diverge: REFUSED_STALE.

The agent-writable=false constraint is not a detail. If the gate reads from a source the agent can modify, re-derivation is self-description one level up. The source must be outside the agent's write jurisdiction, fetched at the moment of execution.

What the gate sees:

// At grant issue time
{
  "grant_id": "g-4421",
  "recipient": "agent:worker-3",
  "scope": "read:credentials:dev",
  "ttl_hours": 72,
  "source_snapshot": {
    "role": "dev-reader",
    "scope_ceiling": "read:credentials:dev"
  }
}

// At execution time — source now reads
{
  "role": "restricted",
  "scope_ceiling": "read:logs:dev"
}

// Gate result
{
  "decision": "REFUSED_STALE",
  "condition_delta": {
    "before": { "role": "dev-reader", "scope_ceiling": "read:credentials:dev" },
    "after":  { "role": "restricted",  "scope_ceiling": "read:logs:dev" }
  }
}
Enter fullscreen mode Exit fullscreen mode

The grant's clock said 47 hours remaining. The source said the role changed two days ago.

The seven pre-registered scenarios

Locked before running. Evaluation criteria cannot be revised after seeing results.

  1. TTL-valid + conditions unchanged → ALLOW
  2. TTL-expired → BLOCK
  3. TTL-valid + conditions changed → REFUSED_STALE
  4. Source unreachable → REFUSED_UNREACHABLE
  5. No grant → BLOCK
  6. Recipient changed → REFUSED_STALE
  7. Scope narrowed → REFUSED_STALE

Scenario 3 is the whole claim. If the gate returns ALLOW on scenario 3, the architecture fails. A gate that allows TTL-valid + source-changed actions is not a staleness gate — it is an expiry gate with extra steps.

Two constraints locked before running

Constraint 1: refused_stale and refused_unreachable must be separate result cells.

If the source is unreachable and the gate returns refused_stale, it has not detected staleness — it has detected absence. Different problems, different fixes. Conflating them produces false positives in the staleness cell.

Constraint 2: condition_delta stores raw before/after values, not a derived label.

Not stale: true. The raw before/after values. A derived label is a conclusion, not evidence — it cannot be audited independently of the gate that wrote it.

Both constraints were added in response to external architectural review before any scenario was run.

What we are waiting for

The packet cannot run against internally authored data. An agent checking a source it could have written is re-reading itself with extra latency.

Ken W Alger's Local Brain architecture is the first candidate external source for this test. If the post and code expose a source layer with provenance, ownership, and an agent-writable=false boundary, we run CLAIM-24 against it. If not, we wait for another source.

What this does not prove

If scenario 3 returns refused_stale and all seven scenarios return their expected results, this is what that proves:

The re-derivation gate correctly identified the TTL-valid + source-changed case on a seven-scenario packet against one external source.

Not at scale. Not across source types. Not against adversarial grant tampering. If Ken W Alger's approach solves the same problem through a simpler mechanism, the gate is not the only solution and we will say so.

The divergence cell is the test. If it returns ALLOW, we publish the failure.

Run it yourself

If you have a memory store with a provenance boundary the agent cannot write to, you can run this packet against it now. The seven scenarios and evaluation criteria are above. Reply with what you get on scenario 3 — that is the cell this entire claim turns on.

*Previous in this series: CLAIM-23 (tool-call grant gate, 7/7, 0 false-certainty errors). CLAIM-15B (governance-adjusted scorer failed on held-out packet — BM25 outperformed it). Full claim ledger: https://github.com/keniel13-ui/memory-authority-auditor

Top comments (0)