# Start read-only, then earn automation

The first useful payment-system decision may be to move no money. A read-only review can reveal missing terms, ambiguous acceptance, duplicate obligations or unexplained transfers while the business keeps its existing signing process.

Countersign's Observe, Prepare and Delegate modes make that progression explicit. The modes apply to engagements; an entire business does not have to adopt one level of automation at once.

## First, use the synthetic workspace

The [interactive demo](/workspace) lets you inspect example invoices and try an acceptance or recovery scenario without real customer data, wallet funding or spending rights. Its browser state is synthetic and isolated. A successful demonstration shows interface behavior, not a real payment or a production integration.

Use it to understand the questions you need to answer: what was agreed, who can accept, which evidence is missing, and what happened to earlier payments.

## Then document one real obligation

Once the deployment has dedicated persistence and your business has approved use of its records, select one existing vendor relationship. Register its independently confirmed destination, source agreement, effective period, per-obligation amount, ceiling and authorized acceptor. Upload only the evidence you are authorized to process.

Run an Observe review. Resolve unclear records as business questions. If acceptance is missing, ask the person named in the terms. If an outgoing transfer is unmatched, find its purpose. If the contract is ambiguous, correct the approved agreement rather than asking a model to guess.

## Establish a history baseline

A current wallet balance cannot tell you whether a vendor has already been paid. A bounded blockchain scan also cannot prove complete history. Reconcile the observed outgoing transfers against statements and invoices, record the scope and keep uncertain operations reserved.

This work is useful even when you never enable Delegate. It produces an obligation register that a reviewer can understand and a list of exceptions that have owners.

## Move to Prepare only when review is useful

Prepare creates a payment proposal tied to the reviewed versions and original operation identity. The human signing process remains in place. Use this stage to confirm that explanations are understandable, destinations match the approved register and accounting exports fit the bookkeeper's workflow.

A PAY result can expire within five minutes. Preparation is not permanent approval, and a saved proposal does not entitle an operator to execute after the terms, destination or policy changes.

## Delegate a narrow, verified scope

Delegation requires a reviewed deployment, compatible Circle path, constrained Safe module, separate verifier, explicit limits, recovery practice and authorized funding. Covered payments need their exact liability fully reserved under accepted terms before execution. The current public deployment has not passed those activation gates.

Choose narrow per-payment, rolling and lifetime limits appropriate to the approved engagement. Keep Safe owner access independent of Countersign. Practice pausing and disabling the module. An outage should leave the owners with their ordinary recovery path, not a request for an agent to hold an unrestricted owner key.

## Decide with evidence

Before broadening scope, compare correct completion, review effort, false holds, unresolved exceptions and recovery behavior against the existing process. Distinguish implementation tests from customer evidence. It is a valid outcome to keep an engagement in Observe or Prepare when its terms or acceptance are not suitable for delegation.

Use [getting started](/docs/getting-started), [security](/docs/security), [automation](/docs/automation) and [evaluation](/docs/evaluation) to design that review.