Regulatory layer
From a legal provision to a testable system requirement
Regulatory Matrix is a versioned repository of regulatory requirements for POS/ERP-class systems. It organises legal provisions, official sources and the system behaviours that follow from them so they can be used in analysis, design, implementation and testing. It is not a list of acts: every relevant norm is translated into an atomic requirement with a stable identifier, an exact source and verifiable scenarios.
Regulatory Matrix supports analysis and design. It is not a legal opinion, a compliance certificate or an assurance that a specific implementation meets every obligation. Scope, date, facts and active gaps must be checked for each use.
- 361
- 1083
- 122
- 66/74
A process card does not copy the law. It cites an identifier.
ORPR describes a process: purpose, boundaries, ownership, inputs, outputs, exceptions and diagnostic questions. Regulatory Matrix answers a different question — which system behaviours or evidentiary duties arise at that point from regulation. Below is the chain every requirement travels, shown on the one binding the data package publishes in full.
Legal or official source
CAT-02 → PL-PRICE-030
Act of 9 May 2014 on informing about prices of goods and services (Poland)
Specific provision or fragment
CAT-02 → PL-PRICE-030
Art. 4(2) (implementing Directive 98/6/EC, Art. 6a)
Atomic system requirement (EARS)
CAT-02 → PL-PRICE-030
PL-PRICE-030 · Reference price when announcing a reduction — Every reduced price shown at the till and on the shelf must be accompanied by the lowest price from the 30 days before the reduction. The pricing system must retain it and pass it on with the price in force.
Positive, boundary and negative scenario
CAT-02 → PL-PRICE-030
Reduction after a stable period · Several price changes within 30 days · No price history
RM functional package
CAT-02 → PL-PRICE-030
Profile "retail core", jurisdiction PL, package 1.0.1, legal state 2026-08-14
ORPR process, card or control point
CAT-02 → PL-PRICE-030
Card ORPR-CAT-02 cites [R: PL-PRICE-030] in its "Regulatory bindings" section — with no legal text.
Because cards reference by identifier, updating a regulatory requirement does not mean rewriting the same interpretation across many processes. Missing coverage is an explicit GAP in the register, never silence.
Five sentence patterns, 361 requirements
Requirements are written in EARS (Easy Approach to Requirements Syntax). A constrained, repeatable syntax reduces ambiguity and makes it easier to turn a norm into an acceptance criterion.
- 275
event-driven
WHEN [event], the system SHALL… - 45
unwanted behaviour
IF [unwanted situation], the system SHALL… - 30
state-driven
WHILE [state], the system SHALL… - 7
ubiquitous
The system SHALL… - 4
optional feature or scope
IF [applicability condition], the system SHALL…
Atomicity means one record describes one enforceable effect. If a norm leads to two independent system behaviours, it is split into two requirements. That makes applicability easier to judge, changes easier to track, and the confirming test easier to point at.
Normative strength and analytical confidence are not the same thing
RM records them separately. A requirement can be mandatory and still need confirmation that it actually applies to a given product or set of facts.
Strength — what the rule demands
- MUST
- 321
- required behaviour
- MUST_NOT
- 37
- prohibited behaviour
- SHOULD
- 2
- recommended behaviour
- MAY
- 1
- permitted behaviour
Confidence — how well the trace is checked
- verified
- 83
- a coherent, structurally checked trace to the cited source — not a legal opinion
- qualified
- 278
- requirement qualified; application to a product or set of facts still needs confirmation
"Verified" means a coherent, structurally checked trace to the cited source. It is not, and does not replace, an external legal opinion.
A machine-processable object, not a sentence
Beyond the EARS sentence, a record can carry, among others:
- 01a stable identifier, domain and title
- 02jurisdiction and effective dates
- 03business profiles, channels, supply-chain roles and assortment overlays
- 04actors, preconditions and exceptions
- 05inputs, outputs, required evidence trail and external interfaces
- 06type of personal data and a reference to retention rules
- 07relations to other requirements and interpretations
- 08source identifier, exact locator and binding type
- 09three verification scenarios
This lets a rule activate only when it genuinely matches the profile, channel, assortment and role of the organisation under analysis. Presence in the base does not mean a requirement applies to every retailer.
The canon is the source of truth. Everything else is generated.
The repository separates three layers. Consumption views are never edited by hand.
- 1
Canon
Sources, requirements, applicability catalogues, gap registers and package definitions. The only place that is edited.
- 2
Control and publication
Data model, validators, generators and an integrity manifest. A release is deterministic: the same canon yields the same package and the same checksums.
- 3
Consumption interface
Static JSON and Markdown packages plus CSV indexes — for people, analytical tools and AI agents. Generated, never hand-edited.
Every package carries a version number, a legal_as_of date, a content status and a deployment-readiness declaration. effective_from and effective_to let a requirement be evaluated for a target date, not just today. An active GAP or critical defect halts use of the affected scope — rather than letting a missing answer be filled by guesswork.
The structure of the release, counted
The figures describe the structure of the release — not a number of legal opinions, nor a number of features ready to ship.
| Element | Count | What the number means |
|---|---|---|
| source cards | 122 | versioned source descriptions with issuer, date and locator |
| legislative documents | 106 | acts, regulations, EU instruments, amending acts, notices and corrections |
| official, technical and guidance material | 16 | supporting sources whose weight is kept distinct from binding law |
| issuing bodies and institutions | 18 | unique issuers of source cards |
| atomic EARS requirements | 361 | separate, identifiable system behaviours |
| verification scenarios | 1,083 | exactly three per requirement: positive, boundary and negative |
| requirement–source links | 514 | relations from a requirement to a source card; 78 distinct cards appear in them directly |
| provision or fragment locators | 363 | locators recorded on source cards |
| relations between requirements | 272 | dependencies and other explicit graph edges |
| references to retention rules | 140 | requirements pointing to a controlled retention rule |
| requirements with an external interface | 186 | records that depend on communication with another system or party |
| functional-package assignments | 251 | requirement memberships in consumption packages |
| functional packages | 21 | ready, bounded contexts for one specific function |
| requirement domains | 19 | thematic areas in the data model |
| business profiles | 5 | pharmacy, grocery, drugstore, sports and DIY |
| delegations and material dependencies | 77 | 44 covered, 32 out of scope, 1 remains a gap |
| requirements active in time | 352 | records active on the release date |
| requirements with unresolved time or scope | 9 | items shown as a gap, not hidden as an assumption |
| active GAPs | 9 | explicit limitations awaiting resolution |
| active P0 defects | 0 | no known active top-severity defects |
Across the 514 requirement–source links, 78 distinct source cards appear directly. The remaining cards preserve, among other things, amendment context, coverage and legislative history.
Where regulation weighs most
The ten ORPR processes with the most regulatory bindings, per the data package. For every other process the number is not published — and this site does not guess it.
- ORPR-FIN-02From inventory to cost of goods sold70
- ORPR-INV-02From transfer to receipt49
- ORPR-FIN-01From sale to ledger44
- ORPR-FIN-03From tax to liability42
- ORPR-INV-06From out-of-stock to resolution41
- ORPR-INV-01From receipt to availability39
- ORPR-SAL-02From sale to fiscal document37
- ORPR-INV-08From transfer discrepancy to reconciliation36
- ORPR-INV-09From inventory events to a trustworthy stock position34
- ORPR-CSH-01From till opening to till close32
The binding count is the number of RM identifiers cited in the card, not a measure of risk or implementation complexity.
A shared retail core, a deep pharmacy profile, a drugstore overlay
The release covers Polish POS/ERP systems. The drugstore overlay includes cosmetics, detergents, conditional biocidal products and CLP and REACH requirements. RM does not claim full coverage of all law affecting every business — it focuses on the duties, prohibitions, exceptions, deadlines and evidence that change the behaviour or data of the system.
Scope is composed by
- business profile
- channel — store, distance selling, click and collect, marketplace
- role — retailer, distributor, importer, brand owner, manufacturer
- assortment type and activated overlays
- features of a specific site or process
Regulatory Matrix can support
- discovery and regulatory impact analysis
- specifications and acceptance criteria
- data-model and integration design
- positive, boundary and negative tests
- gap review before go-live
- controlled retrieval for AI agents — without loading the whole repository into context
The safest way to work: pick a functional package or a specific identifier, check its date and applicability, then keep the complete trail — requirement, source, locator, scenarios, warnings and active GAPs. Never copy a single sentence without its source, date, applicability conditions and relations. A "verified" status does not replace a legal assessment of a specific implementation.