Provide data for policy rules
Start with a Standard control when VeriProof already supplies the required facts. Add application data only when a rule needs a business fact from your system.
| Control level | Data used | Developer setup |
|---|---|---|
| Standard control | VeriProof input, output, identity, tool, and intervention-point facts | No application field contract |
| Business-fact control | Customer-specific facts supplied by the application | Confirm the field contract before activation |
You can create and test a draft while a business fact is missing. VeriProof blocks activation until the exact application data contract and required runtime evidence are ready.
Choose when the rule runs
Each rule uses one versioned data profile.
| Portal choice | Use it for | Contract |
|---|---|---|
| After activity is recorded | Review completed sessions and steps | session_activity@v1 |
| Before an action runs | Decide whether the customer system may perform a proposed action | [email protected] |
The portal and MCP tools select the contract from the application and rule timing. Keep the contract identifier and policy paths in the advanced view unless you are investigating an integration.
Confirm application facts
Administrators and Developers can open Application → Policy → Application data. Governance Engineers can review the same contract and its source but cannot change mappings.
- Choose After activity is recorded or Before an action runs.
- Select fields from the application’s configured SDK vocabulary, or import an OpenAPI, JSON Schema, or code-generated JSON definition.
- If no definition exists, use a representative JSON payload to propose fields for review.
- Review each field’s business meaning, application source, data type, allowed values, and optional example.
- Select Required by the application only when every valid record from the application must contain that field.
- Save the field contract, then send one representative session or action from the application.
- Confirm that VeriProof found the expected values, then tell the Governance Engineer to run the rule tests again.
The Developer defines what the application promises to send. The Governance Engineer decides whether a rule depends on that fact. These are separate decisions.
Understand suggested fields
VeriProof keeps the source and confidence of every proposed field.
| Source | What VeriProof can prepare | Required review |
|---|---|---|
| Configured SDK vocabulary | Type, allowed values, and catalog source | Confirm meaning and application mapping |
| OpenAPI, JSON Schema, or code-generated definition | Type, required status, allowed values, description, and source | Confirm the selected schema and mapping |
| Representative JSON payload | Observed type and example | Confirm meaning, source, type, allowed values, and required status |
| Recorded application activity | Observed path, type, count, and last observation | Create or update the declaration before policy use |
A payload or runtime observation can propose a field. It cannot declare the field, change its meaning, or authorize a rule to use it.
Use the generated integration example
Save the contract, then copy the JSON example from Technical contract details. It reflects the saved profile and contract version.
Check the field types, allowed values, and array structure against the application payload before sending a test record.
Do not copy Rego expressions into application code. For recorded activity, VeriProof projects confirmed SDK attributes into the policy input. For governed actions, build the registered-action request from the generated example and confirmed contract.
The saved declaration has an immutable version and content hash. A later edit creates a new version. Rule readiness and deployment bind to the exact contract used for testing.
Check the result
The application-data view distinguishes these states:
- Provided by VeriProof: the platform supplies the fact.
- Confirmed and found in activity: the declaration and observed type agree.
- Confirmed, not yet found in activity: the application has not supplied current evidence for the field.
- Developer confirmation needed: activity contains a field that is not declared.
- Recorded type does not match: the application supplied a different type than the declaration.
Fix the application source or declaration rather than changing a rule to hide a data mismatch. New compatible evidence refreshes dependent rule readiness automatically.
Respond to production data changes
VeriProof does not create an Inbox item after one missing value. It watches formalized Production applications with enforced rules for repeated changes.
A Developer receives one application request after at least five evaluations in 24 hours and either:
- a rule field is missing from three consecutive evaluations; or
- a rule field has the wrong type in three evaluations.
The request lists only fields used by enforced rules. Compatible activity closes the request. Development, Staging, Shadow rules, and unused application fields do not create this work.
Use industry SDK vocabulary safely
An application may select an industry SDK vocabulary. VeriProof can then offer its enum fields and allowed values during contract review.
The selection does not add rules, choose regulatory frameworks, change processing logic, or infer a business record. Only the fields that an Administrator or Developer reviews and saves become part of the application contract.