# Use code for rules. Use models for judgment.

A decision matrix for choosing code, regex, schemas, retrieval or model judgment without confusing valid structure with a true result.

Version 1.0 · 2026-07-29 · 9 min

## Short answer

Use deterministic code for facts the system can calculate or enforce exactly: authentication, authorisation, totals, thresholds, state transitions, required fields and business invariants. Use parsers or regex for stable syntax with a known grammar. Use retrieval for facts held in named sources. Use a model when the job requires interpreting ambiguous language, classifying intent, drafting or comparing evidence. Constrained or structured output can guarantee a usable shape within its supported schema. It does not prove that the values are true, authorised or consistent with the business.

## Key points

- Authentication, totals and invariants belong to code even when a model prepares their inputs.
- Regex is useful for stable syntax, not for deciding the meaning of ambiguous language.
- A valid JSON object can still contain a wrong amount, record or decision.

## The expensive mistake is using judgment where the answer was already exact

A model can read an invoice, describe an anomaly and propose a category. It should not become the calculator of record for the total or the authority that decides whether the current user may post it. Those answers already belong to code, data and policy.

The reverse mistake also exists. A growing wall of regex and conditionals is a poor substitute for interpreting a supplier email, a maintenance note or a support request whose language varies. The design task is to put each decision in the layer best suited to it.

## A practical decision matrix

Classify the decision before choosing a model, library or prompt.

### 1. Enforce exact policy with code

Keep identity, permissions, thresholds, totals, state transitions, uniqueness and invariants in deterministic application logic.

### 2. Parse stable syntax

Use a parser, regex or schema validator for identifiers and formats with a known grammar. Reject or normalise explicitly rather than asking a model to guess.

### 3. Retrieve named facts

Read changing values from the system of record and stable rules from authorised sources. Preserve provenance and freshness.

### 4. Use a model for judgment

Apply model judgment to ambiguous intent, semantic classification, summarisation, drafting and evidence comparison where several phrasings may be valid.

### 5. Constrain the interface

Request typed output and validate it. Treat structure as an interface contract, then verify identifiers, values and permissions against the host system.

### 6. Escalate unresolved cases

When evidence conflicts or confidence cannot be established safely, expose the uncertainty and route the case to a person instead of manufacturing a binary answer.

## Examples

### Accounting entry

The model classifies a supplier message and extracts candidate fields. Code calculates totals, checks the period and validates the account before any posting proposal.

### Construction access

The model summarises a site request. The application checks identity, habilitation and required approvals from authoritative data.

### SaaS support

A model maps free-form language to a ticket category. A schema validates the payload and the product resolves the actual customer, plan and permissions.

## Common failure modes

- Asking a model whether a user is authorised to read or change a record.
- Using generated arithmetic for financial totals or hard thresholds.
- Growing regex rules to simulate semantic understanding of open-ended language.
- Treating schema-valid structured output as factually correct.
- Calling a second model a deterministic validator of the first model.

## Checklist

1. Every decision is classified as exact, syntactic, retrieved or judgment-based.
2. Authentication, authorisation and invariants remain outside the model.
3. Amounts and totals are recomputed from source values.
4. Regex and parsers have explicit accepted and rejected cases.
5. Structured outputs are validated and then checked against live data.
6. Model judgments retain evidence and a visible uncertainty path.
7. Evaluations include plausible but schema-valid wrong values.

## Limitations

- Deterministic code can still encode an incorrect or outdated business rule.
- Constrained decoding support and schema coverage vary across models and libraries.
- Some business categories remain subjective and require agreed human review criteria.

## Sources

1. [Artificial Intelligence Risk Management Framework 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) — NIST, 2023; type: standard.
2. [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks](https://openreview.net/forum?id=m1YYAQjO3w) — Debenedetti et al., 2025; type: research.
3. [Outlines: Structured Outputs](https://github.com/dottxt-ai/outlines) — Outlines maintainers, 2026; type: official-documentation.
4. [JSONSchemaBench: A Rigorous Benchmark of Structured Outputs for Language Models](https://arxiv.org/abs/2501.10868) — Geng et al., 2025; type: research.

## Practical questions

### Does structured output remove hallucinations?

No. It can constrain syntax and allowed shapes. A well-formed field may still contain an invented or stale value.

### When is regex the right choice?

When the input follows a stable grammar such as a known identifier or delimiter format. It is a poor judge of intent expressed in varied natural language.

### Can a model propose a total or a permission result?

It may explain or display a result calculated by the host. The authoritative calculation and access decision should remain deterministic.

---

Canonical: https://scoperail.fokalabs.io/en/guides/deterministic-code-or-llm-judgment
Author: Ramzi Laieb, FokaLabs