Check executable decision logic for missing or conflicting cases

Why use this

1. A team maintaining executable guidelines may find that each branch looks reasonable while the overall tree leaves some inputs unhandled or gives contradictory outcomes. Reading the code alone may not reveal which cases the checks actually cover.

2. This job could organize a verification plan around explicit input domains and expected behavior. Distinguishing structural logic findings from clinical correctness keeps a useful engineering check from becoming an unsupported assurance about real-world decisions.

Why an agent / simpler alternative

Useful judgment

Identify ambiguous branch conditions, propose coverage partitions and explain contradictions for qualified domain review.

Simpler alternative

Use deterministic exhaustive checks when the input space is small and precisely defined.

Unsuitable when

The task would approve clinical decisions, deploy guideline logic or treat structural coverage as medical validation.

Proposed inputs

1. Name

   Versioned logic specification

   Owner

   Authorized engineering owner

   Minimum scope

   Scoped decision modules and input definitions

   Quality check

   Check boundary conditions and version lineage

2. Name

   Expected-case criteria

   Owner

   Qualified domain owner

   Minimum scope

   Approved outcomes and exception handling

   Quality check

   Separate clinical authority from implementation assumptions

Access and setup — proposed or unknown

Proposed minimum

1. Review fictional decision tables and expected cases; no module execution, patient data or release changes.

Compatibility unknowns

1. Current compiler semantics, verification tooling, module format and runtime compatibility are unknown.

External actions requiring approval

1. Access to clinical systems/data, code changes, test execution and release actions requires explicit scope and qualified oversight.

Expected deliverable and review checks

Proposed artifact

Verification-plan candidate with case partitions, suspected conflicts, unreachable-path questions and evidence needs.

Critical checks

1. Map each condition to a domain; preserve undefined cases; distinguish proposed tests from executed coverage and clinical assurance.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   Two branches overlap at a boundary

   Why it matters

   The same input can receive conflicting outcomes

   Proposed response

   Document the overlap and request the intended precedence.

2. Signal

   A default hides an omitted case

   Why it matters

   Execution may complete with an inappropriate fallback

   Proposed response

   Expose the missing domain case for qualified review.

Effort and cost — unknown

Setup work

1. Define input domains and authoritative expectations.

Ongoing review

1. Engineers and domain specialists review findings and future test evidence.

Unknowns

1. State-space size, verification coverage, tooling compatibility and review costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent a nonclinical routing tree with overlapping thresholds and an uncovered category; derive a paper case table.

Acceptance checks

1. Identify both structural issues; claim no clinical or executable validation; run nothing.

Stop conditions

1. Stop if expected behavior lacks qualified ownership or work would touch live decision systems.

Limits

1. A structural test plan cannot establish clinical safety, complete coverage or correct executable behavior.