Three-layer architecture — Protocol → Platform → Fund A
Hussh's structural thesis. Protocol (PCHP / hu_ssh) inner moat → Hussh.ai platform (One) middle layer → Fund A outer compounding engine.
TL;DR: Hussh's structural architecture is three concentric layers, each with its own moat: Protocol (PCHP / hu_ssh) at the core, Platform (One, Hussh.ai) in the middle, Fund A as the outer compounding engine. Each layer reinforces the next: the protocol is what makes the platform credibly neutral; the platform is what makes the fund a permanent-capital base; the fund is what funds the patient build of the protocol.
Status as of 2026-05-04: see body.
Relations
- PCHP — the inner moat layer.
- One — the platform layer.
- BYOA — the architectural commitment that lets the protocol be vendor-neutral.
- World Model — the user-side encrypted store that the protocol layer unlocks reads against.
- Bible verse #0 — the irreducible product thesis from which the three layers derive.
- north-star user persona — north-star user persona against which platform-layer decisions are tested.
- PCHP brand-side endpoint — Phase 2 monetization sitting on the protocol layer.
- Aloha Compass — governance frame that disciplines decisions across all three layers.
- Apple frame — default decision filter applied at every layer.
- Hussh Glossary — Hussh glossary.
- Three-Layer Architecture — Three-layer architecture diagram.
Layer 1 — Protocol (PCHP / hu_ssh)
The inner moat. Every read of personal data on a Hussh surface completes a PCHP handshake: Consent Receipt Token, Data Access Token, Transparency Log, and ephemeral envelope. Why the protocol is the innermost layer: standards outlive products. PCHP is positioned to outlive any single product Hussh ships. The protocol is also the only layer where the lock-in economics flip in the user's favor: the more places PCHP is honored, the more the user owns their data flow rather than the vendors.
Layer 2 — Platform (One / Hussh.ai)
The middle layer. One is the surface where Kai and Nav act on behalf of the user. The platform is what most users will touch, but its strategic role is to be the most opinionated and most ergonomic consumer of the protocol underneath. The platform is also what creates revenue: agent premium, API consent, data marketplace, and protocol licensing all sit at this layer.
Crucial constraint: the platform must remain model-neutral (BYOA). If the platform locked in a model, the protocol underneath would lose its Switzerland status, and the moat would collapse from the inside.
Layer 3 — Fund A (compounding engine)
The outer layer. Fund A is the permanent capital that funds the patient build of the inner two layers. The Berkshire analogy is on purpose: Berkshire's float funded the patient assembly of operating businesses; Fund A's compounding return is intended to fund the patient assembly of Hussh's protocol and platform without forcing the calendar of venture economics.
Fund A is private to Hussh internally. The page list under wiki/entities/ covers its current pre-launch state; refer there.
Why the layers reinforce each other
- Protocol → Platform: the protocol gives the platform credibility through vendor-neutral consent; the platform gives the protocol distribution.
- Platform → Fund: the platform creates real businesses to invest alongside; the fund holds the equities that benefit from the AI/data flywheel the platform participates in.
- Fund → Protocol: patient capital funds the long arc of standardizing a protocol. Few VC-funded companies could shoulder a 5-10 year protocol-adoption curve.
The shape is dual-flywheel: operating businesses feed permanent capital, permanent capital provides patient runway. The structural framing has been the governing architecture from the earliest Hussh conversations.
Architecture link/status refresh
- Current architecture truth: protocol/platform/fund framing must be read through architecture docs before becoming partner-facing implementation truth.
- North-star direction: PCHP remains the inner trust layer; One remains the platform direction; partner systems remain outside the trust boundary.
- Not shipped or implied: this page does not prove any partner implementation or broad CRM memory storage.
- Source notes: internal architecture catalog and future infrastructure design notes.