Why the future of regulated software depends on a trusted rule layer that can translate legal authority into constraints, tests and evidence for today’s applications and tomorrow’s autonomous AI.
By Darko Pavić
First published 24 July 2026 · Last substantively reviewed 24 July 2026
Definition
A Compliance Compiler is a governed transformation system that converts authoritative legal and technical sources into validated, versioned and machine-readable compliance instructions, tests and evidence requirements. It is necessary because AI-native software may dynamically decide how to execute a business task, while regulated outcomes still require rules that are authoritative, context-aware, deterministic where possible and auditable. The Compliance Compiler separates autonomous execution from legal authority: AI may choose how to act, but it must act inside a rule layer that it cannot invent for itself.
| Darko Pavic’s practical definition A Compliance Compiler is the missing control layer between the law and any system – human-built software today or autonomous AI tomorrow – that must turn a legal obligation into safe, testable and provable action. |
Key takeaways
- Machine-readable law is not merely legislation stored as a PDF, XML file or searchable database. Operational use requires validated interpretation, applicability, exceptions, dates, versioning and evidence.
- The Compliance Compiler affects retailers, POS and ERP providers, e-commerce platforms, payment and e-invoicing providers, tax teams, regulators, auditors and AI-system designers.
- Its first role is practical and immediate: translate regulatory change into reusable requirements, tests and traceability for existing software.
- Its long-term role is architectural: provide the external rule layer that governs autonomous AI when fixed application logic is no longer the main way digital work is performed.
- The critical distinction is between autonomous execution and legal authority. AI may optimize the method; it must not manufacture the rule that authorizes the outcome.
Table of contents
- Why the Compliance Compiler is necessary for the future software industry
- The software industry is moving through three stages
- Machine-readable law is more than digital legal text
- Why giving an AI access to legal documents is not enough
- The Autonomy-Control Principle
- What the Compliance Compiler includes – and what it does not
- How compliance compilation works
- The rule object must carry context, not only a sentence
- Not every rule should be automated in the same way
- The Compliance Execution Contract
- Impact on retail and POS systems
- Comparison with adjacent concepts
- International and regulatory variation
- Governance, provenance and evidence are part of the product
- Strategic relevance for stakeholders
- Common misconceptions
- Darko Pavic’s perspective
- Implementation considerations for retailers and software providers
- Related work by Darko Pavic
- Frequently asked questions
- Conclusion: when software changes, the rules remain
- Sources and further reading
Why the Compliance Compiler is necessary for the future software industry
The Compliance Compiler becomes necessary when responsibility for deciding how work is performed moves from fixed application logic toward autonomous AI. Traditional software contains compliance behavior in code written in advance. AI-native execution can construct workflows, choose tools, communicate with other systems and generate task-specific logic dynamically. That flexibility weakens the assumption that legally relevant behavior will always be constrained by a permanent application.
Regulation does not disappear when application boundaries disappear. A sale must still be recorded correctly. A fiscal receipt may still require defined content, identifiers, sequence and timing. An invoice may still need a prescribed semantic structure. A return may still need to reference the original transaction. A reporting obligation may still depend on country, entity, channel, customer type, payment method or connectivity status. The system must also preserve evidence showing why the action was permitted and which rule version applied.
A general-purpose language model cannot safely become both the executor of a regulated task and the source of the rules governing that task. Generative models can support research, extraction, drafting and comparison, but they remain probabilistic. Grounding and retrieval improve reliability without converting an interpretation into legal authority. The operational rule layer therefore has to be external to the executing model, controlled through validation, versioning and governance. [9] [10] [19]
Autonomy belongs to execution. Authority belongs to the validated rule. – Darko Pavic
The software industry is moving through three stages
The transition can be understood as three overlapping stages. The framework is a strategic model rather than a dated prediction: industries and jurisdictions will move at different speeds, and fixed software may remain necessary in many environments for a long time.
| Stage | Primary actor | Execution model | Role of the Compliance Compiler |
| 1. Task-specific software | Human-designed application | Developers encode logic in advance; the application performs a predefined task. | Compliance knowledge is translated manually into requirements, code, tests and documentation. |
| 2. AI-assisted and AI-orchestrated software | AI working with existing applications | AI interprets the objective, performs parts of the work and coordinates applications that still contain operational logic. | The Compliance Compiler provides validated requirements, applicability, tests, configuration guidance and evidence. |
| 3. AI-native execution | Autonomous AI execution environment | AI performs the complete digital task, assembles capabilities dynamically and communicates with other systems or agents. | The Compliance Compiler supplies governing constraints, approved actions, tests, escalation conditions and evidence requirements. |
Stage 1: compliance is hidden inside the application
In the traditional model, specialists interpret a regulation, analysts write requirements, architects map those requirements to systems, developers implement them, testers create cases and auditors collect evidence. The resulting application becomes valuable partly because it contains an operational interpretation of the law. Replacing the application means recreating that interpretation and its country-specific behavior.
This model can work, but it is slow to update and difficult to scale internationally. The same concept may be interpreted differently by different products or project teams. Knowledge can become fragmented across legislation, technical specifications, tickets, code, test cases, certificates, emails and individual experience.
Stage 2: AI orchestrates software, but the applications still execute
In the second stage, users increasingly describe the outcome while AI chooses information sources, performs analysis, drafts implementation material, creates tests or coordinates existing applications through tools and interfaces. The applications still contain much of the operational logic, but the AI controls more of the workflow.
The Compliance Compiler is already valuable in this stage. It can convert a validated regulatory change into a reusable implementation package: affected scenarios, actors, dates, mandatory data, sequence, permitted exceptions, offline behavior, test cases, traceability and evidence. The goal is not to reveal or dictate the internal architecture of every POS or ERP product. The goal is to define the required behavior and how that behavior can be verified.
Stage 3: the function survives even if the application disappears
In an AI-native environment, a permanent application may no longer be required for every category of digital work. An authorized AI execution environment could receive an objective, assemble the relevant context, choose a method, interact with other systems, perform the calculation, validate the result and record evidence. Computation, identity, networks, security and data remain essential, but they may no longer be packaged for the user as separate applications with fixed boundaries.
The legal obligation remains. The rule defining a valid fiscal transaction, invoice, tax calculation, payment action or return cannot be generated spontaneously by the same probabilistic system that executes the task. The rule must be supplied as an external, validated and versioned control object. The Compliance Compiler therefore connects two technological eras: it helps build and test compliant software today and can govern autonomous execution tomorrow.
Download the companion vision paper
When AI Replaces Software, Machine-Readable Law Becomes the Operating System
This 15-page vision paper develops the strategic argument behind the Compliance Compiler. It explains the transition from task-specific applications to AI-orchestrated and AI-native execution, and why regulated systems will require an independent, validated and auditable rule layer.
PDF · 15 pages · English
This paper complements the authority page with a more focused exploration of the future software architecture and the role of machine-readable law.
Machine-readable law is more than digital legal text
Legal material can become increasingly machine-friendly without yet becoming safe for execution. A document may be available online, carry a persistent identifier, include structured metadata or use XML markup. Those developments are important because they make legal sources easier to find, exchange, compare and process. They do not by themselves determine how a rule applies to a specific transaction or system state.
The European Legislation Identifier improves identification and metadata for legislation. Akoma Ntoso provides a structured format for legal documents. LegalRuleML provides formal features for representing legal norms. W3C PROV-O provides a vocabulary for provenance. Each solves a necessary part of the problem, but an enterprise still needs a controlled transformation from source to operational behavior, test and evidence. [5] [6] [7] [8]
Darko Pavic’s four-layer model for machine-readable compliance
| Layer | What it contains | What it enables |
| Layer 1 – Addressable law | Stable identifiers, authoritative location, jurisdiction, version and metadata. | A machine can reliably find and identify the correct source. |
| Layer 2 – Structured legal content | Document structure, provisions, references, tables, definitions and amendments. | A machine can parse and navigate the legal material. |
| Layer 3 – Formal or computable rules | Actors, modalities, conditions, exceptions, temporal logic, calculations and relationships. | A machine can reason about or execute clearly formalized parts of the rule. |
| Layer 4 – Operational compliance package | Validated interpretation, business applicability, required system behavior, tests, escalation, evidence and change impact. | A retailer, software product or AI agent can apply the rule safely in a defined operational context. |
The Compliance Compiler is primarily concerned with the transformation into Layer 4 while preserving traceability to Layers 1 to 3. It does not replace legal publication standards or formal legal languages. It turns them, together with validated domain interpretation, into operational compliance infrastructure.
Why giving an AI access to legal documents is not enough
Legal obligations are often distributed across laws, secondary regulations, authority guidance, technical specifications, schemas, certification instructions, FAQs and implementation notices. These materials can have different legal status, publication dates and effective dates. They may be amended, superseded, translated or subject to transitional arrangements. A retrieval system can find documents, but retrieval alone cannot decide which interpretation is approved for a particular business context.
Operational systems need answers that legal prose may not express in one sentence: which actor carries the obligation; which event activates it; which data is required; which sequence must be respected; what happens when a service is unavailable; which exceptions are permitted; when a rule becomes mandatory; and what evidence must be retained. These are interpretive and engineering transformations, not merely search tasks.
Academic work has shown both the promise and the difficulty of formalizing law. Logic-program representations, LegalRuleML and the Catala language demonstrate that clearly defined legal computations can be formalized. They also show why collaboration between legal and technical specialists, explicit treatment of exceptions and careful validation are indispensable. [13] [14] [15] [16] [17] [18]
The Autonomy-Control Principle
| Darko Pavic’s Autonomy-Control Principle The more freedom an AI system has to decide how a regulated task is executed, the more independent and explicit the governing compliance layer must become. The executing AI may optimize the route to the objective, but it must not improvise the obligations, prohibitions, permissions or evidence requirements that define a legally valid outcome. |
The principle resolves a common misconception about AI-native systems. Greater intelligence does not remove the need for rules. It makes the boundary between execution and authority more important. A fixed application constrains behavior through code written in advance. An autonomous system can reorganize steps and create temporary execution logic. The rule layer must therefore become more explicit precisely because the execution layer becomes more flexible.
What the Compliance Compiler includes – and what it does not
| Scope | Explanation |
| Includes | Authoritative source capture; source status; exact provision; jurisdiction; publication and effective dates; validated interpretation; actors; obligations, permissions and prohibitions; applicability; exceptions; temporal validity; required data and behavior; tests; evidence; version history; review status; uncertainty and escalation. |
| May produce | Impact analyses, structured requirements, decision tables, acceptance criteria, validation constraints, test cases, evidence templates and machine-consumable compliance packages. The precise outputs depend on the consumer and implementation context. |
| Does not replace | Legislators, courts, tax authorities, qualified legal judgment, product architecture, security engineering, operational responsibility or formal certification where certification is legally required. |
| Is not | A chatbot, a legal search engine, a PDF library, a general knowledge graph, a simple rules engine, an LLM prompt collection or a claim that every legal provision can be fully automated. |
| Public scope of this article | The conceptual lifecycle, governance principles and strategic role. Proprietary implementation details, internal data models, algorithms, technology stack, prompts, pipelines, validation operations and commercial roadmap are intentionally excluded. |
How compliance compilation works
Compliance compilation is a controlled chain of transformations. Each stage adds meaning or control while preserving a link to the preceding stage. The model below explains the lifecycle.
| Transformation stage | Purpose |
| 1. Authoritative source | Capture the law, regulation, guidance or technical specification with jurisdiction, status, language, publication date, effective date, version and integrity information. |
| 2. Relevant provision | Identify the clauses, definitions, tables, schemas and notices that create or modify an obligation, permission, prohibition, exception or deadline. |
| 3. Validated interpretation | Explain the meaning for a defined operational context and distinguish official text, verified fact, approved professional interpretation, recommendation and unresolved question. |
| 4. Obligation and applicability | Represent who must do what, when the rule applies, which conditions activate it, which exceptions override it and which rule has priority. |
| 5. Implementation requirement | Translate the obligation into required data, events, sequence, validation, security, documents, reporting, storage, error handling, offline behavior and operational controls. |
| 6. Rule and test | Express the behavior in a form that can be checked and generate positive, negative, boundary, exception and failure-scenario tests. |
| 7. Evidence and change impact | Record approval, rule version, implementation mapping, test result and responsible roles; identify dependent rules, products and deployments when a source changes. |
| Transformation chain Authoritative source -> provision -> validated interpretation -> obligation and applicability -> implementation requirement -> executable rule and test -> evidence |
The rule object must carry context, not only a sentence
A legally useful machine-readable rule is a governed object. At minimum, the object must identify the jurisdiction and competent authority, the exact authoritative source, the actor carrying the duty, the regulated event, the modality of the rule, applicability conditions, exceptions, temporal validity, required data and behavior, evidence obligations, interpretation status, validation status and the level of judgment required.
- Authority and provenance: source, provision, source language, publication status, version, reviewer and approval history.
- Normative meaning: obligation, permission or prohibition; responsible actor; regulated action or event.
- Applicability: country, legal entity, channel, transaction type, customer type, payment method, product category, threshold, device or business model.
- Time: publication, entry into force, mandatory date, transition period, expiry and supersession.
- Operational behavior: data, calculations, identifiers, signatures, sequence, timing, communications, documents, storage and failure behavior.
- Evidence: what must be recorded, retained, reported or made auditable.
- Knowledge status: official requirement, verified fact, approved interpretation, implementation recommendation or unresolved issue.
- Automation class: deterministic, interpreted but operationalizable, or judgment-based and requiring escalation.
Not every rule should be automated in the same way
| Class | Typical characteristics | Required control |
| Deterministic rules | Clear fields, formats, thresholds, dates, sequences, certificate validity, mathematical calculations or defined transaction states. | Can often be executed and tested automatically after the legal basis has been validated. |
| Interpreted but operationalizable rules | Rules whose application to a business scenario requires an approved legal and technical interpretation. | May be automated only after the interpretation, assumptions and applicability conditions have been approved and versioned. |
| Judgment-based rules | Ambiguity, proportionality, conflicting guidance, novel business models or unresolved authority practice. | Must remain subject to qualified human judgment. The system should abstain or escalate rather than create a false sense of certainty. |
A system that refuses to act when the rule is missing, disputed or outside its approved scope is not failing. In compliance, controlled abstention is a successful safety function. – Darko Pavic
The Compliance Execution Contract
A user prompt is not sufficient to govern a regulated task. In an AI-native environment, the request should be transformed into a Compliance Execution Contract containing four elements: the business objective, the facts that determine applicability, the authority delegated to the AI and the validated compliance package that constrains the action.
| Contract element | Function |
| Business objective | The result requested by the user or system, such as completing a sale, issuing a refund or creating a report. |
| Business context | The facts needed to apply the rule: jurisdiction, entity, channel, transaction state, customer, product, payment, original document, connectivity and time. |
| Authority model | What the AI may access, decide, communicate and execute; which approvals or identities are required. |
| Compliance package | Applicable obligations, prohibitions, permissions, exceptions, tests, evidence and escalation conditions. |
The AI remains free to organize execution efficiently inside the contract. Missing mandatory information, conflicting validated rules or an unapproved interpretation must stop the process or trigger expert review.
Impact on retail and POS systems
Retail is one of the clearest domains in which the difference between legal information and operational compliance becomes visible. A rule may have to control the transaction path in real time, survive network failure, interact with payments and inventory, create a legally defined document, communicate with a tax authority and produce evidence that remains understandable years later.
| Area | Compliance Compiler relevance |
| Checkout process | Determine whether a transaction may proceed, which fiscal event is triggered and which completion or fallback conditions apply. |
| Receipts and documents | Define mandatory content, identifiers, signatures, references, format, language and delivery conditions. |
| Transaction and master data | Specify required fields, semantic meaning, product or tax classifications, customer status and legal-entity context. |
| Integrations | Coordinate POS, e-commerce, ERP, payment, fiscal services, e-invoicing, identity and tax-authority interfaces without losing responsibility boundaries. |
| Security | Apply certificates, keys, signatures, access controls, integrity checks and evidence protection where required. |
| Availability and offline operation | Define when offline execution is permitted, what evidence must be created, how transactions are queued and what happens after reconnection. |
| Corrections and cancellations | Preserve links to original transactions, permitted state transitions, sequence and reporting obligations. |
| Reporting and storage | Define recipient, timing, schema, retention, audit export and reconciliation requirements. |
| International rollout | Separate reusable compliance knowledge from product-specific implementation and identify where country models require different architecture. |
| Retailer-vendor responsibility | Make explicit who interprets, implements, validates, operates, monitors and preserves evidence for each obligation. |
Hypothetical example: online reporting with an offline exception
Assume that a jurisdiction requires a qualifying B2C transaction to be reported before completion but permits offline processing when the authority service is unavailable. The applicable requirements may be spread across law, technical specifications and implementation guidance. A Compliance Compiler would separate and connect the relevant elements: scope of the transaction, event triggering the obligation, mandatory payload, response handling, timeout, valid offline condition, local evidence, receipt marking, queue order, retry behavior and reconciliation after reconnection.
The same package could generate tests for successful reporting, unavailable service, invalid certificate, delayed response, duplicate submission, out-of-sequence transactions and failed retry. The example is hypothetical; it illustrates the transformation method and is not a statement of law for a particular jurisdiction.
Comparison with adjacent concepts
| Concept | Primary purpose | Critical distinction |
| Legal document repository | Provides access to laws, guidance and specifications. | Does not by itself validate applicability or translate the source into system behavior and tests. |
| Legal XML / structured legislation | Makes document structure and metadata machine-processable. | Does not by itself provide an approved operational interpretation. |
| Knowledge graph or retrieval system | Connects concepts and retrieves relevant material. | Retrieval may support research but does not guarantee an authoritative, deterministic compliance output. |
| Rules engine | Executes rules already expressed in a supported formalism. | Does not establish that the rule is legally correct, current, applicable or properly governed. |
| RegTech application | Automates a defined compliance use case within a product boundary. | Usually remains a specialized application; it may not provide a reusable law-to-test-to-evidence layer across systems. |
| Compliance Compiler | Transforms sources and validated interpretation into governed operational rules, tests, evidence and change impact. | Does not replace legal authority, expert judgment, application design or certification obligations. |
Machine-readable law, fiscalization and e-invoicing are related but not identical
Fiscalization governs how retail transactions are created, secured, recorded, reported or evidenced under country-specific rules. E-invoicing focuses on the structured exchange, validation, clearance or reporting of invoice data. Machine-readable law is the representation layer through which relevant obligations can become usable by systems. The Compliance Compiler is the transformation and governance mechanism that connects authoritative requirements to system behavior across these domains. [11] [12] [21] [22] [24]
International and regulatory variation
The form of machine-readable compliance will vary by legal system, regulatory model and technical architecture. Some authorities publish structured schemas, validation rules or rule files. Others publish prose requirements and separate technical documents. Some obligations operate in real time at transaction completion; others apply through periodic reporting, invoice exchange, certification or audit.
| Model or example | What exists | Practical implication |
| European legal-information infrastructure | ELI and Akoma Ntoso improve identification, metadata and document structure. | They strengthen source accessibility and interoperability but do not remove the need for operational interpretation. |
| Formal legal-rule representation | LegalRuleML supports legal norms, temporal features, jurisdiction and provenance-related concepts. | It can support the rule layer, but enterprise applicability, tests, evidence and lifecycle governance still have to be built around it. |
| Swedish tax-rule publication | The OECD reports that the Swedish Tax Agency creates rule-based machine-readable files and written specifications supplied as open data. [26] | A practical example of government rules becoming directly usable by business systems and rule engines. |
| European e-invoicing | EN 16931 defines a semantic data model and business rules; Peppol provides an implementation specification and validation constraints. | Demonstrates that interoperability requires more than a document format: semantics and validation rules matter. |
| Retail fiscalization | Countries may require online reporting, local devices, signatures, secure elements, sequences, certification or combinations of these. | A global Compliance Compiler must represent architectural variation rather than force every jurisdiction into one implementation model. |
The Swedish example and European e-invoicing standards show that parts of the desired future already exist. They should be treated as evidence of direction, not as proof that legislation has become universally executable. [3] [4] [5] [6] [7] [11] [12] [26]
Governance, provenance and evidence are part of the product
A machine-readable rule is useful only when its authority can be demonstrated. A retailer, software provider, auditor, regulator or AI system should be able to determine which source supports the rule, which provision was interpreted, who approved the interpretation, which version applied, which assumptions were used and which implementation or execution result was tested against it.
The knowledge model must keep official law, authority guidance, verified fact, internal interpretation, implementation recommendation and unresolved question visibly separate. It must preserve original language, translations, effective dates and superseded versions. Provenance standards such as W3C PROV-O offer useful building blocks, but governance responsibilities and approval criteria remain domain-specific. [8]
Evidence completes the lifecycle. Every regulated execution should be able to record the objective, relevant context, rule versions, decisions, actions, test or validation result and responsible system or person. The evidence must explain not only what happened but why the action was allowed and which rule required it.
Strategic relevance for stakeholders
| Stakeholder | Strategic relevance |
| Retailers | Create a reusable compliance capability that is less dependent on one POS product or country project; improve change impact, testing, auditability and future control of autonomous systems. |
| POS, ERP and software providers | Consume structured requirements, identify affected processes, generate acceptance criteria and regression tests, and govern future software agents. |
| E-commerce and payment providers | Clarify transaction context, delegated authority, cross-system sequence and evidence at the point where commercial and regulatory processes meet. |
| Tax and compliance teams | Make interpretations explicit, versioned and connected to operational scenarios instead of leaving knowledge dispersed across documents and correspondence. |
| Regulators | Potentially publish more structured rule material, improve consistency of implementation and receive clearer evidence, while retaining legal authority and oversight. |
| Universities and researchers | Study a multidisciplinary field combining legal informatics, compiler design, knowledge representation, formal verification, AI governance, software engineering and retail technology. |
| Investors and technology markets | Evaluate infrastructure whose defensibility comes from validated knowledge, domain depth, provenance, maintenance and trusted rule networks rather than application code alone. |
Common misconceptions
Misconception 1: Machine-readable law is a PDF that an AI can search.
A searchable document improves access but does not encode applicability, exceptions, approved interpretation, system behavior or evidence.
Misconception 2: Retrieval-augmented generation makes an LLM legally reliable.
Retrieval can reduce unsupported output, but the model can still select the wrong version, miss an exception or generate an unapproved interpretation. The validated rule must remain external to the generative model.
Misconception 3: A rules engine is already a Compliance Compiler.
A rules engine executes rules that have already been formalized. A Compliance Compiler governs how the authoritative source becomes a validated operational rule and how the result is tested, versioned and evidenced.
Misconception 4: Every legal rule can be made deterministic.
Some provisions contain ambiguity, proportionality or unresolved practice. A trustworthy system represents uncertainty and escalates rather than hiding judgment behind code.
Misconception 5: AI autonomy reduces the need for compliance software.
It may reduce the need for fixed applications, but it increases the need for external constraints, provenance and audit evidence.
Misconception 6: One global rule model eliminates country differences.
A common meta-model can improve reuse, but jurisdictions differ in legal authority, transaction timing, technical mechanisms, certification, devices, reporting and failure behavior.
Misconception 7: Formalization automatically creates legal authority.
A machine-readable representation is an interpretation or implementation artifact unless an authorized institution gives it official status. Provenance and status must be explicit.
Darko Pavic’s perspective
Based on my experience in international retail technology, the difficult part of compliance has never been only access to the law. The difficult part is the chain between the law and the live transaction: deciding what the requirement means for a business model, locating the right responsibility in the architecture, implementing it consistently, testing the exceptions and proving later that the correct rule was applied.
My view of the future software industry starts with a simple observation. Software exists because computers have traditionally needed a predefined application for each task. As AI becomes capable of understanding an objective, selecting methods and performing more of the task directly, the fixed application can lose its role as the central product. The regulated rule does not lose its role. It becomes more important because the execution method is no longer permanently constrained by application code.
I therefore distinguish between software logic and legal authority. Software logic may be generated, replaced or reorganized. Legal authority must be preserved through validated sources, explicit interpretation, applicability, versioning and evidence. The Compliance Compiler is my name for the infrastructure that maintains this distinction.
The most immediate opportunity is not to wait for software to disappear. It is to reduce the repeated manual translation of the same regulation into different requirements, products and country projects. The long-term opportunity is to create the control layer for AI-native execution. The same validated knowledge objects can serve both worlds.
My working prediction is that competitive advantage in compliance technology will move from owning the largest application toward owning the most reliable, maintained and auditable representation of obligations and their operational consequences. General AI can make execution more abundant. It cannot create legal authority. Trusted domain knowledge, provenance, validation and evidence become the scarce assets.
Implementation considerations for retailers and software providers
The following questions are a strategic and technical checklist, not legal advice. The correct answers depend on the jurisdiction, business model, system architecture and legal interpretation.
Legal scope and authority
- Which sources are legally binding, which are authority guidance, and which are technical specifications or professional interpretations?
- How are publication, entry into force, mandatory dates, transitions, expiry and supersession represented?
- Who approves the interpretation and who may change it?
Applicability and data
- Which business facts determine whether the rule applies?
- Are data meanings consistent across POS, e-commerce, ERP, payment and reporting systems?
- How are missing, contradictory or low-confidence facts handled?
Architecture and integrations
- Where must the control operate: transaction path, back office, fiscal middleware, e-invoicing layer or several locations?
- Which responsibilities belong to the retailer, platform, software vendor, payment provider or local fiscal service?
- Can the same rule package be mapped to different product architectures without changing its legal meaning?
Availability and offline operation
- Which external services are required and what legally valid fallback exists?
- How are queue order, retries, duplicates, timeouts and reconnection handled?
- What local evidence must be created while a central service is unavailable?
Validation and testing
- Which positive, negative, boundary, transition, exception and failure cases are required?
- Can each expected result be traced to an approved rule and source?
- How are regression tests triggered when a provision or interpretation changes?
Governance and evidence
- Can an auditor reconstruct the source, interpretation, rule version, implementation mapping and test result?
- How are official requirements separated from recommendations and unresolved questions?
- What events require human escalation or controlled abstention?
AI controls
- Is the generative model being used for research and drafting, or is its output becoming a legally consequential action?
- Which rule layer is external to the model, and can the model override it?
- How are delegated authority, identity, logging, monitoring and incident response governed?
Related work by Darko Pavic
| Work | Why it is relevant | URL |
| Can LLMs Be Trusted in Compliance? | Explains why fluent generative output is not a safe direct source of tax and compliance decisions. | https://darkopavic.xyz/the-compliance-risk-ai-cannot-talk-its-way-out-of/ |
| Before AI Hype, There Was Logic | Connects rule-based program analysis with the current compliance-intelligence research direction. | https://darkopavic.xyz/before-ai-hype-there-was-logic/ |
| What Is POS Compliance? | Defines the transaction, evidence, availability and governance layers that machine-readable compliance must control. | https://darkopavic.xyz/what-is-pos-compliance/ |
| What Is Fiscalization? | Provides the core legal and system context for retail transaction compliance. | https://darkopavic.xyz/what-is-fiscalization/ |
| Compliance Maturity Model | Explains the organizational and architectural maturity required to turn fiscalization into a managed capability. | https://darkopavic.xyz/compliance-maturity-model/ |
| E-Invoicing Is Not a POS Fiscalization Problem | Clarifies why different compliance domains may require different system placement even when their rule knowledge is connected. | https://darkopavic.xyz/e-invoicing-is-not-a-pos-fiscalization-problem/ |
| Compliance Intelligence Library | Permanent hub for this page, future papers, models, talks and supporting resources. | https://darkopavic.xyz/compliance-intelligence-library/ |
Frequently asked questions
What is the simplest definition of a Compliance Compiler?
A Compliance Compiler is a governed system that transforms authoritative regulation and validated interpretation into operational rules, tests and evidence requirements for software or AI.
Is a Compliance Compiler the same as Rules as Code?
No. Rules as Code is a broader field concerned with producing machine-consumable rules. Compliance compilation focuses on the controlled enterprise transformation from legal source to applicability, system behavior, validation, evidence and change impact.
Does machine-readable law have official legal status?
Not automatically. Legal status depends on the issuing authority and jurisdiction. A private machine-readable representation is normally an interpretation or implementation artifact unless an authorized institution makes it official.
Can an LLM act as a Compliance Compiler?
An LLM can assist with extraction, comparison, drafting and classification, but a trustworthy Compliance Compiler requires external validation, provenance, version control, deterministic checks, governance and escalation. The generative model must not be the sole authority for a legally consequential output.
Will the Compliance Compiler replace POS or fiscalization software now?
No. Its immediate role is to support existing applications with structured requirements, tests and evidence. The longer-term thesis is that the same rule layer can govern autonomous AI if fixed applications become less central.
Can every regulation be converted into executable rules?
No. Deterministic provisions are the strongest candidates. Ambiguous, proportional or disputed rules require approved interpretation or continuing human judgment.
Why is retail a good starting domain?
Retail combines high transaction volume, real-time legal controls, country-specific fiscalization, structured documents, offline requirements, multiple integrations and demanding audit evidence. It exposes weaknesses that a simpler demonstration may hide.
What should regulators publish?
At minimum, regulators can improve stable identifiers, metadata, consolidated versions, structured data models, validation rules and change information. Where appropriate, they can publish machine-consumable rules alongside human-readable law while preserving legal authority and transparency.
Conclusion: when software changes, the rules remain
The software industry was built around applications that encoded a predefined method for performing a task. AI is beginning to separate the objective from the application: a system can increasingly choose tools, organize the workflow and generate execution logic dynamically. In regulated activity, that flexibility creates a new architectural necessity. The rules governing the outcome must be more explicit, not less.
Machine-readable law is the foundation, but machine readability alone is insufficient. A regulated system needs authoritative provenance, validated interpretation, applicability, exceptions, temporal validity, implementation behavior, tests, evidence and controlled change. Compliance compilation is the discipline that connects those elements. The Compliance Compiler is the infrastructure that makes the discipline operational.
Today, the Compliance Compiler can reduce the uncertainty between regulation and existing software. Tomorrow, it can provide autonomous AI with the boundaries inside which it is allowed to act. Its strategic importance therefore does not depend on predicting the exact moment when software changes. It comes from preserving legal authority while execution becomes increasingly dynamic.
Prefer to read offline? Download the complete companion vision paper as a PDF.
Sources and further reading
The following sources were consulted in preparing this article. Official publications, technical standards, academic research and the author’s professional interpretations have been distinguished wherever their status materially affects the analysis.
Official and public-sector research
[1] Jonathan Mohun and Alex Roberts / OECD. Cracking the Code: Rulemaking for Humans and Machines. 2020. DOI: 10.1787/3afe6ba5-en. Relevance: Foundational public-sector study of Rules as Code, including the distinction between human-readable, machine-readable and machine-consumable rules and the need to preserve policy intent through digital implementation.
[2] New Zealand Digital Government. Better Rules for Government Discovery Report. 2018. Relevance: Early government framework for producing rules that are simultaneously usable by people and machines through multidisciplinary rule design and traceability.
[3] OECD. Tax Administration 2024: Comparative Information on OECD and Other Advanced and Emerging Economies. 2024. DOI: 10.1787/2d5fba9c-en. Relevance: Documents tax-administration use of machine-readable tax rules, including the Swedish Tax Agency example of rule-based files supplied as open data for use with rule engines.
[4] OECD. Tax Administration Digitalisation and Digital Transformation Initiatives. 2025. DOI: 10.1787/c076d776-en. Relevance: Provides current comparative material on machine-readable tax law, tax rule management and the embedding of tax services in taxpayers’ natural systems.
Legal-information standards
[5] European Union / EUR-Lex. European Legislation Identifier (ELI): What is ELI?. Current register page, consulted 24 July 2026. Relevance: Authoritative description of the European standard for identifying and describing legislation so it can be understood and reused by humans and machines.
[6] OASIS Open. Akoma Ntoso Version 1.0. Approved 29 August 2018. Relevance: International standard for structured parliamentary, legislative and judicial documents.
[7] OASIS Open. LegalRuleML Core Specification Version 1.0. OASIS Standard, 30 August 2021. Relevance: Formal rule representation standard designed for legal norms, including deontic, temporal, jurisdictional and provenance-related features.
Data and provenance standards
[8] World Wide Web Consortium (W3C). PROV-O: The PROV Ontology. W3C Recommendation, 30 April 2013. Relevance: Provides a standard ontology for representing and exchanging provenance, a central requirement for tracing a compliance rule back to its sources and transformations.
AI governance and risk
[9] National Institute of Standards and Technology (NIST). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. 2024. DOI: 10.6028/NIST.AI.600-1. Relevance: Recognized framework for generative-AI risk, including the governance, documentation and evaluation disciplines relevant to compliance-critical AI.
[10] ISO/IEC. ISO/IEC 42001:2023 – Artificial Intelligence Management System. 2023. Relevance: International management-system standard for responsible development, provision and use of AI systems.
Operational compliance standards
[11] European Commission. Navigating the European eInvoicing Standard Documentation (EN 16931). Current documentation page, consulted 24 July 2026. Relevance: Shows how a legal and policy objective can be operationalized through a semantic data model, business terms and validation rules.
[12] OpenPeppol. Peppol BIS Billing 3.0. Current specification, consulted 24 July 2026. Relevance: A practical implementation specification based on EN 16931, illustrating how semantic requirements and validation constraints become interoperable system behavior.
Academic research
[13] M. J. Sergot, F. Sadri, R. A. Kowalski, F. Kriwaczek, P. Hammond and H. T. Cory. The British Nationality Act as a Logic Program. 1986. DOI: 10.1145/5689.5920. Relevance: Seminal demonstration that parts of legislation can be represented as logic programs, while also exposing the interpretive challenges of formalizing legal text.
[14] Tara Athan, Guido Governatori, Monica Palmirani, Adrian Paschke and Adam Wyner. LegalRuleML: Design Principles and Foundations. 2015. DOI: 10.1007/978-3-319-21768-0_6. Relevance: Explains the design principles of a formal language for norms and legal reasoning.
[15] Denis Merigoux, Nicolas Chataing and Jonathan Protzenko. Catala: A Programming Language for the Law. 2021. DOI: 10.1145/3473582. Relevance: Introduces a domain-specific language for translating algorithmic statutory provisions into executable specifications shared by lawyers and programmers.
[16] James Grimmelmann. Programming Languages and Law: A Research Agenda. 2022. DOI: 10.1145/3511265.3550447. Relevance: Positions programming-language concepts as a substantial research agenda for law and identifies the distinct questions created by formalizing legal rules.
[17] Livio Robaldo and co-authors. Compliance checking on first-order knowledge with conflicting and compensatory norms: a comparison among currently available technologies. 2024. DOI: 10.1007/s10506-023-09360-z. Relevance: Examines formal compliance checking where norms can conflict or compensate for one another, highlighting why operational compliance cannot be reduced to simple field validation.
[18] Enrico Francesconi and co-authors. Patterns for legal compliance checking in a decidable framework of linked open data. 2022. DOI: 10.1007/s10506-022-09317-8. Relevance: Research on compliance-checking patterns that combine linked data and decidable formal reasoning.
Darko Pavic’s related work
[19] Darko Pavic. Can LLMs Be Trusted in Compliance?. 14 July 2026. Relevance: Sets out the reliability boundary between generative language models and legally consequential compliance outputs.
[20] Darko Pavic. Before AI Hype, There Was Logic. 10 July 2026. Relevance: Connects Darko Pavic’s 2001 work on rule-based static analysis with his current research direction in compliance intelligence.
[21] Darko Pavic. What Is POS Compliance? Requirements for Retail Systems. 2026. Relevance: Defines the transaction-level systems, evidence and operational controls that machine-readable compliance must ultimately govern in retail.
[22] Darko Pavic. What Is Fiscalization?. 2026. Relevance: Provides the substantive fiscalization context for the Compliance Compiler concept.
[23] Darko Pavic. What Is a Compliance Maturity Model? The Four-Level Fiscalization Framework. 2026. Relevance: Provides the governance and organizational maturity context within which machine-readable compliance would be adopted.
[24] Darko Pavic. E-Invoicing Is Not a POS Fiscalization Problem. 1 July 2026. Relevance: Clarifies the architectural distinction between transaction-path fiscal controls and structured B2B invoice exchange.
[25] Darko Pavic. Compliance Intelligence Library. Current resource hub, consulted 24 July 2026. Relevance: Permanent hub for related concepts, frameworks and future research publications.
Others
[26] Swedish Tax Agency, rule-based machine-readable files and written specifications supplied as open data
Editorial methodology and publication information
How this page was prepared
This page combines official public-sector research, government and regulatory infrastructure, international technical standards, peer-reviewed academic research, recognized AI-governance frameworks and Darko Pavic’s supplied professional analysis. Official requirements and standards are distinguished from industry implementation examples and from the author’s strategic interpretation.
AI supported research organization and drafting. The article and its interpretations were substantively reviewed and approved by Darko Pavic before publication.
Publication and review information
| Field | Value |
| Prepared | 24 July 2026 |
| First published | 24 July 2026 |
| Last substantively reviewed | 24 July 2026 |
| Author | Darko Pavic |
| Author profile | https://darkopavic.xyz/about/ |
| Editorial status | published |
| Legal status | Expert analysis; not legal advice or an official interpretation by a regulator |
Suggested website citation
Pavic, Darko. “Compliance Compiler and Machine-Readable Law: The Control Layer for AI-Native Software” DarkoPavic.xyz. First published 24 July 2026. Last substantively reviewed 24 July 2026. https://darkopavic.xyz/compliance-compiler-and-machine-readable-law/
Suggested citation for the companion vision article
Pavić, Darko. “When AI Replaces Software, Machine-Readable Law Becomes the Operating System.” Vision article, Version 1.0, July 2026.
Author bio
Darko Pavic is the founder of Fiscal Solutions and a retail technology and fiscalization specialist with more than 28 years of experience in international POS systems, software architecture and compliance-critical retail processes. His work focuses on fiscalization, POS compliance, e-invoicing, compliance intelligence and the use of AI in regulated systems. His earlier academic work addressed rule-based components for error detection in static program analysis, a foundation he now connects with machine-readable regulation and the Compliance Compiler concept.
Newsletter
| Follow the development of machine-readable compliance Subscribe to Future of the High Street for continuing analysis of AI-native software, fiscalization, POS compliance, e-invoicing and the emerging rule infrastructure required for autonomous retail systems. |
Subscription link: darkopavic.substack.com/subscribe