Decision states
RunOnProof uses three business decision states: PROCEED, REVIEW, and STOP. They are not decorative labels. Each state must cause a defined downstream behavior.
PROCEED
PROCEED means the available evidence supports the exact requested action under the named policy, subject to any attached conditions and validity.
It does not mean the company is safe forever. It does not approve a different amount, payee, buyer, country, or future action. An integration should continue only within the returned scope and preserve the decision record.
REVIEW
REVIEW means the system cannot safely complete the action automatically. A person, stronger identifier, missing document, source recovery, payment step, policy approval, or new evidence may be required.
REVIEW is not a soft yes. The default downstream behavior is to pause. A useful result explains why review is needed and what could resolve it.
Common reasons include ambiguous legal identity, insufficient payee binding, possible restriction match, unavailable required source, expired evidence, policy condition, unsupported geography, or a required commercial approval.
STOP
STOP means the action must not continue under the current evidence and policy. Examples can include a policy-disqualifying status, confirmed restricted-party condition within declared coverage, invalid request, or a condition that cannot be remediated for this action.
STOP should include a reason without exposing sensitive internals. A later request may be possible only if the underlying facts or authorized policy genuinely change.
Decision versus technical response
HTTP status and business decision are different. A technically successful response can contain REVIEW or STOP. A payment-required response must not be interpreted as business rejection or approval. A server error must never default to PROCEED.
Recommended automation mapping
| State | Agent behavior | Human behavior |
|---|---|---|
| PROCEED | Continue only the named action and conditions | Audit when policy requires |
| REVIEW | Pause, preserve context, request the named remediation | Inspect evidence and use an authorized resolution path |
| STOP | Block the action and prevent automatic retry loops | Investigate or close according to policy |
Conditions and validity
A decision can include conditions such as a maximum amount, approved payee, buyer, invoice, category, or expiration time. If a condition is not satisfied, the decision cannot be used as PROCEED.
Examples
Company identity: Exact company number and supported status facts may produce PROCEED for Company Check. The same result does not authorize payment.
Ambiguous name: Two matching companies produce REVIEW with a request for company number.
Source outage: If a required source is unavailable, the safe result is REVIEW or STOP according to the consequence. The system does not invent a negative finding.
Policy conflict: If the named onboarding policy forbids the observed status, Supplier Approval returns STOP even if the company record itself was retrieved successfully.
Override discipline
Human overrides must be authorized, reasoned, scoped, logged, and time-bounded. An override should not mutate the original evidence or pretend the automated decision was different. It creates a separate accountable decision.