Prove Before Act

01The Problem

Autonomous agents act. They read data, form decisions, and execute actions — sometimes with real consequences: financial transactions, code deployments, contract signings, infrastructure changes, data modifications.

When something goes wrong, a single question follows: what did the agent decide, and when did it decide it?

Today, that question is almost always unanswerable.

The log is not a witness. The log is the defendant.

Prove Before Act addresses this gap. Not by making agents smarter or safer — but by requiring them to commit to their intended action and decision basis before acting, in a way that cannot be altered after the fact.

02Definitions

03Threat Model

Prove Before Act addresses a specific class of failure. It does not address adversarial attacks, model jailbreaks, or infrastructure compromise. It addresses the accountability gap.

What Prove Before Act protects against

• Post-hoc rationalization — an agent describing decisions it did not make before acting
• Silent failure — an agent that acted incorrectly with no externally verifiable record of intent
• Dispute without evidence — a counterparty claiming the agent acted outside its instructions, with no way to verify
• Regulatory non-compliance — an audit requiring proof of decision provenance the agent cannot produce
• Agent identity drift — a system that changed its model or configuration between commitment and action

What Prove Before Act does not protect against

• A malicious agent that anchors false intent before acting
• Compromise of the anchoring infrastructure itself
• Incorrect decisions that were correctly proven before acting

The pattern proves temporal sequence and commitment, not correctness or safety.

04Why Logs Are Not Evidence

The distinction between a log and evidence is temporal and architectural.

05The Pattern

Prove Before Act is a commit-before-execute sequence. The agent must anchor a cryptographic proof of its intended action before that action executes. The proof timestamp is written by an external ledger.

The second PROVE (outcome) is optional but recommended. Together, they produce a complete chain: intent before action, outcome after — both independently verifiable, linked by a link() call.

The Core Invariant

T(intent_proof) < T(action)

If T(intent_proof) ≥ T(action):
  → the proof is not evidence of pre-action intent
  → it is a record, not a commitment

A hash anchored after execution proves the content existed — it does not prove the intent preceded the action. The timestamp must be written by the anchoring ledger, not by the agent or its operator. This is why the WHEN in the 4W schema is always null in the agent's payload — the ledger writes it.

06The Four Primitives

Any implementation of Prove Before Act requires exactly four operations. These are pattern-level — not specific to any anchoring ledger or implementation.

anchor(content) → proof_id

Compute a SHA-256 hash of the content locally. Write the hash to an external ledger. Return a proof_id with an immutable timestamp. Raw content never leaves the agent's environment.

verify(proof_id) → {timestamp, hash, status}

Given a proof_id, return the anchored hash, the ledger timestamp, and confirmation status. Anyone can call verify — no account required.

compare(proof_id_A, proof_id_B) → {A_precedes_B: bool}

Given two proof_ids, determine whether the first proof was anchored before the second. This is the core evidence operation: it answers whether intent preceded action.

link(intent_proof_id, outcome_proof_id) → chain_id

Explicitly associates an intent proof with its outcome proof, establishing the full WHY→WHAT chain. Required for audit graphs, delegation trees, and agent trust registries. Without this primitive, intent and outcome remain disconnected records rather than a verifiable chain.

// Minimal implementation contract
interface ProveBeforeAct {
  anchor(content: string | Buffer, metadata?: object): Promise<{
    proof_id: string;
    hash: string;
    timestamp: number;         // written by ledger
    verify_url: string;
  }>;

  verify(proof_id: string): Promise<{
    hash: string;
    timestamp: number;
    status: 'confirmed' | 'pending' | 'not_found';
  }>;

  compare(intent_proof_id: string, action_proof_id: string): Promise<{
    intent_preceded_action: boolean;
    delta_ms: number;
  }>;

  link(intent_proof_id: string, outcome_proof_id: string): Promise<{
    chain_id: string;
    intent_preceded_action: boolean;
  }>;
}

07The 4W Audit Trail

For an intent proof to be useful, it must answer four questions independently.

Minimal 4W JSON schema

{
  "who": "agent-id-v2.3.1",
  "why": "RSI below 30 threshold, risk/reward 1:3, within position limits",
  // decision basis, not internal chain-of-thought
  "what": "BUY BTC 0.5 at market",
  "when": null  // set by ledger, not by agent
}

The WHEN field is intentionally null. Writing a timestamp here would allow post-hoc fabrication. The ledger timestamp is the only authoritative WHEN.

08Agent-to-Agent Accountability

When Agent A delegates to Agent B, the Prove Before Act pattern extends to the delegation itself. Each boundary in a multi-agent system requires its own proof.

The delegation proof establishes that Agent A authorized Agent B before B acted. The execution proof establishes what B did. Together — linked via link() — they produce a verifiable chain of custody across agents.

In deeper hierarchies (Human → A → B → C), each delegation boundary requires its own proof. Accountability does not dissolve across boundaries; it is enforced at each one. This is the foundation of machine-to-machine accountability.

09Example Architectures

Financial agent

signal = observe_market()
decision = agent.decide(signal)

# Prove Before Act
intent_proof = anchor({
  who: agent.id,
  why: decision.rationale,   # decision basis, not internal chain-of-thought
  what: f"BUY {decision.asset} {decision.amount}",
  when: null                 # ledger writes this
})

if intent_proof.status == "confirmed":
    result = execute_trade(decision, proof_id=intent_proof.id)
    outcome_proof = anchor({ what: result.summary, when: null })
    link(intent_proof.id, outcome_proof.id)

DevOps agent

pr = observe_pull_request()
analysis = agent.analyze(pr)

intent_proof = anchor({
  who: "deploy-agent-v1",
  why: analysis.rationale,
  what: f"DEPLOY to production: {pr.id}",
  when: null
})

if intent_proof.status == "confirmed":
    deploy(pr, proof_id=intent_proof.id)

MCP integration (xProof reference implementation)

// xProof maps anchor() → certify_file MCP tool
{
  "name": "certify_file",
  "arguments": {
    "file_hash": "sha256_of_intent_json",
    "filename": "intent.json",
    "metadata": {
      "who": "my-agent-v2",
      "what": "execute trade BUY BTC 0.5",
      "why": "RSI=38, below oversold threshold",
      "purpose": "prove_before_act"
    }
  }
}
// Returns { proof_id, verify_url, status: "anchored" }
// → Execute only after status confirmed
// → Use coherence/link to bind intent_proof to outcome_proof

10Implementation Requirements

Any implementation claiming Prove Before Act compliance must satisfy the following.

• Hash computed locally — raw content never sent to anchoring service
• Timestamp written by ledger consensus, not by agent or server clock
• Proof_id publicly verifiable without account or authentication
• compare() returns intent_preceded_action as a boolean derived from ledger timestamps
• link() associates intent and outcome proofs in a queryable, immutable chain
• Proof is immutable after anchoring — no edit, delete, or update operations
• Anchoring ledger is independent of the agent operator

Optional but recommended

• x402 payment support for fully autonomous agent operation without API keys
• 4W metadata schema anchored with each proof
• Outcome proof anchored after execution, linked to intent proof via link()
• Agent identity anchored via a persistent wallet or DID

11Reference Implementation

xProof is the reference implementation of Prove Before Act. It satisfies all requirements in section 10 using MultiversX as the anchoring ledger and supports x402 for fully autonomous operation.

12Contribute

Prove Before Act is an open pattern. It is ledger-agnostic. Any implementation that satisfies the requirements in section 10 is a valid Prove Before Act implementation, regardless of anchoring ledger, payment mechanism, or tooling.

If you have implemented the pattern on a different ledger, built a third-party integration, or identified a gap in this specification — contributions are welcome.

Contact: provebeforeact.com · @JasonxProof