The argument about rules versus language models is usually framed as a choice. For operational software, it is the wrong question.
A single workflow contains facts that should be calculated, policies that should be deterministic, and inputs that need interpretation. Using a model for all three makes the workflow difficult to test. Using rules for all three leaves valuable information trapped in documents and free text.
Proxima treats rules and models as different tools inside one decision path.
Structured facts ──> Calculations ──> Business rules ─────────┐ ├──> Decision Emails and documents ──> Model interpretation ──> Typed fact ─┘ │ └──> Action proposal
The boundary in the middle is intentional. A model may interpret an irregular input, but the workflow still decides how that interpretation should affect the operation.
Start with what should be deterministic
If a decision depends on a known threshold, ordinary code is the clearest implementation.
Suppose a priority shipment is more than two hours late and its value exceeds a defined threshold. The rule can name those conditions, assign a severity, and propose an escalation. The same input produces the same output. An operator can read the condition. A test can cover the boundary at 119, 120, and 121 minutes.
Proxima’s first decision engine is deliberately rule-led for this reason. Workflow-pack rules use normalized and derived fields, support nested conditions, and carry explicit priority. The engine records every evaluated rule and the winning rule rather than returning only the final label.
This is not a temporary substitute for a model. Deterministic policy should remain deterministic.
Use a model where interpretation adds value
Now consider an email from a carrier:
Vehicle repaired. Dispatch expected after the local restriction lifts. Delivery tonight is unlikely.
The message does not contain a clean status code. A model can extract a likely delay category, expected resolution, and confidence. It can turn an irregular piece of language into a bounded result that the workflow can use.
The important word is bounded. The model should receive the context required for that task and return a small, predictable result: the likely disruption category, whether same-day delivery remains plausible, how confident the interpretation is, and which parts of the message support it. It should not be asked to invent an action, choose an API, and decide whether company policy permits the call in one opaque response.
The workflow can combine the interpretation with customer priority, shipment value, and the promised time through explicit decision logic.
The trade-off is additional engineering around the model call. There is more work in defining the interpretation task and validating its result. In return, a model error is contained and diagnosable instead of controlling the rest of the workflow.
Give every decision the same contract
Downstream systems should not need a separate integration for rule decisions and model decisions.
Proxima represents both through a common decision result: classification, proposed action, confidence, reason, evidence, decision source, and trace identifiers. The source may be a rule, a bounded model step, or a fallback that routes the case for review.
That common shape allows the action layer, operator queue, and outcome tracking to remain independent of how the decision was reached.
It also makes mixed decisions possible. A model can interpret a message; deterministic logic can apply policy to the extracted result; the final trace can show both.
Evaluate the component, not just the final answer
An overall accuracy number hides too much.
For rule-based decisions, we care about coverage, conflicting matches, false positives, and boundary cases. For model-backed interpretation, we care about schema validity, classification quality, confidence calibration, evidence support, latency, and cost. For the whole workflow, we care about the action selected and the operational outcome.
These measurements should be kept separate. If the final action is wrong, the team needs to know whether the source mapping, derived field, model interpretation, policy rule, or action routing caused it.
Historical replay provides a common test harness. The same case set can be evaluated after a rule change, prompt change, model upgrade, or field-mapping correction. Differences become reviewable cases rather than a vague change in an aggregate score.
Confidence is not authority
A model’s confidence does not decide whether an action may run. It is one input to workflow policy.
A high-confidence classification may still lead to a reviewed action because the financial or customer impact is high. A lower-confidence interpretation may be acceptable for a reversible task such as adding a queue label. The action’s consequences matter independently of how certain the classifier appears.
This separation keeps authority in the workflow definition. It also avoids hard-coding one platform-wide threshold that makes little sense across different actions and domains.
The same interpretation can also support different actions. A likely delivery failure may justify an internal queue label immediately but require more evidence before changing a customer promise. One confidence score should not collapse those two decisions into a single threshold.
Models will change; contracts should last longer
Model providers, versions, prompts, and context strategies will change quickly. An enterprise workflow should not have to be rebuilt every time they do.
By placing model calls behind narrow, versioned interfaces, Proxima can compare implementations and change them without altering the event model or action lifecycle. A classifier can move from one model to another. A document extractor can be replaced with a specialized service. The rest of the workflow continues to consume the same result shape.
The deeper engineering challenge is not choosing between rules and models. It is deciding where uncertainty belongs, making that uncertainty visible, and preventing it from spreading through the entire system.