Compliance as a Compiler: Kryxis on Synthesizing Fragmented Directives into Executable Code

Every compliance team we talk to describes the same frustration: regulatory directives arrive as a mess of PDFs, emails, spreadsheets, and JSON feeds — each structured differently, often with overlapping or contradictory requirements. The manual work of reading, interpreting, and translating these fragments into internal policies is slow, error-prone, and unsustainable as the number of regulations grows. But what if we treated this problem like a compiler? Just as a software compiler takes source code written in multiple files and languages, resolves dependencies, and produces executable output, a compliance compiler ingests fragmented directives and synthesizes them into unified, enforceable rules. This guide is for compliance architects, data engineers, and regulatory operations leads who already understand the basics and need a practical framework for building such a system — including when it's the wrong choice.

Where This Problem Shows Up in Real Work

The need for a compliance compiler emerges most clearly in organizations that operate across multiple jurisdictions with overlapping regulatory regimes. Consider a financial services firm handling transactions in the EU, UK, US, and Singapore. Each market has its own data protection, anti-money laundering, and reporting requirements. A single transaction might trigger obligations under GDPR, PSD2, the UK Financial Conduct Authority rules, the US Bank Secrecy Act, and Singapore's Payment Services Act — each with different definitions, thresholds, and deadlines.

Manual mapping is the default approach, but it breaks down quickly. One compliance officer we spoke with described maintaining a spreadsheet with over 2,000 rows mapping individual requirements to internal controls. The spreadsheet grew by 15% each quarter, and reconciliation between quarterly updates was a two-week project that delayed policy deployment. Another team tried a rules engine with hand-coded logic for each regulation, but they found that even small changes in one directive required updating dozens of rules, and the interdependencies were impossible to track manually.

The core problem is that regulatory directives are not written as structured data. They embed conditions in natural language, reference other documents, and use terms that differ across jurisdictions. A compliance compiler addresses this by establishing a formal pipeline: parse each directive into a structured intermediate representation, resolve conflicts and dependencies, and then generate executable rules in a target format (e.g., Drools, OPA, or custom policy engines).

This pattern shows up in three common scenarios: (1) multi-jurisdiction financial services, where real-time transaction screening requires rules from dozens of regulators; (2) healthcare data governance, where HIPAA, GDPR, and local laws intersect; and (3) supply chain compliance, where export controls, sanctions lists, and environmental regulations must be checked simultaneously at each node. In each case, the volume and velocity of regulatory change make manual synthesis infeasible.

What a Compliance Compiler Is Not

It's important to distinguish this from simpler approaches. A compliance compiler is not a document management system that stores PDFs with search tags. It is not a checklist generator that extracts action items from a single regulation. And it is not a rules engine that requires every rule to be hand-written by a subject matter expert. Instead, it is a transformation pipeline that turns regulatory source code (directives) into machine-readable policies through formal parsing, semantic resolution, and code generation.

Foundations Readers Often Confuse

When teams first approach compliance compilation, they tend to conflate several distinct concepts. The most common confusion is between parsing and interpretation. Parsing is the mechanical process of converting a document's text into a structured data model — extracting conditions, obligations, and definitions. Interpretation, on the other hand, requires understanding the intent, resolving ambiguities, and making judgment calls. Many teams invest heavily in natural language processing (NLP) for parsing but neglect the interpretation layer, leading to compiled rules that are syntactically correct but semantically wrong.

Another frequent mistake is treating all regulatory sources as equal. In practice, directives come with different authority levels: primary legislation, regulatory guidance, industry standards, and internal policies. A compliance compiler must model these hierarchies and precedence rules. For example, a GDPR provision about consent might be overridden by a more specific national law in Germany, but only if that law is properly enacted. Hard-coding such relationships is brittle; the compiler should allow declarative precedence rules that can be updated without changing the parsing logic.

Resolution Strategies: Union vs. Intersection vs. Priority

When two directives conflict, teams often default to one of three strategies without considering the trade-offs. The union approach applies the strictest requirement from any applicable directive — safe but often over-restrictive. The intersection approach applies only requirements common to all directives — permissive but may miss obligations. The priority approach uses a predefined hierarchy to decide which directive wins — flexible but requires careful maintenance of the priority list. A well-designed compiler should support all three and allow different strategies per domain or conflict type, configurable at compile time.

The Role of Intermediate Representations

Just as compilers use abstract syntax trees (ASTs) and intermediate representations (IRs), a compliance compiler benefits from a domain-specific intermediate representation. This IR captures regulatory concepts (obligations, conditions, exceptions, definitions) in a structured format that is independent of both the source directive format and the target policy engine. Teams often skip this step and try to map directly from PDF to Drools rules, which creates tight coupling and makes it hard to add new regulators or change policy engines. A good IR can be expressed in a format like JSON Schema or RDF, with a well-defined ontology for compliance concepts.

Patterns That Usually Work

From observing several teams that have built successful compliance compilers, a few patterns emerge consistently.

Pattern 1: Modular Parsers with a Shared IR

Instead of building one monolithic parser for all regulation types, create separate parser modules for each source format (PDF, HTML, XML, JSON) and each regulator's style. Each module outputs to the same intermediate representation. This allows incremental development — you can start with one regulator and add others without touching existing parsers. One team we studied began with just GDPR and the UK's Data Protection Act, then added CCPA and LGPD over six months by writing new parsers that fed into the same IR.

Pattern 2: Declarative Conflict Resolution Tables

Rather than coding conflict-resolution logic in a programming language, maintain a table of conflict rules that the compiler reads at runtime. Each rule specifies a condition (e.g., directive A and directive B both define a retention period) and an action (e.g., use the longer period, or use A's period unless B's is stricter). This table can be maintained by compliance analysts without developer involvement, and it makes the resolution logic transparent and auditable.

Pattern 3: Versioned Compilation with Diff Output

Regulations change frequently, and re-compiling from scratch every time is wasteful and risky. Instead, treat each compilation as a versioned artifact. When a directive updates, the compiler can do an incremental re-compile, producing a diff of the generated rules. This diff can be reviewed and tested before deployment. One team uses Git-like versioning for their IR and generated rules, making it easy to roll back if a new regulation introduces errors.

Pattern 4: Human-in-the-Loop for Ambiguity

No parser can resolve every ambiguity automatically. The best compilers flag ambiguous or unresolvable constructs and escalate them to a human analyst via a structured interface. The analyst can then provide an interpretation that gets recorded as a resolution precedent, which the compiler can apply automatically in future similar cases. Over time, the system becomes more autonomous as the resolution database grows.

Anti-Patterns and Why Teams Revert

Despite the promise of compliance compilers, many teams abandon the approach after initial investment. The most common reasons are anti-patterns that seem reasonable at first but create long-term pain.

Over-Automation of Ambiguity

Teams that try to resolve every ambiguity automatically end up with a system that makes incorrect assumptions silently. For example, if two directives define 'consent' slightly differently, an automated system might pick one definition arbitrarily, leading to compliance gaps. The better approach is to flag such conflicts and require human resolution. Teams that skip this step usually discover the problem during an audit and lose confidence in the entire system.

Ignoring Regulatory Context

Regulatory directives are not just sets of rules; they include recitals, guidance, and enforcement history that inform interpretation. A compiler that only parses the operative provisions misses crucial context. For instance, GDPR Article 6 lists lawful bases for processing, but the recitals explain how to apply them in specific scenarios. Teams that ignore recitals often produce rules that are technically correct but fail in practice because they miss the spirit of the regulation.

Tight Coupling to a Specific Policy Engine

Some teams build their compiler to output rules directly in Drools or OPA syntax, embedding engine-specific constructs in the IR. This makes it difficult to switch engines or support multiple engines. When the engine vendor changes licensing or the team needs to deploy rules in a different environment (e.g., edge devices vs. cloud), they have to rewrite the compiler. Keeping the IR engine-agnostic avoids this lock-in.

Neglecting Testing and Validation

A compliance compiler that produces rules without a robust testing framework is dangerous. Teams often assume that if the parser works correctly, the generated rules must be correct. But semantic errors — like misinterpreting a condition or missing an exception — can only be caught by testing the compiled rules against known scenarios. One team reported that 30% of their compiled rules had subtle errors that were only caught during manual review. They now require that each compilation be validated against a test suite of edge cases before deployment.

Maintenance, Drift, and Long-Term Costs

Building a compliance compiler is a significant upfront investment, but the long-term costs are often underestimated. The most insidious cost is drift — the gradual divergence between the compiler's interpretation of regulations and the actual regulatory intent. This happens because regulations are living documents: they are amended, reinterpreted by courts, and supplemented by guidance. If the compiler's parsers and resolution tables are not updated promptly, the generated rules become stale.

Cost of Keeping Parsers Current

Each time a regulator publishes a new version of a directive, the parser for that regulator may need updates. If the format changes (e.g., from PDF to HTML), the parser might need a complete rewrite. Teams often budget for the initial build but not for ongoing parser maintenance, which can be 20-30% of the initial effort per year. One approach is to share parser maintenance across a consortium of organizations, but this introduces coordination overhead.

Resolution Table Decay

Conflict resolution tables also decay over time. A resolution that made sense two years ago may become obsolete due to new case law or regulatory guidance. Without regular review, the compiler may apply outdated precedence rules. Teams should schedule quarterly audits of the resolution table, comparing it against recent regulatory developments.

Testing Infrastructure

As the number of compiled rules grows, the test suite must grow proportionally. Maintaining a comprehensive set of test scenarios for each regulator and each conflict type is expensive. Some teams use property-based testing to generate test cases automatically, but this requires defining properties that capture regulatory intent — a non-trivial task.

Organizational Resistance

Finally, the human cost is real. Compliance analysts who are used to manual interpretation may resist a system that automates part of their work, especially if they feel their expertise is undervalued. Successful implementations involve analysts in the design of resolution tables and ambiguity escalation workflows, making them collaborators rather than bypassed experts.

When Not to Use This Approach

A compliance compiler is not a universal solution. There are clear situations where the costs outweigh the benefits, and teams should consider simpler alternatives.

When the Number of Directives Is Small and Stable

If your organization is subject to only one or two regulations that change infrequently (e.g., a local data protection law that updates once every five years), building a compiler is overkill. Manual interpretation and a simple rules engine will suffice. The upfront investment in parsing and resolution infrastructure will never pay back.

When Regulations Are Highly Context-Dependent

Some regulations require extensive human judgment because they depend on specific business context that cannot be captured in a formal model. For example, regulations that require 'reasonable' measures or 'appropriate' safeguards often leave room for interpretation based on the organization's size, industry, and risk profile. A compiler that tries to encode such open-ended concepts will produce brittle rules that may not satisfy regulators.

When the Organization Lacks the Technical Talent

Building and maintaining a compliance compiler requires a team with skills in NLP, formal language design, knowledge representation, and software engineering. If your compliance team is primarily legal experts with limited technical support, the compiler will likely fail or become a maintenance nightmare. In such cases, investing in better document management and manual workflows may be more practical.

When Regulatory Sources Are Not Available in Structured Formats

If the directives you need to compile are only available as scanned PDFs with no machine-readable structure, the cost of parsing becomes prohibitive. OCR errors and inconsistent formatting will introduce noise that undermines the compiler's output. Until regulators provide structured data (e.g., via APIs or XML), manual extraction may be unavoidable.

When the Cost of Errors Is Extremely High

In domains where a single compliance error can lead to catastrophic penalties or safety risks (e.g., pharmaceutical clinical trials, nuclear safety), the risk of compiler-induced errors may be unacceptable. Human review of every compiled rule is still necessary, and if the compiler's output is always double-checked manually, the automation benefit is diminished. In such cases, a compiler might still be used as a drafting tool, but the final decision must remain with humans.

Open Questions and FAQ

Even after years of work, several open questions remain in the compliance compiler space. This section addresses the most common ones we encounter.

How do we handle regulations that are not available in English?

Most compliance compilers are built for English-language directives, but many regulations are published in other languages. Machine translation can be used as a preprocessing step, but it introduces errors. A better approach is to build parsers for each language, using language-specific NLP models. This is expensive but more accurate. Some teams prioritize the most common languages (English, French, German, Spanish) and rely on human translation for others.

Can we use a compliance compiler for real-time enforcement?

Yes, but with caveats. The compiled rules can be deployed to a rules engine that runs in real-time (e.g., during a transaction). However, the compilation itself is not real-time — it happens offline when directives change. The latency is in the compilation process, not the rule execution. For real-time enforcement, the compiled rules must be pre-deployed and tested.

How do we audit the compiler's decisions?

Auditability is critical. Every compilation should produce an audit trail that records: (1) which versions of which directives were used, (2) which conflict resolutions were applied, (3) which ambiguities were escalated to humans, and (4) the exact generated rules. This trail should be stored in a tamper-evident log, such as an append-only database or blockchain, for regulator review.

What is the role of AI/ML in compliance compilation?

AI can assist with parsing (e.g., extracting conditions from natural language) and with suggesting conflict resolutions based on historical data. However, current models are not reliable enough to operate without human oversight, especially for high-stakes regulations. We recommend using AI as a co-pilot that flags potential issues and proposes interpretations, but always with a human in the loop for final decisions.

How do we get started?

Start small. Pick one regulation that your team knows well and that is available in a structured format (e.g., XML from an official source). Build a parser for that regulation and a minimal IR. Generate rules for a single, well-understood policy (e.g., data retention). Test the generated rules against manual interpretation. Once you have confidence in the pipeline, add a second regulation with known conflicts. Expand incrementally, and invest in testing and audit infrastructure from day one.