Standard otwarty · ORPR v0.1 · wrzesień 2026

Retail nie miał wspólnego języka procesów. Napisałem go.

ORPR (Open Retail Process Reference) to otwarty, wersjonowany słownik procesów handlu detalicznego. Każdy proces ma jedną definicję, tę samą dla człowieka, integratora i agenta AI. Standard jest publiczny, na wolnej licencji, dostępny na orpr.dev.

74
procesy z jedną definicją
22
obszary: 8 przepływów biznesowych i 14 procesów wspólnych
160
wymogów regulacyjnych przypiętych do 66 procesów
6
profili modeli biznesowych: od sklepu po marketplace
Mapa procesów → Karta CAT-02 „Od ceny do kasy” → JSON API → Cały standard w jednym pliku →

Skąd się to wzięło

Logistyka ma SCOR. Telekomunikacja ma eTOM. Gdy dwie firmy z tych branż mówią „przyjęcie dostawy” albo „aktywacja usługi”, mówią o tym samym. Retail powszechnie przyjętego, otwartego modelu procesów nie ma. Każda sieć, każdy dostawca systemu i każdy integrator nosi w głowie własny słownik. Zwykle wychodzi to na jaw dopiero przy wdrożeniu, kiedy „zamówienie” po stronie klienta kończy się w innym miejscu niż „zamówienie” po stronie dostawcy.

Trafiłem na to od nietypowej strony. Prowadzę projekty systemów dla sieci aptek metodą Spec-Driven Development: specyfikacja i testy powstają przed kodem, a kod piszą agenci AI pod moim nadzorem. Agent jest świetnym wykonawcą i fatalnym interpretatorem. Żeby dobrze napisał moduł cen, musi dostać jednoznaczną odpowiedź: kto jest właścicielem ceny, gdzie kończy się oferta, a zaczyna kasa, co dokładnie wchodzi i wychodzi z procesu. Szukałem gotowego standardu, na którym mógłbym oprzeć te odpowiedzi. Nie znalazłem. Więc go napisałem.

Jest też druga warstwa. Wiedza o tym, jak naprawdę działa sklep, apteka i hurtownia, nie leży w podręcznikach. Siedzi w głowach ludzi, którzy przez lata prowadzili takie firmy: zarządzałem sieciami od kilkunastu do 3 800 lokalizacji, dziś wdrażam systemy dla sieci handlowych. ORPR zapisuje tę wiedzę w formie, którą da się przeczytać, sprawdzić, zacytować i podać programowi jako punkt odniesienia. Doświadczenie bez takiej formy jest anegdotą. Z nią staje się standardem.

Co jest w środku

  • Mapa procesów: 74 procesy w 22 obszarach, z jasną granicą między przepływami biznesowymi (zakupy, oferta, sprzedaż, zwroty i tak dalej) a procesami wspólnymi (dane podstawowe, stan magazynowy, finanse, zgodność).
  • Karta procesu: cel, wejścia, wyjścia, właściciel, konsument i przekazania do innych procesów. Jedna struktura dla wszystkich 74 kart. Sześć kart jest wydanych w pełnej wersji, 68 w publicznym skrócie po recenzji.
  • Przekazania: 16 potwierdzonych połączeń między procesami, czyli miejsca, w których jeden proces oddaje wynik drugiemu. To tam zwykle giną wdrożenia.
  • Warstwa regulacyjna: 160 wymogów prawnych przypiętych do 66 procesów. Nie jest to porada prawna, tylko kontrolowana projekcja: analityk widzi, których procesów dotyka przepis, zanim zacznie projektować.
  • Profile modeli biznesowych: sześć wariantów, od pojedynczego sklepu po marketplace, z informacją, które procesy są w danym modelu obowiązkowe.
  • Dostęp dla ludzi i maszyn: strona, otwarte JSON API bez kluczy, pliki llms.txt dla modeli językowych, dane JSON-LD. Publikacja ma sumy kontrolne SHA-256, więc da się sprawdzić, czy to, co czytasz, jest tym, co wydałem.
  • Licencje: treść CC BY-SA 4.0, kod Apache-2.0. Można używać i rozwijać. Warunek jest jeden: wskazać źródło.

Tak wygląda jedna karta. Proces CAT-02 to jedno z najczęstszych miejsc sporu między siecią a dostawcą systemu:

CAT-02 · karta pełna · wydanie 1.0
Od ceny do kasy
Cel
Cena na paragonie jest ceną zatwierdzoną dla tej lokalizacji, tego momentu i tego towaru.
Wejście
Zatwierdzona cena towaru.
Wyjście
Cena operacyjna na kasie.
Właściciel
Oferta.
Konsument
Kasa.

Pięć linijek. Ale kiedy sieć i dostawca podpisują pod nimi umowę, znika połowa późniejszych sporów o to, „czyj to był błąd”.

Dla kogo to jest

Zarząd sieci
Wdrażasz nowy system albo zmieniasz dostawcę. Zakres umowy, testy odbiorowe i lista „co ma działać” opierają się na jednej mapie procesów, a nie na prezentacji handlowca.
Dostawca IT, integrator
Mapujesz swój system na standard i od razu widzisz, które procesy obsługujesz w całości, które częściowo, a których wcale. Rozmowa z klientem zaczyna się od luk.
Zespół budujący agentów AI
Agent dostaje stabilny punkt odniesienia: identyfikatory procesów, właścicieli, granice. Plik llms.txt i API są po to, żeby nie musiał zgadywać, co znaczy „zwrot”.

Jak to powstało

Większość tekstu standardu napisali agenci AI. Wszystkie decyzje są moje. Sposób pracy jest ten sam, który stosuję w projektach dla klientów, tylko tym razem produktem jest standard:

  • Specyfikacja przed treścią. Najpierw powstała struktura karty, reguły notacji i kryteria odbioru. Dopiero potem karty.
  • Agenci jako autorzy, człowiek jako właściciel. Osobiście przeszedłem przez wszystkie 68 kart. Każda ma mój werdykt, nie werdykt modelu.
  • Recenzja niezależna innym modelem. Tekst pisany przez jeden model recenzuje inny, z innej rodziny, w trybie „werdykt, słabe punkty, alternatywa”. Model rzadko widzi własne błędy. Cudze widzi bardzo dobrze.
  • Bramki jakości i zamrożone narzędzia kontrolne. Automatyczne testy spójności spisu, mapy i kart. Zmiana w narzędziu kontrolnym wymaga numerowanego wyjątku wpisanego przed kodem.
  • Rejestr decyzji z odrzuconymi wariantami. Każda decyzja o notacji ma zapisane, co wybrałem, co odrzuciłem i dlaczego. Za rok będę wiedział, czemu mapa wygląda tak, a nie inaczej.
  • Czyste źródło. W standardzie nie ma ani jednego dokumentu klienta. Wiedza domenowa jest moja, forma jest otwarta.

ORPR i macierz regulacyjna

Wcześniej zbudowałem macierz 361 wymagań regulacyjnych dla systemów aptecznych: co system musi robić, bo tak każe prawo. ORPR odpowiada na inne pytanie: jak pociąć procesy handlu i kto za który odpowiada. To dwie warstwy tej samej konstrukcji, zbudowane w jednym celu: żeby specyfikacja systemu dla sieci handlowej zaczynała się od procesu i przepisu, a nie od listy funkcji. Macierz mówi „musisz”, ORPR mówi „gdzie i kto”.

Co dalej

Standard jest wydany. Wszystkie 74 procesy, ich granice i przekazania mają zamknięty werdykt właściciela, spis i mapa są zamrożone, a publikacja ma sumy kontrolne SHA-256. Sześć kart jest opublikowanych w całości, pozostałe 68 w publicznym skrócie. Skrót dotyczy formy publikacji, treść kart jest kompletna.

Czego standard jeszcze nie ma, to weryfikacji rynkowej. Konstrukcja jest gotowa i spójna, ale dopiero użycie jej w konkretnych sieciach i u dostawców systemów pokaże, co warto dociągnąć w kolejnym wydaniu. Dlatego numer to 0.1, a nie 1.0.

Standard jest otwarty na publiczną recenzję. Jeśli prowadzisz sieć, budujesz dla niej system albo agentów i chcesz sprawdzić mapę na własnych procesach, odezwij się. Pierwsi adopterzy dostają najwięcej: ich uwagi trafiają do wersji 0.2.

Chcesz oprzeć projekt na ORPR albo sprawdzić standard na swojej organizacji?

Napisz do mnie → Otwórz orpr.dev →

Atrybucja: ORPR, Rafał Myrta, 2026, myrta.me/orpr. Treść na licencji CC BY-SA 4.0, kod na Apache-2.0. Warstwa regulacyjna wspiera analizę i projektowanie, nie jest poradą prawną.

Rafał Myrta
Rafał Myrta
Porządkuje procesy, role i systemy w firmach wielolokalizacyjnych i regulowanych. Projekty AI prowadzi metodą Spec-Driven Development. Autor ORPR.
Porozmawiajmy →
← Wróć na stronę główną
Open standard · ORPR v0.1 · September 2026

Retail had no shared language for its processes. So I wrote one.

ORPR (Open Retail Process Reference) is an open, versioned dictionary of retail processes. Each process has one definition, the same for a person, an integrator and an AI agent. The standard is public, freely licensed and available at orpr.dev.

74
processes, one definition each
22
areas: 8 business flows and 14 shared processes
160
regulatory requirements bound to 66 processes
6
business model profiles, from a single store to a marketplace
Process map → Card CAT-02 "From Price to Checkout" → JSON API → Whole standard in one file →

Where it came from

Logistics has SCOR. Telecoms have eTOM. When two companies in those industries say "goods receipt" or "service activation", they mean the same thing. Retail has no widely adopted, open process model like that. Every chain, every software vendor and every integrator carries its own dictionary in its head. It usually surfaces during implementation, when the customer's "order" ends in a different place than the vendor's "order".

I ran into this from an unusual angle. I run system projects for pharmacy chains using Spec-Driven Development: specification and tests come before code, and the code is written by AI agents under my supervision. An agent is a superb executor and a terrible interpreter. To write a pricing module well, it needs an unambiguous answer: who owns the price, where the offer ends and the checkout begins, what exactly enters and leaves the process. I looked for a ready standard to base those answers on. There was none. So I wrote one.

There is a second layer. Knowledge of how a store, a pharmacy and a wholesaler really work is not in textbooks. It sits in the heads of people who ran such businesses for years: I managed chains from a dozen to 3,800 locations, and today I implement systems for retail chains. ORPR writes that knowledge down in a form that can be read, checked, cited and handed to a program as a reference point. Experience without such a form is an anecdote. With it, it becomes a standard.

What is inside

  • Process map: 74 processes in 22 areas, with a clear line between business flows (purchasing, offer, sales, returns and so on) and shared processes (master data, stock, finance, compliance).
  • Process card: goal, inputs, outputs, owner, consumer and handovers to other processes. One structure for all 74 cards. Six cards are released in full, 68 as reviewed public summaries.
  • Handovers: 16 confirmed connections between processes, the places where one process hands its result to another. That is where implementations usually go wrong.
  • Regulatory layer: 160 legal requirements bound to 66 processes. Not legal advice, but a controlled projection: the analyst sees which processes a regulation touches before starting to design.
  • Business model profiles: six variants, from a single store to a marketplace, stating which processes are mandatory in each model.
  • Access for people and machines: the website, an open JSON API with no keys, llms.txt files for language models, JSON-LD data. The release carries SHA-256 checksums, so you can verify that what you read is what I published.
  • Licences: content CC BY-SA 4.0, code Apache-2.0. Use it and build on it. One condition: name the source.

This is what a card looks like. Process CAT-02 is one of the most frequent points of dispute between a chain and its software vendor:

CAT-02 · full card · release 1.0
From Price to Checkout
Goal
The price on the receipt is the price approved for this location, this moment and this item.
Input
Approved item price.
Output
Checkout operating price.
Owner
Offer.
Consumer
Checkout.

Five lines. But once a chain and a vendor sign a contract underneath them, half of the later arguments about "whose fault was that" disappear.

Who it is for

Retail chain management
You are implementing a new system or switching vendors. Contract scope, acceptance tests and the "what has to work" list rest on one process map, not on a salesperson's slide deck.
Software vendor, integrator
You map your system onto the standard and see at once which processes you cover fully, partly or not at all. The conversation with the customer starts from the gaps.
Teams building AI agents
The agent gets a stable reference: process identifiers, owners, boundaries. The llms.txt file and the API exist so it does not have to guess what "return" means.

How it was built

Most of the standard's text was written by AI agents. All the decisions are mine. The way of working is the one I use in client projects, except this time the product is a standard:

  • Specification before content. The card structure, notation rules and acceptance criteria came first. The cards came after.
  • Agents as authors, a human as owner. I personally went through all 68 cards. Each carries my verdict, not the model's.
  • Independent review by a different model. Text written by one model is reviewed by another, from a different family, in "verdict, weak points, alternative" mode. A model rarely sees its own mistakes. It sees other people's very well.
  • Quality gates and frozen control tools. Automated consistency tests across the register, the map and the cards. A change in a control tool requires a numbered exception written down before the code.
  • A decision log with rejected options. Every notation decision records what I chose, what I rejected and why. A year from now I will know why the map looks the way it does.
  • Clean source. There is not a single client document in the standard. The domain knowledge is mine, the form is open.

ORPR and the regulatory matrix

Earlier I built a matrix of 361 regulatory requirements for pharmacy systems: what a system must do because the law says so. ORPR answers a different question: how to cut retail processes and who owns which one. They are two layers of the same construction, built for one purpose: so that a system specification for a retail chain starts from the process and the regulation, not from a feature list. The matrix says "you must", ORPR says "where and who".

What comes next

The standard is released. All 74 processes, their boundaries and handovers carry a closed owner verdict, the register and the map are frozen, and the release ships with SHA-256 checksums. Six cards are published in full, the remaining 68 as public summaries. The summary concerns the form of publication; the content of the cards is complete.

What the standard does not have yet is market verification. The construction is finished and coherent, but only its use in real chains and at real software vendors will show what deserves tightening in the next release. That is why the number is 0.1 and not 1.0.

The standard is open to public review. If you run a chain, build systems or agents for one, and want to test the map against your own processes, get in touch. Early adopters get the most: their remarks go into version 0.2.

Want to base a project on ORPR, or test the standard against your organisation?

Write to me → Open orpr.dev →

Attribution: ORPR, Rafał Myrta, 2026, myrta.me/orpr. Content under CC BY-SA 4.0, code under Apache-2.0. The regulatory layer supports analysis and design; it is not legal advice.

Rafał Myrta
Rafał Myrta
Brings order to processes, roles and systems in multi-site and regulated companies. Runs AI projects with Spec-Driven Development. Author of ORPR.
Let's talk →
← Back to the home page