When deterministic rules are better than a model

A task can be technically possible for a model and still be better served by explicit rules.

The deciding question is whether variability helps. A normalization rule should be replayable. A retrieval result or draft may need interpretation and allow several defensible forms. Mixing those needs without naming them makes a system harder to test and harder to explain.

JodyInk uses four questions to choose the mechanism.

Start with the shape of the decision

Before choosing a model, an automation, or a set of rules, ask four questions:

Can the expected result be specified completely? If a field must always be normalized to one known format, the requirement already resembles a rule.
Does ambiguity contain useful signal? A model becomes more valuable when the input needs interpretation and several answers could be defensible.
Must the result be reproducible? Reconciliation, access control, status transitions, and many reporting calculations need stable outputs that can be replayed.
How will a failure be found and reviewed? A probabilistic result needs a review path designed with the feature, not added after it.

The answers often point to a mixed system. Rules establish the boundaries. A model operates where variability is useful. The product makes the handoff visible.

Try the check on two role labels

For illustration, imagine this scene. A reviewer needs to standardize two role labels. An approved mapping covers one label; the other needs a decision. These are sample records, not client data.

Two inputs, two different next steps
Input	Approved mapping	Proposed role and next step
Sr Analyst	Sr Analyst → Senior Analyst	Senior Analyst. Record the mapping used and keep the original label visible.
Lead	No mapping	Unassigned. Flag the missing mapping for review rather than guessing what “Lead” means.

The first result is reproducible because the mapping specifies it. That does not prove the organization uses that title for this person. In the second row, a model might suggest “team lead,” but a suggestion is not an approved mapping. Someone still has to establish which meaning applies.

Use rules when the requirement already contains the answer

In an anonymous client engagement, inconsistent operational records needed to become review-ready without erasing what had arrived from the source. The utility keeps the source sheet in the workbook, places the original role beside the proposed role, and sends complex names and unmapped roles to review. It does not keep a separate original-name column beside every transformed name.

That approach made the behavior inspectable. A reviewer could see what changed, repeat the transformation, and distinguish a known correction from an unresolved ambiguity. The system did not need synthetic confidence. It needed a trustworthy record.

A studio case involving legacy reporting logic presented a similar requirement. The implemented foundation extracts calculations and dependencies into inventories and specification skeletons. The core is deterministic because the purpose is inspection: identical source logic should produce an identical record. A language-model step was considered and removed when it did not improve that result.

A local studio tool in development reads project backlogs without counting an issue’s acceptance checklist as additional tasks. Task identifiers include the project key, so two projects can use the same source identifier without sharing one record. Each parsed task retains its source line and recognition rule. These controls make the parsing inspectable; they do not verify completion or resolve shared ownership.

Use a model when interpretation is the work

SceneArc has a different problem. It helps people retrieve observations and compose from selected evidence. Language can express the same idea in many forms, and useful composition is not a simple mapping from one field to another. Semantic retrieval and model-assisted writing are appropriate there because variability is part of the task.

Selected observations remain attached to generated work. Server-side checks can confirm that cited references belong to the provided evidence set. That is a useful boundary, but it is not a truth detector. Membership can be checked deterministically; factual accuracy still requires judgment against the underlying material.

The model handles the ambiguous work. Explicit controls protect the parts that must remain inspectable.

Evaluation can end with rejection

An AI evaluation can succeed by ending in rejection.

In one task-specific research and content comparison, a model candidate was rejected after it fabricated source references and failed the required output structure. The test was small and specific, so it does not support a broad judgment about the model. It did answer the product question at hand: that candidate was not reliable enough for that role in the workflow.

The full record, including the acceptance dimensions and what the rejection preserved for the next candidate, is in rejecting a model is a useful result.

Evaluation criteria should be written before a convincing demo hardens into architecture. A useful evaluation names the task, the source material, the required structure, and the failure conditions. Rejection is a valid product decision when a candidate does not meet them.

Design the boundary, not just the feature

A mixed system is strongest when each mechanism has a clear job. Source controls define what material may enter. Deterministic operations handle validation, permissions, transformations, and state. Models support interpretation, retrieval, or generation where variability adds value. Review controls expose the source, limitation, and decision to the person responsible for the result.

This is not a prescription against AI. It is a way to use AI without asking it to perform certainty. Choose the least variable mechanism that can do the job well, then make the handoff visible.