Automated Decision Trees for Offline-First Applications

An offline decision tree needs more than a diagram stored on a phone. Our recommendation is to package the rules with their required inputs, define what happens when information is missing, and record which rule version produced each result. Treat a decision that needs unavailable information as pending, rather than guessing an answer so the workflow can continue.

Here, an automated decision tree means a sequence of explicit business rules. We are discussing rules that people approve and software executes, rather than a model trained to predict an outcome. Start with a bounded task, such as deciding which inspection questions to ask, before considering permission to complete an operation.

Make the business rule precise first

Take a hypothetical discount policy: an established customer ordering more than 500 units receives a 5 per cent discount. A new customer needs review. Before building the interface, we would ask who counts as established, whether cancelled units count, and what happens at exactly 500 units. These are policy decisions for the business owner, not details for a developer to infer.

The OMG Decision Model and Notation specification describes decision tables as rules mapping input values to output values. A table is a useful alternative to drawing every branch when several conditions determine the same outcome. We would review the policy in that form before choosing how users move through it.

Decide how competing matches work. DMN distinguishes a unique-match policy from a first-match policy, where rule order determines the result. Under DMN's unique hit policy, rules must not overlap. For an approval workflow, we recommend making conflicts explicit rather than letting whichever condition appears first decide an important exception.

Separate questions from permission

A guided form and an approval decision need separate acceptance criteria. In a proposed inspection workflow, an answer might reveal another question without granting permission to mark the inspection complete. We recommend naming those outputs separately, so the screen cannot confuse progress through a form with an approved result.

The W3C XForms 1.1 recommendation separates relevance, required values and constraints. Relevance controls whether an associated form control is available. A required value must be non-empty to pass validation, while a constraint contributes to whether the value is valid. Those are different checks.

Use that separation when designing a local workflow, whether or not the implementation uses XForms. For example, ask for a measurement only when the selected equipment requires it. Then validate its format and range before considering the operational rule. We would give an absent reading its own outcome, such as “measurement required”, instead of treating it as zero or as a passed check.

Package the inputs with the rules

For each proposed offline decision, list every dependency. An equipment identifier might be available in a downloaded work order. A current recall status might require a server check. We recommend recording that distinction before promising that the whole operation will work without a connection.

Our suggested local package contains the approved rules, a version identifier, the reference data they need and an expiry policy. The expiry policy should say which decisions remain available after reference data becomes too old. For a sensitive action, we would prefer an explicit “connect to verify” result over an unqualified approval from an expired package.

Keep the local data contract small and explicit. Specify units for measurements, allowed codes for equipment types and the meaning of an empty value. If two source systems disagree about a status, assign an owner to resolve it before using that status in an automated approval. Reorganising database tables is a separate task from deciding which business rule should apply.

We recommend saving the inputs actually used, the output and the rule version with the work record. Keep access and retention proportionate to the sensitivity of that data. If somebody later challenges a result, review the saved decision separately from any result produced by a newer policy.

Reconnecting is another decision point

Do not treat reconnection as permission to overwrite the server's current record. For an HTTP API, RFC 9110 describes If-Match preconditions that compare a supplied entity tag with the current representation. The specification identifies preventing accidental overwrites by parallel users as a use for this mechanism.

We would use a failed precondition to start a reconciliation step. Show what changed and decide whether the offline result can still be accepted. Retain the original result if the server reruns the decision under a newer policy. Name the rerun as a separate evaluation rather than silently replacing the record of what the user saw.

Retries need an explicit design too. RFC 9110 cautions against automatically retrying requests that can have a different effect when repeated, unless the client knows retrying is safe or can detect that the original request was not applied. We recommend a stable operation identifier and a server-side duplicate check for queued submissions. Do not assume that pressing “send again” is harmless.

Test the decisions before field use

We would ask the policy owner to approve examples alongside the rule definition. Include boundary values, missing inputs, overlapping conditions and inputs outside the supported range. For the hypothetical discount, test exactly 500 units as well as quantities above and below it. Give each case an expected result before implementing the evaluator.

Then exercise the local package with the network unavailable. Restart the app during a decision, expire its reference data, and reconnect after another device has changed the same record. Test an interrupted upload whose server response never reaches the phone. Agree in advance which states should block completion and which should allow work to be saved for review.

For a first release, we recommend automating one bounded decision and keeping a named escalation route. Require the same approved examples to pass whenever the rules change. Expand the scope only after the business owner has reviewed the exceptions encountered in use.

Update, October 2026

For a related engineering discussion, our article on deterministic routing and explicit risk overrides describes routing work through a table with a separate risk check. It concerns agent delivery rather than offline field apps. Read it for the distinction between a routine rule and an override, not as a ready-made field safety policy.

Sources

• OMG, "Decision Model and Notation, version 1.3", 27 February 2021, catalogue publication date. The PDF states March 2021 as its release month.
• W3C, "XForms 1.1", 20 October 2009.
• IETF, "RFC 9110: HTTP Semantics", June 2022. The RFC gives no publication day.
• Dendro Logic, "The Cheapest Model That Can Safely Do the Job", 30 July 2026. Referenced only in the dated update.