Documentation  /  Track 2 — personal data

I'll write the full functional spec directly as my response. This is a documentation task — no tools needed since the context provides everything required.

HiNet Track 2 — Functional Specification

The Personal-Data & Agentic macOS Product

Document status: Draft v0.1 (functional spec) · Date: 2026-06-22 · Owner: HiNet / iCore product Scope: Track 2 only (the native macOS product). Track 1 (the iCore model science — DNA base, Δ tuning, composition mechanics) is referenced but not specified here. Networking/qCore, token economics, and inter-iCore composition over a network are explicit non-goals for this document.

1. Purpose & Scope

1.1 What Track 2 is

Track 2 is the product surface of HiNet: a native macOS application through which a single human (the owner) installs their personal iCore (a complete, standalone, continually-personalized LLM), opens up their personal data to it via local connectors, and then chats with and delegates to their iCore as a local, consent-gated agent.

The product is built on one non-negotiable invariant, inherited from the HiNet ethos ("not your weights, not your intelligence"):

Local-first, owner-sovereign. All tokens, raw data, derived embeddings, model deltas, and audit logs live on hardware the owner controls. HiNet (the company/network) never receives the owner's connector tokens or personal data. There is no server-side copy. Backups (VaultReplication) go only to owner-owned targets, as ciphertext.

1.2 The product loop

Onboard → Establish identity (Ed25519) → Install iCore (DNA + empty Δ)
   → Connect accounts (in-app OAuth / export import)
   → Consent + ingest → Vault (encrypted) → Build training views
   → Chat / delegate (agentic iCore) → Nightly sleep cycle (personalize Δ + RAG)
   → Repeat. Settings/kill-switch/backups always available.

1.3 MVP scope (must ship in Track 2 v1)

1.4 Deferred (post-v1, out of scope for this spec)

• Networking / composition across iCores (the fractal-holographic layer; qCore). Track 2 v1 is single-iCore, single-owner.
• Token economics / monetization / marketplace.
• Attested cloud sandbox compute (the ComputeBackend "attested cloud" seam is designed but Track 2 v1 runs local-only; cloud tier is a deferred capability behind the same seam).
• Mobile / pocket tier app (phone/Jetson inference). v1 is macOS.
• WhatsApp / iMessage live sync (no personal API; v1 is export-import only).
• Cross-owner sharing, delegation to other people's iCores, group/agency features.

1.5 Honesty note (carried from Track 1)

Track 1 sims validate mechanisms (injection, composition, conflict-based routing). Real-data eval, continual-learning stability, privacy guarantees at scale, and routing-at-scale remain open. Track 2 v1 therefore ships the plumbing (connectors → vault → training views → agent) as production-grade, while the Δ-tuning quality is treated as an evolving capability gated behind the nightly sleep cycle with measurable before/after recall checks (per Track 1 methodology).

2. Primary User Stories

Onboarding & identity - US-1 — As a new owner, I install the macOS app and it generates my Ed25519 identity locally, so my iCore is cryptographically bound to me without any server account. - US-2 — As an owner, I set a vault passphrase and the app provisions my iCore (DNA base + empty Δ), so I have a working personal LLM before connecting any data.

Connecting data - US-3 — As an owner, I connect my Gmail via in-app OAuth, and I can connect a second and third Gmail account (work + personal), each kept distinct. - US-4 — As an owner, I connect multiple Google Drives the same way and choose which folders each account exposes. - US-5 — As an owner, I connect Slack with a user token and choose which workspaces/channels to ingest. - US-6 — As an owner, I import my Telegram "Export Data" JSON (or optionally authorize a Telethon user session) and the app ingests my chats locally. - US-7 — As an owner with no WhatsApp API, I import per-chat "Export Chat" dumps and the app folds them into my vault.

Consent & control - US-8 — As an owner, before any source is ingested I see exactly what will be pulled, its sensitivity class, and its retention, and I must grant a ConsentGrant. - US-9 — As an owner, I open a consent dashboard and revoke a source; the app deletes its derived data and stops using it. - US-10 — As an owner, I hit a kill-switch that instantly halts ingestion + agent activity and locks the vault.

Using the iCore - US-11 — As an owner, I chat with my iCore and it answers in my voice using my own facts (RAG over my vault). - US-12 — As an owner, I delegate a task ("summarize last week's emails from X and draft a reply"), and the agent uses connector tools + RAG, asking consent before any send/write action. - US-13 — As an owner, I see the agent's tool calls and reasoning trace, and every privileged action is in my audit log.

Personalization & backups - US-14 — As an owner, I see nightly "sleep cycle" status: what was ingested, what RAG was refreshed, whether Δ was retrained, and a before/after recall delta. - US-15 — As an owner, I configure VaultReplication to my own cloud bucket and restore my iCore on a new Mac from that ciphertext backup + my key.

3. Connector Framework

3.1 Design

A connector is a local plugin that authenticates with the owner's own credentials, pulls data, and emits normalized SourceRecords into the ingestion pipeline. Connectors never transmit data off-device and never expose tokens to HiNet. They run inside the hinetd Python sidecar, supervised by the Rust security core.

Connector contract (interface):

Connector
  id:            stable connector type (e.g. "gmail", "gdrive", "slack", "telegram", "whatsapp")
  account model: single | multi
  auth():        establish/refresh credentials → store in OS keychain (token ref only)
  list_scopes(): enumerate selectable units (mailboxes, folders, workspaces, chats)
  preview():     describe what would be pulled + counts + sensitivity (for the consent screen)
  pull(scope, cursor) -> [SourceRecord]   # incremental, resumable
  normalize(raw) -> CanonicalItem         # the HiNet Canonical Record (HCR) — docs/specs/HiNet-Canonical-Record.md
  revoke(account): drop token, signal pipeline to purge derived data

Cross-cutting rules for every connector: 1. Local-only. All network calls go directly from the owner's machine to the provider. No proxy, no relay. 2. Token custody. OAuth tokens / session strings live in the macOS Keychain, referenced by handle; the Rust core mediates access. The Python sidecar receives short-lived access tokens only at call time. 3. Consent-before-pull. No connector pulls a single byte before a matching ConsentGrant exists for that account+scope. 4. Sensitivity tagging at the source. Each connector declares a default sensitivity class per record type; owner can override. 5. Incremental + resumable. pull() is cursor-based so re-runs are cheap and an interrupted ingest resumes. 6. Multi-account is first-class. A connector with account model: multi keeps each account as a separate SourceConnection with its own token, scopes, consent, and audit trail. Records carry their originating account_id. 7. ToS posture. We only use official APIs or official user-initiated exports. Where a provider forbids automation (WhatsApp), we are import-only and never automate the client.

3.2 Telegram

• Auth method. Two supported modes:
• (A) Official Export (default, ToS-safe): owner uses Telegram Desktop → Settings → Advanced → Export Telegram Data → JSON. The app imports the export directory.
• (B) MTProto user-API via Telethon (optional, power-user): owner authorizes a user session (phone + login code, optional 2FA). Session string stored in Keychain. Enables incremental live pulls.
• Multi-account. Multiple Telegram accounts allowed. Mode A: one SourceConnection per imported export. Mode B: one Telethon session per phone number. Each is a distinct account with its own consent and scoping.
• Data pulled. Chats (1:1, groups, channels the owner is in), messages (text), timestamps, sender identities, media metadata (and optionally media files if the owner opts in). Owner selects which chats to include via list_scopes.
• ToS / feasibility / limits. Mode A is fully sanctioned and offline. Mode B uses Telegram's documented user API; subject to MTProto rate limits (flood-wait) — connector backs off and resumes. Large histories ingest incrementally.
• Local-first / consent. Default sensitivity Personal; private 1:1 chats default Sensitive. Channels/public groups default Normal. Per-chat consent selection in the connect flow.

3.3 WhatsApp

• Auth method. None / import-only. WhatsApp provides no personal data API and prohibits automating the client. The connector ingests the user-initiated "Export Chat" dump (.txt transcript, optional media zip) that the owner produces in the WhatsApp app and AirDrops/shares to the Mac.
• Multi-account. Each exported chat is its own scope; the connector groups exports under a single WhatsApp SourceConnection (or multiple, if the owner runs multiple numbers). No live linking.
• Data pulled. Message text, timestamps, sender display names, per the export transcript. Media imported only if included in the export and the owner opts in.
• ToS / feasibility / limits. Strictly the official user-initiated export — no Web/QR automation, no whatsmeow-style unofficial protocol, no scraping. This is a deliberate ToS-conservative choice. Limitation: no incremental sync — refresh = owner exports again. Export granularity is per-chat, so coverage is manual.
• Local-first / consent. Default sensitivity Sensitive (WhatsApp is overwhelmingly private 1:1/family). Explicit consent per imported chat. Clear UX that this is a manual snapshot, not live.

3.4 Slack

• Auth method. OAuth 2.0, user token (xoxp) via Slack's Web API. The owner authorizes the HiNet app per workspace; we request read scopes (channels:history, groups:history, im:history, users:read, files:read as opted in). Workspace admins may alternatively provide a workspace export which we import like Telegram mode A.
• Multi-account. Multi-workspace. One SourceConnection per Slack workspace (each has its own user token). Owner selects workspaces, then channels/DMs within each.
• Data pulled. Channel / group / DM message history for selected scopes, user directory (display names), file metadata (and files if opted in), reactions/threads. Cursor-based incremental pulls via Slack pagination.
• ToS / feasibility / limits. Uses official Web API with user token; subject to Slack tiered rate limits — connector honors Retry-After. Some orgs restrict third-party OAuth apps; the export-import path is the fallback. DM history availability depends on workspace settings.
• Local-first / consent. DMs and private channels default Sensitive; public channels default Normal. Per-channel selection. Token in Keychain; revocable from the consent dashboard (also revokes server-side via Slack token revocation).

3.5 Google Drive (multi-account)

• Auth method. OAuth 2.0 with Google, Drive API v3. Scopes minimized to read-only by default (drive.readonly or the narrower drive.file when the owner picks specific files). In-app OAuth via system browser → loopback redirect; refresh token stored in Keychain.
• Multi-account. First-class multi-account. Each Google account = one SourceConnection with its own OAuth token set. The connect flow explicitly supports "Add another Google account." Records tag their account_id and source Drive.
• Data pulled. Owner-selected files/folders. Native Google Docs/Sheets/Slides exported to text (Docs→text/markdown, Sheets→CSV, Slides→text). Binary docs (PDF, docx) have text extracted locally. File metadata (title, path, owners, modified time). Optional: shared-with-me, per opt-in.
• ToS / feasibility / limits. Standard Drive API. Rate/quota limits handled with exponential backoff. Large drives ingest incrementally via the Changes API (cursor = page token / change token) for cheap refreshes. We pull only owner-selected scopes — not the whole drive by default.
• Local-first / consent. Folder/file selection is explicit. Sensitivity defaults Normal, with a per-folder override to Sensitive/Secret (e.g. legal/finance). Text extraction happens locally in the sidecar.

3.6 Gmail (multi-account)

• Auth method. OAuth 2.0 with Google, Gmail API. Read scope gmail.readonly by default; gmail.send requested only if the owner enables the agent's send capability (and even then, every send is consent-gated at action time — see §5). System-browser OAuth + loopback redirect; refresh token in Keychain.
• Multi-account. First-class multi-account — work + personal + others. Each Gmail account = one SourceConnection. "Add another Gmail account" in the connect flow. Threads/messages tagged with account_id.
• Data pulled. Messages and threads (headers, bodies, labels), contacts implied by correspondence, attachment metadata (and attachment text extraction if opted in). Owner can scope by label/folder, date range, and "exclude" filters (e.g. exclude category:promotions). Incremental via Gmail History API (historyId cursor).
• ToS / feasibility / limits. Official Gmail API; Google's OAuth verification + restricted-scope handling required for production distribution (security assessment for restricted scopes). Quotas handled with backoff. We never pull more than the owner-scoped labels/dates.
• Local-first / consent. Email defaults Sensitive. Send capability is off by default and, when enabled, never autonomous — the agent drafts and the owner approves each send (or pre-authorizes narrowly). Token revocable; revocation purges derived data.

3.7 Connector capability matrix

Deferred — live social feed-slice capture. Each social account sees a different slice of the network (its feed, its connections' content) — a valuable differentiated signal — but official APIs rarely expose the feed-view and logged-in session capture is brittle/ToS-fragile. The clean path is export-dumps (own content) + the easy connectors; live feed-slice capture is a deferred, per-platform effort.

4. Ingestion → Vault → Training-Views Pipeline

4.1 Stages

Connector.pull()
   → raw payload (in-memory, never persisted raw to disk unprotected)
   → normalize() → SourceRecord (canonical)
   → consent gate (ConsentGrant for account+scope?)  ──no──▶ drop + audit
   → sensitivity classify (default + owner override)
   → dedupe (content hash + provider id)
   → persist to Vault (SQLCipher, encrypted at rest)
   → enrich: chunk + embed (local embedding model) → vector index
   → CLASSIFY for training: fact → RAG  |  skill/voice → Δ  |  conflicting → route
   → build/refresh Training Views (consumed by the nightly sleep cycle)
   → retention scheduler tags expiry
   → audit hash-chain append (no record content, just event + hash)

4.2 Key pipeline objects

• SourceConnection — one authorized account for one connector. Holds: connector id, account_id, token reference (Keychain handle), selected scopes, status, cursors, created/last-sync timestamps. Multi-account ⇒ multiple SourceConnections per connector.
• SourceRecord — one normalized unit of content (a message, an email/thread, a file/doc). Canonical schema in §7. Carries provenance (connection_id, account_id, provider ids), timestamps, participants, content, content hash, sensitivity, retention policy ref.
• ConsentGrant — owner's explicit authorization for (connector, account, scope, purpose). Records: granted scopes, allowed uses (ingest / RAG / Δ-train / agent-tool-read / agent-tool-write), sensitivity ceiling, retention, granted-at, revoked-at. No pull or training-view use occurs without a matching live grant.
• SensitivityClass — Public · Normal · Personal · Sensitive · Secret. Drives: encryption posture (all encrypted; Secret gets extra access friction), whether content may enter Δ-training vs RAG-only, redaction in agent traces, and replication eligibility.
• RetentionPolicy — per source/sensitivity: keep-until / rolling-window / keep-forever. The retention scheduler purges derived artifacts (records, embeddings, training-view rows) on expiry and on consent revocation, then appends an audit event.

4.3 Fact → RAG / Skill → Δ classification (the core routing decision)

Grounded in Track 1's validated finding: weight-merging facts caps out (~73%) while retrieval handles facts cleanly; voice/skill belongs in weights; conflicting deltas must be routed, not merged. The pipeline applies this at ingest, per chunk:

Classifier mechanism. A local lightweight classifier (heuristic + small-model scoring) tags each chunk fact | skill | voice | mixed, with confidence. fact → RAG-only. skill/voice (high-confidence, non-conflicting) → Δ view. Conflict detection compares candidate skill/voice deltas against existing views; conflicts are flagged route and never merged. mixed is split where possible, else defaults RAG-only (safe: facts never silently enter weights). Sensitivity gates this too — Secret content is RAG-only by default (never enters Δ) unless the owner explicitly opts a source into training.

4.4 Training Views

A TrainingView is a consent- and sensitivity-filtered, classified, deduplicated projection of the vault that the nightly sleep cycle consumes. Two primary views: - RAGView — chunk+embedding corpus + metadata for retrieval. Refreshed every sleep cycle (cheap, incremental). - DeltaView — the skill/voice training set for Δ tuning, partitioned into merge-eligible (complementary) and route (conflicting) buckets per Track 1's composition mechanism.

The sleep cycle (§5.5 / §6.6) reads these views, never the raw connectors.

5. Agentic Layer

5.1 Model

The local iCore model (DNA + owner Δ, served via MLX) is the LLM backend for a Hermes-style agentic framework running entirely on-device. The iCore is not just a chat endpoint — it is an agent that holds conversations, plans, calls tools, and runs delegated tasks, all locally and consent-gated.

5.2 Tools available to the agent

1. Connector tools — read and (optionally, gated) write through the same connectors: - read_email(account, query), draft_email / send_email(account, …) (send gated) - read_drive(account, query), read_telegram(scope), read_slack(workspace, scope), read_whatsapp(scope) - Write/send tools (send_email, post-to-Slack, etc.) are off by default and individually consent-gated.
2. RAG / memory tool — retrieve(query) over the owner's vault (the primary path for facts; see §4.3).
3. Web tool — web_fetch(url) / web_search(query) for external info, clearly marked as off-device network egress (owner-toggleable; off-by-default for Secret-context tasks).
4. Task/plan tools — scratch memory, multi-step planning, and a request_consent(action) tool the agent MUST call before any privileged/irreversible action.

5.3 Consent gating of agent actions

• Read of already-consented sources: allowed within the source's ConsentGrant allowed-uses (agent-tool-read).
• Write / send / external egress: requires either a standing narrow pre-authorization or a just-in-time approval prompt showing the exact action (recipient, content, account). The agent cannot self-grant.
• Sensitivity-aware redaction: when the agent surfaces a reasoning trace, Sensitive/Secret content is redacted in the visible trace by default.
• Every tool call (read or write) is appended to the audit hash-chain.

5.4 Conversation & delegation

• Chat: free-form conversation; the agent answers in the owner's voice (Δ) grounded in the owner's facts (RAG).
• Delegation: the owner assigns a bounded task ("triage today's work-Gmail, draft replies to anything from my manager"). The agent plans, calls tools, pauses at consent gates, and returns results + a trace. Tasks are bounded by: allowed tools, allowed accounts, time/step budget, and a kill-switch.
• Determinism of authority: the agent operates strictly within active ConsentGrants and enabled tools. Disabling a tool or revoking a grant immediately removes that capability mid-session.

5.5 Relationship to the sleep cycle

The agent is inference-time; the sleep cycle is the offline learning loop. They share the vault but are separate: chatting/delegating never mutates Δ live. Improvements to voice/skill land via the nightly DeltaView training; new facts become available via the incremental RAGView refresh (often same-cycle).

6. macOS App UX (screen-by-screen)

Shell: Tauri (UI) + Rust security core (identity, keychain mediation, vault gatekeeper, audit) + Python hinetd sidecar (connectors, ingestion, embeddings, MLX inference, sleep cycle). The UI never touches tokens or raw vault data directly — it goes through the Rust core's mediated, audited API.

6.1 Onboarding

• Welcome → ethos ("your weights, your intelligence; nothing leaves your Mac") → system checks (disk, RAM, Apple-silicon tier detection: pocket/laptop/cloud-eligible).
• Outcome: hardware tier determined, which sets default Δ-tuning method (DoRA vs full-FT) and inference settings.

6.2 Identity

• Generate Ed25519 owner keypair locally; show public identity fingerprint. Set vault passphrase (unlocks SQLCipher). Optional recovery: write down a recovery phrase (used with VaultReplication restore).
• No server account, no email signup. Identity is local and owner-held.

6.3 Install iCore

• Download DNA base (Qwen3-MoE, bf16) with integrity verification; provision empty per-owner Δ; warm up MLX inference. Progress + "your iCore is ready" with a first chat available immediately (pre-personalization).

6.4 Connect accounts (incl. multi-account)

• Grid of connectors (Telegram, WhatsApp, Slack, Google Drive, Gmail) with status.
• Per connector flow: Auth (in-app OAuth via system browser for Google/Slack; import-file picker for Telegram-export/WhatsApp; session login for Telethon) → Scope selection (folders / labels / channels / chats) → Preview (counts + sensitivity per scope) → ConsentGrant (allowed uses, sensitivity ceiling, retention) → ingest with live progress.
• Multi-account UX: Google Drive and Gmail (and generally) show an explicit "Add another account" control. Each connected account renders as its own card with its account_id, scopes, last sync, and an individual revoke. Records and traces always show which account they came from.

6.5 Consent dashboard

• One row per SourceConnection: connector, account, scopes, sensitivity, retention, allowed uses (ingest/RAG/Δ/agent-read/agent-write), last sync, record count.
• Controls: edit scopes, change allowed-uses, change retention, revoke (purges derived data + audits the purge), and a master Pause all ingestion.
• A global Kill-Switch button is present here and in the menu bar (see §8).

6.6 Chat / Agent

• Conversation pane (chat with the iCore). Inline display of tool calls (which connector/account/tool, redacted per sensitivity), retrieval citations (which vault records grounded the answer), and a consent prompt modal for any write/send/egress action.
• Delegate mode: define a task, pick allowed tools/accounts and a budget, run; watch the trace; approve gated steps; get a result + saved transcript (in audit).

6.7 Training / Sleep status

• Timeline of sleep cycles: per night — records ingested, RAGView refreshed (chunks/embeddings), whether Δ retrained (method: DoRA/full-FT, duration), and a before/after recall delta on a held-out probe set (per Track 1's measurement discipline).
• Manual "Run sleep cycle now" for power users; shows resource use and lets the owner defer heavy full-FT to user-owned cloud tier if configured.

6.8 Settings

• Tools & egress: enable/disable each agent tool (send-email, post-Slack, web). Web egress and write tools off by default.
• Kill-switch (also global): halts ingestion + agent + sleep cycle, locks vault.
• VaultReplication backups: configure owner-owned target(s) — local external disk and/or the owner's own cloud bucket (owner's credentials). Encrypt-local → replicate ciphertext; show last backup, integrity status, and Restore flow (new Mac: install app → restore from ciphertext + Ed25519 key/recovery phrase → re-derive vault).
• Identity & keys: view fingerprint, rotate passphrase, export/backup recovery phrase.
• Audit log viewer: browse the hash-chain (events only, content redacted), verify chain integrity.
• Hardware/compute: view tier, configure user-owned cloud ComputeBackend (deferred capability; seam present).

7. Data Model / Key Objects

SourceRecord is now formally the HiNet Canonical Record (HCR) — the implemented, versioned pydantic schema (app/osx/hinetd/hinetd/canonical.py) that every connector's normalize() emits and the vault validates. The sketch below is the high-level view; the canonical doc + module are the source of truth (envelope, conversation/thread model, cross-source identity + entity resolution, stable-ID/dedupe, per-source mapping tables).

Owner
  ed25519_pubkey (identity)         # local, sovereign
  vault_key_ref                     # derived from passphrase; SQLCipher
  hardware_tier                     # pocket | laptop | cloud-eligible

SourceConnection
  id, connector_id                  # gmail | gdrive | slack | telegram | whatsapp
  account_id                        # distinguishes multi-account
  token_ref                         # Keychain handle (never the token)
  scopes[]                          # selected folders/labels/channels/chats
  cursor                            # incremental sync state
  status, created_at, last_sync_at

SourceRecord
  id, connection_id, account_id
  provider_id                       # original message/email/file id
  type                              # message | email_thread | file | doc
  participants[], timestamp
  content                           # normalized text (encrypted at rest)
  media_refs[]                      # optional, if opted in
  content_hash                      # dedupe
  sensitivity                       # Public|Normal|Personal|Sensitive|Secret
  retention_policy_ref
  classification                    # fact | skill | voice | mixed | route
  created_at

ConsentGrant
  id, connector_id, account_id, scope
  allowed_uses[]                    # ingest, rag, delta_train, agent_read, agent_write
  sensitivity_ceiling
  retention                         # keep_until | window | forever
  granted_at, revoked_at

RetentionPolicy
  id, mode (keep_until|window|forever), value, applies_to

EmbeddingChunk
  id, record_id, vector, text_span, sensitivity   # local vector index (RAGView)

TrainingView
  kind                              # RAGView | DeltaView
  partition                        # for DeltaView: merge_eligible | route
  built_at, record_refs[]

AuditEvent (hash-chain)
  id, prev_hash, hash
  event_type                        # ingest | consent_grant | consent_revoke |
                                    # purge | tool_read | tool_write | sleep_cycle |
                                    # kill_switch | backup | restore
  connector_id?, account_id?, tool?, timestamp
  # content-free: hashes/refs only, never record bodies

DeltaState
  base_dna_version (Qwen3-MoE bf16)
  delta_ref (per-owner Δ)
  last_trained_at, method (DoRA|full_ft), recall_probe_score

8. Privacy, Consent, Audit, Kill-Switch

8.1 Privacy posture

• No server-side data, ever. Connector tokens, raw data, embeddings, Δ, and audit logs are local. HiNet receives none of it. Backups are owner-targeted ciphertext.
• Encrypted at rest via SQLCipher; embeddings index and training views inherit encryption. Tokens isolated in the OS Keychain, mediated by the Rust core.
• Least-scope connectors: read-only defaults, owner-selected scopes, restricted OAuth scopes only when a feature needs them.

8.2 Consent (policy engine)

• The consent policy engine is authoritative: every pull, every training-view inclusion, every agent tool call is checked against a live ConsentGrant. No grant ⇒ no action ⇒ audited drop.
• Consent is granular (connector × account × scope × use × sensitivity-ceiling × retention) and revocable, with revocation triggering derived-data purge.

8.3 Audit

• Signed audit hash-chain: append-only, tamper-evident (each event links prev_hash). Content-free — events reference hashes/ids, never bodies. Viewer in Settings verifies chain integrity. Covers ingest, consent changes, purges, every agent tool read/write, sleep cycles, backups/restores, and kill-switch activations.

8.4 Kill-switch

• Global, immediate. Available in the menu bar and Settings. On activation: stop all connector ingestion, abort any running agent task, halt the sleep cycle, and lock the vault (drop the in-memory key; require passphrase to resume). Activation is itself an audited event. This is the owner's hard stop — no network call, no confirmation latency, local and instant.

9. Explicit Non-Goals / Deferred

10. Sovereign storage (VaultReplication) & the proprietary split

(Canonical home — merged from the former Personal-Data-and-Sovereignty doc.)

10.1 What is actually "proprietary"

Each owner does not build a fully private base model — if everyone had a private base, experts could never merge into a bigger model and the fractal thesis dies. The split:

"Your little proprietary model" = your encrypted deltas + data on the commons anchor — what makes ownership and composition possible at once. (Ownership model: Foundational-Model-Plan §2A.)

10.2 VaultReplication — survive device loss without trusting HiNet

encrypt locally (owner's data key) → replicate CIPHERTEXT to N owner-owned targets
   target 0: local disk (primary)
   target 1: the owner's own cloud (Google Drive / S3 / Storj)
   target 2: a decentralized FS (IPFS-with-pinning / Arweave / Storj), ciphertext only

• Only ciphertext ever leaves; every target (and HiNet) holds opaque blobs; the owner holds the keys.
• Replicates the vault (Δ_private, Δ_public, memory/embeddings DB, identity-wrapped material) — content-addressed + versioned → restore on a new machine from any target.
• This is storage replication — a different axis from the compute cloud-sandbox (Node-Packaging-Addendum). Both are "owner-owned cloud," distinct concerns.

10.3 Keys & recovery (the sovereignty tradeoff)

• Ed25519 identity key (signing) in Keychain/Secure Enclave; a separate data-encryption key (DEK) wraps the vault blobs. (Owner↔device identity + the portable owner key: Owner-Identity-and-Proof-of-Personhood.)
• Recovery requires the DEK to survive device loss: a recovery phrase and/or Shamir-split escrow to the owner's own targets. Key loss = data loss — the price of true sovereignty; onboarding must make backup unavoidable.
• POC scope: the VaultReplication interface + local target + one cloud target, encrypt-then-replicate, restore-on-new-machine demo, recovery-phrase backup. Stretch: a decentralized-FS target.

10.4 Security-first sequencing

Ingesting real personal data is the highest-stakes privacy surface in the system: the consent + audit + encryption container must exist before any connector touches your Gmail. Connectors and replication are features of the node container, not standalone scripts — which is why the build order (Whitepaper §8) converges on the container first.

Appendix A — Mapping to existing HiNet primitives

• Shared frozen anchor (Qwen3-MoE / bf16) → §6.3 DNA install, §7 DeltaState.base_dna_version.
• Per-owner Δ (skill/voice) → §4.3 DeltaView, §5.5 sleep cycle, §7 DeltaState.
• Private vault (SQLCipher) → §4, §7, §8.1.
• Ed25519 identity → §6.2, §7 Owner.
• Consent policy engine → §4.2 ConsentGrant, §8.2.
• Signed audit hash-chain → §7 AuditEvent, §8.3.
• VaultReplication → §6.8 backups, §8.1.
• ComputeBackend seam → §6.8, §9 (deferred cloud tier).
• Spectrum router (route/merge/RAG by conflict) → §4.3 classification, §4.4 DeltaView partitions, §5 agent retrieval.

End of Track 2 Functional Specification (Draft v0.1).

Next: Canonical record (HCR) →  ·  All documentation →