Recursive Entropy Chaining (PBREC)

Recursive entropy chaining is the design for keeping one identity continuous while the hardware under it is replaced piece by piece. It is described in patent application 19/567,418, a continuation-in-part pending USPTO examination. Almost none of it is built, and this page is here so the design is not read as behaviour.

What ships today. One action. pg_succession, on the console-only shield-provenance-guard function, writes a row to shield_succession_tokens after checking that at least two senior, active devices vouch for the arriving device. That row is a record of a handover, not a verified chain: nothing signs it, nothing recomputes or checks the chain hash, and the departing device is not deactivated.

What does not exist. There is no Entropy Succession Token generator, no hand-off ceremony beyond that single insert, and no trust-thread verifier anywhere in the build. No function reads shield_succession_tokens back.

The nearest shipped feature. Device enrolment, junior and senior ranks, the quorum requirement and the three-channel verdict are real and are what a constellation runs on today: Provenance Guard.

shield_succession_tokens (migration 20260318125148) holds one row per recorded handover. pg_succession writes these columns:

Two columns exist on the table and are never written: vouching_signatures and pqc_signature. In the design, the departing device and the quorum sign the token with ML-DSA-65. The shipped action writes neither, so a row establishes that an admin asked for a handover and that two senior devices were named, and nothing beyond that.

Because no function reads these rows, the chain is a set of independent records rather than a sequence anything walks or validates. entropy_chain_hash is accepted as an opaque string of the caller's choosing.

pg_succession is reached like every other Provenance Guard action: supabase.functions.invoke with a signed-in tenant admin on the Enterprise plan. There is no public endpoint, and api.passkeybridge.io/v1/shield-provenance-guard answers 404 unknown-function.

const { data, error } = await supabase.functions.invoke("shield-provenance-guard", {
  body: {
    action: "pg_succession",
    tenant_id: tenantId,
    user_hash: userHash,
    new_device_id: newDeviceId,
    vouching_device_ids: [seniorDeviceA, seniorDeviceB],
    entropy_chain_hash: chainHash,
  },
});

The response carries the new row and its timestamp:

{
  "ok": true,
  "succession_token": { "id": "uuid", "created_at": "2026-09-16T17:00:00Z" },
  "correlation_id": "uuid"
}

The arriving device must already be enrolled through pg_enroll before it can be named here, and it keeps whatever rank it has. Promotion still runs through pg_promote and its attestation threshold.

Confirm it in Dashboard, Operations, Audit log: a successful call writes succession_ceremony with the token id as the resource. The device provenance tab does not list succession tokens, so the audit entry is the only place a handover surfaces in the UI.

Every item below is patent-application text with no implementation in this build.

• Entropy Succession Token. The design derives token contents from the atomic fingerprints of the departing and arriving devices and binds them with an ML-DSA-65 signature. The shipped row stores a chain hash the caller computed and carries no signature.
• Chain verification. The design links each token to the previous one and verifies the sequence. No code computes or walks that chain.
• Rank transfer. The design has the arriving device inherit junior rank while the departing device is deactivated. pg_succession updates no device row at all.
• Trust thread runtime. Nothing reads succession tokens, so nothing can report whether a thread is intact.
• Proximity fallback hierarchy. The design orders LEO Doppler, then UWB, then BLE. What ships is a flat protocol list with a distance bound for each, plus Wi-Fi and cell co-presence, and pg_succession stores the protocol string without checking it against anything. The real list is in Provenance Guard.

For the cryptography that does ship, including hybrid ML-DSA-65 signing and per-tenant key management, see Security and cryptography.