Decision Transformation Testing

Test what changes the decision—and what should not

DTT is AnantVerify's property-based method for testing consequential decisions across meaningful changes in enterprise state.

Request a Demo Read the DTT Methodology

At a glance

Examples test answers; DTT tests behavior
A pass on one case says nothing about how the decision moves as the state changes.
Transformations come from enterprise meaning
An approval expiring, a balance crossing a limit, a document being superseded.
Expectations are declared first
An invariant or a material sensitivity is written down before the transformation runs, so the test can fail.
Every result becomes a runtime condition
Testing and enforcement are bound together, so they cannot drift apart.

Change the world around the decision

Change one thing in the world

Invariant changeSomething irrelevant moves

Material changeA fact that should matter

Boundary changeCrosses a limit or jurisdiction

InteractionTwo conditions combine

Temporal changeTiming or order shifts

Re-evaluate the same decisionThe model and the decision logic are not touched; only the state around them.

Expected by the transformation contract

Decision stays the sameStable

Decision respondsChanges

Decision changes at the edgeChanges

Response matches the combinationCombined

Response respects timingTimed

Do not only test the model. Change the world around the decision and test whether the decision changes when it should—and stays stable when it should not.

In the console

Every mismatch, with the reason

The console's failure explorer listing where a supplier-payment agent decided differently from the oracle, including paying after a bank account changed following approval — Every mismatch across providers: the decision before the change, what the oracle allows and forbids, and what the provider did. Here the naive provider pays after a bank-account change that should have held the payment.

Beyond Example-Based Evaluation

A good answer on one test case is not enough

Enterprise decisions live in a state space. The important question is how the decision behaves as that state changes. DTT starts with a state, applies a meaningful transformation, evaluates the decision again and checks the relationship required by a Transformation Contract.

Original State → Decision • Transform State → New Decision • Compare against the required property

Nine Transformation Dimensions

Change what matters. Preserve what does not.

Invariant

If formatting, irrelevant metadata or a non-material relationship changes, the decision should remain stable. Unexpected change is a spurious-sensitivity failure.

Material

If approval expires, a beneficiary changes, a risk threshold is crossed or a required control becomes active, the decision should respond as the contract requires. Failure to change is material insensitivity.

Boundary

Many consequential failures occur near thresholds: amount limits, time windows, risk bands, policy cutoffs and authority boundaries. DTT deliberately exercises both sides of those boundaries.

Interaction

A bank-account change may be acceptable by itself. An approval approaching expiry may also be acceptable. Together they may require HOLD. DTT can compose transformations to expose failures invisible to single-condition tests.

Temporal

Enterprise decisions often depend on when and how a state was reached—not only the final snapshot.

Sequence

Test the path through state, not only the endpoint it arrives at.

Evidence

Test what happens when evidence is added or removed, to understand whether the verdict changes for the right reasons.

Authority

Change governing authority or jurisdiction and test the verdict.

State quality

Introduce missing, stale, conflicted or uncertain state.

Worked Example

Apply a transformation. Watch the decision re-evaluate.

The supplier-payment decision used as a reference case across this site. Choose a transformation to see what the contract requires, what the assurance layer returns, and how much of the decision surface you have actually exercised.

Apply a transformation

Original state (no transformation)BaselineReformat the invoice referenceInvarianceChange the requesting user's display nameInvarianceExpire the approvalMaterialMove the amount to $5,000BoundaryBank account change + approval near expiryInteractionAdd a contradicting finance controlEvidenceRemove the supplier bank-account factState quality

Assurance readout

Baseline

Baseline decision: PAYALLOW
Decision after transformation: PAYALLOW
State status: SUFFICIENT
Evidence status: AGREED

Supplier payment of $4,850. Approval valid, bank account unchanged, state current, no conflicting evidence.

Transformation classes exercised

0 of 9. Passing what you tested is not the same as covering the decision surface.

Invariance
Material
Boundary
Interaction
Temporal
Sequence
Evidence
Authority
State quality

Illustrative worked example, not a live product screen. The decision, states and outcomes shown are constructed to demonstrate the method.

Coverage

Know how much of the required transformation space you exercised

DTT records the transformation families, interaction depth and search policy used. Passing the tested set is not presented as complete assurance.

Important limitation

DTT tests behavior relative to a contract. It does not prove the contract is true. If the governing contract is wrong, more transformation testing can reproduce the wrong expectation more systematically. That is why AnantVerify keeps evidence qualification and authority separate from behavioral testing.