A control test needs a third state: cannot verify.
Definite maps a control population and its supporting evidence into a finance ontology. Configured checks issue the result, incomplete evidence stays unresolved, and people review it with its source context attached.
Bring one controlThe evidence can change. The configured check stays the same.
The example below shows the same vendor-master control before and after an approval record is added to the evidence set.
| Change | Attribute | Finding | Result |
|---|---|---|---|
| VM-1042 | Approval timing | Approval recorded before the vendor record was updated | PASS |
| VM-1087 | Approval timing | Approval recorded after bank details were updated | FAIL |
| VM-1114 | Separation of duties | Requestor and approver resolve to the same user | FAIL |
| VM-1140 | Approval evidence | No approval record is present in the evidence set | CANNOT_VERIFY |
| 6 remaining | All attributes | The retained evidence supports every configured test | PASS |
The missing approval record cannot be treated as a pass or a fail. Definite keeps it in CANNOT_VERIFY until a reviewer supplies evidence or records that it is unavailable.
| Change | Attribute | Finding | Result |
|---|---|---|---|
| VM-1042 | Approval timing | Approval recorded before the vendor record was updated | PASS |
| VM-1087 | Approval timing | Approval recorded after bank details were updated | FAIL |
| VM-1114 | Separation of duties | Requestor and approver resolve to the same user | FAIL |
| VM-1140 | Approval evidence | Approval record received; its timestamp follows the update | FAIL |
| 6 remaining | All attributes | The retained evidence supports every configured test | PASS |
When the approval record arrives, the same configured check can conclude the item, and reviewers can trace which evidence changed the result.
- Unchanged
- Configured checks and mapped population
- Changed
- Approval record added to the evidence set
- Result
- CANNOT_VERIFY becomes FAIL
Fictional records, sample sizes, and results shown only to explain the review logic.
Define the control before running it.
Definite is configured around how the team defines and performs the control today, including what belongs in the population and what evidence is required.
- 01
Control narrative
The process and control objective the team performs today.
- 02
Population definition
The records in scope, source counts, exclusions, and unresolved gaps.
- 03
Configured checks
The repeatable rules, thresholds, and conditions applied to each item.
- 04
Required evidence
The records and support needed for the check to reach a conclusion.
Keep the basis for every run inspectable.
Inputs, mappings, rules, parameters, evidence changes, and review decisions remain attached so the same run can be re-performed.
- 01
Source evidence
Record and field lineage stays attached.
- 02
Mapped population
Identities, dates, approvals, and evidence are related.
- 03
Rules & parameters
The configured basis for each result is retained.
- 04
Run result
PASS, FAIL, and CANNOT_VERIFY remain explicit.
- 05
Review decision
Added evidence and reviewer decisions stay with the run.
Assembles the mapped population and required evidence.
Reviews exceptions and incomplete evidence as a separate role in the data layer.
Bring one control that is painful to test.
We map its population, required evidence, repeatable checks, and review path before configuring the workflow.
Show us the control