Get started

The safest way to learn RunOnProof is to begin with a fictional company and a read-only action. You should understand the shape of the answer before connecting real business data or enabling payment.

Before your first request

Write down five things in plain language:

1. Action: What is the agent trying to do?
2. Company: Which legal business should the evidence belong to?
3. Country: Which jurisdiction controls the registry and policy?
4. Policy: What must be true for this action to continue?
5. Maximum consequence: Is the result informational, onboarding-related, or payment-related?

For example: “Before onboarding this UK supplier, identify the legal entity, confirm the supported company-status facts, check the available restriction evidence, and return a reviewable decision under our supplier policy.” This is much safer than asking, “Is Acme trustworthy?”

A first safe workflow

1. Inspect the catalog

The catalog tells an agent what exists, where it applies, and whether it is active, limited, conditioned, or not yet available. Do not infer availability from a route name or from this documentation alone.

2. Check coverage and source health

Coverage answers “what can this source support?” Health answers “can it support it now?” A healthy registry with no coverage for bank ownership cannot prove bank ownership. A source with the right scope but a current outage cannot support a fresh decision.

3. Run synthetic fixtures

Synthetic fixtures are intentionally fictional. They let you test active companies, ambiguous identities, unavailable sources, payment requirements, and replay behavior without making a statement about a real company.

4. Send an idempotency key

An idempotency key identifies one intended action. If a network retry occurs, the same key helps prevent the action from becoming a second execution or a second charge. Reuse the key only for the same request and business intent.

5. Read the complete result

Do not read only the top-level decision. Record the resolved entity, policy, evidence references, observation times, coverage, conditions, limitations, source health, and decision identifier. A safe integration must be able to show why it continued or stopped.

A human-readable example

Suppose an agent wants to onboard “Northstar Studio.” Two companies have similar names. The registry source is healthy, but the address supplied by the requester does not distinguish them.

The correct result is REVIEW, not a guess. The response should explain that legal-entity resolution is ambiguous and request a stronger identifier, such as a company number. Once the entity is resolved, a separate status check may continue. Identity evidence is not silently stretched into sanctions, invoice, or payee evidence.

Production readiness checklist

• The exact product or solution is active for the intended country.
• Required sources are healthy and within their freshness window.
• The customer policy has a name and a version.
• PROCEED, REVIEW, and STOP are mapped to explicit downstream behavior.
• REVIEW cannot accidentally trigger the action being reviewed.
• Retries use idempotency and committed results can be replayed.
• Pricing or payment requirements are handled before irreversible execution.
• Logs preserve evidence references without exposing unnecessary sensitive data.
• A human can understand the decision and override only through an authorized process.

What not to do

Do not treat HTTP 200 as business approval. Do not turn missing evidence into “probably fine.” Do not cache a result beyond its validity. Do not ask a language model to fill gaps in an official record. Do not connect payment release until the same workflow has passed synthetic and controlled production testing.

Next, read the Catalog, Coverage, and Decision states.