Business team
A shared process language: talking about “listing for sale” means the same to everyone because it points at one record.
v0.1.0
Open standard · two readers: human and agent
One description of a retail process, read by both people and AI systems.
ORPR is an open, versioned vocabulary of retail processes. Each process has a single definition: the same source describes it for a person, for an integrator and for an agent — with no room for interpretations to drift apart.
- 22
- 74
- 74
map content version v0.1.0 · 1.0
6 full · release v0.1.0 · 68 in abridged form
03 / Commercial offerORPR-CAT-02
full card · released 1.0
From price to till
- Purpose
- The price charged at the till is exactly the approved one — in this location, at this moment, for this item.
- Inputs
- approved item price
- Outputs
- price in force at the till
- Gates
- price approval, validity in the location
- Owner / consumer
- Offer (owner), Till (consumer)
- Obligation
- PL-PRICE-030 · Reference price when announcing a reduction
Human layer · System layer · Agent layer1 = 1 = 1
01The gap
The same process gets described in as many ways as it has readers.
An analyst, a software vendor and a language model each receive a different account of the same thing. The differences only surface at implementation — expensively.
- 01
Interpretations drift
With no shared reference, “goods receipt” means something slightly different to everyone. Integration pays for that gap.
- 02
Knowledge trapped in heads
The rule that decides correctness lives in an email, a config file and one person’s memory — not in a description you can point to.
- 03
Agents with nothing to anchor to
A model gets a prompt instead of a definition. Answers drift between runs because there is no stable source.
ORPR closes the gap with one description per process — legible to all three readers.
02How it works · process CAT-02
Follow one process from its name to a legal rule.
Take “From price to till”. The same source yields a short human definition, a structured card for systems, and an explicit binding to a statutory obligation.
Purpose
The price charged at the till is exactly the approved one — in this location, at this moment, for this item.
- Inputs
- approved item price
- Outputs
- price in force at the till
03What it is for
One source, three readers.
Integrator and vendor
A process card with inputs, outputs and gates replaces interpretation. Implementation scope is written in identifiers, not stories.
AI team
Stable context for an agent: the same versioned record as input yields reproducible output across models and runs.
04Applications
What can you use ORPR for?
ORPR is a map of 74 retail processes across 22 areas. Every process has a stable ID, an input, an output, an owner and a rule for which type of company it is required in. That is why it is built for work, not just for reading.
01
See what you are missing
- the list of processes required for your company type: chain, franchise, buying group, e-commerce, marketplace
- a review of processes with no owner, or with two owners at once
- due diligence before an acquisition and an integration plan after it
02
Choose and roll out a system
- ready-made questions for the business, the legacy system and the vendor
- an RFP and offer comparison on a single list of processes
- the scope of an IT contract as a list of IDs instead of prose
- acceptance tests derived from decision gates
- a migration plan, process by process
03
Put the company and contracts in order
- the split of responsibility between head office and store in a franchise agreement
- which system is the source of truth for stock, prices and settlements
- an integration design for POS, ERP, WMS and the online store on named events
- legal obligations written into the process where they arise
04
Work with people and with AI
- a shared language with vendors and auditors (mapping to APQC, ARTS, GS1)
- onboarding a new analyst or PM into retail fast
- domain context for an AI assistant, so it does not reinvent processes
- citation in proposals and studies: open license, stable IDs
05Proof, not promise
What is already confirmed.
The standard grows by cards, not declarations. Every figure below has a named object and comes from the same data file that feeds the map.
- 74
- processes have a card in the standard — 6 presented publicly in full, 68 in an abridged form
- 16
- handoffs and calls confirmed by the author in cards (solid line on the map)
- 66
- of 74 processes have a confirmed regulatory binding — 160 unique requirements, one shown public and in full: CAT-02 → reference price
- 6
- retail business models — from independent store to owned chain — with a profile for each of the 74 processes
Minimal-sufficiency experiment (25 Aug 2026)
One task, one process area. Giving the model an ORPR record instead of a hand-written description narrowed the spread of answers across model families.
- answer spread
- 5×0.5×
- context share of task cost
- 28%
06Machine access
Readable by people and by machines.
The whole standard is available programmatically — no keys, no sign-up, open CORS. The same data that powers these pages is served as JSON and as plain text for language models.
JSON API
/api/orprThe registry as read-only JSON: processes, areas, relations, operating models and the regulatory layer. Every process at its own address.
llms.txt
/llms.txtA concise index for AI agents following the llmstxt.org convention. The full standard in Markdown lives at /llms-full.txt.
Dataset
Hugging FaceThe whole registry as a ready-to-download dataset on Hugging Face — for analysis, model training and offline work.
Structured data
JSON-LD · Schema.org
Every page embeds Dataset, DefinedTerm and breadcrumbs — legible to search engines and assistants without parsing HTML.
07Author and invitation
A standard run in the open, built to be contributed to.
ORPR is the work of one person, run in an open repository. Content is licensed CC BY-SA 4.0, code under Apache-2.0. Cards, relations and regulatory bindings are accepted through a public review process.