When Texas officials began rewriting their eligibility software at the turn of the century, they sought to ensure that Medicaid and SNAP decisions followed state policy in a way that could be audited. Conventional Java code scattered that logic across large blocks of conditional statements, making it difficult for reviewers to see how rules were applied.

Software engineer Paul Snow responded with a decision-table engine that executes the same spreadsheets policy staff maintain. Each row lists conditions, each column maps an action, and the engine walks the grid in a fixed order, recording every step. Two decades later that combination of readability and traceability can serve as an example in discussions about how to govern automated decision systems. The core idea remains simple: when the table is the code, reviewers can see how an outcome was derived.

Texas still cites the Integrated Eligibility Redesign System, or TIERS, in fiscal notes such as the Legislative Budget Board’s 2025 review of HB 321, which describes modifications to TIERS needed to implement new Medicaid and CHIP enrollment rules.

Why Snow’s Rules Still Matter

  • Texas used Snow’s engine to run more than 3,000 decision tables for Medicaid, SNAP and related programs, according to Snow’s 2016 testimony to the U.S. House.
  • Tables stay identical from authoring to execution, reducing gaps between policy text and live code.
  • Deterministic hit-policy makes every outcome reproducible and straightforward to trace during reviews.
  • Snow open-sourced the core in 2004 as DTRules, widening adoption beyond state projects.
  • Immutable timestamps and AI-assisted drafting could extend the same audit principles into future systems.

Decision tables spell out policy at a glance


A decision table is a grid where conditions appear along one axis and permitted actions on the other. Because the logic is visible in one view, analysts can review it for gaps or conflicts before code runs. Oracle’s Rules Designer documentation notes that tables can be checked for completeness, reducing surprises at runtime.

The same grid can also serve as a post-run trace. Instead of reverse-engineering compiled code, auditors can read the rule, the inputs, and the outcome in a single format. Ronald Ross, editor of Business Rules Community, writes that a well-formed decision table forces designers to consider combinations of conditions explicitly, reducing hidden assumptions in policy. For complex benefit programs, that clarity helps when eligibility decisions are subject to audit, reimbursement checks, or appeal.

More Technology Articles

Inside Inveniam’s Full-Stack Bet on Tokenized Private Assets
Move Fast or Move Safely? Matching Delivery Pace to Risk
Swipe-Fee Crackdowns Push Merchants Toward Stablecoin Settlement
Blockchain and Smart Contracts Transform Construction Risk Management

Texas needed an eligibility overhaul


Around 2000, Texas managed more than 50 assistance programs through multiple legacy systems. Snow has described how policy teams tracked rules in large spreadsheets while developers translated those rules into hand-written code. The translation step slowed implementation and introduced opportunities for mismatch between what policy staff wrote and what production code executed.

Snow proposed compiling the spreadsheets directly. His team generated an executable model from each table, feeding inputs such as income and household size and returning eligibility results without a separate manual rewrite layer. Snow’s technical notes describe pilots that processed thousands of tables within service-level targets for interviews. For state workers this meant that updating a rule could be done by editing a cell in the table rather than requesting a new code change.

Building an engine that ran the policy verbatim


Snow’s engine loaded each table into memory and enforced a deterministic hit-policy—first matching rule wins by position—rather than an inference search. This ensured that identical inputs produced identical outputs. During execution the engine logged which rules fired, which values were evaluated, and which actions were taken, and the trace could be stored with the case file so that staff could review how a decision was made.

Because the format stayed consistent, policy analysts, developers, and auditors could review the same artifact. Snow also kept the runtime relatively small by avoiding additional user-interface components in the core engine, which suited the data-center constraints of the period. Performance tests discussed in Snow’s materials show rule evaluation completing within seconds.

From state contract to open-source DTRules


After the Texas rollout and a related audit project in Ohio, Snow re-implemented the core in Java and released it as DTRules under the Apache 2.0 license. His 2019 IEEE speaker bio dates the first public release to 2004 .

The repository at repo.or.cz shows commits back to September 2008, documenting refinements such as a domain-specific language for actions and unit-test fixtures. Publishing the code made it available for academic and commercial experimentation, and Maven Central lists DTRules artifacts that developers can embed without separate vendor tooling. Unlike enterprise rule-management suites that bundle editors and dashboards, DTRules focuses on executing decision tables and emitting logs for each action.

What auditors gained from determinism


Auditors generally look for two properties: reproducibility and traceability. A deterministic table guarantees reproducibility, while rule-level logging supplies traceability. OpenRules, a commercial platform that appeared later, now highlights execution traces and step-by-step reports in its documentation, reflecting similar priorities around logging and explainability.

Because outcomes correspond to explicit rules, agencies can test tables before deployment and can review the exact rule path during appeals or federal reviews, helping them show how each input contributed to a final decision. The same structure supports maintenance: when legislation changes a threshold, teams modify the relevant entries, run regression tests, and publish a new version with recorded changes.

Lessons for today’s policy-as-code projects


First, keep authoring and execution formats as close as possible. Manual rewrites between policy language and system behavior increase the chance of divergence.

Second, favor deterministic outcomes when regulators may revisit a case long after the initial decision. Predictability simplifies review.

Third, governance remains central. Version every table, run automated tests on each change, and involve domain experts in reviews so that the engine stays aligned with intent.

Decision-model notation, feature flags, or machine-learning components can all appear in modern systems, but one control principle remains: explanations should be generated as reliably as outputs.

Looking ahead: immutable logs and AI drafting


Snow later co-founded the Factom (now Accumulate) blockchain project, which anchored records in an append-only ledger. The same approach can be applied to rule-execution logs, anchoring them to an immutable hash so that later edits are detectable.

Large language models can already assist in drafting policy language or candidate rules, but those drafts still require a deterministic execution layer. Decision tables are one option that is both human-readable and machine-runnable. Future architectures could link policy text, compiled tables, and cryptographic proofs into a single chain of custody, extending the audit trail from input to archival storage.

In a regulatory climate that questions opaque algorithms, these forms of verifiable transparency may become a baseline requirement rather than an optional safeguard. Snow’s original objective was to run policy as written in a way that supported review, and the resulting design anticipated many of the questions now raised about explainability in automated decision-making.

Sources