The operating model as code: executable rules and exceptions

Companies often have a documented operating model and another version applied by people handling exceptions. The gap contains rules, tolerances and decisions that were never added to the manual. Operating model as code means expressing those elements precisely enough for agents to execute them, with controls and a trace. The content must come from the company because no vendor knows it in advance.

What it is

Take order-to-cash in an industrial distributor. The documented version says an order arrives, credit is checked, stock is allocated, goods ship and an invoice follows. The executed version may let one account bypass the credit check up to a ceiling, avoid one warehouse for a product family in winter and treat mismatches differently for one customer. If those rules are absent from the manual, the manual is not a complete specification.

Codifying the operating model means capturing that layer, deciding whether each exception should remain and expressing the result as conditions, thresholds, permissions and escalation paths. Agents execute defined cases, people retain specified judgment calls and every action leaves a trace.

The definitions also need versioning and approval. A threshold change should name who requested it, who approved it, when it took effect and which cases ran under each version. Without that history, the process may execute consistently while nobody can explain why its behavior changed. Keep that history with the code.

This differs from documentation because it executes. A document can become outdated without generating a signal. When an executable rule no longer matches how finance handles mismatches, cases fail or escalate and the discrepancy can be measured. Execution makes drift observable.

Why this layer remains custom

The components underneath this layer are maturing: models are utility and orchestration is becoming product. The operating model remains custom because its content differs by company.

A vendor productizes what repeats across customers. The standard order-to-cash flow can become product. Negotiated exceptions and company-specific rules cannot be known before implementation. A package therefore either asks the company to adopt its standard or leaves unmatched cases to spreadsheets and other systems around it.

I therefore place this layer in the custom phase. Vendors may price it as product while services teams perform the company-specific work. The custom phase explains when repeated components can later move to product. Boards should classify the work required rather than the label on the contract.

The work involved

The first task is discovering the rules that the documentation omits.

The team works with process operators to identify exceptions and make deferred decisions: whether an exception is policy or habit, whether a threshold still has a reason and who owns the call. This often exposes rules nobody can justify and controls stored only in one employee’s memory, findings that matter even without an agent.

Agents can help analyze tickets, emails and logs to propose recurring rules and exceptions for people to confirm or reject. They can also execute the resulting definitions. The lower cost of building and maintaining this software is covered in agentic product development. The codified model supplies the permissions, limits and escalation paths for AI agents in operations and the controls described in AI agent governance.

The sequence is to document one process, codify it, execute it under supervision and use escalations to refine the definitions. Each revision should be linked to evidence from operation.

At Arkatai, this company-specific work happens during deployment. A forward-deployed engineer incorporates rules and exceptions into the shared system. Our team maintains the platform while the client retains authority over the process.

What the company retains

After two years, the company can retain several assets independent of the current model vendor.

Rules that depended on a few employees become explicit, executable and reviewable. Each escalated exception can become a proposed revision instead of remaining in an inbox. A pricing rule, approval path or tolerance can be changed once, applied uniformly and traced from a known version. Organizational communication and training may still be required, but the executable behavior changes in one place.

A competitor can buy the same models and tooling but still has to document its own processes and accumulate execution data. The advantage, if one develops, comes from how much of the operation is explicit and tested, not from exclusive access to a model.

Questions boards ask me

Isn’t this just business process management with new vocabulary?

The objectives overlap. The difference is that executable definitions produce signals when they diverge from operation, and agents can reduce the cost of finding recurring exceptions in records. BPM artifacts can also remain useful when they are connected to execution and maintained.

Where should we start, and how big is a sensible first scope?

Start with one high-volume process, describable rules and a named owner. Avoid an enterprise-wide first scope. Measure whether documentation, controls and integration from the first process are reused in the second before claiming a repeatable method.

What happens when the business changes and the code is wrong?

When the model is code, the executable rule is changed once and the trace records when behavior changed. People may still need training for decisions outside the system. The main control is clear ownership of who may change each rule and how that change is approved.

Does this create dependency on the operator?

The platform remains Arkatai software, but the client-specific operating architecture belongs to the client. At termination, the client receives its current version and the agreed exports of data, results and traces. That package can be taken to another implementer or used to build proprietary software. Runtime dependency exists while we operate the service. The codified operating knowledge is not held captive.