Compliance-to-Architecture Specification

§1 — Conformance

An implementation conforms to the Compliance-to-Architecture v0.1 specification iff:

1. it accepts every manifest that passes the canonical validateManifest check;
2. it rejects every manifest that fails the check with a structured issues[] array;
3. it emits every state-changing decision as an Evidence Pack with lineage to the Rule Pack and Manifest versions in force;
4. it stores Evidence Packs in append-only storage with at-least retention-floor protection per §4;
5. it exposes the conformance test endpoint at /.well-known/cta-conformance.

§2 — The 8-Layer Spine

Every artefact in the framework lives at exactly one of these eight layers. Inventing a ninth layer is a constitutional defect — propose a specification amendment instead.

1. L1

   Profile

   A Profile is a stable, named set of conformance criteria. Few and stable. Profiles answer: 'what must an implementation support to be CtA-compliant in this area?' Profiles are versioned semver and have an in-force date.

2. L2

   Rule Pack

   A Rule Pack is a versioned, signed collection of rules grouped by contract type, jurisdiction, regulator, sector, or risk tier. Each rule cites an authority clause and an obligation. Rule Packs are the unit of regulatory change-management.

3. L3

   Dictionary

   A Dictionary is a versioned set of canonical terms with definitions, synonyms, and cross-references. Prevents every regulator / consultant / vendor from inventing different terms for the same concept.

4. L4

   Manifest

   A Manifest is a single signed JSON document binding identity → spine layer → authority → controls → evidence → conformance. Manifests are the marketplace unit — what gets installed, certified, billed, audited.

5. L5

   Gateway

   A Gateway is a deployed service or edge worker that wraps Engines + Rule Packs and emits an AuditTrailEntry per request. Gateways are where a 'should this proceed?' decision happens at runtime.

6. L6

   Engine

   An Engine is the deterministic execution layer. Engines never improvise — they evaluate against versioned Rule Packs + Manifests + Dictionaries and emit structured outputs with audit-trail entries.

7. L7

   Rail

   A Rail is an operating-line abstraction grouping related capabilities. Two tiers: operational backbone rails (Identity, Consent, Evidence...) and product rails (specific contract types / sectors).

8. L8

   Evidence Pack

   An Evidence Pack is the legal-grade record of a state-changing decision. Every Engine output that touches a regulated state produces one. Each pack carries: lineage (which Rule Pack / Manifest / Dictionary versions were in force), inputs (canonical JSON), outputs (canonical JSON), and a cryptographic signature.

§3 — Manifest shape

The canonical manifest is a single JSON document. Required fields: schemaVersion, id, name, version, kind, spineLayer, provenance.

{
  "schemaVersion": "0.1",
  "id": "urn:cta:control:iam:access-review:001",
  "name": "Periodic identity and access review",
  "version": "1.0.0",
  "kind": "control",
  "spineLayer": 5,
  "authorities": [
    {
      "framework": "ISO_27001",
      "version": "2022",
      "clauseRefs": [
        "A.5.18",
        "A.8.2",
        "A.8.3"
      ]
    },
    {
      "framework": "SOC_2",
      "version": "TSC-2017",
      "clauseRefs": [
        "CC6.1",
        "CC6.2",
        "CC6.3"
      ]
    },
    {
      "framework": "PCI_DSS",
      "version": "4.0.1",
      "clauseRefs": [
        "7.2.4",
        "7.2.5",
        "8.2.4"
      ]
    },
    {
      "framework": "NIST_CSF",
      "version": "2.0",
      "clauseRefs": [
        "PR.AA-01",
        "PR.AA-05"
      ]
    }
  ],
  "controls": [
    "CTRL-IAM-ACCESS-REVIEW-001"
  ],
  "evidenceKinds": [
    "access-review-attestation",
    "revocation-log",
    "reviewer-roster"
  ],
  "conformance": {
    "maturityLevel": 3,
    "assertedBy": "urn:org:example-corp",
    "assertedAt": "2026-05-18T00:00:00Z",
    "evidenceRetentionDays": 2555
  },
  "provenance": {
    "author": "urn:org:regunav-inc",
    "createdAt": "2026-05-18T00:00:00Z",
    "license": "Apache-2.0",
    "digestSha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
  }
}

§4 — Retention floors

Evidence Pack retention is per-domain × per-jurisdiction. Implementations MUST take the MAX of all in-scope jurisdiction floors:

§5 — Conformance criteria

The conformance suite ships in packages/ontology/conformance/. It runs a series of MUST / SHOULD / MAY tests against an implementation's public surface and emits a structured conformance report. Pass to claim "CtA-conforming" status.

• MUST tests — implementation rejected if any fail.
• SHOULD tests — failures generate warnings, not rejections.
• MAY tests — purely informational.
• The conformance report is itself a manifest — schema-valid, signed, and storable in an Evidence Pack.

§6 — Versioning policy

The spec follows semver. Patch releases are clarifications. Minor releases add backward-compatible fields. Major releases may break manifest compatibility; a migration tool is published with every major release. The current major is v0; v1.0.0 is targeted when the framework has been deployed in production by at least three independent organisations and the conformance suite has stabilised.