Skip to content
Hussh
Connect MCP

World Model — user-side personal-knowledge store

North-star framing for user-owned personal context. Current repo truth is PKM/vault plus encrypted scoped exports; local/on-device claims remain future-state unless proven.

Concept

TL;DR: World Model is the north-star name for the user-owned personal context model that One can reason over only through consent, vault, PKM, and audit boundaries. Current repo truth is narrower: PKM/vault plus encrypted scoped exports. Local/on-device storage, schema, and Secure Enclave specifics remain future-state unless proven.

  • Status as of 2026-07-03: North-star concept; current shipped boundary is PKM/vault plus encrypted scoped export.

Relations

What it is

The World Model is the north-star name for the user-side personal context model that One can reason over. In current repo language, the practical boundary is PKM/vault state plus encrypted scoped export. Specific two-table storage, key derivation, local-device topology, and schema details are design direction until checked implementation proof exists.

Why it exists

Every personal-AI product faces the same architectural fork: centralize user data and govern it by policy, or make the user-owned context boundary explicit and govern access through consent receipts, scoped exports, and local envelopes where possible. The World Model names Hussh's direction on the second path.

The two tables

North-star storage remains deliberately small and separable for clean reasoning:

  1. Identity table — phone number + email anchor, biometric-derived keys, the user's own canonical record about themselves.
  2. Knowledge table — the typed personal-knowledge graph (accounts, contacts, calendar facts, financial relationships, etc.) that One reads from and writes to under PCHP consent.

Both should be encrypted and should expose plaintext only during a consent-validated read. The exact device/storage primitive must be sourced from checked implementation evidence before it is treated as shipped.

Current PKM access follows the route's owner, token and scope checks, with revocation and audit requirements defined by the owning contract. The proposed CRT/DAT/domain-registration sequence is conceptual and is not a verified universal runtime pipeline.

Relationship to PCHP

PCHP defines the wire protocol; the World Model is the durable user-side store that PCHP consent receipts unlock. They are not the same thing — PCHP is the language, the World Model is the vault.

What it is not

  • The World Model names an ownership and consent boundary. It does not require every encrypted replica to live exclusively on a personal device; storage placement must be established for each supported runtime.
  • It is distinct from the Signature Vault pattern for short-lived sensitive secrets.
  • Personal knowledge is accessed through the applicable consent and vault contracts, never through an unrestricted information-access API.

Repo truth and north-star boundary

  • Verified implementation boundary: PKM and the vault remain the information authority. Agent experience, including conversation history and learned preferences, must not become a competing information store.
  • Runtime distinction: shared services require per-request owner isolation and scoped context. An owner-isolated private agent can retain encrypted experience under its own authority. Persistence alone does not establish correct consent, erasure or recovery.
  • Evidence boundary: implementation, deployed availability and completed lifecycle verification are separate claims. Local projection evidence does not establish complete native parity or recovery after replacement.
  • North-star direction: the World Model describes user-owned personal context accessed through scoped consent and vault authority. Specific device schemas, biometric key derivation and storage primitives remain design proposals until verified for a supported deployment.
  • Review date: 2026-09-05. This clarification updates the architectural distinction; it does not certify a release or a completed private-agent audit.

Information about the person, never application state

Status as of 2026-09-11: stated as a contract with a shared truth table and enforcing tests on the ADK orchestration workstream branch. Not yet merged to the release branch, and the cleanup of already-stored records has not run.

The World Model's whole claim is that it holds what is true about someone. Whether that person finished a setup wizard is true about the app, not about them. The distinction had been drifting, because the onboarding flow wrote its own progress into the same store as the answers it collected.

The measured consequence: for one person's financial records, the store held twenty-four leaf values, of which eight were information about anybody. The other sixteen were routing telemetry, timestamps recording when each answer was given, and wizard checkpoints including one field that had been initialised and never set. All of them were being offered to that person as things they could share with someone else. As the founder put it, nobody wants to know whether a person skipped part of an app.

Two near-misses let it happen, and both are worth remembering because each looked correct in isolation:

  • The filter already knew the routing key was structural, but only ever compared the first path segment, so the same key nested one level deeper published freely.
  • A field initialised to empty and never written was treated as present, because the walk only stopped on a value that was genuinely absent rather than one that was merely empty.

The rule is now a shared truth table rather than prose, with a matching implementation on each side of the wire so the two cannot drift, following the precedent already set for humanized labels. It applies at the point a stored key first becomes a declared, requestable path, which is upstream of display: filtering the catalogue would have stopped a person being offered their own checkpoints, but a store that holds them is already wrong even if nothing renders them.

Sources

  • PCHP - consent protocol that scopes reads.
  • One - relationship layer that uses user-owned context.
  • Signature Vault - separate sensitive-secret pattern.