How it works
Follow the evidence to the next decision.
OpenAuditor checks a record against the rules and evidence you supply. It shows what holds, what fails and what remains unresolved, so your team can take the next step with the findings in view.
Start with the decision in your workflow: release a supplier payment, approve a vendor change, assess a claim or allow an AI action. The result is a review record containing the verdict, individual checks, supporting facts and references back to your submitted data.
From a record to a review decision
- Choose the question. Select a use case and item type. A supplier invoice, a vendor change, an insurance claim and an agent action have different assertions to satisfy.
- Supply the evidence. Send the item together with relevant records and reference data: an employee record, approval limits, contract terms, source passages or granted permissions. An accurate context matters as much as an accurate item.
- Read the findings. Inspect failed and open assertions before acting on the overall verdict. Follow their evidence pointers back to the fields that explain the result.
- Resolve and retain. Correct an input error, obtain missing evidence, or send the item to the responsible reviewer. Keep the response and your review decision in your own workflow when you need a lasting record.
Try one record in the console, or follow the API quickstart to integrate the same checks into a process. Your application remains responsible for executing approvals, payments or other actions after the review.
For audit work, connect each check to the relevant assertion and procedure in your plan. Set the population and evidence requirements, assess materiality in the engagement's context, and document how exceptions will be resolved. The audit concepts guide explains these judgments and how they relate to the product's checks.
A supplier invoice that adds up, but fails the PO control
Consider invoice INV-2026-0841 from Northstar IT Supply: 20 business laptops at $1,240 each, totaling $24,800. The supplied record has no purchase-order reference. The financial-audit rule requires one above $1,000. This is a synthetic business example, verified with the local engine; the published result records what that run established.
| What is checked | Recorded result | What a reviewer learns |
|---|---|---|
| Invoice arithmetic | holds | The line items reconcile to $24,800, with zero tax and discount in the submitted record. |
| Vendor status | holds | The supplied vendor record is active and its creation date precedes the invoice. |
| Duplicate invoice | holds | The example supplies an empty invoice history. The check does not establish that no duplicate exists outside that supplied scope. |
| Purchase-order reference | fails | The amount exceeds the $1,000 threshold and no po_number is supplied. |
| Description of goods or services | not_asked | The direct PO failure already decides the item, so this model question was not asked. |
The recorded overall verdict is false. The model was not asked, because the PO failure already decided the item. The recorded certainty is the published holdout measurement for rules-decided false verdicts, from financial-audit@4’s rules-only run: a 0.00133 upper error bound over 2,253 synthetic items. It describes that synthetic holdout, not this invoice or your records. The result identifies the failed condition and the fields behind it. See the complete financial-audit request and result.
The next step is to inspect the source invoice and purchasing records, confirm the applicable policy and record the review decision. A $1,000 PO threshold is a control parameter, not financial statement materiality. The missing reference does not by itself establish a $24,800 misstatement. Assess the exception's significance and retain the finding with its resolution.
Items, context and assertions
An item is the record or decision being tested. An assertion is a condition it must satisfy: the amount is within an approval limit, the claimant is covered on the loss date, a statement is supported by its source, or an action has the required permission. Each use case publishes its item schemas and assertions.
context.records holds related business records; context.references holds the policy or reference values the checks read. For a batch, comparisons can also see the other items in that batch. Supply the population relevant to your question: splitting a population across separate audits can prevent a comparison from seeing related items unless you include them in context.
For single verification, omitting a required comparison population can leave its check unresolved; an explicitly empty list declares that no comparison records were supplied. A batch also supplies a population through its items, so an omitted or empty context list does not remove relevant batch peers. Neither choice establishes source-system completeness. Likewise, options.skip narrows the checks performed; the response records skipped assertions so a reviewer can see that scope.
The single-verification guide explains how to represent an item, its context and the options that control a review.
Run the defined checks first
Rules that can be computed run as code: limits, dates, totals, duplicate keys, bank-account matches and granted scopes. Money uses decimal arithmetic, so callers send amounts as decimal strings. A check reports holds, fails or the reason it cannot decide, with the facts and request fields it used.
These procedures apply defined comparisons to supplied fields. The hosted API does not independently confirm that a submitted employee record, receipt flag or approval limit reflects the real world. The response makes that boundary visible as scope.evidence: "supplied". Its JSON pointers locate submitted fields; they are not independent attestations of an original document.
Matching two fields does not establish that they came from independent sources. A payment destination and a vendor-master account can agree because one copied the other. The bank-account investigation shows identical inputs and recorded results for two different upstream histories; its downloadable checker compares the published files without rerunning the private engine.
Judgment questions have a qualification gate
SmallDecide answers typed questions that require interpretation: whether a description states a business purpose, whether a narrative matches a claimed peril, or whether a source passage supports a statement. It receives a bounded context built from the item and relevant facts already computed by the tests. It does not browse the web or execute business actions.
A model probability becomes an assertion decision only when the question version is qualified for the model in service. Qualification fits thresholds on calibration data and measures the errors among accepted answers on a separate holdout set. Probabilities between the thresholds abstain. An unqualified question may still record its answer, but leaves the assertion open.
Qualification is specific to a question, model and measurement. The evaluation evidence identifies which configurations were actually evaluated; a rules-only run does not measure a model's added coverage. Each use-case guide links to the live definition so an integration can inspect the qualification attached to the running service.
Three outcomes, with different next steps
| Verdict | How it is reached | Typical next step |
|---|---|---|
false | An applicable assertion fails with an error bound within the error budget derived from the certainty target. One decisive failure can settle the item even when other checks remain open. | Inspect the failed assertion and its evidence; route the exception for correction or review. |
true | Every applicable, unskipped assertion holds, the combined model error bounds fit that error budget, and review indicators remain below the guard. | Confirm that the supplied evidence and tested scope meet your process requirements. This does not certify source authenticity or population completeness. |
uncertain | A check cannot decide, a question is unqualified, the combined bound is too high, the review guard is reached, or nothing applicable was tested. | Read undecided, obtain evidence or assign a human review. |
The default certainty target is 0.995, giving the decision gate an error budget of 0.005. It is not a promise that every individual answer is 99.5% correct. A false verdict identifies a failed requirement in the supplied scope; it does not by itself establish fraud or an accounting misstatement.
The result guide explains each assertion outcome, evidence pointer and response field. Keep failed results and unresolved results separate in your review queue: a missing document calls for a different response from an amount that exceeds an approved limit.
Read certainty separately from probability and risk
| Output | Meaning | How to use it |
|---|---|---|
certainty | For the measured verdict group, bound is the published upper error bound and value is one minus that bound. The object includes the basis, sample count and observed errors when measured. | Check the measurement and configuration. A basis of unmeasured with a null value is not a numerical assurance; uncertain verdicts have no certainty object. |
probability_true | An aggregate from assertion outcomes and available model probabilities. It may use unqualified model answers, and can be null when evidence or answers are unavailable. A rules-only result can report 1.0000 on a deterministic basis. | Read it alongside the assertion outcomes and probability_basis. It is not a measured probability that the original evidence is authentic or the whole transaction is valid. A strong probability does not qualify an answer to decide. |
risk | Weighted failed assertions and review indicators, with a probability derived from a stated base rate. Its basis is prior. | Use the reasons to prioritize review. The hand-set weights do not measure fraud prevalence in your business. |
The certainty fields describe a group of evaluated results, not confidence inferred from one record. The published bounds use the one-sided 95% Clopper–Pearson method. Their interpretation depends on the evaluation population and its assumptions; repeated versions of the same scenario do not automatically provide independent evidence. Synthetic agreement does not establish accuracy on your organization's records.
Close the review loop
Results in a completed batch can be marked correct or incorrect through the verification-marks API, with a note. The service stores the latest mark per item and exposes aggregate counts; it does not provide a read endpoint for individual marks or a full reviewer history. The current service does not automatically retrain the model, change qualification thresholds, or recalculate published certainty from those marks. Retain your review evidence in your own workflow.
Define who resolves each kind of finding and where that decision is recorded. A corrected input can be submitted for a new verification; a judgment question can be assigned to a reviewer. Preserve both the original finding and your resolution when your process requires an audit trail.
Keep the inputs and configuration together
With the same request, configuration and answer cache, results are repeatable apart from the verification id, creation time and per-call usage. The model runs without sampling on CPU in 32-bit floating point. Cached answers are keyed by the model artifact, question and context, and the cache contains no request text.
Save configuration, input_sha256, the full request including options, and the response together. The configuration identifier does not encode parameter overrides or skipped assertions. A changed policy, comparison population or model configuration is a changed review, even if the item's business id stays the same.
Choose one record or a population
POST /api/v1/verify returns one result directly. POST /api/v1/audits queues a batch and lets you retrieve progress and paged results. Keep related records together so population checks can see the evidence they need. The batch audit guide covers submission, polling, results and review marks.
Original batch inputs are removed when processing completes or fails; results expire seven days later unless you delete them sooner. Keep any required long-term review record in your own system. Review the request limits and retention policy when planning an integration.
Put the method to work
Choose a workflow to see a complete recorded example and its supported checks. Use the quickstart to send a first request, or visit Help for guidance on accounts, the console and unresolved results.
Research and practical guides
Visit the OpenAuditor blog for investigations with inspectable examples and guides to the review work around the API. The batch review workflow covers population preparation, assigned exceptions and recorded resolutions.