Sovereignty · architecture and constitution

E03 · 18 September 2026 · Proposed, not implemented. Extends E01 architecture and the living master plan. The current pairwise pilot is server-stored temporary data, not an encrypted personal vault. Research recommendations below are not deployment authority.

1. Own the continuity contract; reuse the machinery

A common interface does not require a single database or universal causal model. Fictional life state, real reports and shared records stay in separate namespaces. A private subjective representation of another person cannot become their identity, vote or account when they join.

“Canonical” means the accepted version of a record and who may change or use it. It does not mean every accepted report is objectively true. Conflicting accounts can coexist. The owner may explicitly correct a record without pretending the original model knew that correction at decision time.

The human owns continuity and controls permitted use. Ownership here means practical control, portability and specified rights; it does not erase another person's privacy, asset licenses, shared-record rights or provider obligations. Legal terms need separate jurisdiction-specific review before an offer. Avoid “knows everything” and “owns every byte” as blanket promises.

2. Minimal conceptual records

These are schema requirements to compare with reused formats, not tables to implement now.

Avoid recording a complete explanation when a minimal nonrevealing receipt suffices. Raw audio, credentials, irrelevant intimate details, unsupported hidden-trait guesses and third-party conversations should not become default permanent memory. A secret reference belongs in memory only when useful; the secret stays in a separate credential store.

3. Context broker and memory write boundary

For “Should I attend tonight?”, resolve the task, persona, provider and purpose. Retrieve only eligible sources, select schedule/goals/constraints that matter, then validate the actual assembled payload against current grants. A broad category is a ceiling, not permission to include every matching entry. Local filtering itself requires applicable access.

The response enters a staging area: a recommendation, candidate memory, proposed action or rejected content. Validate structure, provenance, duplicate identity, source versions and authority before committing anything. Only a user decision or narrowly authorized standing policy can promote eligible content. A model's assertion that permission exists is not permission. Imported memories, skills, routines, prompts and external messages are untrusted data until separately admitted to the relevant execution boundary.

A useful context receipt says: which categories were disclosed, destination, purpose, grant/version, time, known retention, what changed, and remaining uncertainty. Detailed payload inspection stays private. Receipts must not retain deleted sensitive text or leak another person's answer. Unchanged authorized operations need no repeated approval; consequential scope changes do.

Provider choice is independent of storage choice. A locally stored Universe can disclose a small approved prompt to a cloud model. An encrypted hosted vault may disclose nothing until a client decrypts selected records. Ordinary cloud inference sees its plaintext input; encrypted storage does not make that inference zero-disclosure.

4. Adapter boundary and honest degradation

Start with a small capability contract: read selected records, stage proposed writes, commit with expected version, export/import, apply correction, apply deletion and report supported limits. Search and embedding are optional. Transactions, temporal graph queries, signed receipts and multi-device merge are declared capabilities, not assumed universal methods.

Keep a portable source record independent of an engine's summaries. If a backend cannot atomically enforce a permission/version boundary, put enforcement in the trusted owner-side broker or reject that operation. Never silently downgrade a grant or drop a hard constraint to fit a schema. Unknown consequential fields are quarantined; harmless extensions can round-trip without becoming instructions.

A memory exchange format is not a database, and MCP is not a memory model. Prefer importing through validated adapters rather than binding the whole product to a vendor's SDK. A local file/SQLite reference remains the comparison baseline; encrypting it and designing recovery are separate work, not properties SQLite supplies by name.

5. Correction, deletion and synchronization

Use explicit versions and source identity. An inference cannot overwrite a user report merely because it arrived later. Concurrent observations remain separate; incompatible edits require resolution. Goal changes are effective prospectively. Last-write-wins can be acceptable for a benign display preference, not for consent or factual truth.

Deletion/revocation must dominate stale replicas and delayed outputs. Minimal tombstones prevent resurrection without preserving the removed payload. Invalidate dependent summaries, retrieval chunks, embeddings, proposals and approvals; rebuild controllable views. A legal retention exception, if applicable, needs a disclosed restricted scope, not a hidden general archive.

An offline device cannot claim fresh permission. Before a new remote disclosure or shared action, check an authoritative current grant; fail closed if freshness cannot be established. Owner-private offline reading may remain possible under the accepted device policy. There is no promise of instantaneous global revocation while every device is offline.

A recipient who already received plaintext can retain it. Revocation stops future authorized use where controllable and requests cleanup; it cannot prove a malicious recipient forgot. Provider logs/backups and external exports need honest limits. Crypto-erasure works only for copies whose only usable key is actually destroyed; it does not erase previously decrypted copies.

Preserving public project history is different from keeping private memory forever. If deletion removes a required checkpoint dependency, say continuation is unavailable. Preserve separable nonrevealing fiction. Do not sacrifice privacy to a calibration chart or narrative continuity.

6. Keys, identity and surviving provider failure

Prefer established cryptographic libraries and independently reviewed designs. The architecture separates encrypted content, identity/authentication, grants and model billing. Do not create custom cryptography or make a wallet/blockchain account a consumer prerequisite.

Local device keystores and passkeys are candidates, not a completed portable recovery design. A passkey login and the ability to decrypt every old backup are different promises. Export, key backup, restore instructions and an independent implementation must be tested together. Recovery helpers should not automatically gain the ability to read the Universe.

Pseudonymous personas should have scoped identifiers and grants. Do not expose a universal public ID across dating, work and health contexts. Proof that an account controls a key does not prove one unique human, age, honesty or professional competence. Anti-spam may use room invitations, explicit introductions, quotas and proportionate organizer controls before considering stronger identity proof.

7. Intersections without exporting a whole person

Proposed handshake: opt into a specific Room → approve a projection and permitted query family → check mutual constraints → propose a bounded experience with permitted reasons → obtain independent human responses → disclose only the approved mutual result → optionally record each person's own outcome.

The Room is a provider-neutral context, not a global directory or universal trusted authority. Dalat.app is a possible provider pending actual integration permission. E01's Master Brain becomes a replaceable coordinator; it has no inherent right to read everyone. A coordinator can still see metadata, proposals or timing; minimizing raw records does not remove that trust question.

For a first future private prototype, let each owner's boundary return allowed activities and coarse time windows, not the hidden reasons for rejecting alternatives. Do not expose arbitrary predicates such as “does this person have condition X?” Repeated yes/no answers can reveal the hidden inputs, even when each answer looks harmless.

Mitigations to test include fixed query families, bounded repeated attempts, short-lived per-room identifiers, no private failure reasons, output minimization, abuse reporting and generic unavailable states. Colluding accounts and cross-room linkage remain risks. Avoid collecting a permanent social graph merely to enforce perfect deduplication.

Blocking ends affected discovery, pending proposals and future controllable disclosure. It should not announce who blocked whom. Minimal owner-side block records may be needed to prevent recontact; explain this retention instead of promising both zero retained identity and perfect blocking. Consent to one suggestion is not indefinite agent-to-agent access, permission to message, a booking or romantic consent.

Physical attraction may eventually be a privately configured dating preference, but private-photo processing, consent, bias and misuse need a separate design. Do not infer sensitive traits, scrape photos or publish desirability rankings. Keep the first activity pilot adult-only in intent, with its existing explicit limitation that age is self-attested, not verified. A minors product requires its own protection and consent model.

8. Practical privacy technology, by stage

These are research judgments, not performance results. There is no demonstrated general “zero-copy compatibility engine” in this project.

Primary foundations: Microsoft APSI implements asymmetric PSI using homomorphic encryption; its documented public set-size bounds and workload assumptions matter. Google Private Join and Compute explicitly discusses honest-but-curious security and maliciously chosen inputs. These are reasons to test adversaries, not drop-in social matching guarantees.

AWS Nitro Enclaves documents isolation and attestation. NIST SP 800-226 explains differential-privacy guarantees and implementation hazards. W3C Verifiable Credentials 2.0 separates issuer claims, holders and verifiers; cryptographic verification is not a universal truth certificate. The federated-learning membership-inference study is additional evidence that moving training does not by itself remove disclosure risk. No implementation or benchmark from these projects was run here.

9. Serving other AIs

An external assistant could request a purpose-scoped SimSim context tool, receive only authorized material, and return a proposed decision record. Separate read, proposed-memory write and real-action capabilities. Never expose unrestricted read_everything or let model-written arguments name arbitrary private files.

Current OpenAI authentication documentation describes OAuth 2.1 for authenticated MCP servers, with resource metadata, token checks and PKCE-capable clients. The earlier Apps SDK URL redirects to this plugin documentation. This is a feasible integration surface, not evidence that a SimSim app is registered or that it can replace ChatGPT's internal memory. Host product features, review requirements and account availability still need verification.

MCP authorization is a transport authorization specification. SimSim must additionally enforce purpose, record scope and revocation. Use audience-bound tokens and separate downstream credentials; do not pass a consumer's raw model API key through prompts or treat connection to SimSim as authorization to pay a model provider. A local bridge needs authenticated, bounded access too. OAuth does not promise a provider's retention, cancellation or price.

10. Draft SimSim Constitution

1. The human controls their Universe. Deliver practical inspection, correction, export and exit under explicit rights; do not claim ownership of other humans' records.
2. Disclose the minimum needed. Name purpose, recipients and processing path; more context is not automatically better.
3. Humans decide human commitments. Discovery, simulation and capability availability create no work order or consent.
4. Intelligence is replaceable. Preserve source records and permitted persona settings independently of model weights and provider accounts.
5. History is portable. Basic access and exit do not depend on paying to rescue artificially trapped records.
6. Permission can be withdrawn. Stop controllable future use, prevent stale resurrection and state the limits of recalling prior disclosure.
7. Inference remains inference. Preserve sources, contradictions and corrections; repetition and signatures do not certify truth.
8. Simulation expresses uncertainty. No destiny, fabricated probabilities or validation from branch count.
9. Design for provider failure. Test offline recovery and independent reading; disclose key-loss and service limits.
10. Intersections should improve human life. Value freely chosen experiences and attention saved; refusal, quiet use and a closed app remain successes.
11. Fiction remains free and meaningful. Artistic value need not produce productivity or empirical prediction; fiction cannot supply real authority.
12. Enforcement and revision are inspectable. Grants are enforced outside model prose; amendments are versioned and cannot silently expand prior consent. No model may rewrite its own authority.

This is a first policy draft, not an adopted license, legal contract, implemented protocol or claim of compliance.

11. Small proofs before infrastructure

Synthetic exit fixture: one user report, one conflicting inference, one goal revision, one conditional forecast, one missing outcome, one fictional branch, one expiring grant and one deletion. Compare a plain local record with one candidate interchange adapter. Restore on a clean offline environment without original service credentials. Check every meaningful field, then correct and delete, re-import a stale copy and inspect derived outputs. Unsupported semantics must fail visibly. Record bytes, time, loss and required dependencies; no personal data needed.

Context fixture: assemble a benign event recommendation; insert malicious instructions in imported memory; revoke the grant before dispatch; return a delayed proposed write. Verify no widened payload, stale action or deleted-content resurrection. These tests establish only specified policy behavior.

Human proof: compare a simple activity suggestion or ordinary introduction with the existing card flow on consenting occasions. Record comprehension, burden, ownership, felt pressure, whether an experience happened and each person's private account. No response remains missing. Design a stronger comparison before making causal or network-effect claims.

All three are proposed and unrun in E03. Production vaults, crypto, sync, global discovery and automatic execution remain out of scope.