SDK quickstart
Open the application and select Set up SDK. Start with the guided setup to send a test session. Use the other tabs to complete required fields, assign responsibility, or run automated checks.
Work as a small team
An Administrator can assign any combination of the six customer roles to one person, including all six. Each person uses one active role at a time. Switch to another assigned role from the user menu; permissions do not combine across roles.
| Active role | Setup responsibility |
|---|---|
| Administrator | Confirm organization details, configure sign-in, and assign team access. |
| Developer | Register the application, install its SDK, and verify recorded sessions. |
| Governance Engineer | Record application purpose, configure relevant frameworks, and test policy behavior. |
| Compliance Officer | Review framework scope, control results, missing evidence, and assigned decisions. |
| Business Owner | Review application purpose, accountable owners, and business results. |
| Auditor | Review assigned engagement scope, findings, evidence, and export history. |
Open Getting started from the user menu for guidance for your active role. Within an application, the guide uses that application. Opening a guide step does not complete setup. Home reports setup milestones from recorded activity across applications you can access.
Use a Development or Staging application for initial evaluation. Send synthetic sessions with different expected policy outcomes, then compare each recorded result with that expectation. A connected SDK does not establish control coverage or legal compliance.
Production promotion requires different requester and reviewer identities. Switching your own role does not satisfy that requirement. A solo team needs another authorized person for this decision.
One person may also hold Auditor access. Assign an engagement with the intended application, period, and framework scope. That access does not establish an independent audit.
Choose an application
Select the application and environment you want to connect. Installation progress is saved for you, the tenant, and each application. Switching roles retains that progress; credentials and pending actions reset.
Verify the application key
Use the available key action to verify, issue, or rotate the selected application’s key. Store any new key in your approved secrets manager.
Prepare SDK package access
Open Tools and SDKs to download the current language bundle and copy its installation command. Add the framework adapters your application uses. CI can connect the private package source instead.
A CI package credential downloads SDK files. The application key authenticates session traffic. Keep both credentials in approved secret stores.
Install the SDK
Run the command copied from Tools and SDKs in your development project. VeriProof records the installed SDK identity when the application sends a session.
Send and confirm a test session
Run your language’s example in a development project. It records input and, if the protected action runs, output without a model provider. Replace the sample input with values your application’s policies allow.
Open the recorded test in Sessions. Confirm the application, environment, policy result, and captured data. A blocked input confirms receipt, not successful execution. Do not add output to an action that did not run.
Finish required fields
Open Required fields after the first session arrives. Each row explains what a field means and where to add it. Add missing values from the application’s actual data, then send another session. Do not invent a value to clear a missing-field result.
For Actor identity, include initiatorId in the SDK call’s workflow facts. The portal example shows the syntax for your selected language. It uses sdk-quickstart-test for synthetic tests. For real requests, use a stable ID for the initiating account or service, not an email address. This value is reported by your application; it is not independent identity verification.
Framework-related fields come from VeriProof’s evidence profile for the selected framework. Capturing those fields does not prove that a control is satisfied or establish legal compliance.
If input policy blocks the test, send a separate allowed test to check final-response capture. Keep the blocked session unchanged as evidence of the blocked action.
Missing fields do not create Inbox work automatically. When an update is assigned, Required fields shows its Inbox status. Team lists the Developers who maintain the application. A Developer can leave the team after selecting an active replacement and confirming the handoff.
Use Automation when a local script or build pipeline must run the same field check. VeriProof Doctor is read-only and checks sign-in, connectivity, application access, and required fields. Copy the command or open Tools and SDKs to download the approved CLI. Diagnostic JSON and API endpoints are optional details.
Add human review when the application needs it
Human review needs more than a working SDK connection. The application must store a review outcome and check whether work may resume, including after a restart.
In Settings → Human review and escalation → Application setup, configure the human input profile, signed callback, durable receiver, worker, and safe test. A callback receipt means the application stored the outcome. Protected work resumes only after the application state and current VeriProof policy both pass.
If the session does not appear
- Confirm that the selected application and environment match your test.
- Verify the application key again.
- Confirm that your package source and installed SDK match the current Tools and SDKs instructions.
- Review the application health information for the next specific action.