DSL Generation: Transforming Decision Rules Buried in Corporate Documents into Actionable Knowledge

🎥 The YouTube version is also available:

Knowledge Flow: Transforming Enterprise Knowledge into AI-Ready Knowledge Infrastructure

Books: KNOWLEDGE FLOW PRACTICAL GUIDE: Transform Enterprise Knowledge into Al-Ready Knowledge Infrastructure

Knowledge Acquisition collects information across the enterprise, and Semantic Document Chunking divides that information into meaningful units.

Knowledge Extraction then extracts entities, relationships, constraints, events, and intent from the text. Ontology Construction and Knowledge Graph Generation organize the semantic structure and relationships of enterprise knowledge.

At this stage, however, AI merely knows the organization’s rules.

To use those rules in actual decisions, they must be converted into a form a machine can interpret:

under what conditions, what should be evaluated, and what action should be performed.

In Knowledge Flow, DSL Generation fulfills this role.

DSL stands for Domain-Specific Language.

It is a language for converting natural-language rules found in enterprise documents into an executable form for a specific business domain.

Why DSL Is Necessary

Enterprises have a vast number of decision rules.

For example, in contract management:

Contracts with a value of JPY 10 million or more require director approval.

In facility management:

Stop operation when equipment temperature reaches 80°C or higher.

In inventory management:

Place an additional order when inventory falls below 100 units.

In quality management:

Notify the Quality Assurance Department when the defect rate exceeds 5%.

These expressions are easy for people to understand.

However, natural language is inherently ambiguous. For example:

• Does “or more” include the boundary value?
• Which department’s director is meant by “director”?
• Does “stop” mean an immediate stop, or a stop after safety checks?
• Does “notify” mean an email, or an approval workflow?
• When there are multiple conditions, must all of them be satisfied?

For these reasons, natural language alone cannot support safe and consistent execution.

Knowledge Flow converts such decision rules into DSL, making the condition, target, action, and responsible party explicit.

Converting Natural Language into DSL

For example, consider the statement:

Contracts with a value of JPY 10 million or more require director approval.

It can be broken down as follows.

Target:
Contract

Attribute:
Amount

Condition:
Amount >= 10,000,000

Action:
Request Approval

Approver:
Director

Expressed as DSL, it becomes:

RULE ContractDirectorApproval

WHEN
    Contract.Amount >= 10000000

THEN
    REQUIRE Approval BY Director

For a simple case, it can also be represented as:

IF Contract.Amount >= 10000000
THEN Approval = Director

In real operations, however, it is safer to retain the rule name, target, version, source, responsible party, and other metadata as well.

Example: Equipment Shutdown Rule

Consider the following statement:

Stop the equipment and notify the maintenance team when equipment temperature reaches 80°C or higher.

Knowledge Extraction identifies the following elements:

{
  "subject": "Machine",
  "variable": "Temperature",
  "operator": ">=",
  "value": 80,
  "unit": "Celsius",
  "actions": [
    "Stop Machine",
    "Notify Maintenance"
  ]
}

It can be represented in DSL as follows:

RULE MachineOverheatProtection

WHEN
    Machine.Temperature >= 80 CELSIUS

THEN
    STOP Machine
    NOTIFY MaintenanceTeam

When safety must be considered more carefully, the rule can include sensor validity and incident recording:

RULE MachineOverheatProtection

PRIORITY Critical

WHEN
    Machine.Temperature >= 80 CELSIUS

THEN
    REQUEST SafeShutdown
    NOTIFY MaintenanceTeam
    RECORD Incident

REQUIRE
    Sensor.Status == Valid

Basic Structure of a DSL

The DSL generated in Knowledge Flow generally includes the following elements:

Rule ID
Rule Name
Version
Source
Target
Condition
Constraint
Action
Actor
Priority
Exception
Approval
Trace

For example, it can be maintained in YAML:

rule_id: RULE-00031
name: ContractDirectorApproval
version: 1.2
source_document: DOC-001245
target: Contract
priority: High

when:
  field: Contract.Amount
  operator: ">="
  value: 10000000
  currency: JPY

then:
  action: RequireApproval
  approver_role: Director

trace:
  enabled: true

This format is readable for people and processable by systems.

JSON DSL

When system-to-system integration is important, JSON DSL is suitable.

{
  "rule_id": "RULE-00031",
  "name": "ContractDirectorApproval",
  "version": "1.2",
  "target": "Contract",
  "condition": {
    "field": "Contract.Amount",
    "operator": ">=",
    "value": 10000000,
    "currency": "JPY"
  },
  "action": {
    "type": "RequireApproval",
    "actor": "Director"
  },
  "source": {
    "document_id": "DOC-001245",
    "chunk_id": "CHK-000154"
  }
}

JSON DSL is well suited to:

• API integration
• Rule validation
• Version management
• Passing rules to the Runtime Kernel

When Using a Custom DSL

When an enterprise has complex domain-specific business logic, it can design a custom DSL.

For example, in the contract approval domain:

CONTRACT APPROVAL RULE ContractHighValue

IF
    Amount >= 10000000 JPY

AND
    ContractType != Standard

THEN
    APPROVAL REQUIRED BY LegalDirector

BEFORE
    Execution

In manufacturing:

SAFETY RULE MachineTemperatureLimit

IF
    Temperature >= 80 C

FOR
    10 SECONDS

THEN
    SAFE_STOP Machine

AND
    ALERT Maintenance

This makes it possible to use expressions suited to the business domain.

A DSL is not a general-purpose programming language.

Its purpose is to express specific business decisions in a form that both people and AI can understand.

From Single Conditions to Compound Conditions

Enterprise decision rules do not always have only one condition.

For example:

If the contract value is JPY 10 million or more, the counterparty is a foreign company, and the standard contract template is not used, approval from the legal director is required.

This rule can be expressed as follows:

RULE InternationalNonStandardContractApproval

WHEN
    Contract.Amount >= 10000000
    AND Contract.Counterparty.Country != "Japan"
    AND Contract.Template != "Standard"

THEN
    REQUIRE Approval BY LegalDirector

Structured conditions look like this:

{
  "all": [
    {
      "field": "Contract.Amount",
      "operator": ">=",
      "value": 10000000
    },
    {
      "field": "Contract.Counterparty.Country",
      "operator": "!=",
      "value": "Japan"
    },
    {
      "field": "Contract.Template",
      "operator": "!=",
      "value": "Standard"
    }
  ]
}

Making compound conditions explicit clarifies the ambiguous AND/OR relationships that natural language often contains.

Expressing Exception Rules

Enterprise rules have exceptions.

For example:

Contracts with a value of JPY 10 million or more require director approval, except projects already approved by the board of directors.

In DSL:

RULE ContractDirectorApproval

WHEN
    Contract.Amount >= 10000000

THEN
    REQUIRE Approval BY Director

EXCEPT WHEN
    Contract.BoardApproved == true

When exceptions remain implicit, AI may make incorrect decisions.

Converting rules to DSL clearly separates normal conditions from exception conditions.

Expressing Time Conditions

Time is also important in business rules.

For example:

Stop the equipment when its temperature remains above 80°C for at least 10 seconds.

A simple comparison is not enough.

RULE SustainedOverheatShutdown

WHEN
    Machine.Temperature > 80 CELSIUS

DURATION
    >= 10 SECONDS

THEN
    SAFE_STOP Machine

Or:

Escalate to a senior manager if an application is not approved within three business days.

RULE ApprovalEscalation

WHEN
    Approval.Status == Pending

DURATION
    > 3 BUSINESS_DAYS

THEN
    ESCALATE TO SeniorManager

In this way, a DSL can also express temporal constraints.

Connection to the Ontology

The concepts used in a DSL reference Canonical Names in the Ontology.

For example:

Contract.Amount
Director
Machine.Temperature
QualityAssuranceDepartment

are all concepts defined in the Ontology.

This allows terms to be normalized. Even if the sales department uses “Client” and the finance department uses “Customer,” the DSL can standardize them to the Canonical Name:

Customer

Connecting the DSL to the Ontology ensures that the meaning of rules remains consistent.

Connection to the Knowledge Graph

A DSL does not exist in isolation; it connects to the Knowledge Graph.

For example:

Contract
   │
   ├── HAS_RULE ──▶ ContractDirectorApproval
   │
   ├── REQUIRES ──▶ DirectorApproval
   │
   └── DESCRIBED_BY ──▶ ContractPolicyDocument

This makes it possible to trace:

“Which document generated this rule?”

“Which concepts does it apply to?”

“Which approvers are involved?”

Generating DSL with an LLM

In Knowledge Flow, an LLM generates DSL candidates by referring to Semantic Chunks and the Ontology.

An input could look like this:

{
  "chunk_id": "CHK-000154",
  "text": "Director approval is required when the contract value is JPY 10 million or more.",
  "ontology": {
    "Contract": {
      "attributes": [
        "Amount"
      ]
    },
    "Director": {
      "type": "OrganizationalRole"
    }
  }
}

Rather than allowing free-form output, the LLM is given a DSL schema.

An example output is:

{
  "rule_name": "ContractDirectorApproval",
  "target": "Contract",
  "conditions": [
    {
      "field": "Contract.Amount",
      "operator": ">=",
      "value": 10000000,
      "currency": "JPY"
    }
  ],
  "actions": [
    {
      "type": "RequireApproval",
      "actor": "Director"
    }
  ]
}

Validation During DSL Generation

DSL generated by an LLM must not be executed as-is.

Knowledge Flow performs validation in multiple stages.

Syntax Validation

Confirm that the DSL conforms to the defined grammar.

Syntax Validation

For example, verify that operators and field names are valid.

Semantic Validation

Confirm that the DSL uses concepts and attributes that exist in the Ontology.

For example, if the Ontology does not contain:

Contract.Price

and the correct attribute is:

Contract.Amount

the rule should be rejected as an error.

Type Validation

Validate types such as monetary amounts, strings, dates and times, and Booleans.

Contract.Amount >= "Large"

A rule like this is rejected as a type mismatch.

Conflict Validation

Conflicts with existing rules must also be checked.

For example, if both of the following rules exist:

IF Contract.Amount >= 10000000
THEN Approval = Director

and

IF Contract.Amount >= 5000000
THEN Approval = Manager

it is necessary to make clear which rule takes priority for contracts valued at JPY 10 million or more.

Rule Priorities

When multiple rules match, priorities are required.

For example:

RULE StandardApproval
PRIORITY 10

RULE HighRiskApproval
PRIORITY 50

RULE RegulatoryRestriction
PRIORITY 100

In general, the order of precedence is:

Laws and safety rules
        ↓
Enterprise policies
        ↓
Departmental rules
        ↓
Individual business rules

This prevents a departmental rule from overriding a legal requirement.

Human Review

Automatically generated DSL is reviewed by a person before execution.

DSL Candidate

↓

Syntax Validation

↓

Semantic Validation

↓

Conflict Detection

↓

Human Review

↓

Approved DSL

The review screen displays:

• The original text
• Generated conditions
• Generated actions
• Referenced Ontology
• Differences from existing rules
• Expected execution results

People do not need to reread the entire source document; they can review only the rule candidate and its differences.

Rule Repository

Approved DSL is stored in the Rule Repository.

{
  "rule_id": "RULE-00031",
  "name": "ContractDirectorApproval",
  "status": "Approved",
  "version": "1.2",
  "effective_from": "2026-07-01",
  "effective_to": null,
  "owner": "Legal Department",
  "source_document": "DOC-001245",
  "source_chunk": "CHK-000154",
  "approved_by": "USR-0098"
}

The repository manages:

• Version history
• Effective periods
• Approval history
• Owning department
• Scope of application
• Retirement status

Execution in the Decision Runtime Kernel

Approved DSL is evaluated in the Decision Runtime Kernel.

For example, when a contract application is submitted, the flow is:

Decision Request

↓

Context Loading

↓

Ontology Resolution

↓

Knowledge Graph Retrieval

↓

DSL Evaluation

↓

Policy Check

↓

Human Approval

↓

Execution Permission

↓

Decision Trace

If the input is:

{
  "contract_id": "CNT-10021",
  "amount": 15000000,
  "currency": "JPY"
}

the DSL matches the condition:

15000000 >= 10000000

It then produces:

{
  "decision": "ApprovalRequired",
  "approver": "Director",
  "matched_rule": "RULE-00031"
}

A DSL Is Not a Direct Execution Command

The important point is that DSL generated by an LLM must not be executed directly against external systems.

The DSL is first passed to the Decision Runtime Kernel as a decision candidate.

The Runtime Kernel evaluates the following before deciding whether execution should be permitted:

• Policy
• Boundary
• Authority
• Context
• Risk
• Human Approval

For example, even if a DSL contains:

STOP Machine

the equipment should not be stopped immediately without first checking for a possible sensor failure and confirming the safe shutdown procedure.

The DSL represents execution logic, but the Runtime Kernel manages the ultimate authority to execute.

Recording in the Decision Trace

The results of DSL evaluation are recorded in the Decision Trace.

For example:

{
  "decision_id": "DEC-000892",
  "input": {
    "contract_amount": 15000000
  },
  "matched_rule": "RULE-00031",
  "rule_version": "1.2",
  "evaluation": true,
  "required_action": "DirectorApproval",
  "timestamp": "2026-07-14T10:30:00Z"
}

This makes it possible to explain afterward:

• Which rule was used
• Which version was applied
• Which input conditions matched
• Why approval was required
• Who made the final decision

Continuous Rule Improvement

Enterprise rules change.

New laws may come into effect, organizational changes may occur, and approval thresholds may be revised.

When a new document is registered, existing DSL is updated through the following flow:

New Policy Document

↓

Semantic Chunk

↓

Knowledge Extraction

↓

DSL Candidate

↓

Diff Detection

↓

Human Review

↓

Rule Update

For example, if:

JPY 10 million or more

is changed to:

JPY 5 million or more

the Rule Repository manages the change as a versioned difference.

Past decisions remain linked to the earlier version, while new decisions are evaluated using the new version.

DSL Formalizes Organizational Decision-Making

DSL Generation in Knowledge Flow is not merely a process for converting text into programs.

It makes explicit the conditions, constraints, approvals, exceptions, time conditions, priorities, and responsible parties that were embedded in enterprise documents, and converts the organization’s way of making decisions into a form that machines can evaluate.

The Ontology unifies meaning. The Knowledge Graph connects related knowledge. The DSL formalizes how decisions should be made.

The Decision Runtime Kernel then evaluates that DSL, and it proceeds to execution only when it passes Policy, Boundary, Human Authority, Context, and Risk checks.

In other words, DSL is not a mechanism for allowing AI to act freely.

It is a mechanism for connecting AI judgment to organizational rules and transforming it into verifiable, explainable decision-making.

DSL Generation in Knowledge Flow is the core process that transforms an organization’s implicit decision rules into executable knowledge assets for the AI era.