The most expensive misunderstanding between business and IT can fit inside a single ordinary word. "Sold". "Available". "Received". Everyone in the room understands them without effort. The trouble starts when everyone understands them slightly differently, and decisions or the code of management systems are then built on that.

The easier software becomes to write, the more precisely you have to state how the business it serves is supposed to work. Fast implementation usually shortens the road from a vague assumption to an expensive mistake.

That is one of the reasons I built the Open Retail Process Reference. It is an open, versioned standard for the architecture of business processes in retail. ORPR is meant to give a shared point of reference to the people designing a change, and to the systems and AI agents that help carry it out.

The impulse came while I was working on an application built with Spec Driven Development, that is, from a specification describing the expected behaviour. I needed material an AI agent could refer to before it started filling the gaps with its own idea of what retail looks like.

Without that layer, the SDD process produces too many errors that are expensive to remove. The larger problem is that neither a developer nor even a business analyst is able to catch them. That takes knowledge reaching beyond how a process or a feature works. It takes the perspective of the whole business.

I started from the basics. What are we describing, where do we draw the boundaries, and how will we recognise correct execution? The answers shaped how ORPR is built.

A process is recognised by its outcome and its boundaries

The name of a department is not enough. Neither is the scope of a system module. The fact that two activities are performed today by one employee or one application does not settle whether they are the same process.

Take a sale with later collection of the goods. The customer has bought the product but has not picked it up. The company has an obligation towards that customer. The goods are still physically standing in the location. You have to prevent the same quantity from being sold again while keeping truthful information about its physical state.

If a system treats the sale and the release as the same event, that difference is lost. What follows is patching: exceptions, extra fields and manual explanations. I have watched this error in systems serving hundreds of points of sale, and the repair always looked the same. An extra field and an instruction for the cashier.

In ORPR, SAL-01 describes the move from basket to sale, and SAL-03 the move from sale to release of the goods. That distinction has a concrete consequence. A sales record is not proof of physical release, so the outbound movement needs its own confirmation.

Writing it down this way helps both the business conversation and the design of the system. It also gives you a basis for judging whether the solution did what it was supposed to do.

A rule has to survive being checked

The sentence "the system shall handle sales correctly" leaves almost all the work still to be done. The word "correctly" has the convenient property that everyone can sign up to something different underneath it. You have to establish which event closes the sale, what covers it, what happens when a message is repeated, and which effects already belong to other processes.

That is why ORPR contains invariants, that is, conditions that must remain true while the process runs, together with contracts that define its boundaries. Their value lies in the fact that an actual execution can be held up against them.

A model can justify its own behaviour convincingly. Taking that explanation at face value is not enough; the result still has to be checked. A written condition and evidence that it holds let you separate the two.

A missing decision has to be surfaced

Organisations operate under different models. The same process occurs in an independent store, in a partner programme and in a fully owned chain, but the right to decide may sit with different people or different legal entities. Moving a solution from one model to another requires recognising those differences.

For that reason every card carries analytical questions. They are there to help uncover what has not been settled yet, which conditions apply in a particular company, and where matching names hide a difference in how things actually work.

If it is not clear who may release a purchase requirement, an agent should not solve the problem by picking the most probable role. It should surface the missing decision. It is the organisation that grants authority and takes responsibility for its scope.

The same goes for departures from the reference. A company may have a good reason to work differently. That difference should be an explicit decision with its consequences written down. Requirements that follow from law cannot be treated as one more design preference along the way.

People and machines need the same version of the content

Every process has a stable identifier. That lets you refer to it in a conversation, a requirement, an integration or an agent's answer. The version tells you which description a decision refers to. Machine access means the material can be fetched without being retyped from a slide deck.

That is the practical meaning of an API and of files meant to be read by models. Publishing a large amount of text is not enough. You also have to know which fragment concerns which process, and which release is the basis for the work.

The first release of the ORPR map covers 74 processes across 22 areas. The numbers define the scope; on their own they prove nothing about value. That has to be judged on concrete rulings and concrete uses. The ORPR registry.

ORPR as a translation layer between business and IT

The intention "handle the sale" has to be turned into a description of the outcome, the data, the permissions and the conditions of correctness. That description can then be used by an analyst, an architect or an agent building the solution. Each of them should be able to check where the agreed rule ends and an assumption requiring a decision begins.

What ORPR is not: it is not a modelling notation such as BPMN, nor a replacement for SCOR, the reference model for the supply chain. What it shares with APQC PCF, including its retail version, is bringing order to processes. The approach differs. APQC classifies; ORPR describes execution boundaries, invariants and the questions a particular company has to settle before anyone writes the first line of code.

Whether ORPR is useful will be settled by real use in future implementations. Publishing a standard of one's own does not yet mean the industry has adopted it. The map, the process descriptions and six full cards are publicly available. The remaining 68 cards exist in full; publicly only their summaries are visible.

I test the value of my own experience here in a very practical way. Can I explain the difference, write down its consequences, and state the condition by which someone else will recognise correct execution? Knowledge that stays only in the author's head has a limited reach. Written down like this, it can become the basis of someone else's work and the object of substantive criticism.

ORPR is the result of that approach. I want it to help move from experience and business intent to explicit rules that both people and systems can work by. The more of the execution agents take over, the more the quality of those rules will matter.