INCIDENT WINDOW2026-09-29T02:53:10.000Z — 2026-09-29T02:56:10.000Zall times UTC · plate CMP-YJ2T · registry in.xchk.io
VERIFYING — recomputing 2 record hashes and 1 seal hashes locally…
(requires JavaScript; the server-side scan at generation time reported:
INTACT — window anchored at seq 16317)
ATTENTION· issuer verdict ADJUDICATED
1 reference needs your attention — every one already carries a written human finding.
REFERENCE REUSE 1
b596e1226bfbed1ee2a049a6→no row in this window — ⚖ flush retry by sean@maclawran.ca “Aug-8 red-team exhibit: authorized during the drill, recorder deliberately withheld; no production action”
One issued reference carrying divergent host entries — each reference authorizes exactly one action, so this is fabrication evidence until examined.
Each reference links to its flagged row below; the same reference is flagged in both custody tables where it appears in both. A recorded finding never removes an exception — it is printed beside it and the row stays flagged. Counting note: 1 of the window's references were demanded (the action ran: allowed, or attested and approved) and 1 are accounted for. References that were never demanded — refused ceremonies, attests nobody approved, actions predating the recorder (0), and the open in-flight window (0) — are not omissions and are not counted as such.
1. License & registration — the owner behind this agent
Before what the agent did: who owns it, whether that owner is a verified person (the license),
and that this plate is registered to them on this node (the registration). Every record and approval below
inherits its authority from here — like a roadside stop, license and registration come first.
owner · enrolled baseline
Registered owner
sean@maclawran.ca · uid YT4qhKFiihMliSHhurgIHYRM0IV2 — plate CMP-YJ2T on in.xchk.io, issued 2026-07-12T15:53:01Z · full plate record in Section 2
License — identity verified
ENROLLED2026-07-03T08:39:53Z
Email verified
2026-07-03T08:39:53Z
Owner passkey
3 registered __henOA5um2iUX…
KYC (Didit)
VERIFIED legal name: Sean Michael Mac Guire 2026-07-04T05:22:43Z source: registry user record (Didit webhook) Didit session 2b358bd6-083c-4dc7-9278-d9972fa67d7e
PINNED — cred sb5gHjiA_EhCUhAA…, rpId in.xchk.io, origin https://in.xchk.io, since 2026-08-18T06:56:09Z
The registration signature is the owner's own WebAuthn key, host-verified — the owner asserting
authority over this machine's agents, which the platform cannot forge. Where a ceremony in Section 6 is tagged
owner, the approver's identity equals this registered owner (license and registration match). A delegate
tag means a different person approved, and their authority to do so must be established separately.
2. Subject agent (license snapshot at generation)
CMPYJ2TSean
Rendered from the record fields below — the picture is a reading of the data, never evidence itself.
Public roadside check of this plate: https://in.xchk.io/ (plate lookup) — license status is
independently checkable there at any time. Per-record desk condition appears in each record below (in-band).
3. Summary
2 recorded actions in the window
(0 allow, 1 attest, 0 forbid);
1 sealed forensic windows (0 attested-silence);
1 human attestation ceremonies referenced.
4. Action records (the dashcam chain)
Flagged rows:magenta = reference reusered = unmatched / misboundamber = unaccounted — flagged in both the registry and host tables. ⚖ marks a human finding recorded beside the exception; the row stays flagged either way.
#
time (UTC)
disposition
tool/area
summary
run
cond.
authRef
recordHash
16317
2026-09-29T02:53:15.675Z
attest
terminal
cd /Volumes/2TB-FAST/sean-overflow/src/xchk/xchk-server; sed -n 1,60p src/services/ticketSigner.js | grep -n "SECRET\|process.env\|function \|module.exports" | head -12
cd /Volumes/2TB-FAST/sean-overflow/src/xchk/xchk-server; sed -n 1,60p src/services/ticketSigner.js | grep -n "SECRET\|process.env\|function \|module.exports" | head -12
4A. Visual playback — the footage, rendered from the records above
Playback is generated in this browser from the embedded records only — the same bytes the verifier
checked. Colors: ■ allow · ■ ceremony query ·
■ human response · ■ refusal.
These colours describe NORMAL operation — a refusal is the gate working, not a fault. Evidence
exceptions are never a colour alone: they carry a ⚑ badge naming them (⚑ REUSED, ⚑ UNACCOUNTED,
⚑ MISBOUND, ⚑ UNMATCHED, ⚑ FAILS RECOMPUTE) on the tinted rows in the tables above and below.
Streak length = time on task. Playback STOPS on any record that fails recomputation.
4B. Host recorder chain — the second custody domain
The agent's host keeps its own hash-chained record of what it executed, flushed to the
registry in segments. It is embedded here so this file carries BOTH custody domains: the registry's record of what was
authorized (Section 4) and the host's record of what it did. The verifier below recomputes every entry hash,
checks each segment continues the previous head, matches issued authorization references against host entries
(accounting), and compares each matched entry's intent hash against the registry's stored content hash of the authorized
action (content binding). An authorized action with no host entry is an accounting gap the HOST cannot detect or
manufacture away — only the issuer can see it; that asymmetry is the point.
An empty segment is the host's affirmative statement that nothing executed in its window — silence
attested from the host side, corroborating the registry's zero-issuance seals in Section 5 (bilateral silence).
4C. Issuer reconciliation verdict (signed statement by the registry)
Computed by the registry at export over this window and embedded verbatim inside the signed
payload. Chain recomputation (Sections 3/3B) is checked offline by this file; the verdict below additionally reflects
issuer-custody facts the file cannot recompute alone (ceremony pairing, in-flight grace, binding activation, manager
liveness, gate self-attestation). The lamp word is a recomputed theorem, not an asserted label.
Coverage lamp
ADJUDICATED
Reconciled
false
Demanded / accounted
1 / 1
Content-verified
1
Unaccounted (omission evidence)
0
Unmatched (fabrication)
0
Misbound (post-activation)
0
Legacy pre-binding
0
Reference reuse
1
Vacuous
no
Bilateral silence
ATTESTED (both custody domains)
In-flight (open window)
0
Recorder activated
2026-08-08T00:24:30.298Z
Binding activated
2026-09-29T02:56:05.588Z
Manager (host supervisor)
reporting (last —)
Gate self-attestation
modified
Host segments anchored
19578/19593 carry a public-chain no-later-than bound
Anchored seals are corroborated on the Ravencoin blockchain: the OP_RETURN of the transaction shown
carries the sealHash (chained to the previous seal's anchored hash), timestamping the window against a public chain
this registry does not control. Verify with any RVN explorer. Anchoring is corroboration, never a gate — a pending
anchor means the transaction had not yet confirmed at export time.
An attested-silence seal is an affirmative, hash-chained statement that no actions were authorized in
that window — the absence of activity is itself evidenced, not inferred.
CMP-YJ2T.403 (via Claude Code) wants to cd /Volumes/2TB-FAST/sean-overflow/src/xchk/xchk-server; sed -n 1,60p src/services/ticketSigner.js | grep -n "SECRET\|process.env\|function \|module.exports" | head -12
User proof — who authorized this, end to end. Each webauthn ceremony carries the verbatim
WebAuthn assertion (clientDataJSON, authenticatorData, signature) and the approver's registered public key,
both embedded in the signed payload. The sealed attestation hash commits to webauthnCredentialId
and sha256(authenticatorData), so the assertion is bound to the chain: this file's verifier
recomputes sha256(authenticatorData) and matches it to the sealed digest (the binding line
in the user-proof column). Any WebAuthn library can additionally re-verify the signature against the embedded public
key offline — this file hands over the material to do so without trusting xChk.
Identity. The live photo is captured on the approver's device during the ceremony; the
baseline is the face enrolled beforehand. Shown side by side so the live approval can be checked against the
enrolled reference — a ceremony photo with no baseline is a face; with one it is an identity claim someone can
adjudicate. Photo bytes travel inside this file as data URIs; the attestation's chained hash seals the references to
the decision.
7. Verification recipe (in-band — no xChk software required)
Each record's recordHash = SHA-256 of the canonical JSON of its fields
(keys sorted lexicographically, undefined omitted, integers/strings/booleans/null only), with field list:
v, agentId, plate, seq, ts (ISO-8601), harness, runSeq, runRef, area, tool, summary, paramsHash, amount,
disposition, code, reason, deskCondition, continuityClass, authRef, prevHash.
Each record's prevHash must equal the previous record's recordHash; sequence numbers must be contiguous.
An edit breaks a hash; an omission breaks the sequence and the link.
Each seal's merkleRoot = pairwise SHA-256 over the window's recordHashes in sequence order (odd leaf carried up);
sealHash = SHA-256 of the canonical seal fields; seals chain by prevSealHash.
Each host entry's entryHash = SHA-256 of the canonical JSON of
localSeq, authRef, tool, intentHash, resultHash, startedAt (ISO-8601), endedAt, prevHash
(same canonicalization as step 1); the first entry's prevHash is the segment's prevSegHead, each
subsequent entry links to the previous entryHash, and the last entryHash is the segment's segHead (an empty
segment carries its prevSegHead forward). Accounting: every windowed registry record's authRef should be cited
by exactly one host entry; content binding: that entry's intentHash must equal the record's paramsHash.
The embedded script below performs steps 1–4 automatically when this file opens; the banner reports the verdict.
The same computation can be reproduced with ~10 lines of Python (hashlib + sorted-keys json).
7A. Registry signature over this package
The registry signed this export (RS256). The statement binds the exact embedded
evidence payload (SHA-256 47872628f35fdfe9815210f3bab7924c9971d72d767a0a1b6735ace0dfc48051), the chain head, and the export metadata.
Verify against the registry's published keys at
https://in.xchk.io/.well-known/xchk-registry (token_use
incident_package). The verifier below also recomputes the payload hash — a match proves the
evidence in this file is byte-identical to what was signed.
8. FRE 902(13) certification — record generated by an electronic process
I, , am employed as and am qualified to
certify records of the xChk registry system operating at in.xchk.io. The records in Sections 3–5 were generated
by that system's regularly conducted, automated authorization and sealing process, at or near the times shown, as a regular
practice of that activity. The process produces hash-chained records whose integrity is verifiable by the recipe in
Section 7. Executed on .
Signature:
8. FRE 902(14) certification — data copied and verified by hash
I certify that the digital records embedded in this file are true copies of the registry's records, and
that verification was performed by recomputation of the SHA-256 hash values shown in Sections 3–4, which matched the
values recorded in the registry's chain at the time of export. Executed on .
Signature:
Print this page for a filing exhibit; the tables paginate. This file also embeds a
machine-readable JSON copy of every record and seal above — the verifier reads it on open, and you can extract it
here. Its SHA-256 is 47872628f35fdfe9815210f3bab7924c9971d72d767a0a1b6735ace0dfc48051, the same value covered by the registry signature.
9A. Machine-readable — the underwriter's incident schema (JSON)
The same window as this package, as the common incident schema an underwriter reads (Trout et al., "Underwriting the
Agent Economy", §II.1): controls in force, oversight posture, near misses, kill-switch state, the forensic-data counts.
Harm and loss are left null — the registry never asserts a harm it did not observe; a named admin states them.
Moved here from the console on 18 Sep 2026: the schema belongs with the report it describes, not beside a button.
Generated 2026-09-29T03:25:52.053Z by registry in.xchk.io. This file is
self-contained and self-verifying: opening it in any modern browser recomputes every hash above from the embedded
records, offline. It does not ask to be trusted; it asks to be checked.
All times in this package are UTC (ISO 8601, 24-hour clock).
WHAT THIS FILE PROVES — AND WHAT IT DOES NOT
Proves
Authorization: every action shown was decided by the gate before it ran, and a ceremony marked approved carries the approver's own signed proof. Tamper-evidence: altering or reordering any record breaks its hash and every hash after it — your browser checks this, not us. Omission-evidence: two independent chains (this registry's, and the host recorder's) are reconciled against each other, so an action that ran without being recorded shows up as an absence. That is what the ⚑ UNACCOUNTED rows are.
Does not prove
That nothing ran outside the gate. The recorder sees what passes through the harness hook. An action that never reached the gate leaves no reference and no entry, and reconciliation cannot see it. Bilateral silence and host supervision are the backstop, not this chain. That execution matched the authorization. The host binds what it declared it was doing to what was authorized; it does not prove the effect matched the declaration. Anything outside the window below. This is a slice, records #16317–#16318 of this agent's lifetime chain — sequence numbers run continuously for the life of the plate, so a gap at either edge is this window's boundary, not a missing record.
Glossary
plate
The agent's licence number. Issued by the registry, unique for life, never reissued to another agent — so evidence citing a plate resolves to exactly one agent, forever.
allow / attest / forbid
What the agent was permitted to do in an area of work. allow = it proceeds and is recorded. attest = it stops and a human must decide. forbid = refused outright. With no permission on file the default is attest — nothing is refused merely for lacking a permission, it stops and asks.
approved / denied
A human's answer to an attest. approved = a named person said yes, with their own signed proof; denied = they said no. Both are binding.
authRef
The receipt number the gate issued for one decision. Each one authorizes exactly one action — which is why the same reference appearing twice, describing different things, is evidence of fabrication.
intentHash / paramsHash
A fingerprint of what the action was. The registry stores the fingerprint of what it authorized; the host stores the fingerprint of what it says it did. They must match — if they do not, the row is flagged ⚑ MISBOUND.
seal / merkle root
A periodic signed statement covering a batch of records. A seal over zero actions is an affirmative claim that nothing happened in that window — silence on the record, rather than absence of record.
anchor
A seal's fingerprint published in a public blockchain transaction. It proves the record existed no later than that block — a clock this registry does not control.
the two chains
The registry chain (what was authorized) and the host recorder chain (what the machine says it did) are kept independently. Comparing them is what makes a missing action visible; one chain alone could never show you what is not in it.
⚑ badges
UNACCOUNTED = authorized and it ran, but the host has no record of it. REUSED = one receipt number covering several different actions. MISBOUND = the host's record does not match what was authorized. UNMATCHED = the host cites a receipt this registry never issued. FAILS RECOMPUTE = the record's own hash does not reproduce — the strongest finding there is.
⚖ adjudication
A named person examined an exception and wrote down what they found, with the date. It sits beside the exception and never removes it — the row stays flagged. Findings that name a danger (a recorder fault, a confirmed fabrication) deliberately do not quiet the alarm.
