How to reconstruct an AI payment hold

Start with an outcome you can name

Choose a specific payment and state, such as PAY-88219 on HOLD in Victoroff’s synthetic demonstration. Define the question narrowly: why does this state exist, and could this actor change it? Record the time and system in which the state was observed. A broad request to explain an entire AI system is harder to resolve than a bounded question about one consequential outcome.

Build the chain from records

Trace the trigger that started the workflow, the actor that performed each action, the authority it relied on and the policy in effect. Connect those items to the evidence considered, any required human approval and the resulting state. This is Victoroff’s reconstruction method. It is a way to organize a review; it is not a prescribed regulatory checklist or proof of compliance.

Distinguish observation from inference

A log may show that a release was requested without showing that it succeeded. A policy may describe who can approve a release without proving that an approval occurred. For each finding, identify the source, the relevant timestamp and what the record actually supports. If two systems disagree, preserve the disagreement. Do not silently choose the most convenient version or replace a missing record with a confident narrative.

Ask whether authority existed at that moment

An actor’s current role does not necessarily establish its permissions when the event happened. A useful reconstruction looks for the applicable delegation, conditions and policy version at the time of the attempted action. Human approval also needs context: what was approved, by whom and for which transaction? Where the evidence cannot answer those questions, record a gap rather than asserting that the action was authorized.

Turn gaps into a bounded next step

The output should separate established findings, unresolved questions and the additional records needed to resolve them. A missing approval record may call for a retention or instrumentation review; a conflicting state may require checking the system of record. In a real engagement, agree handling arrangements before sharing operational records. The public Victoroff demo uses synthetic data only, and the proposed Snapshot begins with an enquiry and scope discussion.

At 14:04, what do you actually know?

Take the fictional PAY-88219 snapshot at 14:04 UTC. You have records of a submitted payment, the agent, a delegation, a policy, an invoice match, missing bank verification, a pending approval and a hold event. You do not have access to a live bank account. You do not know what happened after the snapshot. Those limits belong at the beginning of the report, where a reader can use them to interpret every finding.

A precise opening might say that the supplied records establish HOLD at the snapshot time and do not establish the required verification or approval. It should not say that fraud occurred, that a customer lost money or that an event never happened outside the evidence set. A useful reconstruction makes the limits of knowledge as inspectable as the conclusion.

Create a source register before writing the story

Give each supplied record a stable identifier. Record its description, source as supplied, relevant time, version if available and any limitation on authentication. Keep the original material separate from your interpretation. For the public example, every origin is fictional; a source label identifies its role in the demonstration, not independently authenticated provenance.

In a real engagement, evidence-handling arrangements must be agreed before records are shared. The initial enquiry should describe the categories of records rather than contain them. Once an authorized review begins, a source register helps reviewers resolve questions such as whether two findings rely on the same event, whether a policy version was applicable and whether a late-arriving record changes the analysis. A checksum can identify file bytes, but it does not establish that their contents are true.

Build the timeline without smoothing the gaps

In the synthetic case, the payment enters review at 14:00, invoice matching is recorded at 14:01, the bank-verification gap appears at 14:01:30, approval is pending at 14:02 and the hold is recorded at 14:03. Each event answers a different question. Put them in order, preserve their identifiers and explain what the sequence supports.

Now ask what is absent. Do you have the initiating request? Does a policy citation identify a version? Is there evidence of execution or only an intention? If two records conflict, show the conflict and identify the investigation needed. A tidy timeline assembled by deleting inconvenient discrepancies is less useful than an incomplete timeline whose uncertainty is explicit. The reviewer should be able to distinguish an observed event from an inferred relationship.

Separate three conclusions people often collapse

The first conclusion concerns state: what outcome is recorded? The second concerns explanation: which evidence and conditions account for that outcome? The third concerns authority: who could legitimately perform a particular next action? Answering one does not automatically answer the others. A hold can be understandable while the record of who may release it remains incomplete.

In PAY-88219, the recorded delegation allows inspection, recommendations and holds within its stated boundary. It excludes release. Supplying the missing verification and approval would address policy conditions, but would not silently expand the agent’s delegation. This distinction is specific to the fictional records. In a real review, the applicable authority must be established from the agreed evidence rather than imported from the demonstration.

Write findings another person can challenge

A useful finding contains a conclusion, the records supporting it, the scope of the conclusion and any unresolved dependency. “Approval is pending in APR-031 as of the snapshot” is more reviewable than “the process lacks governance.” The latter may be an interpretation, but it needs a defined basis and should not replace the narrower fact.

Try a second-reviewer exercise. Give someone the finding and its source references without the author’s spoken explanation. Can they locate the relevant record and understand the inference? Can they tell what additional evidence would change the conclusion? If not, revise the finding. This does not turn a reconstruction into an audit opinion; it improves the clarity and traceability of the bounded deliverable you actually agreed to produce.

Make the action register earn its place

“Improve controls” is not a very useful next step. Name the gap, the proposed action and the evidence that would close it. For a missing verification record, closure might require a payment-linked record identifying the verification method, reviewer and time. For an untested enforcement boundary, closure would require an authorized test plan and system-side execution evidence. These are different work items.

Identify owners as proposed unless they have accepted responsibility. Keep deadlines and acceptance status unassigned when they have not been agreed. The public review pack follows that pattern: it supplies concrete closure criteria while leaving customer acceptance unperformed. This is a stronger deliverable than a long list of recommendations with no way to tell whether any recommendation has been addressed.

What makes a sensible first engagement?

Choose one outcome, a bounded evidence set and a decision the review will support. Confirm who will deliver the work, who can provide records, how evidence will be handled and who will review the findings. Agree the deliverables and acceptance criteria before using a proposed price or target date as a commitment. Additional systems, cases or implementation work may require a different scope.

You can begin without uploading confidential information. Describe the workflow category, the outcome you need to explain and the kinds of records you believe exist. Read the synthetic sample, inspect its source package and download the acceptance checklist. If that structure fits your question, the next step is a scope discussion. The demonstration is evidence of a working example, not proof of customer delivery history or availability.

Worth your next read

Outside perspectives selected to deepen the discussion. These links do not imply a partnership or endorsement.

• Martin Fowler’s site — Making Your Data Ready for Agentic AI ↗

  Further reading on preparing data and interfaces for agents; helpful background when identifying what records an investigation would need.

• Simon Willison — The lethal trifecta for AI agents ↗

  A related security perspective for workflows in which retrieved content and powerful tools meet. This is context, not a payment-reconstruction standard.

Sources and further reading

Primary references checked on 24 September 2026. The workflow examples and suggested review questions are Victoroff’s explanation.

• NIST: AI Risk Management Framework