Validate the input file with decision table recognizer

[DariuszDepta]

Load only input files that are validated using dsntk-recognizer and are horizontal or vertical decision tables.

[magick93]

Does dsntk-recognizer work with markdown tables?

[DariuszDepta]

No, dsntk-recognizer does not recognize markdown tables. This question is in fact quite interesting. I am just wondering how the DMN compliant decision table could be represented using makdown tables. I am open to implement this in the recognizer ;-).

[magick93]

I'm glad to see this is idea is well received.

I think md dmn tables can really open up dmn table editing and viewing as there is a vast md eco-system.

In particular, the main benefit of dmn is is its ease of visually reading and understanding.
The main disadvantage, currently, is the use of highly verbose xml. Markdown is a good solution for, at least, the decision table portion of this.

[magick93]

Some brain dump thoughts on using markdown to model DMN.

---

1. DMN Document Metadata

Use front matter for namespace declarations and document-level attributes:

---
dmn:
  namespace: "https://mycompany.com/dmn/loan-approval"
  id: "loan_approval_v1"
  exporter: "MarkdownDMN v1.0"
  definitions:
    - decisions: [D1, D2]
    - inputs: [input1, input2]
    - knowledge_sources: [KS1]
---

---

2. Decision Element Definition

Embed decision metadata in front matter before the table:

---
dmn:
  id: "D1"
  name: "Loan Approval"
  hit_policy: "UNIQUE"
  requirements:
    - decision: "D2"
    - input: ["input1", "input2"]
  output:
    name: "approval_status"
    type: "string"
    allowed: ["Approved", "Denied", "Pending Review"]
---
| Income ≥ | Credit Score ≥ | Approval Status   |
|----------|----------------|-------------------|
| 50,000   | 700            | Approved          |
| 30,000   | 650            | Pending Review    |
| -        | <650           | Denied            |

---

3. Relationship Mapping

Front matter can explicitly declare relationships between elements:

---
dmn:
  type: "decision_requirements"
  elements:
    D1:
      type: "decision"
      links:
        - "D2#income-check"
        - "input1#income"
        - "input2#credit-score"
    KS1:
      type: "knowledge_source"
      url: "https://example.com/credit-policy.pdf"
---

---

4. Type Definitions

Standardize data types across the system:

---
dmn:
  type: "data_types"
  definitions:
    Income:
      type: "number"
      range: ">= 0"
      format: "USD"
    CreditScore:
      type: "integer"
      range: "300..850"
---

---

5. Decision Service Contracts

Define service interfaces for executable decisions:

---
dmn:
  type: "decision_service"
  id: "DS1"
  inputs:
    - name: "applicant_income"
      type: "Income"
      source: "input1"
    - name: "credit_score"
      type: "CreditScore"
      source: "input2"
  outputs:
    - target: "D1#approval_status"
---

---

6. Knowledge Source Attribution

Link to regulations/policies:

---
dmn:
  type: "knowledge_source"
  id: "KS1"
  authority: "National Credit Regulator"
  validity: "2023-01-01/2025-12-31"
  references:
    - url: "https://regulator.gov/credit-rules-v12"
      section: "4.2a"
---

---

7. Validation Rules

Embed FEEL-like constraints in front matter:

---
dmn:
  type: "input"
  id: "input1"
  validation: |
    if Income < 0 then 
      "Invalid negative income"
    elif Income > 10_000_000 then
      "Income exceeds sanity check threshold"
    else null
---

---

Key Advantages of Front Matter Integration

1. Machine-Readable Relationships
   Tools can parse YAML front matter to:

   • Generate visual DRDs
   • Validate decision dependencies
   • Export to DMN XML

2. Version Control Friendly
   Changes to metadata and content are tracked together in Git

3. Multi-File Organization
   Each decision/input can be a separate Markdown file with front matter linking to others:

   ---
   dmn:
     requires:
       - "../decisions/income_check.md#D2"
       - "../inputs/credit_score.md"
   ---

4. Documentation Generation
   Static site generators (Jekyll/Hugo) can auto-create DMN documentation websites

---

Full Example: Combined File

---
dmn:
  namespace: "https://bank.com/dmn"
  id: "loan_v1"
  decisions: [approval, income_check]
  inputs: [income, credit_score]
---

# Loan Approval DMN

## Input Data: Income
```yaml
---
dmn:
  type: "input"
  id: "input1"
  datatype: "decimal"
  unit: "USD"
  validation: "value >= 0"
---
```

## Decision: Income Check (D2)
```yaml
---
dmn:
  id: "D2"
  requires: [input1]
  output_type: "boolean"
---
| Income Threshold | Valid? |
|------------------|--------|
| >= 50000         | true   |
| <50000           | false  |
```

## Decision: Final Approval (D1)
```yaml
---
dmn:
  id: "D1"
  requires: [D2, input2]
  hit_policy: "FIRST"
---
| Income Valid? | Credit Score | Outcome  |
|---------------|--------------|----------|
| true          | >=700        | Approved |
| true          | 650-699      | Pending  |
| false         | any          | Denied   |
```

---

And alternative to using front matter:

Decision D1: Loan Approval

Hit Policy: UNIQUE
Inputs:

• Income (number)
• Credit Score (number)

Output: Approval Status (string)

Income ≥	Credit Score ≥	Approval Status
50,000	700	"Approved"
30,000	650	"Pending Review"
-	<650	"Denied"

The links could be to a jsonschema, yaml or other data description format file .