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.
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
- 01
Authentication, totals and invariants belong to code even when a model prepares their inputs.
- 02
Regex is useful for stable syntax, not for deciding the meaning of ambiguous language.
- 03
A valid JSON object can still contain a wrong amount, record or decision.
01 / SITUATION
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.
02 / MECHANISM
A practical decision matrix
Classify the decision before choosing a model, library or prompt.
- 01Enforce exact policy with code
Keep identity, permissions, thresholds, totals, state transitions, uniqueness and invariants in deterministic application logic.
- 02Parse 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.
- 03Retrieve named facts
Read changing values from the system of record and stable rules from authorised sources. Preserve provenance and freshness.
- 04Use a model for judgment
Apply model judgment to ambiguous intent, semantic classification, summarisation, drafting and evidence comparison where several phrasings may be valid.
- 05Constrain the interface
Request typed output and validate it. Treat structure as an interface contract, then verify identifiers, values and permissions against the host system.
- 06Escalate 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.
03 / In real work
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.
Implementation checklist
- Every decision is classified as exact, syntactic, retrieved or judgment-based.
- Authentication, authorisation and invariants remain outside the model.
- Amounts and totals are recomputed from source values.
- Regex and parsers have explicit accepted and rejected cases.
- Structured outputs are validated and then checked against live data.
- Model judgments retain evidence and a visible uncertainty path.
- Evaluations include plausible but schema-valid wrong values.
What this approach does not claim
- 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 and reference types
- 01Artificial Intelligence Risk Management Framework 1.0NIST · 2023Standard
- 02AgentDojo: A Dynamic Environment to Evaluate Prompt Injection AttacksDebenedetti et al. · 2025Research
- 03Outlines: Structured OutputsOutlines maintainers · 2026Official documentation
- 04JSONSchemaBench: A Rigorous Benchmark of Structured Outputs for Language ModelsGeng et al. · 2025Research
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.