Skip to content
Octopus Core

Evidence & Replay

AI should produce evidence, not just claim completion

A conversational explanation is not proof. Important AI actions should leave inspectable records — inputs, model and version, policy decision, tool invocation, human approval, output and verification — that can be replayed.

What gets recorded

Evidence for a governed action

Principles

Store-untrusting, fail-closed, verdict-as-evidence, pinned contracts and tamper-evident records — expressed in plain operational terms.

  1. Inputs & context

    What the system saw, and where it came from (provenance).

  2. Model & version

    Which model and version produced the output.

  3. Policy decision

    What was allowed, and under which policy.

  4. Tool invocation

    Which tools were called, with what parameters.

  5. Human approval

    Who approved a high-impact action, and when.

  6. Output & verification

    The result, and any verification applied.

  7. Failure state

    If something failed, the record fails closed — not silently.

From explanation to evidence

An explanation tells you what a model probably did; evidence lets you check what actually happened. Octoryn records the provenance of each action — the model and version, the policy decision, the tool that was invoked, any human approval, the output, and the verification applied to it. Because the record is captured as the action runs and is tamper-evident, it can be reviewed later without depending on the model to recount its own reasoning.

  • Provenance for each action, captured as it runs
  • Model and version recorded alongside the policy decision
  • Tool invocation and any human approval linked to the output
  • Verification result kept with the record
  • Tamper-evident rather than reconstructed after the fact

What replay can and cannot do

Replay walks back through a recorded run — the inputs, decisions, tool calls, approvals, and outputs — so a reviewer can follow the path an action took step by step. What it does not claim is to perfectly re-run a model and reproduce its output, since model behaviour can vary; replay is a faithful record of the run, not a re-execution of it. Read this way, replay answers "what happened and why" rather than "what would happen if we ran it again".

  • Steps through recorded inputs, decisions, and outputs
  • Shows what was decided and on what basis
  • Supports audit and incident review
  • Not a re-execution of the model
  • A faithful record of the run, not a reproduction

Discuss your architecture with us