Verify an integration
Verify that your application sends the facts a policy needs and that the policy responds as intended. Developers confirm application data. Governance Engineers create and test rules; authorized publishers or approvers control deployment.
Developers verify application data. Governance Engineers test policy behavior. Administrators manage access and can confirm application fields.
Use this guide with an approved SDK package, an application credential, and a test session visible in the portal. See Govern your first action if no session has arrived.
Review the application
Open Applications, select the application, and open Policy. Review the declared input profile, observed fields, responsible Developer, and existing rules. The policy author starts the draft from this application; Developers do not need rule-authoring access to verify its data.
Add the decision record
Use the current core SDK reference for your language to record the decision, rationale, confidence when known, risk level, and terminal session outcome. Typed SDK helpers and enums are preferred over free-form attributes.
Test a Standard control first
Standard controls use the VeriProof input, output, tool, identity, and intervention-point fields supplied by the selected profile. A policy author can test one without declaring application-specific fields.
The policy author selects New rule in the application’s Policy tab. Start with Review model inputs, Review agent outputs, or Require identified tool calls. These controls use data supplied by VeriProof. Review the conditions and run the tests before requesting or starting a Shadow deployment.
Confirm business facts when needed
If the intended policy needs application-specific data, VeriProof shows observed or imported candidates. Review the candidate once. Confirm its business meaning, source in the application, type, allowed values, and whether the application must supply it. Add an example when useful. Technical data paths remain in the advanced mapping view.
Import a schema when one is available. A sample payload can suggest fields, but it cannot confirm their meaning or source. A Developer must review each suggestion. Runtime evidence can verify a confirmed declaration but cannot create one.
Developers and Administrators review these fields in the application’s Policy → Application data section. Import a supported schema or sample payload, then review the suggested fields before saving. Importing data does not confirm its meaning or save a field contract. See Application fields for policies for the review steps.
Send one test session
Use safe, recognizable test data from a development application. End the session normally so the exporter can send every completed span.
Verify the recorded values
Open Sessions, select the test session, and confirm its decision, steps, and policy inputs. In Policy → Application data, check that the saved field contract agrees with the recorded activity. A field appearing in a session does not confirm its business meaning. An authorized Developer or Administrator must review and save that declaration.
Check SDK Health
Open SDK Health and review field coverage. Address the highest-impact missing field used by an active rule, then send another test session.
Test rules before rollout
The Governance Engineer tests positive, negative, and boundary cases. A missing historical-session result is not a test failure. The authorized publisher or approvers follow the organization’s Streamlined, Controlled, or Regulated deployment profile.
Do not send production prompts or responses while testing content capture. Confirm redaction, retention, and access controls with representative safe data first.