Decision Tables as a Durable SaaS Moat

The DTRules engine has executed more than 3,000 decision tables in the Texas Integrated Eligibility Redesign System, known as TIERS, since 2003. That system determines eligibility for Medicaid, SNAP, TANF, and related programs across one of the largest state benefit operations in the country.

Deloitte has deployed modified versions of the same decision-table technology in Michigan, Colorado, and New Mexico. A separate decision-table engine by the same developer, Paul Snow, powered the Ohio OFAST system for corporate audits. Decision tables have been encoding institutional policy at scale for more than two decades.

That track record matters now because SaaS markets are compressing around features that can be copied quickly. Dashboards, intake flows, and natural-language interfaces are increasingly table stakes. The harder asset to reproduce is the validated logic that determines how decisions are made, documented, and defended.

Why Decision Logic Matters More Than Features

A decision table is a structured way to represent rules. It lays out inputs, conditions, and outputs so a business decision can be checked against explicit criteria rather than interpreted differently across teams or software modules.

The strategic value of that structure appears when an organization has spent years refining how it handles exceptions, thresholds, documentation standards, and escalation paths. Those rules often reflect regulatory interpretation, internal policy, customer contracts, and lessons learned from prior incidents.

A competitor can reproduce a dashboard with relative speed. Reproducing a mature body of business logic is slower because the logic has to be collected, clarified, tested, and proven reliable in the customer's operating context.

This is why a decision table is best understood as a container for institutional methodology. The durable asset is the accumulated judgment encoded inside it and the operational discipline that keeps it current.

DTRules and the Scale of Real Rule Systems

The strongest argument for decision tables is operational. Eligibility systems like TIERS combine scale, complexity, and review pressure in ways that test whether rule logic can survive sustained use.

TIERS must encode formal eligibility rules, exceptions, and documentation requirements while producing outcomes that can be defended in audits, appeals, and administrative review. According to DTRules project documentation, the engine uses unbalanced decision tables that reduce rule complexity by roughly 30 percent on average, lowering the need for developers to assist business analysts in building and maintaining tables.

The Ohio OFAST project shows a different application of the same architecture. That system supported five types of corporate audits, each specified entirely in XML using decision tables and ran as a standalone application. It was a separate codebase from DTRules, but the shared design principle is the same: policy expressed as inspectable, executable tables rather than conventional application code.

A system of this kind derives its value from a maintained body of operational logic: definitions, thresholds, exceptions, escalation paths, and testing practices that preserve consistency over time.

Why AI Risk Increases the Value of Deterministic Rules

Generative AI has made software outputs more flexible, but it has also made verification more important. In its 2024 Generative AI Profile, NIST identifies confabulation as a core risk in generative systems. The profile defines it as the production of confidently stated but erroneous or false content.

The same profile recommends reviewing and verifying sources and citations in system outputs and calls for tracking and documenting data provenance. If a model invents a citation, misstates a source, or produces an answer that cannot be traced to validated inputs, the institution inherits a verification burden that may cancel much of the speed advantage the model appeared to offer.

Decision tables address this problem directly. Each rule can be examined, each change can be logged, and each expected outcome can be checked against known scenarios. An auditor can trace a disputed result to a specific row in a specific table, rather than accepting that a model usually produces acceptable answers.

The value of decision tables therefore rises as explainability requirements rise. If an organization must show why an application was approved, why a claim was flagged, or why a transaction was escalated, repeatable rule logic has practical advantages over outputs that depend on probabilistic generation.

How Institutional Knowledge Gets Encoded

In mature deployments, institutional knowledge is rarely captured in a single table. It tends to become a library of interlocking rules: eligibility definitions, thresholds, required evidence, exception classes, manual review triggers, allowable data sources, and fallback paths when information is missing or disputed.

That body of logic is usually the result of repeated adjustment. Teams respond to policy changes, internal audit findings, customer disputes, and new edge cases. Over time, the system stops being a generic rules engine and starts reflecting a specific institution's operating doctrine.

The older Drools documentation shows how decision tables can be authored in spreadsheets for business-level rules, with each row generating a rule. DTRules uses a similar model: tables are maintained in Excel and extracted to XML for execution. This matters because it allows policy experts and business analysts to read, modify, and validate the rules directly.

That collaboration is often the mechanism by which tacit judgment becomes a maintained system artifact. Once experts can review rules directly, an organization can preserve methods that would otherwise remain dispersed across emails, training habits, and undocumented approvals.

Hybrid Systems and the Role of Standards

Decision Model and Notation, or DMN, is a standard published by OMG for specifying business decisions and rules in a form readable by business users, analysts, and developers. It provides a shared format that reduces handoffs dependent on informal interpretation.

DMN is one option among several for standardizing rule logic, and portability is one of its benefits. But portability alone does not remove dependency on the vendor that built, tested, and maintained the logic library. In most enterprise settings, the expensive part is proving that rules behave correctly, and that work stays with the vendor that did it.

Large language models are better suited to bounded roles inside a governed system than to final authority over consequential decisions. A hybrid design can let a model summarize documents, extract candidate facts, or draft explanations, while a deterministic rule layer checks whether required conditions are met and whether the case must be escalated for human review.

That approach fits the controls described by NIST, including verification, validation, source review, and provenance tracking. Where consequences are serious, automation must remain bounded by reviewable controls and accountable human authority.

Where the Moat Appears in SaaS

The moat effect is strongest in SaaS categories where customers buy reliability under scrutiny. That includes underwriting support, claims operations, eligibility management, transaction controls, vendor risk review, and compliance workflows where each decision may need to be explained later.

In those markets, customers buy the reduction of governance burden alongside software features. If a vendor maintains a well-tested decision layer with clear rule history, the customer may avoid rebuilding that discipline internally.

This creates a form of dependency different from conventional product lock-in. The customer may retain access to exported models or data, yet still face substantial work to replace the supplier. The logic would need to be revalidated, exception handling would need to be reconstructed, and audit evidence would need to be matched to a new operating process.

The switching cost is partly technical and partly procedural. Replacing the vendor can mean repeating approvals, test runs, signoffs, and documentation checks that were previously embedded in the service. That kind of governance rework is slow, expensive, and often difficult to schedule.

Why Governance Determines Whether the Advantage Lasts

A decision table only becomes a durable asset if it is governed like product code. That means version control, peer review, change approval, regression testing, and clear ownership over definitions and exceptions.

Without that discipline, tables can become another opaque layer. A spreadsheet full of legacy conditions is not inherently more explainable than application code if no one can say which rule changed, why it changed, or which test cases confirm that the change did not break adjacent logic.

The strongest implementations make policy semantics visible to customers and internal reviewers. Change logs, release notes for logic updates, and traceable links between requirements and test cases reduce disputes because they establish a common record of what the system was designed to do at a given point in time.

That is also where the strategic asset becomes cumulative. A vendor that has maintained rule quality over many years acquires deeper confidence in those rules, and that confidence has operational value because it lowers the need for repeated manual checking.

Limits of the Thesis

Decision tables are not a universal moat for SaaS. Many products compete on distribution, workflow convenience, network effects, integration breadth, or proprietary data rather than formalized business decisions.

They are also less useful where the task depends on open-ended judgment that cannot be reduced to stable criteria. Creative drafting, exploratory research, and loosely structured collaboration may benefit more from flexible models than from deterministic decision grids.

Even in regulated settings, a table is only as good as the institution that maintains it. If policy ownership is weak, if exceptions accumulate without review, or if tests cover only obvious cases, the logic base can become brittle instead of defensible. The claim is therefore narrower than it first appears. Decision tables are a durable moat in categories where customers must be able to reproduce, contest, and document important decisions.

What Endures When Features Flatten

As more software products adopt generative AI features, visible differentiation may become harder to sustain. In sectors where scrutiny is routine, the harder question is whether the system can show its work. A vendor with a mature library of governed decision logic may hold a stronger position than a vendor with a more polished interface but weaker operational semantics.

If SaaS competition continues to compress around product features, the defensible layer in some categories may sit lower in the stack. It may consist of the encoded methods, test coverage, and auditability that let organizations trust how it reaches an outcome. TIERS has been running on that premise for more than twenty years.

Sources

• DTRules. "DTRules: Decision Table Rules Engine." DTRules, 2023.
• Paul Snow. "History and Pointers." DTRules, 2012.
• DTRules. "DTRules Company Page." LinkedIn, 2024.
• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." U.S. Department of Commerce, 2024.
• Object Management Group. "Decision Model and Notation (DMN)." Object Management Group, 2025.
• JBoss Community. "Drools Expert Documentation: Chapter 6. Authoring." JBoss Community, 2011.
• Beige Media. "Decision Tables for Explainable Institutional AI." Beige Media, 2026.