eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How People Translate Quickly | DMN 1.5 Decision Tables: Translate Decision Labels Without Changing Business Rules

—

by

eduKate Asia

How do people translate DMN decision tables quickly without changing the decisions they make? Separate explanatory labels, documentation and approved presentation text from the executable expressions, data field names, hit policies and output contracts. Translate the words a reader needs to understand the rule, but keep the logic that calculates the answer stable. Then test identical input cases against the original and localized deployment. A bilingual rule table is safe only if it communicates the same policy and produces the same intended result for every relevant case.

Decision Model and Notation, or DMN, gives teams a way to describe decisions and their logic. A table may appear to be a simple spreadsheet with everyday words such as Age, Member Type and Eligible, but the cells can carry FEEL expressions and controlled output values that other systems consume. A careless localization can turn a valid comparison into inert prose, or translate an output token that a downstream application expects verbatim. The resulting table may still look neat to a human reviewer while deciding the wrong thing or failing at runtime.

This article uses the Object Management Group’s DMN 1.5 standard as the technical reference and a fictional community-course eligibility decision as the running example. It covers names and labels, input expressions, rule entries, hit policies, output identity, tests, diagnostics and repairs. The purpose is not to teach a full DMN modelling course or rewrite business policy. It is to help a translator and rules engineer deliver genuinely understandable multilingual decision interfaces while preserving the meaning and implementation of approved rules.

Establish the decision and the reader job before translating

Imagine a community center offering a course that adults may register for. Its application collects an age value and returns an eligibility result. The rules team has built a DMN table, while the parent-facing form and staff guide must work in English and Chinese. These are distinct outputs: an operational rule engine that evaluates age, a user interface that tells people what information is needed, and an explanatory document describing why the decision was reached. The language team should know which layer it owns before touching any file.

Write a testable acceptance sentence: a Chinese-speaking applicant can understand the question and explanation, while the model returns the same eligibility boolean for the same numeric age as the approved English version. The statement explicitly forbids turning ‘at least 18’ into ‘older than 18’. It also separates visible wording from the data element the engine evaluates. If the team later wants different regional eligibility thresholds, that is a policy change needing separate approval, not a translation of an existing model.

Ownership matters because a DMN file may belong to an insurer, school, government office or company. A translator can improve clarity, flag ambiguous source wording and propose a safer explanation; a translator should not silently adjust a rule’s priority or substitute a different criterion. When an awkward sentence reveals a contradiction in policy, put the issue in a decision log and refer it to the decision owner. A fluent bilingual interface that faithfully implements a flawed source policy may still need correction, but the correction should be traceable and authorized.

A DMN table is more than a row of headings

The visible decision table has input clauses, output clauses and rules. An input clause describes a value to inspect, often with an input expression; a rule contains input entries that test that value and output entries that yield results. A hit policy determines how the model treats multiple matching rules. These parts may be rendered in a business-friendly editor, yet the serialized model distinguishes machine-evaluated content from explanatory text. A translator should ask the rules engineer to show both views and describe which values are contractually stable.

For instance, the input label might read ‘Applicant age’, while the input expression refers to a variable named applicantAge. The label is for human comprehension; the expression identifies a value in the decision context. Translating the variable into another script without updating the entire integration means the model may no longer find it. Similarly, an output heading might say ‘Eligible’, but the output name could be approved, with a boolean result expected by downstream software. Those forms perform different jobs despite sharing an everyday meaning.

The rule cells need their own classification. Some may contain simple numbers or dashes; others may include FEEL expressions, ranges, comparators, named variables, functions or strings that represent output codes. A translator cannot safely infer their role by whether they look like English. An output expression such as the string literal "APPROVED" may be an API contract, not a piece of user-facing language. Treat every expression as protected until the model owner confirms a localized value is allowed and all consumers have been reviewed.

Learn the distinction between a display label and a model identifier

In a DMN XML model, identifiers help connect model elements and support references. A decision can have a human-facing name and a stable technical ID; input and output clauses can have explanatory labels while executable expressions refer to context variables. The important rule is that the permission to translate one field does not transfer automatically to another field next to it. Make a glossary of fields that are visible to end users, fields visible to analysts only, and fields the execution engine treats as inputs or identifiers.

Our example decision might be named ‘Adult course eligibility’ and have a machine ID such as adultCourseDecision. The Chinese-facing interface may display an approved equivalent of ‘Adult course eligibility’, but the ID remains fixed. The applicantAge variable likewise remains unchanged unless the integration contract is deliberately refactored. A refactor can be valid engineering work, yet it requires source-code changes, model updates and tests beyond a translator’s remit. Calling it translation masks its true risk and deprives the team of proper review.

There is a further distinction between a display name used only by a modelling tool and one exported into the evaluated runtime artifact. Some editors regenerate IDs, flatten labels or serialize only certain attributes. The workflow must inspect the actual saved DMN representation, not assume every visual edit stays in a harmless display layer. If a tool replaces an expression as a side effect of renaming a column, the final model diff will reveal the change. A release should be judged on the exported artifact and its evaluation behavior, not merely the editor view.

A minimal decision-table example shows the protected parts

The following XML demonstrates a simple DMN-style decision table with a numeric input, two rules and a boolean output. The candidate translation would change the human-visible labels in the editor or related presentation and leave applicantAge, the rules, the hit policy and output values unchanged. This is an educational fragment intended to illustrate field roles; its XML syntax can be parsed, but schema conformance and engine compatibility still require tests against the exact vendor and version used in production.

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="https://www.omg.org/spec/DMN/20230324/MODEL/"
             id="course-eligibility" name="Course decisions"
             namespace="https://example.org/dmn/course">
  <decision id="adultCourseDecision" name="Adult course eligibility">
    <decisionTable id="adultCourseTable" hitPolicy="FIRST">
      <input id="input-age" label="Applicant age">
        <inputExpression id="age-expression" typeRef="number">
          <text>applicantAge</text>
        </inputExpression>
      </input>
      <output id="output-eligible" label="Eligible"
              name="approved" typeRef="boolean"/>
      <rule id="adult-rule">
        <inputEntry id="age-at-least-18"><text>&gt;= 18</text></inputEntry>
        <outputEntry id="eligible-true"><text>true</text></outputEntry>
      </rule>
      <rule id="other-rule">
        <inputEntry id="any-age"><text>-</text></inputEntry>
        <outputEntry id="eligible-false"><text>false</text></outputEntry>
      </rule>
    </decisionTable>
  </decision>
</definitions>

At age 18, the first rule should match and return true. At age 17, it should not match, so the fallback rule returns false. The ordering matters under a FIRST hit policy: a broad wildcard rule placed above the specific adult rule could intercept every case. The output name approved is still the stable result contract used by the application, regardless of how a display label is translated. These behaviors should be written as expected outcomes before someone edits the wording. The tests are small, but they expose a large proportion of typical accidental changes.

The example illustrates an important editorial boundary: ‘Eligible’ may be translated into the application interface and a display-oriented clause label if that editor supports the change, while true, false, >= 18 and applicantAge are part of executable meaning. A Chinese explanation might say that applicants must be at least eighteen years old, but should not replace the FEEL expression with a Chinese sentence inside the input-entry cell. One representation helps people; the other helps the engine decide. Treating them as interchangeable is the core failure this article aims to prevent.

Preserve FEEL syntax, operators and data types

Friendly Enough Expression Language, or FEEL, is designed for expressing decision logic, not for arbitrary prose translation. Comparisons, ranges, functions and identifiers have their own syntax and semantics. A translator who sees words inside an expression should not assume they are commentary. Some may be built-in language tokens, some may be identifiers provided by the surrounding model, and some may be literal values that an application contract expects. The rules engineer should label these classes before a translation vendor exports segments into a general text tool.

Consider the difference between >= 18 and > 18. To a casual reader the distinction is a small symbol; to an eligibility model it changes what happens to an eighteen-year-old applicant. Likewise, true and "true" can represent different types: boolean and string. Translating a literal string into a human-language word may look attractive but can break an integration that expects an exact status code. A robust QA script compares the evaluated expressions before and after localization, not simply the visual similarity of the table.

Spaces, punctuation and decimal notation require deliberate handling too. A rule editor may use FEEL syntax whose numeric representation differs from a reader’s normal regional formatting. A localized interface might show a friendly number format, but rewriting a numeric constant inside executable syntax to use a different decimal separator could change parsing. Keep the canonical expression in the model and localize a presentation rendering where supported. For high-stakes monetary or scientific decisions, verify that every constant and unit in the explanation corresponds exactly to the expression it describes.

Hit policies are operational meaning, not decoration

A decision table’s hit policy controls how matching rules contribute to a result. UNIQUE, FIRST, ANY, RULE ORDER, COLLECT and related policies are not interchangeable formatting choices. Their names may be shown in an editor or explained in training material, but the serialized policy value is an engine instruction. A translation that changes FIRST to UNIQUE because the target-language glossary makes them sound similar can alter evaluation or introduce runtime errors. Preserve the policy code and translate only an explanatory caption that accurately tells readers what it does.

The test design must reflect the policy. For FIRST, include an input that could satisfy more than one condition if overlapping rules exist, because rule order may determine the result. For UNIQUE, look for unintended overlaps that violate the premise. For COLLECT, evaluate accumulation and any specified aggregation behavior. Translating a table with only one happy-path case does not prove the rules remain correct. The most informative cases target boundaries, overlaps, missing inputs and exceptions, which often reveal mistakes that are invisible on a normal screen.

If the model owner wants to simplify a table before localization, do that as a separate versioned modelling change. Merging rules or reordering them might preserve behavior in some circumstances but not others, particularly when the hit policy is order-sensitive. A language review should not certify a combined refactor and translation as if it were a harmless text edit. Release evidence should separate the approval for business logic from the approval for human-facing wording so that any unexpected result can be traced to the correct change.

Output descriptions can be translated while output contracts stay stable

An application may receive a boolean named approved, a status code such as WAITLISTED, or a structured result with several fields. The person completing the form sees a sentence like ‘You can register for this course’. These are different layers. Good localization transforms the presentation of the result while keeping the machine contract stable. If a team wants localized output strings directly from DMN, it must confirm that downstream consumers are designed for that representation and test every supported locale, rather than replacing existing codes in place.

Suppose another rule returns "REVIEW_REQUIRED". An unguarded translator might substitute a fluent Chinese sentence inside the output cell. The user interface now looks more informative, but the integration may have an exact-match branch checking for REVIEW_REQUIRED and route unmatched values into an error path. The safe alternative is to keep REVIEW_REQUIRED as the result code and map it to an approved localized message in the presentation layer. This preserves system decisions while improving their explanation to the user.

If a decision truly outputs natural-language text as its approved business value, treat the case explicitly. Some DMN models may have been designed to produce user messages, and those messages may be eligible for localization after thorough contract review. The team should document whether they are changing a display string, a service payload or a rule condition. The method is not to forbid all translation inside DMN; it is to identify exactly when a string is part of the decision’s meaning and obtain authorization for any change that reaches beyond presentation.

Build a source-to-target traceability table

A useful review sheet gives each eligible string a stable locator: model version, decision ID, table ID, clause ID, field role, source text, proposed target text, reviewer and status. The locator matters more than simply numbering translation segments from top to bottom. A decision model can be re-exported with fields reordered, or a tool can change the visual order of clauses while retaining their IDs. If approvals depend only on row positions, a later import might attach a translated label to the wrong input.

For the eligibility table, record ‘input-age label: Applicant age’ separately from ‘input-age expression: applicantAge’. The first may receive a Chinese display form; the second remains protected. Record ‘output-eligible label: Eligible’ separately from ‘output-eligible name: approved’. This dual listing makes it difficult to mistake a presentational synonym for a runtime rename. It also gives a second reviewer a simple question to answer: does this target label still accurately describe the technical value or decision that will appear beneath it?

Add policy notes for controlled terminology. A school may need to distinguish ‘eligible’, ‘enrolled’, ‘accepted’, ‘approved’ and ‘registered’ with great care. They sound related, but each can represent a different stage in an educational process. If the same Chinese word is used for all five, readers may misunderstand whether they have permission to join a course or have actually secured a place. The glossary should reflect the institution’s actual process and link each term to the underlying result code, not merely to an English dictionary entry.

Translate the explanation of a rule, not the right to change it

A decision table often appears beside a narrative business rule or policy explanation. That prose should help someone understand what the algorithm does, but it can be badly written or inconsistent with the executable model. When the narrative says ‘over eighteen’ and the expression says >= 18, the mismatch needs a policy owner to resolve before translation. Otherwise an accurate Chinese rendering of the narrative may faithfully transmit a source error. Mark the discrepancy; do not choose whichever form seems more reasonable.

The source of truth may be the approved business policy, the executable model or a combination governed by the institution. The translator should not decide that hierarchy alone. Ask for a decision from the policy owner and keep evidence of the approved meaning. The wording can then be revised in every supported language and the model corrected through a controlled engineering change if necessary. This separation is especially important when decisions affect financial aid, eligibility, benefits or safety-critical approvals.

When the model is already approved and cannot be altered in the current release, the translation team can still improve reader comprehension by writing an accurate explanation of its actual behavior. It should avoid claiming the decision is fair, legally compliant or officially correct merely because the expression is syntactically valid. Standards conformance and policy legitimacy are different judgments. The role of this article is to protect decision equivalence while language changes, not to endorse the institution’s rules as socially or legally ideal.

Test a behavior matrix rather than a screenshot

Visual inspection answers whether labels fit in the table and readers can understand them. Behavioral testing answers whether the model still makes the same decision. Build a small fixture set containing representative values below, at and above every threshold, along with missing or unusual inputs. For the adult course example, age 17 should yield false and age 18 should yield true; a nonnumeric value should trigger the same declared validation or error path in both language environments. Specify expected outcomes rather than generating results from the edited model itself.

Compare the baseline model and localized candidate with the same engine version and input objects. An equivalent output across one case is weak evidence; an equivalent output across boundary and overlap cases is stronger. If the candidate fails to evaluate an input expression, inspect whether its variable name, type reference or expression syntax was changed. If it evaluates but gives a different answer, inspect comparator, rule ordering and hit policy. If outputs match but a UI message is wrong, inspect the localization mapping outside the model. This diagnostic partition prevents random edits.

For complex models, include downstream integration tests. A decision’s output may be consumed by another decision, a workflow or a form. A model could evaluate correctly in isolation but fail because a localized output key no longer matches the integration contract. Trace inputs and outputs at the boundary, and compare their names and types exactly. Do not infer success from an attractive decision-table editor or a JSON response that merely has the expected number of keys. The evidence must show that the consuming system recognized and acted on the value correctly.

Error cases deserve better translations than the happy path

What happens when applicant age is missing? Some systems reject the form before evaluation; others pass null or another defined state to the decision service. The target-language error must not invent a policy such as ‘You are ineligible’ when the actual result is ‘We cannot evaluate until age is provided’. Such a mistake conflates missing evidence with a negative decision. A translator should review the error taxonomy, the decision’s input contract and the precise circumstances in which each message appears.

Ambiguous or negative-result wording requires a careful tone. ‘Not approved’ might sound final, while ‘Not currently eligible under the adult-course rule’ gives a more accurate explanation if the decision concerns one course only. However, do not add appeals processes or deadlines that the institution does not offer. The target message must be readable and compassionate without changing the available rights or pathways. Readers often encounter these strings at stressful moments; precision is a service, not merely a technical checkbox.

Test long labels, small screens and accessibility surfaces. A decision-table editor may truncate a Chinese heading, break punctuation across lines or fail to expose an explanation to keyboard or screen-reader users. The executable model may be correct while the language interface remains unusable. Capture those findings as presentation defects, not rule defects. The fix might be a wider column, an accessible tooltip, a shorter approved label or a responsive layout. Changing the input expression to make the label fit would be an absurd but surprisingly common boundary mistake.

Diagnosing failures after import or export

Some tools save proprietary layout settings or normalize a standard DMN XML document when it is imported. If a translated editor label disappears after re-export, determine whether the tool supports that field, whether it intentionally prefers another display attribute, or whether the translation was placed in a vendor-only extension. The resulting behavior should be documented in the tool compatibility matrix. Do not claim universal portability simply because one vendor’s designer accepted the edit.

Another failure occurs when translating XML text indiscriminately. An XML file contains attribute values such as IDs and reference URIs, expression text, element names and presentational labels. A script that processes all text and attributes as natural language can invalidate the model without producing malformed XML. The document may parse perfectly yet refer to an unknown variable or a broken decision reference. Inspect the logical DOM diff by field role and execute the model, not just run an XML syntax check.

If an import suddenly changes hit policy, rule count or input order, stop. Those are model changes outside the translation scope, even if they happened through an export tool rather than a human editor. Revert to the baseline, reproduce the transformation, and ask the owner whether the changed behavior is intentional. A localization release should include a list of allowed changes and a machine-generated list of observed changes, with any mismatch treated as a blocker. Quietly accepting unrelated changes destroys the evidence that translation was behavior-preserving.

A lightweight invariant check and its limits

The following Python example illustrates a basic file-level comparison of the two DMN XML documents. It reads the same namespace-qualified structure from both files and collects selected protected attributes, then rejects changes. This helps identify accidental renames or policy edits, but it is not a full equivalence checker. A production test would also compare FEEL expressions, rule cells, semantic references and engine outputs, and would account for legitimate nonsemantic changes introduced by the modeling tool.

from lxml import etree
ns = {"d": "https://www.omg.org/spec/DMN/20230324/MODEL/"}
base = etree.parse("decision-source.dmn")
local = etree.parse("decision-localized.dmn")
for xpath in ("//d:decisionTable/@hitPolicy",
              "//d:inputExpression/d:text/text()",
              "//d:inputEntry/d:text/text()",
              "//d:outputEntry/d:text/text()"):
    assert base.xpath(xpath, namespaces=ns) == local.xpath(xpath, namespaces=ns)

This script gives the team a first alarm, not a semantic certificate. It assumes both files use the expected DMN namespace and that element order is meaningfully comparable for the selected paths. It does not establish that a given model is valid against the DMN 1.5 schema, that the source model itself was correct, or that every consumer handles the same subset of FEEL. The review report should identify exactly what the script checks and reserve strong compatibility claims for confirmed runtime evaluations in the chosen deployment environment.

Changed-context transfer exercise: public library fee waivers

A public library has a DMN table deciding whether a borrower qualifies for a late-fee waiver. Its conditions include age, a membership category and a special exception. The output is a string status used by an accounting system. The language team wants to create a Malay guide and notices the rule output "EXCEPTION_REVIEW" has no natural Malay meaning. A colleague proposes replacing that output with a Malay sentence and reordering the exception rule above the ordinary rule to make the table easier to read. Explain the safe choices and the tests needed before the multilingual guide is released.

Worked answer

Translate the human-facing status explanation in the guide or interface, while keeping the machine output token EXCEPTION_REVIEW unchanged unless the accounting integration is deliberately migrated. Record the output-code-to-label mapping in a versioned glossary. Do not reorder an exception rule merely for reading flow until the decision owner and engineer confirm that the hit policy and overlapping conditions preserve results. Check representative cases for every membership category, each age boundary and the exception, including inputs matching more than one condition. Compare the accounting system’s received status codes and the target-language message separately.

The changed context makes the distinction between a decision table and an explanatory table especially important. The guide may reorganize information for clarity, but the executable model’s rule order and semantics must remain as approved. It also exposes a common service mistake: an output code can be opaque to borrowers without needing to be translated inside the rule engine. The best solution is often a clear presentation layer and traceable code mapping, not a risky attempt to make executable strings sound like natural language.

A practical review checklist for a multilingual DMN model

Confirm the approved rule version and decision owner; list decisions, tables, inputs, outputs and hit policies; classify labels versus identifiers and expressions; maintain stable data names and output contracts; translate approved explanatory text; compare FEEL syntax and rule ordering; run boundary and overlap tests; check error messages and assistive presentation; inspect the exported XML; and record tool versions, limitations and approvals. A review should be reproducible from the source, candidate and fixture set, rather than depending on one modeler’s memory of how the table looked.

The final sign-off should be shared between the language reviewer, policy owner and rules engineer. The language reviewer verifies reader comprehension and equivalence of stated conditions. The owner confirms the policy has not been inadvertently broadened or narrowed. The engineer verifies expressions, data interfaces and runtime outputs. If any reviewer discovers a source contradiction, record the issue and pause release instead of trying to solve it through word choice alone. This approach may feel slower at the beginning but saves considerable time when decisions have operational consequences.

Make the QA evidence easy to inspect. A useful manifest lists original and translated artifact hashes, allowed changed fields, rejected differences, representative inputs and observed outputs, the language of the public explanation, and whether production integration testing took place. A claim such as ‘valid XML’ should not be placed beside ‘behavior equivalent’ as if they were interchangeable. Each statement refers to a different test. Precision in the release notes is part of what makes a translation workflow dependable.

Scope limits and the responsible end state

DMN 1.5 standardizes a decision-model language and interchange artifacts, but software implementations can differ in supported features, import behavior, UI labels and FEEL details. A successful syntax parse does not prove full schema validity, and a validated schema does not prove two models always calculate the same outcome. This article’s worked example is illustrative; production teams must test their deployed engine and applicable business rules. Do not promise legal or policy correctness merely because an output stayed unchanged after translation.

This specialized task is distinct from translating BPMN process-diagram labels. BPMN describes process flow; DMN focuses on decision logic. A process diagram may tell staff what step follows a decision, while a DMN table evaluates the rule that produces the answer. A translation team should protect the respective execution semantics of each format rather than collapsing both into the broad task of ‘localize a workflow graphic’. Keeping the boundaries clear also avoids duplicating an existing BPMN translation article while still solving an important new reader problem.

The dependable workflow is simple to state: preserve executable rules, translate approved explanations, trace every display label to its technical meaning, and compare real outputs under controlled cases. It is more demanding than translating headings in a spreadsheet because the table can drive actual decisions. When staff and readers get clearer language without changing the model’s answer, translation has improved access while preserving institutional accountability. That is how speed and reliability can reinforce each other instead of competing.

Design a regression set from the rules, not from convenient examples

A decision table with several inputs can have more important combinations than a human reviewer will notice from ordinary screenshots. Build the test set systematically from each condition’s boundaries, every overlap implied by the hit policy and the meaningful missing-value states. For a course decision based on age and membership, test someone just below the age threshold, someone exactly at the threshold, someone just above it, and each membership status that can alter the result. Add cases where two conditions are simultaneously true so rule order or uniqueness assumptions become visible. These tests should exist before the target-language labels are introduced.

Pair every fixture with the expected output and the reason it follows from approved policy. A simple table with ‘age 17 → false’ and ‘age 18 → true’ is useful, but a full rule book should also explain whether age is measured in completed years, whether a missing age is invalid input and whether a special exception overrides the ordinary criterion. Without these definitions, two evaluators can disagree while both apparently follow the displayed table. Translation cannot solve the hidden ambiguity; it can reveal it early enough for the policy owner to make an explicit decision.

For each executed fixture, record the input JSON or FEEL context, the engine version, the original model’s result, the localized model’s result and the visible translated explanation. Keep these three result layers separate. A code value can stay identical while its explanation becomes misleading; an explanation can stay perfect while a variable rename makes the engine fail. If a regression is detected, reproduce it with the smallest failing input and compare the protected expressions first. This is faster and more dependable than changing several labels and rules simultaneously until one demonstration appears to work.

Treat business approval and linguistic approval as separate evidence

A multilingual decision release needs explicit sign-off from people responsible for different risks. The language editor owns semantic equivalence, tone and reader comprehension. The rules engineer owns machine syntax, data interfaces and evaluation behavior. The decision owner owns the legitimacy of the actual policy and how exceptions should operate. Passing one of those reviews does not imply passing the others. A fluent label approved by a translator can still describe a policy the institution has changed; a passing unit test can still produce a confusing or misleading notice to an applicant.

Set a clear threshold for escalation. Any proposed change to a number, rule comparator, input variable, output token, hit policy, rule order or decision reference is a model-change request, not a language-only correction. Record the proposal and reason, then defer it to the proper owner. If the approved source text conflicts with executable logic, label the release blocked until there is an authoritative resolution. This preserves accountability and avoids making the translator the hidden final arbiter of institutional rules.

After approval, archive the localized label sheet with the exact model revision and test fixtures. On the next software release, run a field-level comparison before reusing the translations. A regenerated decision table may have added a column, changed an output contract or revised the meaning of ‘eligible’. A language asset tied only to a filename can drift; one tied to a versioned decision identity and evidence set can be revalidated intentionally. This is how a multilingual rule interface stays trustworthy as the organization evolves.

Frequently asked questions

Can I translate FEEL expressions directly?

Do not translate executable FEEL as ordinary prose. Its syntax, identifiers, operators and typed values require a governed model change and testing if altered. Translate an approved explanation or supported display label instead.

What is the difference between a decision’s name and its ID?

A name may be presented to humans, while an ID is used for machine references. A localized display name need not and generally should not rename the stable technical ID.

Why can changing a single comparator break eligibility?

>= 18 includes age eighteen; > 18 does not. Tiny syntactic differences can change a decision at a real boundary even though the surrounding explanation sounds similar.

Is a boolean result the same as a translated yes-or-no sentence?

No. A boolean value is machine-typed data. The interface may display a localized explanation of it, but downstream logic must still receive the expected data type.

What is a DMN hit policy?

It defines how the table handles matching rules, including cases with overlap or multiple results. Its operational value must remain stable during a pure translation change.

Can I translate an output string such as REVIEW_REQUIRED?

Not without confirming whether it is an exact downstream contract. Usually keep the status code and translate the user-facing message mapped to that code.

Why is passing an XML parser insufficient?

A well-formed XML file can contain changed expressions, identifiers, output values or hit policies. Structural syntax alone does not establish decision equivalence.

Should a translated label be shorter than its original?

It should be accurate first, then adjusted for the supported interface. Test truncation and accessibility; do not edit executable fields just to make a heading fit.

What should happen when an explanation contradicts the executable rule?

Flag it for the decision owner. Do not decide silently whether the policy prose or model should prevail, and do not conceal the disagreement through translation.

How do I test a translated decision model?

Use the same test inputs on baseline and candidate, emphasizing boundaries, overlaps, missing inputs and downstream output contracts. Record actual engine behavior and limits of the tested environment.

Authoritative sources