DecisionManager
Back to Blog & Articles
Architecture·8 min·2026-08-05

AI Boundary Coverage: Both Sides of Every Threshold — Derived From the Rules, Not Guessed

The Boundary Coverage panel derives boundary values directly from stored rule definitions — both sides of every comparison, every enumerated domain, every unconstrained input. AI generates test cases, each verified by server-side execution before being offered. No token spent on unverified suggestions.

Yasmine Lefèvre

Yasmine Lefèvre

Product Engineer

'ai_prompts::derive_boundaries' walks the stored rule definition and vocabulary, returning per input path: both sides of every comparison (649 and 650 for 'score >= 650'), every member of enumerated domains, and every declared input that no rule constrains — an unconstrained input being a coverage gap worth reporting.

**The derivation is free**: no token cost, no model call. It runs on the stored definition and vocabulary types before any AI is involved.

**The AI step** generates test cases for each boundary. Each proposed case is executed server-side: 'suggest-tests' sends the case to the engine's trace endpoint and checks whether 'matched' contains the target boundary's rule. A case that doesn't exercise its target boundary is discarded — not offered. "Verified by execution" is a measurement, not a model claim.

**Coverage Gap Closer**: reads two independent measurements — suite coverage ('/scenario-runs/:id/coverage') and production dead rules ('/monitoring/rules/dead'). A rule dead in both places is the highest-priority gap to close, and gets cases first.

Target Topics & Keywords

#boundary coverage#AI test generation#BRMS boundary testing#decision table coverage#rule boundary values#threshold testing

Ready to evaluate DecisionManager?

Plans without a public rate card. Live demo runs in the browser with no signup. ODM export inventory stays on your machine. Free trial — no card, does not auto-convert.