NALV × DIFY
Release checks for Dify agents before you ship
After changing a prompt, model, knowledge base, tool, or flow, re-check the behaviors that matter before the change reaches users.
A reply that looks finished is not the check. NALV compares the behavior you required with the execution evidence from the run.
Re-checks tool execution, human handoff, policy boundaries, repeated requests, and whether the evidence is complete enough to decide.
NALV Release Checks on the Dify Marketplace. Run it on a chat app or Chatflow.
What a change can move
The reply can stay fluent. The behavior behind it can still move.
You changed
- Prompt
- Model
- Knowledge
- Tools
- Flow
What can silently change
- Tool execution
- Human handoff
- Policy boundaries
- Repeated-request behavior
- Grounding / retrieval behavior
Controlled reproduction
When “done” is not evidence
NALV can fail a release check when a required tool is missing from a complete execution trace — even if the agent says the action succeeded.
- Agent response
- “Done successfully.”
- Required tool
- Missing
- Release verdict
- FAIL
What NALV re-checks
Each check holds a required behavior next to the evidence from the run.
- Tool execution
- Did the required tool actually run? A complete trace with that tool missing fails the check, even when the reply says the action succeeded.
- Human handoff
- Did the bot hand off when the person asked for a human?
- Policy boundaries
- Did the bot stay inside the allowed action or refund boundary when the person pushed?
- Consistency
- Did repeating the same unresolved request change what the bot agreed to do?
- Evidence coverage
- Is the runtime evidence complete enough to decide? If NALV cannot see the record well enough, the verdict stays in review.
Run it on a chat app or Chatflow.
The release verdict
Read the verdict against the evidence. A missing record is not a pass.
- PASS
The tested behavior satisfied the release check.
- REVIEW
The evidence is incomplete or ambiguous, so NALV will not close the question. REVIEW is not a pass, and it is not a confirmed failure. Incomplete tool visibility stays here. A complete trace with the required tool absent does not.
- FAIL
The tested behavior violated the release check.
- RELEASE_BLOCKER
A blocking behavior issue was detected.
See traceable evidence on the homepage for how a verdict sits next to what the bot did.
Exact Retest
After a fix, NALV can rerun the same frozen test condition. The request and the check requirement stay as they were. The recipe and the check are not chosen again.
Preserving that condition does not make model behavior deterministic. A later run can still change wording, tool choice, or whether the agent fails in the same way.
When to run a release check
Use it as the regression check for the behaviors a support bot has to keep.
Run a release check after
- Prompt changes
- Model changes
- Knowledge updates
- Tool changes
- Flow changes
- Policy changes
Also useful before
- Client handoff
- Production release
- A major support-bot update
Re-check the behaviors your support bot must keep before release.
Start with DifyNALV Release Checks on the Dify Marketplace. Run it on a chat app or Chatflow.