Personal Knowledge Model (PKM) Upgrade Rehearsal
Public concept page defining the zero-information-loss upgrade and rehearsal framework for Hussh Personal Knowledge Models (PKM), framed on Hussh's control-plane posture.
TL;DR: A PKM upgrade rehearsal tests whether a specified version change preserves every supported historical information occurrence, keeps uncertain information in encrypted quarantine, and can roll back coherently. Passing a bounded rehearsal is required evidence for that upgrade; it is not a universal guarantee that every future migration or recovery path is lossless.
Status as of 2026-09-23: engineering acceptance method. The checked-in PKM stores segmented ciphertext and versioned structural metadata. One-owned portable memory and complete provider-backed recovery remain qualified product goals, not established by the rehearsal alone.
Relations
- One β private-agent ownership direction.
- PCHP β scoped consent and export boundary.
- Connected Systems β source integration context.
What a rehearsal proves
For a named source version, target version, and historical corpus, the upgrade process decrypts only in an authorized key-holding boundary, transforms the information, encrypts it again, and compares the result with occurrence-level lineage. It checks values and types, equal-value deduplication, version and scope coherence, repeatability, and rollback to a new coherent revision. Unknown or conflicting information is preserved in encrypted private quarantine rather than silently discarded.
A passing result applies to the tested corpus, code revision, storage shape, key boundary, and environment. A new migration, unsupported historical shape, provider recovery path, or deployed client requires its own evidence. The model can propose structure; it cannot authorize dropping or overwriting a person's information.
Storage and custody boundary
The current PKM architecture stores encrypted segments with versioned metadata. A coherent read binds ciphertext to its content and manifest revisions. This source-level property does not by itself prove where every owner's compute runs, which provider holds recovery material, or whether every backup and deletion path is complete. Those claims require separate target-specific verification.
The private agent is the intended owner relationship layer. Current implementation evidence still includes finance-specialist compatibility paths. The rehearsal checks preservation across a specified transition; it does not turn the whole One ownership and recovery roadmap into current deployed behavior.
Promotion gate
An upgrade should advance only after deterministic historical fixtures pass with no lost, changed, or unmapped occurrences; uncertain values remain quarantined; scopes and authority remain stable; the target schema and routes are checked; and rollback restores an equivalent coherent view. A reviewer session may then verify an authorized sample in the app without storing keys or decrypted information in artifacts. A failing case blocks promotion until it is resolved or explicitly bounded.
Sources
- Hussh Research repository β checked-in PKM storage and upgrade contracts.
- Internal Hussh private-agent north star β custody and recovery qualifications.
- Internal Hussh PKM upgrade rehearsal and reviewer acceptance contracts β historical corpus, rollback, and scope proof requirements.