Protocol Governance

AIEP is an open protocol. Its governance is designed to serve a single goal: ensuring that “AIEP-compliant” means something verifiable and consistent, no matter who implements it or where.

This page explains how the protocol itself is governed — how the spec evolves, how the GENOME kernel is kept stable, how builders participate, and who stewards the patent estate.


Governance principles

Every design decision, spec extension, and implementation choice in AIEP is constrained by a set of canonical principles. The core four that bear directly on governance:

PrincipleWhat it means in practice
Deterministic reasoningOutputs must be reproducible from inputs. No governance decision can introduce indeterminacy into the canonical kernel.
Evidence chain integrityEvery spec change must be traceable to evidence — prior art, test results, or formal proof. Protocol changes are not made by opinion.
Open auditability, closed implementationThe specification is fully public. Piea’s implementation is a trade secret. Anyone can verify compliance; no one can clone the runtime without a licence.
Version pinningEvery spec, schema, and contract is version-pinned. Unversioned artefacts are not valid.

These constraints mean that protocol governance is, by design, conservative. Adding a capability is easy. Changing something that could break existing conformant implementations requires a major version bump and migration documentation.


How the specification evolves

AIEP uses Semantic Versioning across all documents, schemas, and engineering specs:

Version changeWhen it applies
MAJORBreaking change — existing implementations must update
MINORBackwards-compatible new capability or field
PATCHClarification, typo fix, non-normative change

What freezes a version

A specification version is frozen the moment it is:

  1. Published at https://aiep.dev
  2. Referenced in a filed patent application with the UKIPO
  3. Committed to an open-source repository
  4. Distributed under a licence or NDA

Frozen versions are not edited. A new version is created instead. The previous version remains at its published path — the record does not change retroactively.

Breaking changes

A breaking change to any core protocol document requires:

  • A MAJOR version increment
  • An entry in the Innovation Ledger
  • A migration note in the schema catalogue
  • Legal review if the document is patent-referenced

This process is slow by design. The integrity of existing deployments takes precedence over convenience.


GENOME lockfile integrity

The GENOME canonical kernel (R1–R8) is the cryptographic foundation of the entire protocol. It is pinned by a single file: GENOME_LOCKFILE.json.

The lockfile records:

{
  "version": "1.0.0",
  "kernel": {
    "R1": { "label": "sorted-keys", "hash": "sha256:..." },
    "R2": { "label": "compact-separators", "hash": "sha256:..." },
    "R3": { "label": "nfc-unicode", "hash": "sha256:..." },
    "R4": { "label": "nan-rejection", "hash": "sha256:..." },
    "R5": { "label": "negative-zero-rejection", "hash": "sha256:..." },
    "R6": { "label": "empty-string-rejection", "hash": "sha256:..." },
    "R7": { "label": "type-coercion-rejection", "hash": "sha256:..." },
    "R8": { "label": "canonical-hash", "hash": "sha256:..." }
  }
}

Every AIEP SDK and conformant implementation ships with a hash of this lockfile. Any implementation that deviates from the canonical kernel produces pack hashes that are incompatible with all other implementations — the divergence is mechanically detectable, not a matter of interpretation.

Changing the GENOME kernel is a MAJOR version event with patent implications. It has never been done. The kernel is stable by design.


Community participation

AIEP is an open protocol and its specifications are publicly available. Community participation currently operates through:

  • GitHub: Open issues and pull requests against the public repositories are reviewed for spec alignment. Proposals that add capability without breaking existing conformant implementations are accepted as MINOR changes.
  • Builders Programme: The Builders Programme offers early access to pre-release specs, direct input into roadmap prioritisation, and attribution for implementations that advance the protocol.
  • GENOME SDK: Any developer can run aiep-genome-sdk --self-test to verify that their local kernel matches the canonical lockfile. Divergence is a first-class observable event.
  • Innovation Ledger: The public changelog records every spec change with rationale and version history. The record is append-only by convention.

Protocol governance proposals that involve changes to the GENOME kernel, the canonical schema format, or the Mirror discovery standard require review against the full specification and legal review against the patent portfolio before acceptance.


Certification and conformance

Using AIEP does not require certification. Open use is always permitted. The certification layer exists only to protect the meaning of a specific claim: “AIEP Certified.”

The certification process:

  1. An implementation publishes a complete .well-known/aiep/ surface
  2. The AIEP Hub Validator runs 15 structural checks against the live endpoint
  3. A conformance certificate is generated, hash-bound to the validator output
  4. The certificate is listed in the public registry

A self-test pass (aiep-validator --self-test) is a necessary but not sufficient condition for certification. Full certification requires the live endpoint to pass the complete validation suite.

See: Certification & Registry


Patent stewardship

AIEP has filed 26 patent applications with the UK Intellectual Property Office across four filing layers:

LayerFiledApplicationsCoverage
Layer 1 — FoundationNovember 20259 (P01–P09)Constitutional substrate, canonical primitives, quantum alignment, hardware governance chip
Layer 2 — Constitutional Stack07 April 20269 (P37, P41, P46, P50, P79, P80, P83, P89, P91)Deterministic divergence, recall substrate, GoalVector, meta-strategy, dual-ledger memory
Layer 3 — AGI Cognitive Architecture08 April 20266 (P200, P209, P210, P264, P265, P269)World-model substrate, multi-agent reasoning, goal arbitration, federation, cross-boundary validation
Layer 4 — Serialisation & Encoding11 April 20262 (P270, P273)Cross-platform fixed-point float serialisation, canonical JSON normalisation

The patents protect the implementation. They do not restrict open use of the protocol. An organisation publishing a Mirror endpoint, building a validator, or using the GENOME SDK to create verifiable records does not require a patent licence.

A patent licence is required for:

  • Deploying production systems that implement the full Piea Surface (P116–P128) as a commercial offering
  • Embedding the AIEP Miner governance architecture in commercial autonomous systems

Open-source, academic, and personal projects are not subject to licence requirements.

See: Patents · IP & Licensing


Decision authority

AIEP is founder-governed at this stage of development. Protocol decisions that affect the canonical kernel, the patent estate, or the certification standard are made by the AIEP founder.

Decisions that do not affect any of these — open-source contributions, community implementations, vertical AIEP applications, sector-specific Mirror extensions — do not require central approval. The protocol is designed so that most things communities might want to do are architecturally possible without changing the spec.

The governance model will formalise as the protocol matures. The Builders Programme is the first step toward a broader governance structure that reflects the community of production implementations.