Practical guide / synthetic example / October 2, 2026
AI action validation: check permission before execution.
An action can exist and still be inappropriate now. This runnable example holds the proposed action and confidence constant while changing approval state—and compares KVRM with a plain rules baseline.
The operational question
Suppose an assistant proposes publishing a draft. A correctly formatted tool call does not establish that a reviewer approved it, the intended draft is selected, or the publication window is open. Before execution, those conditions need explicit checks.
For a workflow owner, separate four questions: Is the action registered? Are the supplied conditions sufficient? Are its parameters permitted? Can the executor be reached without passing the checks? A plausible answer or a high confidence score is not authorization.
KVRM is one architecture for bounded decisions, not a replacement for identity, access control, trustworthy state collection, or monitoring. A policy engine or a few conventional rules may be all you need.
What this example actually runs
The Python script uses the public KVRM runtime at a pinned revision. A fixed synthetic selector proposes either publishing or holding a draft. The registry declares approval and window conditions. The only executor appends a value to an in-memory list: it cannot publish, send a message, or alter a real system.
Eight hand-authored cases passed on October 2, 2026. KVRM and the independent simple-rules baseline agree on all eight. This demonstrates a decision boundary—not a learned-model benchmark, customer result, or advantage over rules.
Important implementation limit: the pinned public revision is not a complete JSON Schema parameter validator. The first run exposed an invalid-parameter case that passed without an extra check. This example therefore supplies an explicit domain precondition for the draft identifier and type. Schema declarations alone are not treated as proof of enforcement.
| Case | KVRM | Simple rules | Expected |
|---|---|---|---|
| approval present | Allow | Allow | Allow |
| approval absent | Block / abstain | Block / abstain | Block / abstain |
| approval missing | Block / abstain | Block / abstain | Block / abstain |
| window closed | Block / abstain | Block / abstain | Block / abstain |
| unregistered action | Block / abstain | Block / abstain | Block / abstain |
| invalid parameter | Block / abstain | Block / abstain | Block / abstain |
| low confidence | Block / abstain | Block / abstain | Block / abstain |
| hold without approval | Allow | Allow | Allow |
Run it yourself
Python 3.10+ and Git. The sparse checkout retrieves the core rather than the large experimental artifact trees. Package installation needs internet access; the example itself makes no network calls.
git clone --filter=blob:none --no-checkout https://github.com/robertcprice/KVRM.git kvrm-example
cd kvrm-example
git sparse-checkout init --cone
git sparse-checkout set kvrm-core
git checkout 85fe4dc8a4f5a7010dd19f98bd8a934554fb8663
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -e kvrm-core
curl --fail https://blackweb.ai/downloads/kvrm/approval-boundary.py -o approval-boundary.py
# Read the downloaded source before running it.
python approval-boundary.pyThe command exits unsuccessfully if an expected result or baseline comparison fails. Changing the rules changes the contract: passing these eight cases does not establish exhaustive correctness. The checksums identify these files, not the truth of their input data.
Beyond a permission check: support-first selection
Five additional synthetic cases exercise the hybrid selector, evidence fusion, registry changes and fallback validation in the pinned public runtime.
The approval example above intentionally ties simple rules. This second example shows more of the architecture: three fixed sources propose rollback at 0.99 and restart at 0.90 and 0.86. These are illustrative scores, not measured model outputs or calibrated probabilities.
When rollback is unsupported, the hybrid selector filters it before fusion. Evidence for restart survives and reaches the in-memory executor. When both actions are supported, rollback wins. Registry version 2 adds an approval requirement; loading that registry into a newly constructed runtime changes the result without changing or retraining the proposal sources. This is not hot reload.
Fallbacks are not assumed safe: a supported human review reaches the simulated executor, but an unavailable reviewer leads to fail-closed. This is a concrete architecture test, not a comparison with Jev, OPA or a customer workflow. Conventional code can implement the same logic.
| Case | Registry | Simulated action | Status |
|---|---|---|---|
| high score unsupported | v1 | restart | executed |
| both supported | v1 | rollback | executed |
| new contract same proposals | v2 | restart | executed |
| supported handoff | v1 | human_review | fallback executed |
| handoff unavailable | v1 | None | fail closed |
After completing the pinned-core installation above, download and inspect the second script, then run it in the same environment:
curl --fail https://blackweb.ai/downloads/kvrm/support-first-selection.py -o support-first-selection.py
# Read the downloaded source before running it.
python support-first-selection.pyWhat changes in a real workflow
- Trusted context: approval here is synthetic input. A real integration must authenticate its source, bind approval to the exact action and target, and define freshness.
- Execution timing: conditions can change between checking and acting. Revalidation or transaction boundaries must be designed for the actual system.
- Useful refusal: blocking every action is not success. Measure valid actions blocked as well as prohibited actions allowed, and define a safe human-review path.
- Honest comparison: preserve the existing rules as a baseline, use permissioned cases with independent labels, and report failures and ties. There may be no reason to add KVRM.
From an example to a paid evaluation
Start with one workflow and five to ten actions. Agree on the owner, baseline, sanitized data, and success criteria. The first evaluation makes no production writes and ends with an integration or no-go recommendation. Price and timing follow written scope—not a benchmark score.