Designing the Boundary Between Deterministic and Semantic Systems

Most technology leaders have made their peace with a reasonable-sounding principle: keep the systems that already work, and add AI where it helps. It is a correct instinct and a real advance over the reflex to treat every capable model as a reason to replace the existing stack. The trouble is that it is a starting point dressed up as a conclusion. Deciding that deterministic systems and semantic reasoning should coexist settles almost nothing about the decision that actually matters, which is where the boundary between them should sit and how the two are supposed to work across it. That boundary gets drawn in every AI project whether or not anyone decides it deliberately. In most organizations it is drawn by default.

The default has a direction. Once a team has a capable model in hand, the gravitational pull is to move to the model anything the model can plausibly attempt. A step that used to run on fixed rules gets handed to a system that produces a fluent answer, and because the answer looks right in the demonstration, the boundary quietly moves. “Add AI where it helps” offers no resistance to this, because almost anything can be made to look like it helps in a single trial. The principle tells you that AI belongs somewhere in the workflow. It does not tell you which work should cross the line and which should stay where it is, and that is the entire design question.

The criterion is the nature of the work

The useful criterion is the nature of the work, not the age of the technology that currently does it. Some work has a single correct outcome that follows from known rules, has to produce the same result every time, and needs to be controllable and auditable after the fact. Calculating a price from a rate table, applying an entitlement rule, reconciling two ledgers, enforcing a validation constraint: these are deterministic problems, and the reason to keep them deterministic has nothing to do with the age of the code. The organization needs the answer to be exact, repeatable, and explainable, and a system built from explicit rules delivers all three by construction. Other work is nothing like this. The input arrives ambiguous or unstructured, the rules cannot be fully enumerated in advance, and the actual task is judgment over messy context: reading intent from a support message, drafting from scattered notes, deciding which of several conflicting documents to believe. That is where semantic reasoning earns its place, because writing enough deterministic rules to cover the variation is either impossible or produces a system so brittle no one can maintain it.

Two ways to draw it wrong

Because the boundary is a design decision, it can be made badly, and it fails in two opposite directions. The first is putting deterministic work behind a model. Suppose a team decides that a reconciliation or an approval check, previously a set of explicit rules, should now be handled by a model because the model can read the messy inputs and work it out. What the organization has bought is a probabilistic answer to a problem that had a correct one. The result is usually right, which is worse than reliably wrong, because it means the failures are occasional and unpredictable and have to be caught by checking the output every time. The consistency is gone, the audit trail is gone, since the model cannot tell you which rule produced the answer when there was no rule, and the cost per decision is higher than the deterministic version it replaced. Work that has a correct answer should keep producing it the same way every time.

The opposite error is quieter and older. It is forcing genuinely judgment-heavy work through rigid rules, which is what many organizations did for years before capable models existed. A support-routing system encoded as a hundred if-then branches, a policy engine that cannot handle a case its authors did not anticipate, an intake form that rejects anything phrased in an unexpected way: these are all attempts to make deterministic systems do work that requires interpretation. They produce the brittle, exception-choked behavior that trains people to route around the system, which is the exact fragility the argument for keeping deterministic systems is supposed to prevent. Each kind of work belongs on the side of the boundary suited to it. Forcing judgment onto rigid rules is a boundary error in the same way that forcing rules onto a model is, and treating deterministic systems as categorically safer simply replaces one misplacement with the other.

The real work is at the seam

If the placement of the boundary is the first design decision, the second and harder one is what happens at the seam, the point where a semantic component hands its output to a deterministic one that depends on exact inputs. This is where most of the real engineering lives, and it is the part most teams neglect because the demonstration rarely exercises it. A model that reads a document and produces a structured record is only useful to the deterministic step downstream if that record is well-formed every time, and a probabilistic system does not produce well-formed output every time on its own. Designing the seam means deciding what the deterministic side will accept, validating the model’s output against that contract, constraining the model’s output so it can conform, providing a fallback path for the cases where it does not, and putting a human review step at the handoffs where a wrong input would be expensive to discover later. Wiring a model’s output straight into a system that assumes exact inputs, as though the model were as reliable as a deterministic function, is the most common way these pairings fail once they leave the demonstration and meet real inputs at volume.

A concrete example makes the seam visible. I built a pipeline that turns a flat directory of source documents into a structured, chapter-organized knowledge base. It runs as a sequence of stages: one identifies the distinct topics across all the documents, one synthesizes the material for each topic into a single account, one organizes those topics into a chapter structure, and one writes the final narrative for each section. What is instructive about it is how cleanly it divides into deterministic and semantic work. The orchestration is deterministic: discovering the input files, resolving their paths, running the stages in a fixed order, and, most importantly, handing off between stages as files written to disk that the next stage reads. The judgment is semantic: deciding what counts as a distinct topic, reconciling two source documents that disagree, noticing that a topic has only thin coverage, and combining several topics into prose that reads as one argument. Neither side could do the other’s job. A model asked to also own the orchestration would give up the repeatability and the ability to rerun a single stage, and a rule-based system asked to decide what counts as a topic would be the brittle intake engine described earlier.

What matters for the boundary argument is where the two meet. Each semantic stage produces an intermediate artifact, a list of topics or a proposed chapter structure, that a later deterministic stage consumes. Those artifacts are the seam, and they are the reason the pipeline is trustworthy rather than merely impressive. Two of them are deliberately exposed for human review before the next stage runs: the topic list can be edited to merge duplicates or drop noise, and the chapter structure can be rearranged, before any of the expensive synthesis work depends on it. That review step is where the boundary is governed, at the handoff where a semantic judgment is about to become a fixed input to everything downstream. Exposing the intermediate artifact for correction is the practical form of governing a probabilistic-to-deterministic handoff, and it is far cheaper to fix a wrong topic at the list stage than to discover it woven through fifty finished pages.

This example also answers the objection that better models will eventually make the boundary unnecessary by absorbing the deterministic work as they improve. Even with a markedly better model doing the synthesis, I would keep the deterministic orchestration and the file-on-disk handoffs, because they are what make the pipeline repeatable, inspectable, and cheap to correct. A more capable model produces better topic summaries. It does not give me the ability to rerun one stage without redoing the others, to see and edit exactly what the previous stage decided, or to guarantee that the same inputs produce the same structure. Those properties come from the deterministic design around the model rather than from the model, and no amount of model improvement supplies them. This is why the boundary survives better models rather than dissolving into them. Its purpose is to let you trust and control a system’s behavior regardless of how good the model is, and that purpose does not go away when the model gets better.

What this asks of leaders

None of this stays solved by itself, which is why the boundary is an operating-model question and not only a technical one. Someone has to own where the line sits for a given workflow, with the authority to decide that a particular step stays deterministic even when a model could plausibly take it over. The placement should be traceable, so that a year later it is clear why a step was left on rules or moved to a model and what would justify revisiting it. And the seam should be instrumented, so that when a model’s output starts failing validation more often, or a fallback path starts carrying more traffic than it was built for, the organization sees the drift while it is still cheap to correct rather than after it has produced a run of quiet errors. This is the same case for governance that applies across AI adoption generally, that its job is to supply confidence and control up front rather than to review outputs at the end, narrowed here to the specific and very concrete point of the deterministic-to-semantic handoff.

The organizations that get durable value from AI will be the ones that treat this boundary as something they design and govern on purpose. Drawn well, it lets a model do the ambiguous, judgment-heavy work it is genuinely good at while the deterministic systems keep producing the exact, repeatable, controllable results the rest of the business depends on, with the seam between them engineered rather than assumed. Drawn by accident, it produces systems that are impressive in a demonstration and untrustworthy in production, either because judgment was forced onto rules or because work that needed a correct answer was handed to something that only produces a likely one. The capable model is now the common part. The advantage is in knowing exactly where to rely on it, where not to, and how to build the handoff in between.