Business rules to DMN 1.5

Turn spaghetti code into clean DMN decision tables.

PYD ENTERPRISES separates the rules from the plumbing, writes them as DMN 1.5 tables and FEEL formulas, and puts every row beside the lines it came from for sign-off.

Request a codebase scan Explore demo

DECISION · COASTAL WIND LOADhit policy UNIQUE

State	Coastal	Wind load	Source
"FL"	"Y"	base × 0.185	RT2400:10-12
"FL"	"N"	0	RT2400:13-14
not("FL")	-	0	RT2400:13-14

approved by underwriting SME · 2026-10-29signed off

Rules vs. infrastructure

Seventeen lines. Two rules.

Most of a legacy paragraph is I/O, logging and error handling. The rule extractor works from program slices to business outputs, so plumbing falls away by construction.

L2 to 6READ with INVALID KEY, DISPLAY, abendPlumbing: I/O and error handling
L7 to 9FILE STATUS check, log paragraphPlumbing: error handling
L10 to 15Coastal wind load for FloridaRule RT-2400-01 (calculation)
L16Accumulate into total premiumRule RT-2400-02 (aggregation)
L17Operator messagePlumbing: logging

RTPREM24.cbl · 2400-POST-PREMIUMruleplumbing

1       2400-POST-PREMIUM.
2           READ POLICY-FILE INTO WS-POLICY
3              INVALID KEY
4                 DISPLAY 'RT2400 POLICY NOT FOUND ' WS-POL-KEY
5                 PERFORM 9999-ABEND
6           END-READ
7           IF WS-POL-FILE-STATUS NOT = '00'
8              PERFORM 9100-LOG-IO-ERROR
9           END-IF
10           IF WS-POL-STATE = 'FL' AND WS-POL-COASTAL-IND = 'Y'
11              COMPUTE WS-WIND-LOAD ROUNDED =
12                      WS-BASE-PREM * 0.185
13           ELSE
14              MOVE ZERO TO WS-WIND-LOAD
15           END-IF
16           ADD WS-WIND-LOAD TO WS-TOTAL-PREM
17           DISPLAY 'RT2400 PREM POSTED ' WS-POL-KEY

Human-in-the-loop validation

Every row beside the lines that justify it.

Click a row to highlight its source. Approve, flag for a subject matter expert, or reject the extraction. RT-06 is already flagged: a 1991 Massachusetts override silently discards the claims surcharge.

RTAUTO03.cbl · decisions: Base age factor (UNIQUE), Driver factor (FIRST)

1/6 reviewed

1      * RTAUTO03  DRIVER RATING FACTOR  (1991, CR 2207 MA RULE)
2       01  WS-DRIVER.
3           05  WS-DRV-AGE          PIC 9(03).
4           05  WS-DRV-CLAIMS-3YR   PIC 9(02).
5           05  WS-DRV-STATE        PIC X(02).
6       01  WS-FACTOR               PIC V999 COMP-3.
7 
8       3000-DRIVER-FACTOR.
9           EVALUATE TRUE
10              WHEN WS-DRV-AGE < 21
11                 MOVE 1.850 TO WS-FACTOR
12              WHEN WS-DRV-AGE < 25
13                 MOVE 1.400 TO WS-FACTOR
14              WHEN WS-DRV-AGE > 74
15                 MOVE 1.250 TO WS-FACTOR
16              WHEN OTHER
17                 MOVE 1.000 TO WS-FACTOR
18           END-EVALUATE
19           IF WS-DRV-CLAIMS-3YR > 1
20              COMPUTE WS-FACTOR ROUNDED = WS-FACTOR * 1.300
21           END-IF
22           IF WS-DRV-STATE = 'MA' AND WS-DRV-AGE < 21
23              MOVE 1.600 TO WS-FACTOR
24           END-IF.

#	Age	Claims 3y	State	Factor	Status
RT-01	< 21	-	-	1.850	pending
RT-02	[21..25)	-	-	1.400	pending
RT-03	> 74	-	-	1.250	pending
RT-04	[25..74]	-	-	1.000	pending
RT-05	-	> 1	-	base × 1.300	pending
RT-06	< 21	-	"MA"	1.600	flagged

RT-06 · DRIVER FACTOR · LINES 22 TO 24

Executes after the claims surcharge and overwrites it. A Massachusetts driver under 21 with two claims gets 1.600, not 1.850 × 1.300 = 2.405. Confirm this is intended policy.

approved: 0
flagged: 1
rejected: 0

Mathematical formula extraction

Interest, tax and actuarial math, with the rounding intact.

Compound interest

COMPUTE WS-MAT-VAL ROUNDED =
    WS-PRIN * (1 + WS-RATE / 12) ** WS-TERM

principal * (1 + annualRate / 12) ** termMonths

Monthly compounding. ROUNDED half-up to the target PIC scale (2 decimals).

Tax withholding

EVALUATE TRUE
  WHEN WS-GROSS <= 1000  ...  * 0.10
  WHEN WS-GROSS <= 4000  ...

decision table, hit policy UNIQUE, 4 bracket rows

Brackets become rows; cumulative base amounts are carried as outputs.

Actuarial present value

PERFORM VARYING WS-T FROM 1 BY 1
  UNTIL WS-T > WS-YEARS ...

sum(for t in 1..years return payment * survival[t] * (1 + i) ** -t)

Loop recognized as a summation over a mortality table read from VSAM.

Truncation, not rounding

COMPUTE WS-DAILY = WS-ANNUAL / 365

round down(annual / 365, 2)

No ROUNDED phrase: COBOL truncates to the target scale. PYD ENTERPRISES writes the truncation explicitly so the new service matches to the cent.

“A 4,000-line procedural routine became decision tables our actuaries could check line by line.”

Lead business analyst · Regional P&C insurance carrier

DMN editor & exporter

Edit visually, export standard XML.

Analysts can rename inputs, merge rows that PYD ENTERPRISES proves equivalent and annotate rules in the console. Every edit is diffed against the extracted baseline, so intentional changes stay visible.

UNIQUEUsed when PYD ENTERPRISES proves the branch conditions cannot overlap, as with an EVALUATE over disjoint ranges.

FIRSTUsed when legacy order matters: nested IFs or overrides that later statements apply. Overlaps are listed for analysts.

PRIORITYUsed when outputs carry an explicit ranking, such as the most severe edit code winning.

COLLECTUsed when every matching branch contributes, for example multiple surcharges added to one premium.

driver-factor.dmn (excerpt)XML

1<decision id="baseAgeFactor" name="Base age factor">
2  <decisionTable hitPolicy="UNIQUE">
3    <input label="Driver age"><inputExpression typeRef="number"><text>age</text></inputExpression></input>
4    <output name="factor" typeRef="number"/>
5    <rule>
6      <description>RTAUTO03.cbl:10-11 (RT-01)</description>
7      <inputEntry><text>&lt; 21</text></inputEntry>
8      <outputEntry><text>1.850</text></outputEntry>
9    </rule>
10    <rule>
11      <description>RTAUTO03.cbl:12-13 (RT-02)</description>
12      <inputEntry><text>[21..25)</text></inputEntry>
13      <outputEntry><text>1.400</text></outputEntry>
14    </rule>
15  </decisionTable>
16</decision>

Exports import into Camunda and Drools. Read the DMN specification guide for hit policies and FEEL.

FAQ

Rule extraction questions.

How does PYD ENTERPRISES decide what is a business rule and what is plumbing?

From the program slices that reach business outputs. Statements that only affect file status, logging, abend handling, cursor and connection management or screen attributes never reach a business output and are classified as plumbing. Statements on a slice to an output field that the business cares about (a premium, a fee, an eligibility flag) become rule candidates. Anything ambiguous is flagged for review.

Does every rule become a decision table?

No. Condition-heavy logic becomes DMN decision tables. Arithmetic becomes formulas in FEEL with their rounding behavior. Iterative calculations such as amortization are exported as formulas with worked examples, because forcing them into a table would hide what they do.

Who signs off extracted rules?

Your analysts and subject matter experts, in the side-by-side review view or through the Jira integration. PYD ENTERPRISES records who approved each rule and when, and only approved rules are included in a baseline export.

Can we guarantee every rule was found?

PYD ENTERPRISES accounts for every executable path: each one is extracted as a rule, classified as plumbing, or flagged for review, and the counts are reported per program. That is a stronger claim than a percentage, because nothing is silently dropped, but it still relies on human review of the flagged set.

Which DMN engines can run the exports?

DMN 1.5 files open in standard DMN modelers and engines such as Camunda and Drools. If your engine expects an earlier DMN version, set the export target to match; the export report lists any construct the target cannot express.

Give your analysts tables, not printouts.

Run PYD ENTERPRISES on 100,000 lines of COBOL or Java in your private VPC and review OpenAPI specs and DMN tables tomorrow.

Request a codebase scan Book technical walkthrough