Resources

Evidence

Every state-changing action in KYA Pro writes an evidence row — a signed record of what happened, who did it, when, and why. Rows are linked together so any tampering after the fact is easy to detect.

Evidence rows are what your compliance packs are built on.

What creates evidence

An evidence row is written every time authority changes, a policy verdict fires on an action, a rogue signal is recorded, or a compliance pack is produced.

Each row includes at minimum:

  • evidence_id — a per-workspace number that always goes up (never repeats, never resets)
  • tenant_id — always set; keeps workspaces isolated
  • event_type — one of the codes above
  • actor_id — the account or agent that caused the row
  • occurred_at — UTC timestamp
  • payload — action-specific structured JSON
  • signature — tamper-proof mark showing the row hasn't been edited since it was written

Reading evidence

For most uses you don't read raw evidence rows — you generate a compliance pack, which bundles the relevant subset with human-readable framing.

Evidence shows up inline in several endpoints:

  • Grant responses include evidence_id — the id of the evidence row created by that action. See Delegations.
  • Chain-of-custody responses include the verification result for each handoff proof, which re-reads the signed record. See Principals.

Compliance packs are the way to pull evidence at scale.

Integrity guarantees

The signing model is documented at Security › Signed evidence chain. Two things matter:

  1. Each row can't be edited without detection. Every row carries a signature over its contents. Change the record after it was written and the signature stops matching.
  2. The order can't be changed without detection. Rows are linked so inserting, deleting, or reordering them shows up during verification.

The verifier walks the chain and reports the first mismatch it finds. Verification uses the public key at /.well-known/pack-verification-keys.json — no KYA credentials needed.

Compliance pack verifier

A regulator handed a KYA Pro pack does not need any KYA credentials to verify it. They fetch the public key from /.well-known/pack-verification-keys.json and run the same check the API does.