CAIN-42 CAIN Studio

Developer documentation

Evidence

Last reviewed 31 August 2026

All docs

Every decision is written to a durable, tenant-scoped record with the stage-by-stage verdicts that produced it. The purpose is the incident review six months later, not a dashboard today.

What is recorded#

identity, intent, action, resource, tenant, policy and policy version, risk, verification, approval, decision, enforcement, execution, result, timestamp, correlation id.

Retrieving it#

cain inspect                       # recent decisions
cain inspect --chain <cor_...>     # one correlated agent run, in order
cain explain <decision-id>         # stage by stage, with the policy version
cain audit --decision <id>         # the signature covering it
cain audit                         # who has read evidence

Searchable by decision id, agent, tenant, action, time, resource and correlation id.

Correlation#

Calls made during one agent run share a correlation id, so a run reads as a sequence rather than scattered rows. cain inspect --chain reports the outcome, where it stopped, and -- importantly -- would_block_if_enforcing: what a shadow deployment would have refused.

Signatures#

cain audit --decision <id>

Decisions are signed so alteration is detectable. Signing is deterministic: the same decision signs identically every time, which is what makes a changed signature meaningful.

This is tamper-evidence, not tamper-proofing, and not third-party notarisation. The API response says so in its own scope_note field.

Reading evidence is itself recorded#

"Who looked at this decision" is the second question an investigation asks. cain audit shows that log, including which credential type was used.

A failure to write an access-audit row never fails the read -- turning a logging fault into an outage would be worse than the gap it closes.

Retention#

evidence:
  enabled: true
  retain_days: 90

Decisions are retained for the life of the account by default so they remain available for review. See the DPA for deletion.