-
Notifications
You must be signed in to change notification settings - Fork 0
Behavioral Regression Testing
Traditional software tests usually ask whether a function returned the expected value.
AI systems introduce another question:
Did the system follow the expected process while producing that result?
DProvenanceKit treats agent behavior as something that can be regression-tested.
Consider a workflow designed to perform four steps:
retrieve evidence
↓
verify evidence
↓
generate conclusion
↓
record decision
After a model update, prompt change, framework upgrade, tool modification, or application refactor, the agent may instead execute:
retrieve evidence
↓
generate conclusion
↓
record decision
The final answer may still look convincing.
But the verification step disappeared.
An output-only test may never notice.
DProvenanceKit is designed to make that behavioral difference visible.
A known-good execution can be recorded as a behavioral baseline.
Known-good execution
↓
Review
↓
Golden baseline
Once that baseline exists, future candidate executions can be compared against it:
Golden baseline
│
├──────────────┐
│ │
▼ ▼
Expected behavior Candidate behavior
│ │
└──────┬───────┘
▼
Structural comparison
▼
Regression assessment
The baseline represents behavior that has already been reviewed or accepted.
It does not mean every future execution must be byte-for-byte identical.
The purpose of the baseline is to provide a stable reference for detecting changes that matter.
A candidate run may differ from its baseline in several ways.
DProvenanceKit can reason about changes such as:
- removed steps,
- added steps,
- changed critical events,
- reordered critical behavior,
- structural divergence,
- materially different execution paths.
For example:
GOLDEN
plan
↓
search
↓
verify
↓
decide
may become:
CANDIDATE
plan
↓
search
↓
decide
The final decision may still look reasonable.
The structural regression is that verify disappeared.
DProvenanceKit records execution as structured events rather than treating an agent run as an opaque block of text.
That makes it possible to compare how an execution was assembled.
For example:
Golden
A → B → C → D
Candidate
A → C → D
The important observation is not merely:
The traces are different.
It is:
Step B disappeared.
If B represents required verification, authorization, evidence retrieval, or another critical operation, that difference may be significant even when the final generated output remains acceptable.
Regressions are not limited to missing steps.
A candidate may introduce behavior that was not present in the reviewed baseline.
GOLDEN
retrieve
↓
verify
↓
decide
becomes:
CANDIDATE
retrieve
↓
external_tool
↓
verify
↓
decide
The new step may be harmless.
It may also represent:
- an unexpected tool invocation,
- a new external dependency,
- an unintended side effect,
- or a meaningful change in the workflow.
The point is not that every added step is automatically wrong.
The point is that important additions become visible and reviewable.
Order can matter even when every expected step still occurs.
Consider:
EXPECTED
retrieve
↓
verify
↓
decide
versus:
CANDIDATE
retrieve
↓
decide
↓
verify
All three steps occurred.
But verification happened after the decision.
For workflows where ordering expresses a real control boundary, that can be a meaningful regression.
DProvenanceKit's behavioral model allows execution order to participate in regression analysis.
Some events carry more significance than others.
A diagnostic event moving position may not matter.
A critical decision, approval, verification, or policy check changing materially may matter a great deal.
Conceptually:
Low-impact variation
↓
May be tolerated
Critical behavior change
↓
May trigger regression
This is why behavioral regression testing should not be reduced to raw trace equality.
The goal is to identify meaningful behavioral change, not simply any difference.
Generative AI systems are stochastic.
Two healthy executions may not be identical.
DProvenanceKit does not attempt to eliminate that variability.
Instead, the assurance model asks whether a candidate execution has crossed a boundary that matters.
Variation
│
├── benign difference
│ ↓
│ accept
│
└── material behavioral change
↓
investigate / fail
This allows systems to remain flexible without making important process changes invisible.
Not every behavioral difference should have the same consequence.
A useful assurance system distinguishes between changes that are informational and changes that represent significant behavioral risk.
Conceptually:
Difference detected
↓
Interpret significance
↓
Regression severity
↓
Pass / Warn / Fail
That allows teams to define stricter expectations around critical behavior while tolerating lower-impact variation where appropriate.
DProvenanceKit separates inspection from enforcement.
Use:
dpk comparewhen you want to inspect the difference between the candidate run and the accepted baseline.
Use:
dpk gatewhen that behavioral comparison should affect whether the change is accepted.
The distinction is:
dpk compare
↓
What changed?
dpk gate
↓
Should this change be allowed?
This makes the same behavioral model useful both during development and in CI.
A typical workflow looks like:
Code or prompt change
↓
Execute agent tests
↓
Record candidate behavior
↓
Compare with golden baseline
↓
Evaluate structural differences
↓
Regression?
┌────┴────┐
│ │
yes no
│ │
Fail CI Continue
This puts agent behavior into the same software engineering discipline already used for:
- unit tests,
- integration tests,
- API compatibility,
- type checking,
- performance regression testing,
- and security checks.
A golden baseline should represent behavior that has been reviewed and intentionally accepted.
It should not simply be regenerated whenever a test fails.
Otherwise:
Regression occurs
↓
Update baseline automatically
↓
Regression becomes "expected"
and the gate loses its value.
A better workflow is:
Behavior changes
↓
Regression detected
↓
Review the difference
↓
Was the change intentional?
┌────────┴────────┐
│ │
no yes
│ │
fix regression approve new behavior
↓
update baseline
A baseline is useful because it represents an accepted behavioral contract, not merely the most recent run.
DProvenanceKit does not attempt to make generative AI deterministic.
It does not assume:
different = broken
It does not replace evaluation of:
- output accuracy,
- relevance,
- faithfulness,
- model quality,
- latency,
- cost,
- or human preference.
Instead, it adds another dimension:
Did the execution itself materially change?
A complete AI quality strategy may therefore include both:
Output evaluation
+
Behavioral assurance
Traditional testing often evaluates:
What did the system return?
DProvenanceKit adds:
How did the system get there, and did that process materially regress?
That distinction matters because an AI system can produce a plausible answer while silently dropping a step that the application depended on.
Behavioral regression testing makes that failure mode testable.
- Rules and Enforcement — turn explicit behavioral requirements into machine-checkable controls.
- Provenance and Audit Evidence — understand how trace data becomes reviewable evidence.
- Architecture and Integrations — see how DProvenanceKit fits alongside observability and existing AI frameworks.
- Cross-Language Conformance — learn how Python and Swift share behavioral expectations.
Observe what happened. Define what must happen. Detect when behavior changes. Gate what should not ship. Preserve the evidence.
Home · Quickstart · Behavioral Regression Testing · Rules and Enforcement · Provenance and Audit Evidence · Architecture and Integrations · Cross-Language Conformance