Status
This page explains how to determine whether a RunOnProof capability can be used now. It is not a hand-maintained promise that every documented feature is live.
Four different questions
A capability can be:
- Implemented: code and tests exist.
- Technically certified: the contract passed the required technical checks.
- Promoted to production: the certified release is deployed.
- Operationally usable: required sources, configuration, access, coverage, and economic gates are healthy now.
These states must not be confused. “Implemented” does not mean “for sale.” “Deployed” does not mean every upstream source is healthy. “Listed” does not mean purchase is authorized.
Runtime truth to inspect
Before a production action, an integration should read:
- the machine-readable catalog for product state and scope;
- the coverage declaration for country, entity, claim, and limitations;
- source-health information for required dependencies;
- release identity so the decision can be tied to a known version;
- price or payment requirements before execution;
- the committed decision or replay record after execution.
Healthy failure is still a correct result
If an official source is down, RunOnProof may be operating correctly when it refuses to produce an unsupported PROCEED. A REVIEW caused by unavailable evidence is safer than a fabricated approval. The status of the service and the status of the business decision are separate.
Documentation dates are not health checks
A page may be reviewed today while a source changes five minutes later. Likewise, an old document can describe a model that still works while runtime coverage has expanded. Treat dates in documentation as editorial context, not live evidence.
Incident behavior
For a required-source incident, safe integrations should preserve the request, return a non-approval state, explain the affected evidence, avoid duplicate charging, and allow a controlled retry or replay. They should not silently switch to an unapproved source or let a language model simulate the missing fact.
What a status message should answer
A useful message says: which capability is affected, in which jurisdiction, which source or gate is responsible, whether existing committed decisions remain replayable, and what the caller should do next. “Service unavailable” alone is not enough for a business workflow.
Release reconciliation
Public documentation, API contracts, catalog entries, prices, and deployed code should be traceable to release identities. When they differ, integrations must fail safely and operators should reconcile them before expanding use.
For the concepts behind active, limited, conditioned, inactive, roadmap, and blocked states, see the Catalog.