AETHMERE RESEARCH · GPM

The target changed.The old record stayed.

An owner revokes a deployment target. A new session still has the old record. Aethmere’s research tool checks whether that explicit claim can be released now.

Watch the narrated replay ↘Read the technical note

Research adapter · Synthetic project · Structured tool output only

01 / DEMO

One changed deployment target

About 69 seconds · English narration + captions

English synthetic narration and on-screen captions accompany this visual replay of recorded tool responses. It is not a live client recording; no deployment takes place. The requests and returned values appear below for inspection.

Download the video ↓Watch the scenario version with Chinese narration ↗

02 / GPM

Five requests, two decisions

First A passes. The owner then revokes A and admits B. A fresh Claude Code session and Codex both receive empty output for old A, while current B still passes.

Client and stage	Requested target	Current state	Tool result
Claude Code · Before	`staging-blue`	A current	Release`release · 1`
Claude Code · Fresh session	`staging-blue`	A revoked	Abstain`abstain · 0`
Claude Code · Same fresh session	`staging-green`	B current	Release`release · 1`
Codex · After	`staging-blue`	A revoked	Abstain`abstain · 0`
Codex · Same session	`staging-green`	B current	Release`release · 1`

One controlled run recorded by the author. Hosts were explicitly prompted to submit the test claims. Independent reproduction is still pending.

Inspect one complete post-revocation request and selected response fields

{
  "id": "claude-after-A",
  "client": "Claude Code",
  "at": "2026-09-23T12:03:03.625Z",
  "request": {
    "query": "Which synthetic target is approved?",
    "claims": [
      {
        "entity": "demo-project",
        "key": "approved-target",
        "value": "staging-blue",
        "source_fact_ids": [
          "F-DEMO-A"
        ]
      }
    ]
  },
  "result": {
    "decision": "abstain",
    "reason": "claim_set_not_closed",
    "policy_version": "gpm-i5-v3",
    "ledger_head": "4fab4f1617241cd0add37ce239e0175a5032a6ead68ff84e0c0df16cdcdf35a5",
    "claim_set_sha256": "71ea1ee15eb3627216a058db36b9ec3d9b051d510fe7ee3c7258b66d5b2ddfbe",
    "released_claims": []
  }
}

Download all five receipt excerpts (JSON) ↓

The download records a SHA-256 reference to the original evidence and identifies retained fields. A digest identifies bytes; it does not independently attest to client execution.

03 / Technical note

A retrieved record still needs a release decision

Read the GPM paper · arXiv v2 ↗

An old fact can remain in the history

A project first approves staging-blue, then switches to staging-green. The old record can explain a past decision. Whether it may support a new output depends on the current state. Finding the record does not answer that question.

The GPM paper studies persistent state semantics and a source-bound release contract. This demo makes one case observable: whether an explicit claim passes through the same tool after its source is revoked. An owner supplies the change; the system does not discover an external project change by itself.

The valid replacement still passes

A tool that refuses every request would also stop old A. The positive control matters: both clients also request current B and receive its structured released claim. The normal path remains available in this run.

Claude Code uses a scoped CLI-to-MCP bridge; Codex uses native MCP. The stale requests share a query and claim-set hash. Post-revocation receipts refer to the same policy version and ledger head. The transport changes while the observed release boundary stays consistent.

The boundary ends at this tool response

The tool checks explicit claims and decides whether to return released_claims. A host can still repeat a value from its prompt, use another tool, or act after a later state change. A real action needs another check at its execution boundary.

This research adapter is separate from the publicly distributed Agent Client. This page provides recorded results and the paper. The executable demo package is not distributed here; a video and JSON receipts do not replace independent reproduction.

Where ACS relates to this demo

This comparison uses ACS v0.1.0 at commit 27799c2. It identifies related behavior and gaps. No ACS conformance is claimed.

Scope	Observed here	Missing evidence
Core	Structured release or abstain decisions	ACS handshake, signatures, replay protection and host decision honoring
Provenance / Trace	Source IDs, decisions and timestamps	Required field-level provenance objects and event exports
Inspect / Crypto / Audit	Record hashes can be inspected	The inventory, signature and audit-chain implementations required by those profiles

Read the pinned conformance specification ↗

Three cases worth testing next

A revoked claim is released through this tool.
A valid claim with an exact source match is incorrectly refused.
A mixed valid and invalid claim set is partially released.

These are targets for a future review, not completed independent tests.