okhp3-decision-model-authoring

Topics in the source

• okhp3-decision-model-authoring
• Purpose
• When to use this skill
• When NOT to use this skill
• DMN Table Structure
• Authoring Workflow
• Step 1 — Extract decision points
• Step 2 — Identify inputs and outputs

OverKill Hill P³ · overkillhill.com · github.com/OKHP3 Transform PNS decisionpoints into structured DMN-aligned decision models. Each decision point becomes a decision table with explicit input conditions, output values, and the business rule governing the routing logic. -- PNS has ≥3 decisionpoints — this is the mandatory trigger condition User needs a decision table to communicate routing logic to implementers Business rules are complex enough that prose descriptions are insufficient Preparing a decision catalog as part of governance documentation PNS has fewer than 3 decisionpoints — inline the logic in the PNS decisionpoints[] section Decision logic is trivially binary (yes/no) with no business rule — document in businessrules[] instead Do not model decisions before the PNS is validated (score ≥ 75) -- Each decision table entry has: | Field | Description | |---|---| | decisionid | Stable identifier matching pns.decisionpoints[].id | | decisionname | Human-readable label | | activityid | The PNS activity where this decision occurs | | hitpolicy | U (Unique) \| F (First) \| A (Any) \| C (Collect) | | inputs[] | Each input: name, type (string\|number\|boolean), values[] | | output

This is an excerpt. Refer to the complete source and its current requirements.