VII. Legal Architecture as a Layer of Enterprise Architecture

Modern organizations maintain elaborate maps of their structure. Enterprise architecture frameworks describe business units, processes, and capabilities. IT architecture describes systems, data flows, and infrastructure. These architectures are documented, version-controlled, and used for planning and impact analysis. When a business process changes, the enterprise architecture helps identify affected systems. When an IT system is modified, the architecture reveals downstream dependencies.

What is conspicuously absent from most enterprise architecture frameworks is a legal layer. Legal obligations attach to business units and information systems, but these attachments remain implicit, documented (if at all) in scattered policy documents, contracts, and compliance checklists. The corporation-as-code model enables a different approach: legal architecture as an explicit, structured layer integrated with enterprise and IT architecture.

The Enterprise Architecture Paradigm

Enterprise architecture as a discipline emerged to manage organizational complexity. Frameworks like TOGAF (The Open Group Architecture Framework) provide structured approaches for describing how an organization’s business, data, application, and technology components fit together.1 These frameworks enable understanding how changes propagate across domains, identifying redundancies, and maintaining alignment between strategy and implementation.

A well-maintained enterprise architecture answers questions like “which systems need integration when we acquire a subsidiary?” through explicit encoded relationships rather than tribal knowledge.

This paradigm is well-established in the technology domain. Organizations invest significantly in maintaining architectural documentation, employing architects who understand both business and technical concerns, and tooling that visualizes dependencies and supports impact analysis. The return on this investment comes from faster decision-making, fewer integration failures, and better alignment between strategy and execution.

Legal obligations pervade organizations but rarely appear in architectural representations. Consider a typical enterprise:

  • The human resources business unit is subject to employment law, benefits regulations, and data protection requirements.
  • The customer data system holds information subject to privacy regulations (GDPR, CCPA) and potentially industry-specific rules (HIPAA, PCI-DSS).
  • The corporate entity structure includes subsidiaries in multiple jurisdictions, each with its own corporate law, tax obligations, and reporting requirements.
  • Commercial contracts impose performance obligations, limitations of liability, and intellectual property constraints.

These legal attachments are real and consequential. A change in privacy regulation affects specific systems. A corporate restructuring triggers filings in multiple jurisdictions. A new product launch requires compliance review across multiple legal domains.

Yet these relationships are rarely modeled with the same rigor as technical dependencies. Legal obligations exist in documents (contracts, policies, regulatory summaries) rather than in structured representations. Impact analysis requires lawyers to read documents and exercise judgment rather than querying a model. The result is slower response to legal changes, higher compliance costs, and increased risk of overlooking obligations.

The maturity gap is striking. Organizations have embraced Infrastructure as Code for technical systems, GitOps for deployments, and Policy as Code for security controls.2 Yet organizational structure, governance rules, and legal obligations (arguably more consequential than infrastructure configuration) remain trapped in static documents. The tools and paradigms exist; they have simply not been applied to this domain.

A legal architecture layer would model legal obligations as structured entities with explicit relationships to business units, systems, and data. The core elements might include:

Legal Regimes: Structured representations of applicable law. A regime might describe a jurisdiction (Delaware corporate law), a regulatory domain (SEC reporting requirements), or a contractual framework (master services agreement with a key customer). Each regime specifies obligations, constraints, and compliance requirements.

Attachments: Explicit links between legal regimes and organizational elements. An attachment might state that the customer database is subject to GDPR, that the UK subsidiary is governed by Companies Act 2006, or that the sales process must comply with the terms of a distribution agreement.

Compliance States: Structured representations of the organization’s compliance posture. For each attachment, the model records whether obligations are met, what evidence supports compliance, and what actions are required.

When legal requirements change (a new regulation, an amended contract, a court decision), the legal architecture enables immediate impact analysis. Which systems are affected? Which business units bear new obligations? What compliance actions are required? The answers emerge from querying the model rather than from document review.

A useful distinction here is between what we might call legal data primitives and interpretive legal questions. Legal data primitives are deterministic facts that can be verified programmatically: “Is this entity registered in Delaware?” “Does this system process personal data?” “Has this director’s term expired?” “Does this investor have MFN rights?” These are binary questions with objective answers. Interpretive legal questions, by contrast, require judgment: “Does this conduct constitute a breach of fiduciary duty?” “Is this disclosure materially misleading?” “Does this hybrid waterfall structure qualify as American or European?”

The legal architecture approach focuses on the former while acknowledging a continuum between the two categories. At one end are purely factual checks (consent exists or it does not; a filing was made or it was not). At the other end are questions requiring substantive legal analysis. But the boundary between these categories evolves. Over time, as market practice standardizes legal language and as AI-driven tools create pressure toward consistent interpretation, more questions migrate from the interpretive toward the deterministic end of the spectrum. Unique identifiers for contract clauses, standardized term definitions, and machine-readable legal language push interpretation toward convergence. In this light, legal data primitives become foundational: they are the core around which increasingly deterministic legal analysis accretes.

Policy-as-Code

Tools like Open Policy Agent (OPA) treat operational policies as executable specifications that can be version-controlled, tested, and audited like any other software artifact.3

The benefits are significant: consistency across systems, centralized policy management, audit trails for policy changes, and the ability to test policies before deployment. The same policy can govern access to Kubernetes clusters, API endpoints, and database records.

Legal architecture extends this paradigm. Governance rules, compliance requirements, and regulatory constraints can be expressed as structured specifications. Systems can query the legal architecture to determine applicable obligations. Changes to legal requirements propagate automatically to affected systems.

Consider a concrete example: a privacy regulation requires explicit consent for processing personal data for marketing purposes. In a policy-as-code model, this requirement is expressed as a rule; the marketing system queries the policy engine before sending communications; non-compliant actions are blocked. The example works because checking whether consent exists is a factual query (a legal data primitive), even if determining what constitutes valid consent may require legal analysis. Organizations already implement such systems for technical policies. Extending the approach to legal requirements is a natural progression.

Real-Time Compliance

The integration of legal architecture with enterprise architecture enables a shift from periodic compliance review to continuous compliance monitoring. Rather than conducting annual audits that sample documents and interview stakeholders, organizations can maintain real-time visibility into their compliance posture.

The model knows which regulations apply to which systems. It knows the current state of corporate governance (directors, officers, filings). It knows the terms of material contracts. When something changes (a new regulation is enacted, a director resigns, a contract is amended), the impact is immediately visible. Affected obligations are flagged. Required actions are identified. Compliance dashboards update automatically.

This does not eliminate the need for legal judgment. Complex regulatory questions still require human analysis. Novel situations still require interpretation. But routine compliance monitoring, the work of tracking deadlines, verifying documentation, and maintaining records, becomes systematic rather than manual.

Integration with Corporation as Code

The legal architecture concept integrates naturally with corporation-as-code. The corporate data structure provides the foundation: entities, ownership, governance, history. The legal architecture layer adds the legal overlay: which regimes apply, what obligations exist, what compliance state obtains.

Consider how an integrated model might be structured:

# Corporate structure (from corporation-as-code)
corporate_group = {
    "parent": {
        "id": "acme-delaware",
        "jurisdiction": "US-DE",
        "systems": ["crm-main", "erp-global"]
    },
    "subsidiaries": [
        {"id": "acme-uk", "jurisdiction": "GB", "systems": ["crm-eu", "hr-uk"]},
        {"id": "acme-india", "jurisdiction": "IN", "systems": ["dev-bangalore"]},
        {"id": "acme-brazil", "jurisdiction": "BR", "systems": ["sales-latam"]}
    ]
}

# Technology architecture
systems = {
    "crm-eu": {"data_types": ["customer_pii", "contact_info"], "location": "eu-west"},
    "hr-uk": {"data_types": ["employee_pii", "payroll"], "location": "eu-west"},
    "dev-bangalore": {"data_types": ["customer_pii", "analytics"], "location": "ap-south"},
    "sales-latam": {"data_types": ["customer_pii", "transactions"], "location": "sa-east"}
}

# Legal architecture layer
legal_regimes = {
    "gdpr": {
        "applies_to": ["customer_pii", "employee_pii"],
        "jurisdictions_with_adequacy": ["US-DE", "GB", "CA", "JP"],  # simplified
        "requires_for_transfer": "adequacy_decision OR standard_clauses OR binding_rules"
    }
}

def find_gdpr_transfer_risks(corporate_group, systems, legal_regimes):
    """
    Find all systems processing personal data for entities in
    jurisdictions without GDPR adequacy decisions.
    """
    risks = []
    gdpr = legal_regimes["gdpr"]
    all_entities = [corporate_group["parent"]] + corporate_group["subsidiaries"]

    for entity in all_entities:
        if entity["jurisdiction"] not in gdpr["jurisdictions_with_adequacy"]:
            for system_id in entity.get("systems", []):
                system = systems.get(system_id, {})
                pii_types = [d for d in system.get("data_types", [])
                            if d in gdpr["applies_to"]]
                if pii_types:
                    risks.append({
                        "entity": entity["id"],
                        "jurisdiction": entity["jurisdiction"],
                        "system": system_id,
                        "data_types": pii_types,
                        "required_safeguard": gdpr["requires_for_transfer"]
                    })
    return risks

# Execute the query
risks = find_gdpr_transfer_risks(corporate_group, systems, legal_regimes)
# Returns:
# [
#   {"entity": "acme-india", "jurisdiction": "IN", "system": "dev-bangalore",
#    "data_types": ["customer_pii"], "required_safeguard": "adequacy_decision OR..."},
#   {"entity": "acme-brazil", "jurisdiction": "BR", "system": "sales-latam",
#    "data_types": ["customer_pii"], "required_safeguard": "adequacy_decision OR..."}
# ]

This query, which would require hours of document review and legal analysis in a traditional setting, executes in seconds. Note that this query asks factual questions (which entities exist, what data they process, which jurisdictions lack adequacy decisions) rather than encoding the substantive legal rules themselves. The legal architecture models facts and relationships; human judgment determines what those facts mean. The answer combines IT architecture (which systems exist and what data they process), corporate structure (which subsidiaries operate in which jurisdictions), and legal architecture (which privacy rules apply and what transfer mechanisms are required). No single document contains this information. The integrated model does.

The same pattern applies to other compliance questions:

  • “Which entities have directors whose terms expire in the next 90 days?”
  • “What filings are required if we change our registered agent in Delaware?”
  • “Which contracts reference the subsidiary we’re planning to dissolve?”

Each question spans multiple architectural layers. Each would traditionally require a lawyer to read documents, consult spreadsheets, and exercise judgment. With an integrated model, each becomes a query returning precise, auditable results.

The result is legal reasoning that is architectural rather than artisanal. Compliance becomes a structural property of how the organization is modeled, not an after-the-fact review of whether documents meet requirements.

  1. The Open Group, “TOGAF Standard,” https://www.opengroup.org/togaf ↩

  2. Rothmann, Daniel, “Company as Code,” 42 Futures, February 25, 2025, https://blog.42futures.com/p/company-as-code ↩

  3. Open Policy Agent Documentation, https://www.openpolicyagent.org/docs ↩

© 2026 Xavier Beauchamp-Tremblay & Frédéric Boivin Couillard. All rights reserved.

This site uses Just the Docs, a documentation theme for Jekyll.