Verification protocol

The rules are publishable.

The verification protocol is the contract between the substrate and its consumers. It is not a manual; it is a list of rules a consumer or an auditor may follow to independently confirm that a delivery is what it claims to be.

Rules

Six rules. No exceptions.

Each rule is a single instruction. A delivery that fails any rule is not a delivery.

Rule I · Identity

The requester is verified at the edge before the substrate is touched. A request from an unverified identity is refused at the edge and is not recorded as a packaging event.

Rule II · Coherence

Packaging requires phi at or above 0.85 at the cycle of request. A request received during rebalancing is queued to the next coherent window or refused with a Retry-After header.

Rule III · Selection

Selection within the substrate is procedural. A request resolves to a region; the region is sampled; the sample is the input to packaging. Selection is logged.

Rule IV · Packaging

The packaging step is determined by the requester’s declared format and the published catalog. Packaging is deterministic given a sample, a format, and a cycle.

Rule V · Signature

Every delivered crystal carries an Ed25519 signature over the canonical body, the manifold-state hash, the phi value, and the trust-key identifier.

Rule VI · Locker

Every delivery writes a record to an independently operated evidence locker before the response is returned to the requester. A delivery whose locker write fails is not delivered.

Trust keys

Keys are published.

The current trust key and every retired trust key are published. Rotation is quarterly and is itself signed.

Trust-key registryapplication/json
{
  "current": "kts-trust-key/2026-04",
  "alg": "Ed25519",
  "rotation": "quarterly",
  "retired": [ "kts-trust-key/2026-01", "kts-trust-key/2025-10" ]
}