BLACKWEB AI / KVRM / SUPPORT-FIRST DECISION ENGINE
Choose the next supported action—not just the most likely one.
KVRM combines rules, retrieved cases, and compact learned models to choose among your operational actions. It filters unsupported primary candidates before ranking the remaining evidence, then validates the winner and any fallback. An inspectable Python decision engine—not another required LLM call.
Research-stage · paid workflow evaluations. Email-first scoping with Bobby. No meeting required.
Feasibility before confidence. Intelligence inside the boundary.
The problem is not merely whether a model can name an action. It is how to choose among conflicting recommendations when the conditions for acting can change.
Select—not just veto
A check on one proposed action can tell you to stop. KVRM’s hybrid path compares candidates from multiple selectors, removes unsupported primary actions before fusion, and can still select a supported alternative. If none qualifies, the result is a validated handoff or refusal.
Change the contract, not the evidence
Action eligibility lives in a versioned registry outside model weights. Load a revised contract and the same proposals can produce a different permitted result. This does not teach a model a new action or eliminate integration testing.
Own the decision path
Run the Python core locally with rules, retrieval, prototype matching and compact learned selectors. An external language model is optional, not a prerequisite. Inspect candidate evidence, validation outcomes and the registry digest rather than relying only on a returned label.
Runnable synthetic example / no production effects
The highest score says rollback. The operating state says no.
A fixed retrieval proposal scores rollback at 0.99. Two other sources propose restart at 0.90 and 0.86. Rollback is unavailable; restart is supported. KVRM removes rollback before fusion, combines the remaining evidence, and selects restart in the simulation.
01 / PROPOSE
Rollback 0.99 · Restart 0.90 / 0.86
Multiple sources contribute candidates. Scores are hand-authored for this example.
02 / FILTER + FUSE
Unsupported rollback leaves the ranking
The supported restart evidence remains available; the top raw score does not win by default.
03 / VALIDATE
Restart reaches the simulated executor
If neither action nor human review is supported, the same pipeline fails closed.
Five executable cases also cover a changed registry contract and an unavailable fallback. These are not Jev outputs, calibrated probability measurements, a customer incident, or proof of superiority over a policy engine.
Inspect the source, recorded results and pinned public revision →Measured against model-only and model-plus-checks paths.
Our 586-case retrospective replay reports correct supported routing, false accepts, and ties with a no-learning constraint control. It separates ordinary validation from KVRM’s action selection. Archived small-model outputs—not a Jev or OPA benchmark.
See the comparison scorecard, controls and reproducible results →Where KVRM fits beside Jev and policy engines
Different responsibilities—not a claim that nobody else can compose these ideas. Reviewed against first-party documentation on October 2, 2026.
| Layer | What it already does | Why evaluate KVRM? |
|---|---|---|
| Jev / TypeSafe | Learned judgments over typed choices, probabilities and confidence. Its documentation already includes uncertainty-driven review. Choice · Confidence | For a reusable runtime that combines multiple proposal sources with explicit support conditions, evidence fusion and fallback validation. KVRM is an architecture, not a competing general-purpose pretrained decision model. |
| OPA / Rego | Deterministic policy evaluation, including structured decision outputs—not just allow/deny. OPA documentation | When you also need a packaged multi-selector ranking and evaluation path. If explicit rules already select the right action reliably, KVRM must earn its place rather than replace them by default. |
| Cedar / authorization | Decides whether a principal may take an action on a resource under a policy. Cedar documentation | For selecting a supported operational action across evidence sources. Keep identity and access control: KVRM is not an authorization-service replacement. |
Could you build this from a model plus a policy engine? Yes. KVRM’s offer is the inspectable composition and evaluation workflow, not ownership of constrained decision-making. Action shielding also predates KVRM. A buyer evaluation must establish whether this implementation improves useful coverage, failure handling or integration effort.
Where Jev could fit: as an upstream source of semantic judgments or action proposals, with execution-critical facts supplied separately. Its confidence is not automatically interchangeable with KVRM’s fusion scores. This is a proposed adapter experiment—not an available integration or partnership, and no KVRM-versus-Jev performance claim is made.
Built to be inspected, not taken on faith
Source code, executable examples, and dated research evidence—not a universal safety score.
The internal publication snapshot covers 12 domains and 682 cases. More important than the headline: the repository tests what happens when the support gate is removed, fallback feasibility fails, or the registry changes. Those are architectural probes, not customer outcomes.
Inspect the open-source implementation · Read evidence versions, baselines and limitations
Put one expensive decision under the microscope.
For automation delivery teams, MSPs and platform engineers choosing among runbooks, escalation paths or approval-dependent workflow actions.
Bring a workflow where recommendations conflict, operating conditions change, or too much legitimate work ends in manual review. We will test whether support-first selection adds value—not merely whether it can block actions.
Define the decision
One owner, five to ten actions, explicit conditions and permissioned historical cases. Preserve the rules or model-plus-policy path you already use as the baseline.
Measure useful coverage
Compare valid actions completed, prohibited actions allowed, unnecessary refusals and decision latency on agreed held-out cases. Report losses and ties as well as wins.
Get a build-or-no-go answer
Receive the action registry, evaluation results, failure analysis and a written integration recommendation. Price and timing follow scope and data readiness—not a benchmark headline.
One workflow. Five to ten defined actions. Sanitized historical cases. No production writes in the initial evaluation. A paid, fixed-scope evaluation. Price and timing are agreed in writing after scope and data readiness are confirmed. Production integration and support are separately scoped.
Request a pilot scope by emailThe deployment boundary
The runtime checks supplied facts; it cannot establish that those facts are true or fresh. Identity, authorization, parameter enforcement, executor isolation and execution-time state changes require integration-specific controls. Research results do not establish production safety or compliance. The pinned public example documents its parameter-validator limitation. Complete independent decision replay and cryptographic authenticity are not offered as verified production capabilities. KVRM does not guarantee the optimal permitted action.
BLACKWEB AI builds across frontier systems. KVRM is one flagship; oNeura is a separate computational-biology research and strategic-IP program.