Agent Dashcam — Black Box Report

TRUST ◦ VERIFY ◦ PROOF

Generated 2026-08-24T07:24:20.726Z by registry in.xchk.io. This file is self-contained and self-verifying: opening it in any modern browser recomputes every hash below 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).

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.

Registered owner	sean@maclawran.ca · uid YT4qhKFiihMliSHhurgIHYRM0IV2 — plate OPS-YDDS on in.xchk.io, issued 2026-07-12T15:53:01Z · full plate record in Section 2
License — identity verified	ENROLLED 2026-07-03T08:39:53Z	Email verified	2026-07-03T08:39:53Z
Owner passkey	3 registered __henOA5um2iUX…	KYC (Didit)	not required
Registration signature (owner command-signing key)	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)

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

6 recorded actions in the window (2 allow, 2 attest, 0 forbid); 12 sealed forensic windows (11 attested-silence); 2 human attestation ceremonies referenced.

4. Action records (the dashcam chain)

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.

5. Window seals

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.

6. Human attestation ceremonies in the window

When (UTC)	2026-08-24T07:01:10Z	Verdict	completed OWNER
Approver	sean@maclawran.ca	Reached	push, sms, telegram
Method	webauthn	Area / tool	operations terminal
User proof	webauthn ✓ · cred Yqa88hkURHnP… · public key ✓ · binding…
Prompt	⚠️ delete in root path Shell Command `( rm -rf /tmp/bobo ); echo __XCHK_UID__:$(id -u):$(whoami)__`
Record hash	85fd5c516e4acaef9aef36e22f4bd46c028bf035be1379f9b2a84ceb3b99e84a	Blockchain anchor	1a0b9a716a9c11071799e95758b355a22af24359e3d269e1fa39b75f836136a4

When (UTC)	2026-08-24T07:23:35Z	Verdict	completed OWNER
Approver	sean@maclawran.ca	Reached	push, sms, telegram
Method	webauthn	Area / tool	operations terminal
User proof	webauthn ✓ · cred Yqa88hkURHnP… · public key ✓ · binding…
Prompt	⚠️ delete in root path Shell Command `( rm -rf /tmp/bobo ); echo __XCHK_UID__:$(id -u):$(whoami)__`
Record hash	3f098dfb23e5c4d607fee827929af4add2bd11f76f176b4c2d38906768c73122	Blockchain anchor	865db2d87e36b1b36e887b4658bb4964e9721d47486802259a3b34d81253827a

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)

1. 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.
2. 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.
3. 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.
4. 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.
5. 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 5ae05ff5fab4e5979ba806ff0f7f255b70c3d0833bc69f80ba79ea3ddb86a427), 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.

payload hash: checking…

8. FRE 902(13) certification — record generated by an electronic process

8. FRE 902(14) certification — data copied and verified by hash

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 5ae05ff5fab4e5979ba806ff0f7f255b70c3d0833bc69f80ba79ea3ddb86a427, the same value covered by the registry signature.

Download evidence JSON Show it here