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

Source: Dev.to

Overview

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

A time‑to‑live (TTL) grant has an expiry date: when the clock runs out, the gate blocks.
However, a grant can become invalid before the clock expires if the source condition that justified the grant changes (e.g., a role reassigned, a scope narrowed, a recipient replaced). Timestamp‑only expiry cannot catch this, so the gate may allow an action on stale authority.

Gate Logic

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 the snapshot recorded at issue time with the current source state.

• If they match → ALLOW
• If they diverge → REFUSED_STALE

The agent-writable=false constraint is essential: the source must be outside the agent’s write jurisdiction and fetched at the moment of execution.

Example Payloads

// 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" }
  }
}

In this example, the grant’s clock still shows 47 hours remaining, but the source changed two days ago.

Evaluation Criteria

Scenario 3 (TTL valid + source changed) is the pivotal claim: if the gate returns ALLOW, the architecture fails because it would be an expiry gate with extra steps rather than a true staleness gate.

Constraints

1. Separate result cells – refused_stale and refused_unreachable must be distinct. Conflating them yields false positives.
2. Raw condition delta – condition_delta must store the exact before/after values, not a derived label. Evidence must be auditable independently of the gate that produced it.

Both constraints were added after an external architectural review, before any scenario was run.

External Source Candidate

Ken W. Alger’s Local Brain architecture is the first external source considered for this test. If the post and code expose a source layer with provenance, ownership, and an agent-writable=false boundary, CLAIM‑24 can be run against it. Otherwise, we will wait for another suitable source.

Claim Outcome

If scenario 3 returns REFUSED_STALE and all seven scenarios return their expected results, this demonstrates that the re‑derivation gate correctly identifies the TTL‑valid + source‑changed case for a seven‑scenario packet against one external source.

Limitations: not at scale, not across source types, not against adversarial grant tampering. If Ken W. Alger’s approach solves the same problem more simply, the gate is not the sole solution, and we will acknowledge that.

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

If you have a memory store with a provenance boundary the agent cannot write to, you can run this packet now. Reply with the result for scenario 3—the cell on which the entire claim hinges.

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: