CLAIM-24 SourceAdapter candidate: narrow FIPSign CA adapter test

[keniel13-ui]

BODY

Hi German — following up from the DEV comment thread on your CLAIM-26 article.

The open slot

CLAIM-24 in the Self-Correcting Systems series tests whether a re-derivation gate catches TTL-valid but source-stale grants. The gate reads from a source the agent cannot write to, fetches current signed state at execution time, and compares it against what the grant recorded at issue time.

The harness has been running against a mock source adapter since June 4. The mock validates the gate structure — it confirms that a timestamp-only gate fails the divergence cell and the re-derivation gate catches it. But mock-source validation is a different evidence tier than real external-source evidence.

The CLAIM-24 SourceAdapter contract requires:

• An external source the agent cannot write to
• Signed responses (so a substituted or rolled-back source fails the signature check, not just a storage check)
• A readable current state the gate can compare against the grant's recorded state at issue time

FIPSign's CA matches that shape. The certificate represents a signed, external, agent-unwritable authority state.

The narrow test

One question before anything else: can the gate fetch a signed source state from FIPSign's CA, verify the signature, and distinguish current signed state from stale or substituted state?

Concretely:

1. Gate fetches current certificate state from FIPSign CA at execution time
2. Gate verifies the ML-DSA-65 signature against the public key
3. Gate compares current certificate scope/status against what the grant recorded at issue time
4. If they diverge — scope narrowed, certificate revoked, recipient changed — gate returns REFUSED_STALE
5. If a substituted or rolled-back state is provided, signature check fails before any staleness comparison

If those five steps hold, CLAIM-24 moves from mock-source validation to real external-source evidence.

What we would need

A minimal read path against FIPSign CA: something the gate can call at execution time to fetch the current signed state of a certificate and verify it. The CLAIM-24 packet JSON is ready to share — seven pre-registered scenarios, divergence cell locked before running.

Happy to open a follow-up issue in the research repo with the full packet if FIPSign has an endpoint that fits the SourceAdapter contract.

References

• CLAIM-24 pre-registration: https://dev.to/zep1997/the-grant-was-still-valid-the-source-had-changed-claim-24-pre-registration-self-correcting-52o2
• CLAIM-26 article (where this thread started): https://dev.to/zep1997/-the-agent-was-allowed-to-act-the-log-could-not-prove-whyai-memory-judgment-claim-26-4o8k
• Research repo: https://github.com/keniel13-ui/ai-memory-judgment-demo

— Keniel (@zep1997)

[mobydickfinance]

The five steps map directly to existing endpoints.

1. GET /ca/certificate/:certId — fetches current certificate state including status.revoked, status.expired, and status.expiresAt
2. The certificate is signed with ML-DSA-65, verifiable against GET /public-key
3. Certificate scope is in the meta fields recorded at issuance — comparable against the grant's recorded state at issue time
   Note: the meta field is available on PQCert format only — not X.509. The SourceAdapter test uses PQCert.
4. If revoked or expired — status.revoked: true or status.expired: true — gate returns REFUSED_STALE
5. If a substituted or rolled-back state is provided — signature verification fails before any staleness comparison

One thing worth naming clearly: in FIPSign, certificate scope is immutable after issuance — by design, because a mutable scope would break what the signature covers. The SourceAdapter detects divergence via revocation or expiry, not via scope mutation within a certificate lifetime. That's not a gap specific to FIPSign — it's how certificate authorities work. If scope changes, the correct operation is revoke and reissue, which is detectable.
The read path is live and free — no token cost on GET /ca/certificate/:certId. Everything needed to build the adapter is in the public API and the developer guide at fipsign.dev/guide.

[tacoda]

Update: there is more in place with the separate repo solution. There is active drift-detection and the plugins are read-only. This is a bit more robust than it was before, but a separate authority would be the last binding piece.

[keniel13-ui]

@mobydickfinance The immutable scope point is actually the clearest thing you could have said. I was
thinking about this wrong — scope mutation within a certificate lifetime is not how CAs
work, and re-deriving against a signed state that cannot change mid-life is a cleaner
contract than what I had in the mock. Revoke-and-reissue is the correct operation and
it is detectable. That is not a gap, that is just how the boundary actually works.

PQCert format is fine for the adapter test. The SourceAdapter just needs to fetch
current state, verify the signature, and compare against what the grant recorded at
issue time. If revocation or expiry happened since the grant was issued, that is the
divergence cell.

Going to build the adapter against those two endpoints and run the seven pre-registered
scenarios. Will follow up here with results once it is done.

[keniel13-ui]

@tacoda Drift-detection plus read-only plugins is the right shape. The separate authority point
is exactly what CLAIM-24 is testing from the other side — the gate only earns the
evidence if the source it reads is one the agent cannot produce or modify. Read-only
gets you partway. Signed and external closes it.

Looks like we are converging on the same architectural layer from different directions.

[keniel13-ui]

@mobydickfinance Hey German, quick follow-up on the FIPSign CA adapter path.

I implemented a CLAIM-24 SourceAdapter for the contract you described:

• GET /ca/certificate/:certId
• GET /public-key
• PQCert-style state with status/meta fields

The adapter is public now and passes a local contract test through my existing re-
derivation gate.

What I need to run the real external-source test is just:

1. the FIPSign CA base URL
2. one or more test certificate IDs I can safely fetch
3. if available, a minimal example of the returned PQCert JSON shape
4. optional: the exact payload/signature format for ML-DSA verification, if you want me
   to test signature verification too

For now I’m not claiming external validation. I’m only at “adapter implemented, live CA
inputs pending.”

Once I have a base URL + test cert IDs, I can run the seven frozen CLAIM-24 scenarios and
report exactly which cells are real external-source results and which remain mock-only.

[mobydickfinance]

Here are the live CA inputs for the CLAIM-24 SourceAdapter test.

Base URL: https://api.fipsign.dev

API key for the test project: pqa_443cc89fc0ee48b662e70c31a1a7167f5b565a8c1e3023137438dd56d630e742

Test certificate IDs:

certId	status
cert_95ba1e49b71e0fc0669790e0baa2fc75	active
cert_832f3a3b65ec5897eb1803789899281e	revoked — revokedAt: 1781195531

Endpoints:

• GET https://api.fipsign.dev/ca/certificate/:certId — requires X-API-Key header
• GET https://api.fipsign.dev/public-key — no auth required

Exact response shape for GET /ca/certificate/:certId:

{
  "success": true,
  "certificate": {
    "type": "CA_CERT",
    "id": "cert_...",
    "subject": "...",
    "publicKey": "<base64 ML-DSA-65 1952-byte public key>",
    "caId": "ca_...",
    "issuedAt": 1781195426,
    "expiresAt": 1783787426,
    "algorithm": "ML-DSA-65",
    "standard": "NIST FIPS 204",
    "meta": { "test": "claim24", "scenario": "active" },
    "signature": "<base64 ML-DSA-65 signature>"
  },
  "status": {
    "revoked": false,
    "expired": false,
    "revokedAt": null,
    "expiresAt": 1783787426
  }
}

The divergence cell maps directly to status.revoked: true for the revoked cert. The gate checks status.revoked or status.expired — if either is true, the source state has diverged from what the grant recorded at issue time.

ML-DSA-65 signature verification: the signature field covers the canonical JSON of the certificate object with all fields except signature itself, keys sorted alphabetically. Verify against the public key returned by GET /public-key.

Both certIds will remain live for the duration of the test. When you're done I'll clean up the test project.

[keniel13-ui]

man thank you for this. the live run is done and the divergence cell caught a real
revocation from your CA, exactly the failure the whole claim was built around.

results and the run script are public now in commit 90db04d. i kept the boundary honest:
mapped subset only, no signature verification claimed.

one housekeeping thing: please rotate or kill the test api key now that the run is
recorded. dont want it sitting live on either side.

if youre up for one more round, two cells still need live fixtures to finish the full
seven. first is recipient-changed drift, a cert where the subject or recipient field
changes after i record the grant against the original. second is scope-narrowed drift, a
cert that starts with a wider scope and gets reissued or updated narrower.

doesnt need to be fancy, just two cert ids i can read before and after the change so the
gate sees real divergence instead of a fixture i authored myself. appreciate you brother,
this moved CLAIM-24 from mock/harness-only to real external-source mapped subset.mobydickfinance

[mobydickfinance]

Here are the two additional fixtures. API key rotated as requested — new key below.

API key (rotated): pqa_39da011471f91b9652ef6fd6db239a7b467dac160417a6aaa3a0851500171e6b

---

Fixture: recipient-changed drift

The grant records the original cert. After the grant is recorded, the original cert is revoked and a new cert is issued to a different recipient.

role	certId	status
grant records this	cert_bfdb36ff56b7ae6acd7440f26e4237fd	revoked — meta.recipient: "agent-A"
current state	cert_da4c5c6648d147c4c279fb72d53df1ea	active — meta.recipient: "agent-B"

Gate behavior: fetch cert_bfdb36ff56b7ae6acd7440f26e4237fd → status.revoked: true → REFUSED_STALE.

[mobydickfinance]

Fixture: scope-narrowed drift

The grant records the wide-scope cert. After the grant is recorded, the wide cert is revoked and a narrower cert is issued.

role	certId	status
grant records this	cert_a2ce09a774df3635ed11cb302b75866d	revoked — meta.scope: "read write execute"
current state	cert_89a1fdf358b7210b03cff2f3bd227cd8	active — meta.scope: "read"

Gate behavior: fetch cert_a2ce09a774df3635ed11cb302b75866d → status.revoked: true → REFUSED_STALE.

---

Both fixtures follow the same divergence pattern as the first run: the grant-recorded cert is revoked, the gate detects status.revoked: true, and returns REFUSED_STALE. The scope and recipient fields in meta document what changed — the gate reads revocation status, not field diffs.

Let me know when the run is done and I'll clean up the test project.

[keniel13-ui]

@mobydickfinance thank you for moving this forward and for rotating the key.

i want to keep the evidence boundary clean here. these fixtures are useful, but they are
still revocation-mediated replacement cases, not clean cells 6 and 7 under the frozen
standard.

mechanically, the gate only ever fetches the grant-recorded cert id. if that cert now
returns status.revoked: true, the verdict is REFUSED_STALE because of revocation, and the
raw field that moved is status. that is the same live signal as cell 3. the replacement
cert never enters the comparison because the grant does not point at it.

for cell 6, the distinct evidence would be subject or recipient drift on the grant-
recorded cert while status stays active, not revoked, not expired.

for cell 7, same shape but the scope field narrowing while status stays clean.

the acceptance test is simple: GET the same cert id before and after, and the only raw
field that moved is subject for cell 6 or scope for cell 7. if status moved, it is cell 3
again no matter what else changed.

so i would label these separately as revocation-mediated replacement fixtures. still
valuable, and i will record them as that, but i am not counting them as cells 6 and 7
validation because that would collapse the exact distinction the schema doc was trying to
protect.

and if FIPSign does not support clean-status metadata drift, that is a real finding too.
then the honest result is that cells 6 and 7 need a dedicated test-fixture path or a
source type that exposes post-issue field drift directly.

[mobydickfinance]

You are right to keep the boundary clean, and the distinction is valid.
FIPSign does not expose post-issue metadata drift on a stable identifier by design. Certificate fields — subject, scope, meta — are immutable after issuance because mutability would break the ML-DSA-65 signature that covers them. If those fields need to change, the correct operation is revoke and reissue. That is not a gap in FIPSign — it is the property that makes the certificate a trustworthy source in the first place.
So the honest finding is this: FIPSign can provide real external-source evidence for revocation-based cells, but it cannot provide clean-status field drift because it is structurally incapable of it. A CA is not the right source type for cells 6 and 7.
What cells 6 and 7 need is a mutable identity registry — a source where an entity's attributes can be updated without invalidating the identifier. Something like a user directory, a device registry, or a role store where subject or scope can drift while status stays clean. That is a different source contract than a CA.
The revocation-mediated fixtures are still worth recording as a separate category. They demonstrate that the gate catches the correct signal when a CA is the source. But you are right that collapsing them into cells 6 and 7 would obscure exactly the distinction the schema was trying to protect.
If you find a source type that fits the clean-status drift contract, I am happy to provide equivalent fixtures from that side.

[keniel13-ui]

@mobydickfinance this is exactly the answer the experiment needed, and honestly it is better than a
fixture would have been.

i am recording it as a source-contract finding: certificate fields are immutable after
issuance by design, because mutability would break the signature that covers them. so
revoke-and-reissue is not a CA limitation, it is correct CA behavior. a CA speaks in
status signals, not drift signals. cells 6 and 7 were asking a question your source type
structurally cannot be asked.

that actually sharpens the architecture instead of weakening it. the seven cells span two
different source contracts: immutable credential sources for revocation-based evidence,
and mutable identity registries for clean-status drift. a re-derivation gate needs to
know which contract its source speaks.

i will take you up on the offer. next step on my side is publishing a minimal registry
source contract, same way we did the grant schema: stable identifier, a read endpoint
returning subject, scope, and status, where subject or scope can change post-issue while
status stays clean. once that doc is up i will link it here, and equivalent fixtures from
your side would make cells 6 and 7 real external evidence.

and agreed, the revocation-mediated fixtures get recorded as their own category. they
earned that.

[keniel13-ui]

@mobydickfinance doc is up here:
https://github.com/keniel13-ui/ai-memory-judgment-demo/blob/main/claim_24/REGISTRY_SOURCE_CONTRACT.md

this is the source contract for the cells 6 and 7 path. it keeps the CA finding intact:
FIPSign speaks in status signals, and that is correct for immutable signed credentials.
cells 6 and 7 need a different source type, a mutable identity registry with a stable
identifier where subject or scope can change while status stays clean.

i also added the normalization lesson from the live CA run: volatile fields like
updated_at, etags, version counters, or server time need to stay out of the normalized
snapshot, otherwise every read diverges for the wrong reason.

if your side has an equivalent registry-style source or can expose a small test fixture
with two observable states on the same stable id, this doc should be the exact contract
for it.

[mobydickfinance]

Contract reads clean. The two-contract finding is the right result.
One clarification on section 5: I did not offer to provide fixtures for cells 6 and 7 from FIPSign. What I said was that if a fitting registry source exists, I am happy to help from the credential side — meaning FIPSign as a signing layer on top of a registry, not as the registry itself. FIPSign cannot be the source for those cells by design, and that was already established in the thread.
If you find an external registry that fits the contract, reach out. But the fixtures need to come from whoever operates that registry.

[tacoda]

We are ready to get started with this once it's a bit more well-defined. Policies should have everything in place to build a CA on top.