P129 — AIEP — Trusted Node Hardware Attestation Protocol

Publication Date: 2026-03-13 Status: Open Source Prior Art Disclosure Licence: Apache License 2.0 Author/Organisation: Phatfella Ltd Schema: AIEP_OS_SPEC_TEMPLATE v1.0.1 — https://aiep.dev/schemas/aiep-os-spec-template/v1.0.1

Framework Context

[0001] This disclosure operates within an Architected Instruction and Evidence Protocol (AIEP) environment as defined in United Kingdom patent application number GB2519711.2, filed 20 November 2025, and GB2519798.9, filed 20 November 2025, the entire contents of which are incorporated herein by reference.

[0002] The present disclosure specifies the architecture of an AIEP Trusted Node — a self-contained substrate emulator running on local or embedded hardware that generates a cryptographic identity, maintains an evidence ledger, enforces governance rules through a power-graduated capability model, and seals its full operational record for migration when energy budget falls to a defined threshold.

Field of the Disclosure

[0003] This disclosure relates to governed artificial intelligence substrate nodes that maintain cryptographically anchored identity, graduated operational capability under power constraint, admissibility-gated evidence ingestion, and sealed signed migration of accumulated ledger state to a successor node.

[0004] More particularly, the disclosure concerns: (a) ECDSA P-256 node identity derived from a hashed environment fingerprint; (b) a graduated power state model with four defined states and associated capability suspension tables; (c) a governance admissibility layer enforcing power budget and payload size thresholds before evidence is committed to the node ledger; (d) negative proof issuance for rejected operations; (e) reasoning chain construction binding inference steps to committed evidence artefacts; and (f) a sealed migration procedure producing a signed MigrationRecord at power State D.

Background

[0005] AI substrate nodes deployed on constrained hardware must operate correctly under degraded power conditions without silently ignoring governance constraints. Existing approaches either shut down capability entirely at low power or continue operating without any governance guard, creating a gap between full operation and complete shutdown during which ungoverned inference may occur.

[0006] Evidence-grounded AI systems require that every ingested source passes an admissibility check before its content is committed to the evidence ledger. Without a per-record admissibility gate enforcing minimum power budget and maximum payload size, an underperforming or overloaded node may commit evidence that degrades inference reliability.

[0007] When a hardware node must be decommissioned or migrated, the accumulated evidence ledger, reasoning chains, and negative proof records represent auditable state that must be transferred with cryptographic integrity guarantees. Without a formal sealed migration procedure, this state is either silently discarded or transferred without a verifiable provenance chain.

Summary of the Disclosure

[0008] A NodeIdentity is generated at boot by: (a) creating an ECDSA P-256 key pair via the Web Crypto API; (b) exporting the public key in raw format and deriving a nodeId as the prefix "aiep-node-" concatenated with the first 16 hexadecimal characters of the SHA-256 hash of the raw public key bytes; (c) computing an environmentFingerprint as the first 32 hexadecimal characters of the SHA-256 hash of the concatenated string platform:arch:nodeVersion derived from the runtime process context.

[0009] The PowerGovernor maintains one of four discrete power states — A (100%), B (60%), C (30%), D (15%) — and a monotonic capability suspension table:

State transitions are monotonic in both directions. Each transition notifies registered onStateChange listeners synchronously. isCapable(capability) returns false for any capability in the suspension table of the current state.

[0010] The Governance Admissibility Gate is applied before each evidence commit. A record is rejected (and a negative proof issued) if: (a) the fetch status is "failed"; (b) the current power budget is below 15%; or (c) the content byte length exceeds 512,000 bytes (500 KB). All three conditions produce a distinct reason string in the resulting NegativeProofRecord.

[0011] A NegativeProofRecord comprises: a 32-character id derived as the truncated SHA-256 hash of the concatenated string negative-proof:{operation}:{reason}:{timestamp}; the operation string identifying the rejected step; the reason string explaining rejection; the issuing node_id; an ISO 8601 timestamp; and a base64-encoded ECDSA-P256 signature over {id}:{operation}:{reason}:{node_id}:{timestamp} signed with the node’s private key.

[0012] A ReasoningChain is constructed by the node’s reasoning module, binding multi-step inference trajectories to the set of evidence artefacts committed to the ledger at the time of construction. Dissent forks are recorded when two or more reasoning chains arrive at mutually incompatible conclusions using overlapping evidence artefacts.

[0013] Sealed Migration is triggered automatically when the PowerGovernor transitions to State D. sealAndMigrate() produces a MigrationRecord comprising: a migration_id (32-character truncated SHA-256 of migration:{nodeId}:{ledger_hash}:{sealed_at}); the source_node_id; a ledger_hash computed as the SHA-256 hash of the concatenation of all committed evidence content hashes in ledger order; the chain count; the negative proof count; a sealed_at ISO 8601 timestamp; and a base64-encoded ECDSA-P256 signature over {migration_id}:{node_id}:{ledger_hash}:{sealed_at}.

[0014] The node exposes a machine-readable mirror at /.well-known/aiep/ publishing a JSON manifest and a content-hashed index of committed pages. This mirror follows the format specified in P61 (Well-Known Manifest Specification) and the extension defined in P132.

Detailed Description

[0015] NodeIdentity Interface:

interface NodeIdentity {
  nodeId: string;                // "aiep-node-" + sha256(publicKeyRaw).slice(0,16)
  publicKeyJwk: JsonWebKey;      // exportable ECDSA P-256 public key
  privateKey: CryptoKey;         // non-extractable private key
  publicKey: CryptoKey;          // CryptoKey object for verification
  environmentFingerprint: string; // sha256("platform:arch:nodeVersion").slice(0,32)
}

[0016] PowerGovernor Interface:

interface PowerGovernor {
  onStateChange(listener: (state: PowerState) => void): void;
  getState(): PowerState;
  getBudget(): number;
  degrade(): PowerState;
  restore(): PowerState;
  isCapable(capability: string): boolean;
  getStateChangedAt(): Date;
}

[0017] AdmissibilityResult Interface:

interface AdmissibilityResult {
  admissible: boolean;
  reason?: string;  // present when admissible === false
}

[0018] MigrationRecord Interface:

interface MigrationRecord {
  migration_id: string;      // 32-char truncated SHA-256
  source_node_id: string;
  ledger_hash: string;       // SHA-256 of concatenated content hashes
  chain_count: number;
  negative_proof_count: number;
  sealed_at: string;         // ISO 8601
  signature: string;         // base64 ECDSA-P256 over canonical payload
}

[0019] Boot Sequence. On first boot the node: (a) generates a NodeIdentity; (b) loads governance rules; (c) initialises the evidence ledger (empty); (d) sets PowerGovernor to State A; (e) registers the auto-migration listener for State D transitions; (f) starts an HTTP dashboard; and (g) begins the evidence polling cycle against a defined set of baseline source URLs.

[0020] Evidence Polling Cycle. On each cycle, the node selects the next source URL from a round-robin baseline source list, fetches the URL via HTTP, computes the SHA-256 content hash of the response body, and invokes checkAdmissibility(). If admissible, the record is appended to the evidence ledger. If rejected, issueNegativeProof() is called and the record is discarded from the ledger.

[0021] Capability Degradation Contract. A capability is considered suspended if and only if its identifier string appears in the SUSPENDED_CAPABILITIES entry for the current PowerState. The contract guarantees that capability checks are purely table-driven — no imperative logic evaluates power budget thresholds at the point of use.

[0022] Signing Protocol. All ECDSA signatures use the ECDSA-P256 algorithm with SHA-256 as the hash function, producing a raw DER-encoded signature of 64 bytes, serialised as a base64 string. The signing private key is generated non-extractable at boot and is not persisted to disk; its loss prior to migration means the associated NodeIdentity cannot sign further records.

[0023] Distinction from Cloud Substrate (P116). P116 defines a cloud-resident, always-running substrate with Durable Object persistence and multi-channel delivery. P129 defines a hardware-resident substrate with power-graduated capability, local evidence polling, and a one-way sealed migration exit path. The two substrates are architecturally complementary: a P129 node may act as a local evidence collector whose ledger is migrated into a P116 cloud substrate for long-term governance continuity.