Sovereign Compliance for the 14 Eyes Nations

TL;DR

The 14 Eyes intelligence-sharing alliance — Australia, Canada, New Zealand, the United Kingdom, the United States, plus Denmark, France, Germany, Belgium, Italy, the Netherlands, Norway, Spain, and Sweden — operates the world’s most demanding regulatory environment for sensitive programme data. Regulated programmes in any of these jurisdictions must navigate a layered standards landscape that covers cybersecurity, data sovereignty, export control, personnel security, and cross-border data exchange — simultaneously.

Legacy enterprise systems fail this environment in three compounding ways:

1. Architecture: a monolithic relational database with god-mode service accounts cannot be multi-tenant, cannot enforce NOFORN boundaries structurally, and cannot isolate tenants cryptographically. The security problem is not a configuration problem. It is a data-model problem.
2. Trust model: legacy systems treat the database as the security boundary. An employee with DBA access owns every customer record, every classified reference, every design decision — forever. This is the Snowden architecture. The same architecture that let one contractor exfiltrate terabytes of NSA data is in every major PLM, ERP, and MBSE suite in production today.
3. Compliance posture: most legacy vendors respond to regulatory requirements with documentation — policy statements, compliance matrices, penetration test certificates. Documentation is not architecture. A pentest certificate on a system with god-mode service accounts certifies that the perimeter is hard to cross, not that the interior is safe from the people who already have keys.

Clarity’s architecture was designed from day one to close all three gaps:

• Customer-owned KMS keys — Clarity employees cannot read customer data even with full AWS console access. The key is not ours.
• Immutable tenant_id JWT claims — extracted from Cognito at the API Gateway boundary, never from the request body. A tenant cannot forge their own identity or access another tenant’s data.
• Three-tier permission model — Primary roles (Seeker / Solver / Decider) are schema primitives enforced at the AWS control plane. Secondary roles are customer-configured, mapped to primary roles, and scoped to overlay groups and Lx layers. Tertiary roles (SME, Mentor, Moderator, Observer, Gardener) are earned from documented activity and recorded in @source provenance. Together they implement a complete RBAC + ABAC stack without a single flat permission flag in the system.
• S3 object isolation — per-tenant key prefix, per-tenant KMS key, S3 Object Lock for WORM compliance, S3 Versioning for tamper-evident history.
• @source provenance — every entity carries a cross-lifecycle provenance chain. The @source schema ties every field to its originating document, decision, and principal. Tampering with data does not erase the evidence of the original state.
• Overlay compliance system — the 14 Eyes standards landscape is mapped as overlay groups on the Lx schema. Compliance is computed from the data, not assembled from documents.

If you only read one sentence: the 14 Eyes standards landscape is not a documentation problem — it is a data architecture problem. Clarity solves it at the architecture level. Legacy enterprise systems cannot.

The bargain on offer

Every engineering programme operating in the 14 Eyes regulatory environment has had the same conversation. The auditor arrives. The compliance manager produces a folder of certificates, policy statements, penetration test reports, and attestation letters. The auditor reviews them. The programme passes. Six months later, a contractor with DBA access — or a compromised IT admin, or a phishing email that lands in the right inbox — exfiltrates a decade of proprietary engineering data. The audit passed. The architecture failed.

The GDPR fine lands on the CEO’s desk. The NCSC incident report names the organisation. The US DoD suspends the contract pending a CMMC Level 2 re-assessment. The Australian Government requires an IRAP reassessment before the next delivery milestone. And the same compliance manager who produced the attestation folder now has to explain why the architecture that passed the audit did not prevent the breach.

The explanation is always the same: the compliance documentation described what the system was supposed to do. It did not describe what the system actually is. And what the system actually is — a monolithic relational database with a flat permission model and god-mode service accounts — cannot structurally enforce the controls that the documentation claimed it had.

Clarity’s founders have operated inside, audited, and recovered programmes from the consequences of this gap — across three continents, across defence, nuclear, advanced manufacturing, government, and critical infrastructure — for three decades. This whitepaper documents what they found, what the 14 Eyes standards landscape actually requires at the architectural level, and how Clarity closes every gap structurally.

It has three sections:

• Section 1 — How legacy enterprise systems fail the 14 Eyes regulatory environment: god-mode databases, the Snowden architecture, multi-tenancy as an afterthought, NOFORN boundary failures, and the documentation trap.
• Section 2 — How Clarity’s 13 lifecycle verticals, 10 overlay groups, and @source provenance system comply with each major standard in the 14 Eyes landscape: NIST CSF, FedRAMP, IRAP, ASD ISM, NCSC CAF, GDPR, NIS2, ISO 27001, FIPS 140-3, CMMC, and emerging standards including Zero Trust, post-quantum cryptography, and DORA.
• Section 3 — Clarity’s security USPs: a three-tier permission architecture (primary schema primitives, customer-configured RBAC secondary roles scoped to overlay groups, and provenance-earned ABAC tertiary roles), S3 isolation with customer-owned KMS keys, object locks, versioning, immutable JWT claims, and diode-and-airlock connectors for cross-boundary exchange.

Section 1 — How legacy systems fail the 14 Eyes regulatory environment

1.1 The god-mode database problem

Every major enterprise software suite of the last four decades — PLM, ERP, MES, MRO, EAM, and every point solution in between — is built on the same foundation: a relational database with a service-account connection string. That service account has read and write access to every table in the database. The application enforces access control through application logic — a permissions check in the code, a role flag in a user record, a session token validated by a middleware function.

This architecture was designed in an era when the database was behind a firewall and the users were on the same LAN. It assumed a single organisation, a single security boundary, and a threat model that did not include the organisation’s own administrators.

The consequence of this architecture, in a 14 Eyes regulated environment, is structural:

Every person with DBA access owns everything. A single compromised DBA credential, a single rogue employee in the IT department, a single misconfigured backup job — and every tenant record, every design decision, every classified reference stored in the system is readable. Not because the application let them through. Because the database layer has no concept of tenancy, no concept of classification, and no concept of a boundary between one customer’s data and another’s.

Application-layer permissions can be bypassed at the database layer. A user who is blocked from seeing a record in the application UI can read it directly with a SQL query if they have database access. Compliance documentation that describes application-layer permissions is therefore describing a control that exists in only one of the two places where data can be read.

Encryption at rest is not the same as encryption per tenant. Most legacy enterprise suites encrypt data at rest using a platform key managed by the vendor or the cloud provider. This protects against physical media theft. It does not protect against a compromised administrator who has access to the key management system. If Clarity encrypted all customer data with a single KMS key, the security posture would be identical to a legacy vendor’s platform key — the person who controls the key controls all the data. Clarity uses per-tenant customer-managed KMS keys precisely to prevent this.

This is not a configuration problem. It is a data architecture problem. No amount of application-layer hardening changes the fact that the database service account has god-mode access to every row in every table.

1.2 The Snowden effect — what god-mode permissions make possible

In 2013, Edward Snowden — a contractor with legitimate administrative access to NSA systems — exfiltrated an estimated 1.5 million classified documents. He did not hack the perimeter. He did not exploit a zero-day vulnerability. He used the access he had been legitimately granted to copy data he was not authorised to read.

The Snowden incident is not a cautionary tale about contractors. It is a cautionary tale about architecture. Every legacy enterprise system with god-mode service accounts, flat DBA permissions, and no cryptographic isolation between tenants or classification levels has the same architectural vulnerability: a single trusted insider with sufficient access can exfiltrate everything, and there is no structural mechanism to prevent it.

The 14 Eyes nations spent the years following Snowden hardening their perimeter controls, their personnel vetting procedures, and their access review processes. All of these are necessary. None of them address the architectural root cause: a data model in which administrative access and data ownership are the same thing.

The vendors whose products power the majority of classified engineering programmes — the PLM suites, the requirements management tools, the configuration management systems — have made some of these same perimeter improvements. WAFs, MFA, SSO, SIEM integrations, penetration testing programmes, and SOC 2 certifications. All of these improve perimeter security. None of them change the fact that the person who can connect to the database with the service account can read everything in it.

What the 14 Eyes standards landscape requires is not better perimeter security. It is cryptographic isolation at the data level — so that administrative access to the infrastructure does not translate to access to the data. This is precisely what customer-managed KMS keys provide, and precisely what legacy enterprise systems cannot implement without rebuilding their data models from scratch.

1.3 Multi-tenancy as an afterthought

Most legacy enterprise systems were designed for a single organisation. Multi-tenancy was added later — either through a tenant_id column on every table (soft multi-tenancy), or through separate database schemas per tenant (schema-level multi-tenancy), or through separate database instances per tenant (database-level multi-tenancy). Each approach is a retrofit on a single-tenant architecture, and each introduces characteristic failure modes:

Column-level soft multi-tenancy (the most common approach) relies entirely on application logic to filter queries by tenant_id. A missing WHERE clause in any query returns all tenants’ data. This has happened in production at multiple major SaaS vendors — including in PLM tools used in regulated environments. Every query in every service must be audited against tenant-filter correctness. A single missed join, a single raw SQL query executed under operational pressure, exposes all tenants.

Schema-level multi-tenancy is more isolated but introduces schema drift — different tenants on different schema versions — and creates operational complexity that leads to security exceptions: “we’ll migrate tenant X’s schema next quarter, so for now they share the default schema.”

Database-level multi-tenancy is closest to true isolation but is operationally expensive and rarely used in practice for SaaS products. The vendors who claim database-level isolation for enterprise tiers typically mean separate RDS instances — still encrypted with a platform key, still accessible to any DBA with access to the RDS cluster.

None of these approaches provide cryptographic isolation. The data is separated by logic, not by a key the vendor does not hold.

1.4 NOFORN boundaries and joint ventures across 14 Eyes nations

The term NOFORNN — Not Releasable to Foreign Nationals — is the canonical US classification marking for information that may not be shared outside US persons. The 14 Eyes context adds further complexity: AUKUS, the Five Eyes agreement, bilateral intelligence-sharing arrangements, and joint ventures across different national classification levels all require fine-grained control over what data crosses which boundary, at which classification level, in which direction.

Legacy enterprise systems have no native concept of a NOFORN boundary. Data stored in a PLM system that is shared across a US prime and its UK subsidiary — a common arrangement in AUKUS programmes — lives in the same database. The technical mechanism for enforcing which data the UK subsidiary can see is an application-level permissions check. That permissions check can be bypassed by anyone with database access. And the “boundary” it enforces is a row-level filter on a table that contains data from both national contexts in adjacent rows.

Joint ventures introduce a further dimension: two organisations, each with their own security requirements, each with their own classification levels, sharing a programme. The Clarity diode-and-airlock connector pattern was designed explicitly for this scenario. A diode allows one-way metadata flow — controlled, structurally irreversible — with three independent enforcement layers that are not configurable from application code. An airlock allows two-way exchange with joint approval from both parties, a bilateral audit trail neither party can deny, and fail-closed behaviour on policy infrastructure failure. This is not a feature of a legacy PLM system. It is a capability that requires a completely different architectural model.

1.5 The documentation trap — why compliance documents are not compliance

The standard response from a legacy enterprise vendor to a compliance requirement is a compliance matrix: a spreadsheet that maps each control in the framework (NIST SP 800-53, ISO 27001 Annex A, CMMC Level 2) to a policy or procedure document, and marks each control as “Met,” “Partially Met,” or “Planned.” These matrices are often accurate as far as they go. The policy documents they reference are real. The procedures they describe are implemented — in the application layer.

The gap is between what the compliance matrix describes and what the architecture actually enforces. A NIST SP 800-53 AC-3 (Access Enforcement) control is met if the system enforces approved access controls. A system that enforces access controls in application code but has god-mode service accounts at the database layer meets the letter of AC-3 as described in the compliance matrix. It does not meet the spirit of AC-3 as understood by a reviewer who has read the architecture diagram.

The same gap applies to every data-level control in every 14 Eyes framework. AC-4 (Information Flow Enforcement), AU-10 (Non-Repudiation), SC-28 (Protection of Information at Rest), SC-12 (Cryptographic Key Establishment and Management) — all of these are satisfiable in a compliance matrix by describing application-layer controls. All of them require cryptographic data-level enforcement to be genuinely effective against an insider threat.

Section 2 — How Clarity complies with the 14 Eyes standards landscape

2.1 The standards landscape — a single compliance surface, not fourteen separate audits

The 14 Eyes regulatory environment produces what appears to be an impossible compliance problem: fourteen different national frameworks, multiple international standards, sector-specific overlays (defence, medical, nuclear, financial), and a raft of emerging standards that are being finalised simultaneously across multiple jurisdictions. Organisations that operate across 14 Eyes nations face the prospect of maintaining fourteen separate compliance programmes, each with its own audit cycle, its own evidence requirements, and its own remediation timelines.

Clarity’s overlay system makes this tractable. The 10 overlay groups in the Lx schema include a dedicated Regulatory & Compliance overlay group (Lx.2). Every standard in the 14 Eyes landscape is mapped as a sublayer within this group. Compliance evidence is generated from the Lx data — the @source provenance chain, the change records, the decision history, the invariant state — not assembled from documents. Adding a new standard is a sublayer configuration change, not a programme of work. The compliance surface is one, not fourteen.

Lx.2 — Regulatory & Compliance Overlay sublayers

Every entity in every Lx layer carries a compliance assessment against the standards applicable to that entity’s context, classification level, and nation. Adding a new national requirement is a sublayer configuration entry — not a programme of work.

2.2 NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5

The NIST Cybersecurity Framework (CSF) is the de facto baseline for public and private sector security programmes across all 14 Eyes nations. Its five functions — Govern, Identify, Protect, Detect, Respond, Recover — map directly to Clarity’s architectural properties.

NIST SP 800-53 Rev 5 provides the control baseline for FedRAMP High and CMMC Level 3. Every AC (Access Control), AU (Audit and Accountability), CM (Configuration Management), IA (Identification and Authentication), SC (System and Communications Protection), and SI (System and Information Integrity) control family maps to a Clarity architectural property. The mapping is not a compliance matrix — it is a structural property.

2.3 FedRAMP High

FedRAMP (Federal Risk and Authorization Management Program) is the US federal government’s cloud security authorisation framework. FedRAMP High applies to systems that process Controlled Unclassified Information (CUI) and is a prerequisite for cloud services in US federal and intelligence community contexts.

FedRAMP High requires 421 controls from NIST SP 800-53 Rev 5. The controls most frequently failed by cloud services are those that require data-level enforcement rather than application-level enforcement: SC-28 (Protection of Information at Rest), SC-12 (Cryptographic Key Management), AC-3 (Access Enforcement), and AC-4 (Information Flow Enforcement).

Clarity’s architecture addresses these directly:

• SC-28: Per-tenant customer-managed KMS keys. Data encrypted at rest with a key the customer — not Clarity — owns. Clarity employees cannot decrypt customer data even with full AWS console access.
• SC-12: KMS key lifecycle management is the customer’s responsibility. Clarity provides the CDK template and the operational procedures; the customer owns the key. Key rotation is configurable and auditable via KMS CloudTrail events.
• AC-3: Access enforcement at three layers — Cognito JWT validation, IAM role policies on Lambda, S3 bucket policies with tenant_id path prefix conditions. A Lambda function processing a request for Tenant A cannot access Tenant B’s S3 prefix, regardless of application logic.
• AC-4: Information flow enforcement through diode-and-airlock connectors. Cross-tenant and cross-classification flows are structurally impossible by default; the diode and airlock patterns provide the only approved exchange mechanism, with three independent enforcement layers and a bilateral audit trail.

FedRAMP High also requires FIPS 140-2 (transitioning to FIPS 140-3) validated cryptographic modules. AWS KMS is FIPS 140-2 validated. AWS Cognito operates in FIPS mode in GovCloud. All Clarity cryptographic operations use AWS-managed services with validated module certification.

2.4 IRAP — Australian Information Security Registered Assessors Program

IRAP is the Australian Government’s framework for assessing cloud services against the Protective Security Policy Framework (PSPF) and the ASD Information Security Manual (ISM). IRAP assessment is required for cloud services that process, store, or communicate Australian Government data classified at OFFICIAL: Sensitive and above.

IRAP assessment evaluates a system against the ASD Essential Eight, the ISM controls relevant to the system’s classification level, and the PSPF requirements for access control, personnel security, and physical security.

For PROTECTED level deployments (IRAP assessed), Clarity supports deployment into the Australian Government’s Whole of Government Cloud (WoGC) environment using the same CDK architecture with AWS GovCloud (AP-SOUTHEAST-2 with sovereignty controls enabled).

2.5 UK NCSC CAF and Cyber Essentials Plus

The UK National Cyber Security Centre Cyber Assessment Framework (CAF) applies to operators of essential services and relevant digital service providers under the NIS Regulations. The CAF has four objectives: managing security risk (A), protecting against cyber attack (B), detecting cyber security events (C), and minimising the impact of cyber security incidents (D).

Cyber Essentials Plus is the UK government’s baseline technical standard for cyber security. It is a prerequisite for UK government contract eligibility and maps to a subset of the CAF’s Objective B controls.

Clarity satisfies both through its serverless, IAM-enforced architecture. The absence of persistent servers eliminates the largest attack surface in most Cyber Essentials assessments: unpatched operating systems, misconfigured network services, and default credentials on infrastructure components. Lambda functions are stateless, have no listening network services, and are governed by IAM policies that are auditable in source control.

2.6 GDPR and UK GDPR

GDPR and UK GDPR impose three categories of obligation relevant to Clarity’s compliance posture:

Data minimisation and purpose limitation: Clarity only stores the data that users explicitly upload and the structured entities that Clarity’s AI generates from it. No behavioural analytics, no third-party data sharing, no advertising profiles. The @source provenance chain provides a complete record of what was collected and why — satisfying the GDPR accountability obligation (Article 5(2)) without requiring a separate data catalogue.

Right to erasure: The tenant_id-prefixed S3 path structure means all data for a tenant can be identified and deleted without a cross-table query. Tenant deletion is a single S3 prefix deletion operation. KMS key deletion renders all encrypted data irrecoverable without any deletion operation. This is a structural property, not a procedure.

Data protection by design and by default (Article 25): Customer-owned KMS keys, per-tenant S3 isolation, and Cognito JWT identity enforcement are architectural properties, not optional configurations. The default state of a Clarity deployment is maximum isolation. Relaxing isolation requires explicit configuration changes, not the reverse.

Data transfer: For UK GDPR, Clarity can deploy within UK AWS regions (eu-west-2, eu-west-1). For EU GDPR, deployment in eu-west-1 (Ireland) or eu-central-1 (Frankfurt) keeps data within the EEA. For customers operating across both UK and EU jurisdictions, separate deployment instances with diode connectors provide the exchange mechanism — data crossing the boundary does so through a controlled, logged, and auditable transfer, not through shared infrastructure.

2.7 NIS2 — Network and Information Systems Directive 2

NIS2, effective October 2024 across EU member states, extends the scope of NIS1 to cover a broader range of essential and important entities — including providers of digital infrastructure, managed service providers, and many supply chain participants in regulated sectors. NIS2 introduces mandatory 24-hour early warnings for significant incidents, 72-hour incident notifications, and new personal liability for senior management.

The management liability provision of NIS2 is the element most likely to change buying behaviour. Under NIS2, CEOs and board members of essential entities can be held personally liable for cybersecurity failures. This shifts the compliance conversation from IT teams to the C-suite — and it shifts the question from “is our system compliant?” to “can we demonstrate, to a regulator, that we took all appropriate measures?”

Clarity’s @source provenance chain, L5 decision records, and L4 baselines provide exactly the evidence base that a NIS2 personal liability defence requires. Every security-relevant decision — “we chose to use a customer-managed KMS key rather than a platform key because…” — is a structured L5 decision record with an evidence chain, a timestamp, and an identified Decider. The programme cannot claim the decision was made; it can prove what the decision was, who made it, and on what basis.

2.8 ISO/IEC 27001:2022 — Information Security Management Systems

ISO 27001:2022 restructures its Annex A controls into four themes: Organisational (five controls), People (eight controls), Physical (fourteen controls), and Technological (thirty-four controls). The Technological theme is the most directly relevant to Clarity’s architecture.

The Technological controls most structurally relevant to Clarity:

2.9 FIPS 140-3 — Cryptographic Module Validation

FIPS 140-3 (transitioning from FIPS 140-2, with FIPS 140-2 certificates remaining valid through 2026) specifies the security requirements for cryptographic modules used by US federal agencies and their supply chains. It is referenced by FedRAMP, NSA Suite B, CMMC Level 3, and the equivalent classified cryptographic standards across Five Eyes nations.

AWS KMS uses FIPS 140-3 validated cryptographic modules. AWS Cognito operates in FIPS mode in GovCloud. AWS API Gateway with TLS 1.2+ uses only FIPS-approved cipher suites. CloudFront can be configured to use FIPS-validated TLS endpoints.

Clarity’s architecture uses only AWS-managed cryptographic operations. There is no custom cryptographic code in Clarity’s Lambda functions. All key generation, key storage, encryption, and decryption operations use AWS KMS. This is a structural property — Clarity cannot use non-FIPS cryptography because all cryptographic operations are delegated to AWS services with validated module certification.

For post-quantum cryptography (NIST PQC standards finalised in 2024 — ML-KEM, ML-DSA, SLH-DSA), AWS is migrating KMS to support hybrid classical/post-quantum key exchange. Clarity’s architecture is positioned to adopt this migration transparently — customer KMS keys are managed by AWS KMS; when AWS KMS upgrades its cryptographic module, all data encrypted under customer-managed keys automatically benefits from the upgraded module.

2.10 CMMC — Cybersecurity Maturity Model Certification

CMMC 2.0 (implemented December 2024) requires defence industrial base (DIB) contractors and subcontractors to achieve independently assessed certification at Level 2 (110 controls from NIST SP 800-171) or Level 3 (110 NIST 800-171 controls plus 24 from NIST 800-172) before handling Controlled Unclassified Information (CUI) or Federal Contract Information (FCI).

For engineering programmes in the US DIB supply chain — the Tier 2, 3, and 4 suppliers that make up the majority of Clarity’s target market — CMMC certification is becoming a contract prerequisite. A supplier that cannot demonstrate CMMC Level 2 will be disqualified from bids that involve CUI.

The practical consequence for Clarity’s target customers: they need a platform that either already achieves CMMC Level 2 architectural requirements by design, or one that documents a credible path to Level 2 certification.

Clarity’s architecture satisfies the most demanding CMMC Level 2 requirements structurally:

• 3.1 Access Control (22 requirements): Cognito JWT + IAM + S3 bucket policy + Lambda resource policy — four independent enforcement layers.
• 3.3 Audit and Accountability (9 requirements): CloudWatch structured logging, CloudTrail API audit, tamper-evident @source provenance on every entity.
• 3.4 Configuration Management (9 requirements): Infrastructure as Code, git-tracked configuration, no console-click deployments, L4 baselines for all Lx configuration state.
• 3.5 Identification and Authentication (11 requirements): Cognito MFA, immutable tenant_id JWT claim, SAML/OIDC federation.
• 3.13 System and Communications Protection (16 requirements): TLS 1.2+ in transit, KMS encryption at rest, per-tenant S3 isolation, diode-and-airlock for cross-boundary flow.

2.11 Emerging standards — Zero Trust, Post-Quantum, DORA, and FedRAMP 20x

Zero Trust Architecture (NIST SP 800-207): Clarity’s architecture is zero-trust by design. There is no network perimeter to trust — Lambda functions are invoked over HTTPS, validated by Cognito JWT, authorised by IAM policy, and isolated by S3 key prefix. No Lambda function trusts another Lambda function’s identity claim. Every invocation is independently authenticated. Every S3 access is independently authorised. This is not zero-trust-as-marketing; it is zero-trust-as-consequence-of-serverless-design.

Post-Quantum Cryptography: NIST’s 2024 standardisation of ML-KEM, ML-DSA, and SLH-DSA marks the beginning of the PQC transition period for regulated systems. Clarity’s reliance on AWS KMS for all cryptographic operations means the PQC migration is managed by AWS — Clarity customers do not need to audit Clarity’s cryptographic code when AWS KMS migrates its modules. The Lx.2 overlay includes Lx.2.14 (NIST PQC) as a tracking sublayer for customers operating on timelines that include classified or long-lived sensitive data.

DORA — Digital Operational Resilience Act: DORA (effective January 2025) applies to financial entities and their ICT service providers across EU member states. For Clarity customers in the financial services sector — asset managers, banks, and insurance companies in 14 Eyes nations — DORA imposes mandatory ICT risk management frameworks, incident reporting timelines, and third-party ICT provider oversight requirements. Clarity’s L4 baselines (operational snapshot), L5 decisions (change governance), and @source provenance chain provide the evidence base for DORA’s ICT risk management documentation requirements.

FedRAMP 20x: The US General Services Administration’s FedRAMP 20x initiative (piloting 2025–2026) seeks to automate compliance assessment through machine-readable security documentation. Clarity’s Infrastructure as Code (CDK TypeScript), git-tracked configuration, and structured log format are aligned with FedRAMP 20x’s machine-readable posture requirements. The Lx.2 overlay will include automated FedRAMP 20x control mapping as a sublayer configuration as the standard matures.

AUKUS Pillar 2 Emerging and Disruptive Technologies (EDTs): The AUKUS Pillar 2 programme is developing interoperability standards for AI, quantum, hypersonics, cyber, and undersea capabilities across Australia, UK, and US. These standards — currently emerging from the TTCP structure and the AUKUS Advanced Capabilities Technical Working Groups — will impose new requirements for programme data sovereignty, AI explainability, and cross-boundary digital thread exchange. Clarity’s diode-and-airlock connector framework and BYOM (Bring Your Own Model) AI architecture are designed for exactly this scenario: programme data stays within national KMS boundaries; structured digital thread subsets cross national boundaries through policy-governed exchange with bilateral audit trails.

Section 3 — Clarity’s security USPs — compliance by architecture

3.1 Three-tier permission architecture — primary, secondary, and tertiary roles

Clarity’s permission model has three independent tiers. Each adds a refinement layer on top of the one below it. The result is a complete RBAC + ABAC stack that is simultaneously auditable at the platform level, configurable at the customer level, and responsive at the individual level — and that satisfies the segregation of duties requirements in every major 14 Eyes framework without a single flat permission flag in the system.

Tier 1 — Primary roles: schema primitives

The primary roles are Seeker, Solver, and Decider. They are not configuration flags. They are schema primitives — encoded into the @source provenance record on every entity, enforced at the API Gateway boundary on every request, and verified in the IAM policy on every Lambda invocation. A legacy enterprise system with “admin” and “user” roles has flat permissions: a role grants access to a set of operations. Clarity’s primary roles enforce a structural separation between evidence gathering, analysis, and authorisation:

A Solver cannot approve their own analysis. A Seeker cannot propose changes. These are not policy settings that an administrator can relax. They are structural constraints enforced at the AWS control plane, independent of application logic.

Tier 2 — Secondary roles: customer-configured, overlay-scoped (RBAC)

Secondary roles are customer-defined job titles and functional groups — “Systems Engineer,” “Programme Director,” “Technical Authority,” “Bid Manager” — mapped by the customer to one of the three primary roles. They carry two additional attributes that primary roles do not:

1. Primary role mapping — each secondary role resolves to exactly one primary role. This mapping determines the operation envelope. The mapping is recorded in the JWT claim and verified at the API Gateway boundary on every request.
2. Overlay group and Lx layer scope — secondary roles are bounded by overlay group or Lx layer. A “Systems Engineer” might be a Solver for L1–L3 (requirements, architecture, analysis) but a Seeker for L4–L5 (baselines and formal decisions). A “Programme Director” might be a Decider for L5 decision records but a Seeker for detailed L2 parameter analysis. A “Supplier Representative” might be a Solver scoped only to the Lx.2 regulatory overlay for their national jurisdiction.

This tier implements RBAC: roles are predefined, assigned by a Decider, recorded in the Cognito JWT, and verified on every request. The permission registry (permissions.json) is version-controlled, baseline-locked, and auditable. It enumerates every operation and the minimum secondary-role mapping required to invoke it. No operation grants access through application logic alone.

The overlay group scoping is what gives this tier its regulatory significance. A single Clarity instance can hold programme data under multiple classification contexts simultaneously — ITAR-controlled components, GDPR-governed personnel data, NOFORN-restricted analysis arcs. Secondary role scoping to overlay groups means that a user’s access is determined not just by their job function but by the intersection of their job function and the classification context of the data they are requesting. This is not a row-level filter. It is an IAM attribute condition evaluated at the AWS control plane.

Tier 3 — Tertiary roles: activity-attained, provenance-recorded (ABAC)

Tertiary roles are not assigned. They are attained through documented activity in the platform and recorded permanently in the @source provenance chain. They do not override primary or secondary role permissions. They modify the ABAC scope — narrowing or expanding the entity and overlay group scope within the primary role’s envelope — based on demonstrated, evidenced contribution.

The regulatory significance of the tertiary tier is that it makes the audit trail richer than role assignment alone. When a Mentor validates a Solver’s L2 analysis, the @source provenance record carries not just the Solver’s identity and primary role, but the Mentor’s validation — with their tertiary role attainment history as evidence of qualification. This is the basis for a structured competency argument in a safety or regulatory submission: not “this person was authorised to perform this operation,” but “this person was authorised, qualified by prior documented activity, and their work was independently validated by a qualified peer whose qualification is itself evidenced in the record.”

How all three tiers work together

3.2 RBAC and ABAC — technical enforcement across all three tiers

The three-tier model described in section 3.1 maps cleanly to the AWS-level enforcement stack:

RBAC enforcement (primary and secondary tiers) is implemented through the custom:role Cognito JWT claim, which carries the user’s secondary role. Every Lambda handler extracts the role claim from event['requestContext']['authorizer']['claims'] at invocation — not from the request body, not from a session store. The permission registry (permissions.json) maps every API operation to the minimum required secondary role and its primary role mapping. An operation that requires a Solver-mapped secondary role will be rejected at the Lambda level for a Seeker-mapped claim, regardless of application logic. This is enforced at the IAM resource policy layer, not the application layer.

ABAC enforcement (primary, secondary, and tertiary tiers) operates at two levels:

The first is tenancy isolation. The custom:tenantId JWT claim is bound to the S3 prefix condition in the IAM policy on every Lambda execution role. A Lambda processing a request for Tenant A cannot access Tenant B’s S3 path prefix because the IAM condition prevents it at the AWS control plane — not because the application code checks and returns an error. This applies equally to the overlay group scoping of secondary roles: the overlay group scope is encoded in the JWT and evaluated as an IAM condition, not checked in application code.

The second is entity-level provenance. Every entity in the Lx schema carries a _provenance field recording the tenant_id, originating document reference, principal identity, primary role, and (where present) tertiary role attainment of every operation performed on that entity. Classification-aware redaction in the diode pattern uses these ABAC attributes to determine what can cross a sovereignty boundary — not a rule applied to the whole payload, but a per-entity decision made from the entity’s own provenance record. An entity in a NOFORN-scoped overlay group carries that attribute in its provenance record. The diode evaluates it before the transfer executes.

The combination — structural primary role primitives, customer-configurable RBAC secondary roles bounded to overlay groups and Lx layers, and ABAC tertiary roles earned from provenance-evidenced activity — is what closes the gap the legacy enterprise permission model leaves open. Legacy systems have flat permissions and an application-layer access check. Clarity has three independent tiers of access control, each enforced at a different layer of the AWS stack, each producing an auditable record that cannot be retroactively modified.

3.3 S3 isolation with customer-owned KMS keys

The S3 bucket structure in Clarity provides two levels of isolation:

Namespace isolation: projects/{tenantId}/{projectId}/ — all objects for a tenant are under a single path prefix. IAM bucket policies enforce that a Lambda processing Tenant A’s request can only access projects/tenant-a/. The prefix is extracted from the JWT, not from the request body.

Cryptographic isolation: each tenant’s data is encrypted with a customer-managed KMS key. The key is created in the customer’s own AWS KMS account (for own-account and air-gapped deployments) or in a Clarity-managed KMS with customer-controlled key policy (for SaaS deployments). In either case, Clarity’s operational principals — developers, support engineers, on-call responders — do not have kms:Decrypt permission on customer keys. Customer data is cryptographically inaccessible to Clarity staff.

This is the architectural property that differentiates Clarity from a legacy PLM vendor’s “encrypted at rest” claim. Both systems encrypt at rest. Clarity encrypts at rest with a key the customer owns. The legacy PLM encrypts at rest with a key the vendor’s DBA can access.

3.4 S3 Versioning and Object Lock — WORM compliance and tamper-evident history

S3 Versioning is enabled on all user and proprietary S3 buckets in Clarity’s deployment. Every write to an S3 object creates a new version, preserving the previous version. Object versions are retained according to the lifecycle policy configured at deployment. For regulated deployments, version deletion requires explicit authorisation; for classified deployments, version deletion can be prevented entirely via Object Lock.

S3 Object Lock in COMPLIANCE mode implements WORM (Write Once, Read Many) storage. Objects locked in COMPLIANCE mode cannot be deleted or overwritten by any AWS principal — including the root account. This is the same technology used by financial institutions for SEC 17a-4 and CFTC 1.31 compliant recordkeeping. For 14 Eyes regulated programmes, Object Lock on Clarity’s @source provenance records and L4 baseline snapshots provides a tamper-evident record of the programme’s decision history that cannot be erased or modified — even by Clarity, even by the customer, even by AWS.

The combination of Versioning and Object Lock means that the programme’s historical state is permanently preserved. An L5 decision record created in 2026 and locked via Object Lock will be readable, verbatim, in 2056 — regardless of what has happened to the production system in the interim.

3.5 Immutable JWT claims — the tenant_id guarantee

Every Clarity Lambda handler extracts tenant_id from event['requestContext']['authorizer']['claims'] — not from the request body, not from a query parameter, not from a path segment. The claims are set by Cognito at authentication time and cannot be modified by the client. A user cannot forge a tenant_id claim, cannot escalate their role claim, and cannot impersonate another tenant.

This is Pattern P-01 in Clarity’s architectural pattern library. It is not a best practice. It is an invariant that is verified in code review, enforced in pre-commit hooks, and tested in the automated regression suite. Any Lambda handler that reads identity from the request body rather than the claims is a defect — flagged immediately, not shipped to production.

3.6 Diode and airlock connectors — the architectural solution to multi-tenancy

Sections 1.3 and 1.4 documented the two structural multi-tenancy failures of legacy enterprise systems: tenants sharing a database with only application-layer row filters between them, and joint ventures / NOFORN-boundary programmes sharing infrastructure with no structural enforcement of cross-boundary data flow. The diode and airlock connector patterns are Clarity’s architectural answer to both.

These are not features. They are infrastructure patterns — enforced at the AWS IAM and S3 levels, auditable from CDK source, and structurally incapable of being misconfigured into a permissive state. No legacy PLM or ERP system has an equivalent.

Why the multi-tenancy problem requires a connector architecture

The standard response to multi-tenancy is isolation: per-tenant namespaces, per-tenant KMS keys, JWT-enforced tenant_id claims. Clarity implements all of these (sections 3.3 and 3.5). But isolation alone solves only the intra-system case — tenants on the same Clarity instance cannot see each other’s data.

It does not solve the inter-system case: a US prime and its UK subsidiary running separate Clarity instances on separate classification networks that need to share a structured digital thread subset. Or a Five Eyes programme office exchanging engineering data with a national supplier whose Clarity instance is in a GovCloud account under a different sovereignty boundary. Or an AUKUS programme requiring structured artefact exchange between three national instances, each under a different NOFORN equivalent, none of which can share infrastructure.

This is the multi-tenancy problem at its hardest: not preventing tenants from seeing each other inside one system, but enabling controlled, auditable, structurally irreversible data flow between sovereign instances that must never merge their trust boundaries.

The diode pattern — one-way, infrastructure-enforced, three independent layers

The diode allows one-way data flow from a source instance to a target instance. The flow is structurally irreversible — not configured to be irreversible, not blocked by application logic that could be patched. Structurally irreversible. Three independent enforcement layers each prevent reverse flow independently, at the AWS infrastructure level:

The three layers are independent. A bug in the Lambda code cannot create reverse flow because the IAM Deny operates at the AWS control plane, not at the code level. An operator misconfiguring the Lambda role cannot create reverse flow because the S3 bucket policy independently denies it. A rogue EventBridge rule cannot trigger reverse flow because there is no CloudFormation resource that authorises one — and CloudTrail records any attempt to create it.

For the 14 Eyes regulatory context, these three layers map directly to the defence-in-depth requirements of NIST SP 800-53 SC-7 (Boundary Protection), AC-4 (Information Flow Enforcement), and the equivalent controls in IRAP, NCSC CAF, and the ASD ISM. Each layer is independently auditable. No single control failure can create a data crossing.

What crosses the boundary — and what never does

The diode does not transfer data. It transfers structured metadata — specifically, a CrossDomainTraceLink record:

The payload — the classified content, the engineering data, the source tenant’s KMS-encrypted objects — never crosses. An organisation can know that “Requirement REQ-4521 was approved in the classified instance on this date at this classification level” without ever seeing the requirement text. The traceability exists. The boundary holds.

The airlock pattern — controlled two-way exchange with joint governance

The airlock extends the diode for scenarios where bidirectional exchange is required: a joint venture where both parties need to see each other’s interface specifications, a prime-supplier arrangement where approved engineering data must flow in both directions, or an AUKUS programme where three nations need structured artefact exchange under shared governance.

The airlock adds a fourth control layer on top of the diode’s three. The connector is deployed to a dedicated transit AWS account — no permanent tenant data lives there. The IAM resource policy on the transit account requires approval from both parties’ principals before any transfer executes. Either party can suspend unilaterally with immediate effect. The policy infrastructure fails closed: if the approval mechanism is unavailable, no transfer proceeds.

The bilateral CrossDomainTraceLink records are the audit trail. Neither party can forge or deny the exchange occurred — the record is in both instances, independently, signed with the transfer timestamp and the digest of the transferred metadata. For NOFORN boundary programmes, this is the audit evidence that demonstrates controlled exchange with documented approval from both parties.

Compliance mapping — what the diode and airlock satisfy

The diode and airlock connector framework directly satisfies the multi-tenancy and boundary-enforcement controls in every major 14 Eyes framework:

No legacy enterprise system has a multi-tenancy architecture that satisfies these controls structurally. Every legacy solution relies on application-layer enforcement that can be bypassed at the database level, misconfigured by an administrator, or circumvented by a DBA with direct database access. The diode and airlock patterns enforce boundary control at the AWS infrastructure level, independently of application code, independently auditable from CDK source and CloudTrail. This is the architectural gap the 14 Eyes regulatory framework requires to be closed — and the one that legacy systems cannot close without rebuilding from the foundation.

3.7 Active compliance mapping — the USP that eliminates the documentation trap

Clarity’s compliance posture is not maintained through documentation. It is maintained through the data model. Every entity in the Lx schema carries its compliance assessment as a first-class attribute — computed from the entity’s properties, its @source provenance, and the applicable overlay sublayers. A NIST CSF assessment is not a spreadsheet produced quarterly — it is a view over the Lx model, generated on demand, always current.

This means that when a standard changes — when NIST releases a new CSF profile, when CMMC Level 2 adds a new control, when DORA’s incident reporting timelines are updated — the compliance view updates with the data. The organisation does not need to run a compliance gap assessment. It reads the gap from the model.

For the 14 Eyes regulated programme operating across multiple national standards simultaneously, this is not a productivity improvement — it is an architectural necessity. The alternative is maintaining fourteen separate compliance programmes, each with its own audit cycle, each drifting from the programme’s actual state the moment the last assessment was completed. Clarity makes active compliance mapping — compliance computed from live data, not assembled from stale documents — the default state of every programme.

The compliance case — what changes when architecture is the compliance layer

The traditional compliance conversation ends at the audit. The auditor reviews the controls, the organisation demonstrates that the controls are in place, the certificate is issued, and both parties move on. Six months later the system has changed, the controls have drifted, and the next audit cycle begins.

Clarity changes this conversation permanently. When the compliance evidence is the Lx model — not a folder of PDFs — the compliance posture is always current. When the access controls are IAM policies derived from CDK source — not application code that can be patched between audits — the compliance posture is auditable from the code repository. When the cryptographic isolation is customer-owned KMS keys — not a vendor attestation — the compliance posture is verifiable from the KMS key policy, not from the vendor’s word.

For 14 Eyes regulated programmes, this is not a better compliance programme. It is a different kind of compliance — one that closes the gap between what the documentation describes and what the architecture actually enforces. That gap is where every major security incident of the last decade has lived. Clarity closes it structurally. No other engineering platform does.