Fit
Start with one action in your application.
Choose an action that needs approval and may wait, change or be retried before it happens. Your team must control the point where that action is sent.
Keep your existing controls.
Identity, permissions and approval systems may already check the exact action. We compare against those controls before proposing DVS.
Agree on the comparison before implementation.
Choose the action. Name what gets approved, who owns the application and what system carries it out.
Define the result. Agree on what must be allowed, what must be stopped, and how both sides will observe the result using permitted test data.
Compare the same workflow. Check both your existing controls and DVS against those conditions. Count legitimate actions incorrectly stopped as well as changed actions incorrectly allowed.
Record the decision. Your controls may already be sufficient. DVS may add a useful check. Or the comparison may be inconclusive. Only observed results can settle it.
A check has limits.
DVS only controls actions that pass through it. Other routes must be controlled separately or left outside the claim.
If a record changes after the check, your application must check its current version before saving. DVS cannot freeze another system’s state.
Allowing a request does not prove completion. Confirm the result in the system that performs the action. A retry may need a new approval.
Agree on data and responsibilities.
Your team owns the application integration. Agree on data access, record storage and software licensing before work begins. Use synthetic or explicitly permitted test data. Source code, private records and production access are not part of an initial inquiry.
Checking evaluation availability…