One broken byte, one broken check.

Access comes first. Your files stay in your Token Holder vault, and the assistant reaches them only with a bearer scoped to you: a grant you approve in your wallet, and can revoke from one page. Every vault read and write it makes lands on your usage chain, and the audit view recomputes that chain's integrity on demand.

There are two records, they work the same way, and the difference between them matters — so here is both.

The hosted usage chain covers everything the assistant does to your data. Each row is reduced to a canonical twelve-field projection — fixed field order, explicit nulls, no whitespace — and hashed together with the previous row's hash and a separator byte, so the rows are linked in order. Change a field, drop a row, or reorder two, and the recomputed head stops matching the stored one. That is what Verify integrity checks. The rows are chained; they are not individually signed.

The local file-activity ledger covers file writes on your own machine and goes one step further. Each event's diff is hashed, a canonical fourteen-field core is chained onto the previous event, and the resulting hash is signed with the agent's Ed25519 private key, which never leaves the machine. Token Holder holds the registration of the matching public key and can sign a statement binding it. Tamper anywhere — the diff, a field, a link, a signature — and exactly one check breaks; the verifier names it.