# AIEP GENOME SDK: An Architectural Standard for Protocol-SaaS Layer Isolation in Evidence-Governed AI Infrastructure ## AIEP-ARCH-STD-001 v1.1.0 **Neil Grassby** Phatfella Limited, United Kingdom *Correspondence:* aiep@phatfella.com *Document number:* AIEP-ARCH-STD-001 | *Version:* 1.1.0 | *Status:* FORMAL STANDARD — KERNEL FROZEN *Effective:* 2026-02-27 | *Supersedes:* AIEP-GENOME-SDK v1.0.0 *Licence:* Apache-2.0 | *Published:* 2026 --- > ⚠ This is not a design proposal. It is a specification with normative requirements. MUST, MUST NOT, and SHALL carry RFC 2119 meanings throughout. --- ## Abstract Governed evidence-management infrastructure designed for simultaneous deployment as a protocol reference implementation and a production-grade enterprise software service faces a structural paradox: determinism and mutability, append-only guarantees and SaaS configurability, and protocol canonicity and enterprise flexibility are simultaneously required yet architecturally in tension. This paper specifies the AIEP GENOME SDK Architectural Standard (AIEP-ARCH-STD-001 v1.1.0), which resolves this tension through a hard boundary architecture modelled on the Linux kernel/userland separation. A frozen kernel layer (v1.0.0) implements six constitutional invariants governing artefact integrity, deterministic serialisation, hash-binding, fail-closed gating, and constitutional arbitration. A LOCKFILE.json cryptographic manifest binds every kernel module to a specific hash at version declaration time; startup verification is fail-closed — any checksum mismatch causes the deployment to refuse initialisation. Eight canonicalisation rules (R1–R8) define the deterministic serialisation standard. A hostile cryptography audit addresses six attack vectors including SHA-256 collision, replay, registry substitution, silent kernel mutation, and concat boundary collision, with formal proof of boundary-collision impossibility. Mirror is elevated from optional integration to first-class architectural expectation, with all artefacts mirrorable by default under governance-controlled visibility modes. Conformance requirements are specified across four dimensions: kernel, gate, enterprise, and mirror. The standard is presented as a formal normative specification and demonstrates that the protocol-SaaS tension is not a design tradeoff but an architectural separation of concerns resolvable by hard boundary enforcement. **Keywords:** evidence governance; deterministic serialisation; kernel freeze architecture; cryptographic integrity; append-only ledger; SaaS-protocol boundary; constitutional invariants; AIEP GENOME SDK --- # **1. The Core Problem** GENOME must simultaneously satisfy two sets of non-negotiable requirements that are structurally in tension: **Property** **Protocol requirement** **SaaS requirement** **Conflict?** **Determinism** Identical inputs → identical outputs, always May need per-tenant configuration YES **Mutability** Canon-locked, version-fracture on change Configurable, extensible YES **State** Append-only, no delete Retention policies, GDPR deletion YES **Replay** Any party can replay from raw artefact Payloads may be private YES **Failure mode** Fail-closed — suppress execution on gate failure Graceful degradation preferred YES These conflicts cannot be resolved by tweaks, configuration flags, or runtime overrides. They can only be resolved by hard boundary architecture — a strict layered model in which the protocol layer is physically and logically isolated from the configuration layer. **AIEP-ARCH-001 **The resolution to the protocol/SaaS tension is strict layer isolation, not compromise. The kernel layer is the protocol. The enterprise layer is the configuration. They never touch. # **2. Required Architecture** The GENOME SDK is structured as five layers with unidirectional dependency. Lower layers never depend on higher layers. Higher layers may call lower layers but may never modify their behaviour. ## **2.1 Layer Structure** **Layer** **Directory** **Role** **Dependency rule** **0 — Kernel** kernel/ Cryptographic OS kernel. Protocol core. No external deps **1 — Governance** governance/ Protocol logic. Policy evaluation. kernel/ only **2 — Mirror** mirror/ First-class mirror surface. kernel/ \+ governance/ **3 — Enterprise** enterprise/ Configuration. Never logic. All layers — config only **4 — Examples** examples/ Conformance proofs. Read-only. All layers — read-only ## **2.2 Kernel Subdirectory Map** **kernel/canon/** Canonical serialisation engine. Rules R1–R8. Zero external deps. **kernel/hashing/** Algorithm registry. Collision policy. Timeout policy. **kernel/validation/** Invariant engine I1–I6. Returns GateResult. Never raises. **kernel/negative_proof/** Temporal evidence gap commitment. NegativeProofHash. **kernel/arbitration/** Constitutional arbitration. Admissibility evaluation. **kernel/LOCKFILE.json** Kernel freeze manifest. Mutation = version fracture. # **3. Kernel Freeze Specification (A)** The kernel/ layer is frozen at v1.0.0. This section defines what frozen means, what triggers a version fracture, and what the mutation rules are. ## **3.1 What Frozen Means** A frozen kernel means: - Any file in kernel/ that is changed requires a new KERNEL_VERSION in the affected module. - Any change to LOCKFILE.json requires a new LOCKFILE_VERSION. - A LOCKFILE_VERSION change breaks backward compatibility with all downstream repos. - Version fracture is not optional. It is enforced by kernel_bundle_hash in LOCKFILE.json. - Silent mutation is architecturally impossible — any change produces a hash mismatch detectable at load time. **AIEP-NMR-001 **No canonical artefact may be modified in-place after release. Any change is a clean rewrite issued as a new version, leaving prior versions immutable and replayable. ## **3.2 What Triggers Version Fracture** **Change** Version fracture required? **Hash algorithm (sha-256 → sha-3-256)** YES — LOCKFILE_VERSION \+ KERNEL_VERSION **Unicode normalisation (NFC → NFD)** YES — LOCKFILE_VERSION \+ KERNEL_VERSION **Key ordering rule** YES — LOCKFILE_VERSION \+ KERNEL_VERSION **Number normalisation rules** YES — LOCKFILE_VERSION \+ KERNEL_VERSION **MAX_ACTIVE_FRONTIER value** YES — LOCKFILE_VERSION \+ KERNEL_VERSION **Invariant I1–I6 logic change** YES — LOCKFILE_VERSION \+ KERNEL_VERSION **Governance/ policy change** NO — governance version only **Enterprise/ config addition** NO — config schema version only **Mirror visibility default change** NO — mirror_policy.json version only **Documentation update** NO ## **3.3 Kernel Properties (Non-Negotiable)** **✗ **kernel/ contains any UI logic **✗ **kernel/ contains any SaaS configuration **✗ **kernel/ imports any module outside kernel/ **✗ **kernel/ raises exceptions as control flow (GateResult pattern enforced) **✗ **kernel/ depends on current system time (timestamps are data, not datetime.now()) **✗ **kernel/ contains any network calls **✓ **kernel/ is fully replayable from raw artefact **✓ **kernel/ self-tests via run_self_test() with known hash vectors **✓ **kernel/ operates on explicit state parameters (no implicit state) **✓ **kernel/ has zero external dependencies beyond Python stdlib # **4. LOCKFILE and Checksum Model (B)** The LOCKFILE.json is the cryptographic manifest of the kernel freeze. It binds every kernel module to a specific hash at the time of version declaration. ## **4.1 LOCKFILE.json Structure** **Field** Description **LOCKFILE_VERSION** Version of this manifest. Increment on any lock change. **LOCKED_AT** ISO 8601 UTC timestamp of this freeze. Recorded as data. **canonical_schema.sha256** SHA-256 of aiep.canonical.schema.v2.0.0.schema.json. Must match on load. **deterministic_engine.*** Hash algorithm, encoding, concat method, unicode, numbers, key ordering. **kernel_bundle_hash** SHA-256 of the canonical JSON of all kernel file hashes. Detects any mutation. **kernel_files** Per-file SHA-256 map. Every kernel/ .py file is listed. **negative_proof_version** Version of NegativeProofRecord schema. **invariant_version** Version of invariants I1–I6. **max_active_frontier** MAX_ACTIVE_FRONTIER constant (16). Constitutional — not configurable. **mutation_rules** AIEP-NMR-001 statement embedded. **replay_requirement** AIEP-REPLAY-001 statement embedded. ## **4.2 Checksum Verification at Load Time** Any conformant GENOME deployment MUST verify the following at startup: - kernel_bundle_hash matches recomputation over kernel_files map - canonical_schema.sha256 matches the file at schemas/core/aiep.canonical.schema.v2.0.0.schema.json - SHA256SUMS.txt is verified for all SDK files **AIEP-VERIFY-001 **If any checksum fails at startup, the deployment MUST refuse to initialise. This is not a warning. It is a fail-closed startup gate. ## **4.3 Downstream Pinning** All downstream repositories (aiep-evidence-ledger, aiep-mirror, aiep-hub-validator) MUST pin a specific LOCKFILE_VERSION. When LOCKFILE_VERSION changes: - Downstream repo receives a PR with the new LOCKFILE_VERSION pinned. - CI in the downstream repo verifies the kernel_bundle_hash against the claimed LOCKFILE_VERSION. - If hashes do not match, CI fails and the downstream repo does not accept the update. # **5. Hostile Cryptography Audit (C)** This section simulates the questions a hostile cryptographic auditor would ask. Each attack vector is named, analysed, and answered with a specific control. ## **5.1 Attack Surface Summary** **Vector** **Attack** **Control** **Residual risk** **AV-001** SHA-256 collision AIEP-HASH-COLLISION-001 migration path. schema_version_id in all hashes. Negligible **AV-002** Replay of old commitment collection_ts \+ expiry_ts \+ schema_version_id bound in commitment. Low **AV-003** Registry substitution canonical_schema.sha256 in LOCKFILE. Checked at load time. Low **AV-004** Silent kernel mutation kernel_bundle_hash in LOCKFILE. CI enforced. Any mutation detectable. Negligible **AV-005** Concat boundary collision Length-prefixed-8be eliminates all boundary collisions algebraically. None **AV-006** Minus-zero injection R5: canon.py raises ValueError on minus-zero before hashing. None **AV-007** NFC bypass R3: NFC applied to all strings before serialisation. None **AV-008** Gate bypass via exception GateResult pattern — gate never raises, CLOSED is data not exception. Low ## **5.2 Boundary Collision Proof** The length-prefixed-8be concat method eliminates boundary collision. The proof: concat_hash("ab", "c") ≠ concat_hash("a", "bc") Encoding of ("ab", "c"): [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02] [0x61 0x62] ← len=2, 'ab' [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01] [0x63] ← len=1, 'c' Encoding of ("a", "bc"): [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01] [0x61] ← len=1, 'a' [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02] [0x62 0x63] ← len=2, 'bc' The byte sequences are distinct at byte 7 in the first group. SHA-256 of distinct inputs is distinct (with overwhelming probability under preimage resistance assumption A1). ## **5.3 Deterministic Replay Proof** The following hash outputs are fixed reference values. Any conformant implementation, on any machine, at any time, MUST produce these exact values from the fixed inputs in examples/deterministic_trace_v1/trace.py: **Step** Expected SHA-256 (hex-lower) **Step 1: Canonical JSON hash** 7da3d0cf50986a44d34dfd66e46d54b26d6685d508dfdada80f79153c855d7e8 **Step 2: EvidenceCommitment** 3bc275ffb68f68e72c9e71c20e1fdf5f924c9b16298426f0bfe29a225a5ad4af **Step 5: ReplayPack hash** 827955f221a3115fe0d58e43f3bacfe9e0490c45d0aed7dbd4d6884a4e8d4075 **Step 6: NegativeProof hash** 5309c9344c1bc9af01f46a79dd07ec27975a6dec58509b55b2fdf870093bff56 **AIEP-REPLAY-001 **Any two systems with identical Evidence Ledger, Reasoning Ledger, and LOCKFILE_VERSION MUST produce identical pack_hash. If they do not, one or both systems are non-conformant. ## **5.4 Fail-Closed State Diagram** The gate evaluation produces exactly two states. There are no intermediate states, no error states, and no timeout states for deterministic operations. Operation requested | Evaluate I1–I6 (all checked, even if earlier fail) | ┌─────────────────┐ │ All pass? │ └────┬──────┬─────┘ YES NO | | OPEN CLOSED Proceed Suppress \+ append rejection record **⚠ **CLOSED is a deterministic non-executable state. It is not an error. It cannot be caught as an exception. It cannot be suppressed by any instruction above the kernel. # **6. Enterprise Boundary (Linux Kernel / Userland Model)** The enterprise/ layer is the userland. It has full access to kernel/ APIs but zero ability to modify kernel behaviour. This is the same model as Linux: the kernel provides syscalls; userland cannot patch the kernel at runtime. ## **6.1 What Enterprise Config MAY Control** **✓ **Mirror visibility (PUBLIC / PRIVATE / SELECTIVE) **✓ **Storage backend and location (sqlite, postgres, S3, custom) **✓ **Authentication provider (JWT, OAuth2, SAML, API key) **✓ **Multi-tenancy mode (single, multi, isolation level) **✓ **GDPR/retention: records can be tombstoned (commitment preserved, payload already deleted by design) ## **6.2 What Enterprise Config MAY NOT Control** **✗ **kernel.canon.algorithm — hash algorithm selection **✗ **kernel.canon.unicode_normalisation — NFC is non-negotiable **✗ **kernel.canon.key_ordering — lexicographic UTF-8 byte order is non-negotiable **✗ **kernel.validation.invariants — I1–I6 are constitutional **✗ **kernel.validation.max_active_frontier — 16 is a constitutional constant **✗ **kernel.arbitration.constitutional_constraints — CC-001 through CC-005 are non-negotiable **✗ **kernel.negative_proof.hash_function — negative_proof_hash algorithm is locked **AIEP-ENTERPRISE-001 **Enterprise configuration controls WHERE data goes and WHO can access it. It never controls HOW data is hashed, validated, or arbitrated. These are different concerns at different architectural layers. # **7. Mirror as First-Class Architectural Expectation** Mirror is not a feature. It is not an integration. It is a first-class architectural expectation. Every artefact produced by the GENOME kernel is mirror-compatible by default. ## **7.1 The Mirror Rule** **AIEP-MIRROR-001 **All artefacts are mirrorable. Visibility is governed, not optional at code level. The kernel always assumes mirror compatibility. Mirror cannot be bolted on after the fact. ## **7.2 Visibility Governance Model** **Mode** Description **PUBLIC** Mirror page accessible without authentication. Default for Hub deployments. **PRIVATE** Mirror page requires authentication. Default for GENOME SaaS deployments. **SELECTIVE** Visibility configured per artefact. Requires explicit governance decision per record. Visibility mode is an enterprise/config concern. It never affects the kernel-level content_hash computation. ## **7.3 Mirror Content Hash Binding** **AIEP-MIRROR-002 **mirror.content_hash = sha256(canonical_json(data)). This is a kernel-level binding. It is computed by kernel/canon/. It cannot be overridden by enterprise/ config or mirror/ adapter. ## **7.4 No Additional Facts** **AIEP-MIRROR-003 **Mirror pages must not contain facts not derivable from the human-readable source page (P60). The mirror is a structured representation of the source — it is not an enrichment layer. # **8. Canonicalisation Rules (R1–R8)** These rules are implemented in kernel/canon/canon.py and locked in LOCKFILE.json. They are constitutional. Changing any rule requires LOCKFILE_VERSION increment. **Rule** Definition **R1 Key ordering** All JSON object keys sorted by lexicographic UTF-8 byte order (RFC 8785 / JCS-compatible). **R2 No whitespace** Compact serialisation. No indentation, padding, or trailing whitespace. **R3 Unicode NFC** All string values normalised to NFC before serialisation. ensure_ascii=False (no \\uXXXX escape). **R4 SHA-256** All digests are SHA-256, lowercase hexadecimal, 64 characters. **R5 Number rules** No scientific notation. Trim trailing zeros. Minus-zero forbidden (raises ValueError). **R6 UTF-8** All serialisation and hashing in UTF-8 strict mode. **R7 Length-prefix** Multi-part hash inputs use 8-byte big-endian length prefix. Eliminates boundary collision. **R8 Timestamps as data** Timestamps are recorded values. datetime.now() is never used as a hash input. # **9. Conformance Requirements** An implementation is AIEP GENOME conformant if and only if it passes all of the following: ## **9.1 Kernel Conformance** - MUST pass kernel/canon/canon.py run_self_test() with zero failures - MUST produce the reference hashes in Section 5.3 from the inputs in examples/deterministic_trace_v1/trace.py - MUST verify kernel_bundle_hash in LOCKFILE.json at startup - MUST verify canonical_schema.sha256 in LOCKFILE.json at startup - MUST fail startup (not warn) if any LOCKFILE.json checksum does not match ## **9.2 Gate Conformance** - MUST evaluate all six invariants (I1–I6) before any gated operation - MUST NOT proceed after a CLOSED gate - MUST NOT retry without resolving the violation - MUST NOT treat CLOSED as a transient error - MUST append a rejection record on CLOSED ## **9.3 Enterprise Conformance** - MUST NOT expose any mechanism for enterprise config to modify kernel/ behaviour - MUST NOT expose any mechanism to override content_hash computation - MUST NOT expose any mechanism to disable the fail-closed gate - MUST enforce enterprise/config/config_schema.json validation at startup ## **9.4 Mirror Conformance** - MUST treat all artefacts as mirrorable by default - MUST enforce visibility at the mirror/ layer, never at the kernel/ layer - MUST compute content_hash via kernel/canon/canonical_json() only - MUST NOT add facts to mirror pages not present in the source ## Discussion ### The Kernel Freeze Tradeoff The central architectural decision in this standard — freezing the kernel at v1.0.0 — represents an explicit tradeoff between stability and adaptability. The tradeoff is intentional and justified: the invariants I1–I6 and canonicalisation rules R1–R8 are properties of the evidence commitment protocol, not of any specific deployment. Changing them after deployment would invalidate the hash chain integrity of any existing evidence ledger. This is not a tradeoff specific to AIEP GENOME — it is the same tradeoff that makes the Bitcoin block structure immutable once adopted (Nakamoto, 2008) and that makes RFC 4122 (UUID specification) non-negotiable in deployed systems (Leach et al., 2005). However, the freeze creates a genuine engineering risk: if a vulnerability is discovered in the SHA-256 canonicalisation chain (attack vector AV-001 in Section 5), the migration path is constitutional rather than operational. The AIEP-HASH-COLLISION-001 migration specification is referenced but not fully elaborated in this document. Future versions should provide a complete specification of the hash algorithm migration procedure, including backward compatibility guarantees for evidence committed under the prior algorithm. ### Comparison with Existing Evidence Management Approaches The GENOME architecture occupies a specific position in the design space of evidence management infrastructure. Blockchain-based approaches (Wood, 2014; Buterin, 2014) share the append-only, hash-chained, immutable properties of the GENOME evidence ledger, but they are general-purpose distributed ledgers designed for financial transactions rather than for governed reasoning artefacts. They do not implement evidence weighting, branch genealogy, or constitutional arbitration. The GENOME kernel is more constrained than a general-purpose blockchain, but more expressive along the specifically governed-reasoning dimensions. Verifiable credentials systems (W3C, 2022) address some of the same auditability requirements but at the data layer rather than the computation layer — they attest to data properties, not to the integrity of the reasoning process that produced conclusions from data. The GENOME kernel includes both layers: the canonical hash attests to both the data and the deterministic computation performed on it. The enterprise configurability model has a direct precedent in the OpenID Connect / OAuth 2.0 architecture, where the protocol layer is standardised and the identity provider implementation is enterprise-configurable. AIEP-ENTERPRISE-001 formalises the equivalent separation for evidence governance. ### Practical Conformance Considerations The conformance requirements in Section 9 are necessary but not sufficient for operational deployment. Several practical considerations are outside the scope of this standard but affect conformance in practice. Multi-tenancy isolation — where a single GENOME deployment serves multiple organisations — requires that no tenant's evidence artefacts can affect the hash chain integrity of another tenant's artefacts. The standard specifies that enterprise configuration controls multi-tenancy mode but does not fully specify the isolation guarantees required. Operational key management — the procedures for the governance keys used in constitutional arbitration — are also outside scope but material to the security properties of a deployed system. These are areas where implementation guidance documents supplementing this standard are needed. ### Limitations The standard specifies conformance requirements but not performance requirements. A conformant implementation that satisfies all four conformance criteria but takes minutes to produce a kernel hash would be conformant but operationally unusable. Future revisions should include normative performance bounds for kernel operations. Additionally, the standard describes the GENOME SDK in isolation; the interaction properties of multiple GENOME deployments participating in a shared swarm substrate are specified in separate AIEP specifications (AIEP-GB1 through AIEP-P100) that are referenced but not reproduced here. ## Conclusion This standard specifies the hard boundary architecture that resolves the fundamental tension in governed evidence infrastructure between protocol canonicity and enterprise configurability. The frozen kernel layer (v1.0.0), LOCKFILE.json cryptographic manifest, six constitutional invariants, and eight canonicalisation rules together provide the guarantee that any two conformant implementations produce identical outputs from identical inputs — a property necessary for trust in distributed evidence management at scale. The hostile cryptography audit demonstrates that the six principal attack vectors are either eliminated algebraically (concat boundary collision via length-prefix-8be), negated by fail-closed design (gate bypass), or reduced to negligible residual risk through specific controls. Mirror as first-class architectural expectation, with governance-controlled visibility rather than build-time configuration, ensures that auditability is a structural property of the system rather than an optional integration. The Linux kernel/userland model applied to evidence governance provides an established design precedent for hard boundary enforcement that the AI governance field can build on. The primary research programme ahead includes formal verification of the invariant set, migration path specification for hash algorithm succession, and swarm consensus properties at deployment scale. --- ## References 1 Bai, Y. et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.06950. 2 Buterin, V. (2014). Ethereum: A Next-Generation Smart Contract and Decentralised Application Platform. Ethereum Foundation. 3 ENISA. (2021). Securing Machine Learning Algorithms. European Union Agency for Cybersecurity. 4 EU. (2024). Artificial Intelligence Act. Regulation (EU) 2024/1689 of the European Parliament and of the Council. 5 Grassby, N. (2025–2026). AIEP Specification Portfolio. GB2519711.2, GB2519798.9, GB2519799.7, GB2519801.1, GB2519826.8. Phatfella Limited. 6 Jones, M. et al. (2015). JSON Web Token (JWT). IETF RFC 7519. 7 Lamport, L. (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, 21(7), 558–565. 8 Leach, P., Mealling, M. & Salz, R. (2005). A Universally Unique IDentifier (UUID) URN Namespace. IETF RFC 4122. 9 Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. 10 NCSC. (2022). Guidelines for Secure AI System Development. UK National Cyber Security Centre. 11 W3C. (2022). Verifiable Credentials Data Model v1.1. W3C Recommendation. 12 Wood, G. (2014). Ethereum: A Secure Decentralised Generalised Transaction Ledger. Ethereum Project Yellow Paper. --- # **10. Version History** **Version** Change **1.0.0** Initial SDK release. Schemas, policy docs, CI. Classified as serious prototype. **1.1.0** Hard boundary architecture. Kernel frozen at 1.0.0. LOCKFILE.json introduced. Security layer added. Mirror elevated to first-class. Enterprise config boundary formalised. Deterministic trace with reference hashes. **AIEP-NMR-001 **v1.0.0 is immutable and referenceable. Any deployment pinning v1.0.0 remains valid indefinitely. v1.1.0 adds the kernel freeze layer; it does not change the canonical schema. AIEP GENOME SDK — Architectural Standard AIEP-ARCH-STD-001 v1.1.0 | Apache License 2.0 | Phatfella Ltd / AIEP Ltd | 2026