data handling & retention policy

This policy is consistent with the Threat Model & Scope.

2.1 Threat model

Threat actors that matter for data handling include:

• States and regulators (courts, subpoenas, administrative orders).
• Corporations and platforms (SaaS providers, email hosts, cloud vendors).
• Synthetic governance / AI gatekeepers (risk scores, analytics, “trust and safety” systems).
• Data utilities (chain analytics, KYC vendors, credit bureaus).
• Criminal organizations and opportunistic attackers targeting high-value individuals and infrastructures.
• Insiders and ex-partners who might gain access to devices, accounts, or records.

On my side, I assume:

• My devices could be seized (locked or unlocked).
• I could be compelled to disclose passwords or keys to my own systems, within the limits of local law.
• I could be questioned about what I remember.

Out of scope:

I do not accept:

• Clients under active, targeted pursuit by top-tier intelligence services or sophisticated organized crime where safe handling is not realistically achievable.
• Engagements whose primary purpose is evading sanctions, laundering proceeds of crime, or committing fraud or violent coercion.

Those engagements are declined.

2.2 Design principles

All SovStack client work follows these principles:

• Data minimization
  Collect and retain only what is strictly needed to design, deliver, and audit the agreed work and meet legal/accounting requirements.
• Abstraction over identity
  Model systems by roles and nodes (e.g. “Primary Operator”, “Guardian 1”, “Node A”) rather than real-world identities wherever possible.
• Compartmentalization
  Each client’s data is segregated and pseudonymous. Even if I am compromised, cross-client correlation and actionable detail are structurally limited.
• No custody of secrets
  I never require or store seed phrases, private keys, or ongoing access credentials to your assets.
• Constrained AI / cloud processing
  I do not send raw client artifacts (Dossiers, legal docs, full spreadsheets, ID scans, etc.) to generic cloud tools or AI systems. Any use of external AI (including Maple, PPQ, Routstr) is strictly abstracted and governed by §6.2 and a separate AI & Cloud Processing policy.
• Limited scale
  Capacity is intentionally limited so this policy can be executed precisely. I would rather say no than dilute the standard.
• Lawful use only
  Sovereign Systems Architecture is for lawful, non-aggressive purposes. If it appears an engagement is being used for crime, fraud, or systematic abuse, it is terminated.

I distinguish several categories of data on my side:

3.1 Role & contact data

• Pseudonyms and role labels (e.g. “Primary Operator”, “Guardian”, “Infra Admin”, “Family Member A”, “Cell Member 3”).
• Cryptographic identifiers (PGP keys, Nostr pubkeys), messenger IDs, and time zone.
• For some engagements, minimal real-world contact details (e.g. email, rough location) to coordinate calls or in-person work.

Real names, full legal IDs, and exact addresses are not required for most remote work. Where they are required (e.g. for certain legal or on-site tasks), they are collected minimally and kept short-lived.

3.2 Technical architecture data

• Abstracted diagrams of nodes, networks, roles, and flows.
• Asset class tiers (e.g. BTC / infra scale expressed as low/medium/high, not exact balances).
• Threat models, risk assessments, and remediation plans.
• Checklists and implementation notes derived from these models.

3.3 Operational records

• Statements of Work (SOWs) and their cryptographic hashes.
• Milestone records and internal notes limited to what is needed for the engagement.
• Session summaries and decisions (e.g. “agreed to move custody from X to Y”).

3.4 Payment & transaction data

• BTC / Lightning transaction references (IDs, approximate amounts, dates).
• Where other media of exchange are used per the MOE Codex (XMR, cash, metals, stablecoins, etc.), minimal necessary payment details.
• An internal pseudonymous client ID associated with relevant payments.

Where fiat/bank rails are used (for example in some jurisdictions or for compliance with local obligations), account identifiers and legal names are kept separate from SovStack architecture artifacts and minimized.

3.5 Comms context & scheduling

• Dates and times of sessions and calls.
• Channels used (e.g. PGP-secured email, a specific E2EE messenger, Nostr DM, SimpleX).
• Scheduling metadata (time windows, not full calendar histories).

3.6 System & application artifacts

• Local autosaves and temporary files created by editors or diagramming tools.
• Local application caches and “recent files” entries.
• OS-level artifacts (clipboard history, search indexes, thumbnail caches) where they cannot be fully disabled.

These are treated as client data for SovStack work and fall under the same minimization and deletion goals where technically feasible.

3.7 Categorically excluded data

I will not intentionally collect or store:

• Seed phrases, private keys, or other direct recovery material.
• Wallet or system passwords and login credentials.
• Copies of passports or government IDs, except if and where strictly necessary for an agreed, narrow purpose.
• Exact bank account or card details, beyond what is unavoidable where fiat is used.
• Exact physical addresses, except where strictly necessary for on-site work and then only in minimal, short-lived form.
• Exact asset balances beyond order-of-magnitude tiers unless explicitly necessary and agreed.

If such information is inadvertently received, it is handled per §4.3.

4.1 Minimality

I collect data only when:

• It directly affects architecture, threat modeling, or safe implementation, and
• It cannot be adequately represented in more abstract or generalized form.

Clients are encouraged to redact or generalize wherever possible.

4.2 Abstraction

Where feasible:

• Real-world identifiers (names, street addresses) are replaced by roles and generalized location information (e.g. “Northern Europe”, “US Southwest”, “coastal SE Asia”).
• Asset information is represented in tiers, not exact figures.
• Highly sensitive details (e.g. names of specific banks, vendors, or counterparties) are kept out of “big picture” diagrams if not necessary.

4.3 Inadvertent receipt of forbidden data

If you send forbidden data (e.g. seed phrases, private keys, full ID scans):

I will:

• Inform you as soon as feasible that such data is neither needed nor retained.
• Strongly recommend rotating or securing affected secrets.

I will:

• Immediately remove and securely delete that information from my devices and storage, to the extent technically possible.

I will never ask for seeds, keys, or credentials. Any request for them allegedly from me should be treated as malicious.

5.1 Per-client segregation

• Each client is assigned a random internal client ID not directly tied to your real-world identity or payment addresses.
• All SovStack client data on my side is stored under that ID in a dedicated encrypted container or directory.

5.2 Devices

Client data is handled only on:

• Dedicated SovStack workstations with:
  • Full-disk encryption.
  • Hardened OS configuration.
  • OS-level cloud sync (OneDrive, iCloud, Google Drive, etc.) disabled.
  • Telemetry and diagnostic data minimized where possible.

These devices are not used for:

• Personal accounts and casual browsing.
• Public-facing writing and content work where cross-contamination is possible.
• Random SaaS experiments and “try this new thing” tools.

5.3 Passwords & keys

• Device encryption, container passphrases, and application credentials are strong, unique, and not reused elsewhere.
• If a password manager is used for client work:
  • It is local-only (no cloud sync).
  • Its vault is itself protected by strong authentication.

Container passphrases are never stored in plain text or in cloud-hosted services.

5.4 Indexing & telemetry

• File content indexing is disabled on client-data containers where possible.
• OS-level and application-level features that send text to cloud services (e.g. “smart” spell-check, cloud input prediction) are disabled for client work.
• Application telemetry and crash reporting are disabled or blocked by firewall when feasible.

5.5 System & application caches

• Tools are chosen to minimize background syncing and persistent caches.
• Cache directories and “recent files” lists for client applications are periodically cleared as part of operational hygiene.

6.1 Local / offline tools by default

For SovStack client work:

• Diagrams, notes, and documents are created and edited using local, offline-capable tools (preferably FOSS) with no automatic cloud sync.
• Browser-based editors, online whiteboards, and SaaS document platforms are not used for client-specific materials, unless explicitly agreed and risk-assessed.

6.2 AI & cloud processing (summary)

AI is part of how I think, draft, and refine architectures, but it is also an attack surface. The core rules:

• No raw uploads. I do not upload full, raw client artifacts (Dossiers, legal documents, spreadsheets, ID scans, internal dashboards, etc.) to external AI services.
• Abstraction only. Client-derived information is only processed by external AI tools in abstracted form:
  • Names → roles (e.g. “Founder A”, “Guardian 1”).
  • Exact locations → regions (e.g. “EU-member state”, “US West Coast”).
  • Exact balances → tiers (e.g. “mid-7-figure BTC treasury”).
• Hard red lines. The following never go to external AI providers (including Maple, PPQ, Routstr, or others):
  • Seed phrases, private keys, or other recovery material.
  • Wallet / system passwords and credentials.
  • Full combinations of legal name + exact address + exact asset figures.
  • Scans of IDs, detailed legal filings, unredacted banking/card data.
  • Private or access-controlled URLs (internal dashboards, private docs), including via AI web-research features.
• Provider classes.
  • Class 0: local / self-hosted models (no data leaves the agreed environment). Default for highly sensitive work.
  • Class 1: privacy-focused, enclave/E2E-style services (e.g. Maple). Used only with abstracted content; their privacy guarantees are treated as strong but not absolute.
  • Class 2: routing/marketplace services (e.g. PPQ, Routstr) that broker access to many upstream models. Treated as untrusted with sensitive content and used only with fully abstracted, non-identifying prompts, if at all.
• High-OPSEC / high-threat clients.
  For high-threat clients (as defined in the Threat Model & Scope page), Class 2 tools are not used by default. Any AI use beyond local models is agreed explicitly; you may request “Class 0 only” or “Class 0 + Class 1 only (no Class 2),” and that becomes part of the engagement spec.
• Metadata awareness.
  External AI providers are treated as nodes in the Synthetic Stack that can be logged, compelled, or compromised. Network contexts for SovStack AI calls are separated where practical; catastrophic data never leaves local.

This is a summary. A detailed version of the AI & Cloud Processing rules, including provider classes, threat-tier gating, and hygiene, is maintained in a separate policy here, which governs how Maple, PPQ, Routstr, and similar tools are used in practice.

6.3 Copy / paste & reuse discipline

• Copying content between client containers is avoided.
• When design patterns are reused:
  • They are recreated from generic templates and principles, not cloned from a specific client’s artifact and lightly redacted.
• Cross-client references (“like another client’s setup”) are not recorded inside your data.

7.1 Channels

Client communications use:

• Nostr DMs, SimpleX, or other E2EE messengers, and/or
• PGP-secured email where appropriate.

Plaintext email is reserved for basic coordination only. Sensitive attachments over email are PGP-encrypted.

7.2 Messenger usage

• E2EE messengers are treated as transport, not archival storage:
  • Important documents are pulled into the client’s encrypted container.
  • Where feasible, older message histories for closed projects are pruned from devices.
• Screen or call recordings are not made by default. If recording is ever necessary:
  • Explicit consent is obtained.
  • The recording is stored in the client’s encrypted container and subject to the same retention rules.

7.3 Metadata acknowledgment

• Messaging and calling inevitably generate metadata (time, duration, frequency) stored by providers.
• Practice aims to:
  • Keep communications purposeful.
  • Avoid unnecessary chatter.
  • Move detailed technical exchanges into documents rather than sprawling chat threads.

8.1 Payment methods

Preferred mediums:

• BTC on-chain
• Lightning Network

Other media of exchange (XMR, stablecoins, cash, metals, barter, etc.) may be accepted or rejected according to the MOE Codex. Any use of fiat/bank rails is kept separate and minimal.

8.2 Recording

For each payment, I may record:

• Date/time.
• Approximate amount.
• Relevant transaction reference(s).
• Internal client ID.

For fiat/bank payments (if any), legal names and account identifiers are captured only to the extent required by the payment method and any legal obligations, and not mixed into architecture artifacts.

8.3 Retention

• Per-client payment details are stored in the client’s encrypted container as part of their record.
• A separate accounting view may track aggregate income and timing without listing client identities.
• Payment records are retained as needed to meet accounting and legal requirements; where possible, they remain pseudonymous and decoupled from any real-world identity.

Retention is deliberate and time-bound.

9.1 Definitions

• Project Completion Date: the date on which the agreed scope of work is delivered, unless otherwise defined in the SOW.
• All timeframes below are counted from this date.

9.2 Active engagement + grace period (completion + 30 days)

For the duration of the engagement and up to 30 days after Project Completion, the client’s encrypted container may hold:

• SOW and hash.
• Full architecture diagrams and working notes.
• Threat model, checklist, and remediation notes.
• Session summaries.
• Payment records.

Purpose: support follow-up questions, minor fixes, and a short stabilization period.

You may request an earlier transition to minimal retention; such a request must be authenticated via known keys or established secure channels.

9.3 Medium-term minimal retention (completion + 180 days)

From day 31 to day 180 after Project Completion, I may retain:

• SOW and hash.
• A short, abstract architecture summary (no real names, full addresses, or exact balances).
• Pseudonymous payment log entries for the client.

Detailed working artifacts (iterative diagrams, verbose notes, chat transcript exports, screenshots) are:

• Securely deleted to the extent technically possible, or
• Moved to an offline archive only if explicitly agreed.

9.4 Long-term offline archive (optional, max 5 years)

By default, I do not maintain full long-term client archives.

An offline encrypted archive for a specific client may be kept only if:

• Explicitly agreed in the SOW or a subsequent signed / cryptographically verified agreement, and
• You understand what is stored and for how long.

Such archives:

• Reside on encrypted offline media.
• Are labeled only with internal client ID(s), not names.
• Contain, at most: SOW, hashes, minimal architecture summary, and payment log entries.

Hard maximum retention for any such archive: 5 years from Project Completion, after which the archive is securely destroyed.

9.5 Payment / accounting data

Minimal pseudonymous payment and accounting records may be retained beyond 180 days or 5 years if required by applicable law or tax rules. For pseudonymous / high-OPSEC engagements, those records will not contain real names where that is legally permissible.

9.6 Deletion procedures

When data reaches its scheduled deletion point:

1. Logical removal
   Files are removed from client containers and, where applicable, from any offline archives. Applications’ “recent files” lists and relevant cache directories are cleared where possible.
2. Secure deletion & hardware refresh
   Secure deletion tools are used where supported by the filesystem and hardware.
   Periodically, storage media are fully wiped or physically destroyed and replaced, with only live client data migrated.

Once destroyed according to this process, data is not recoverable by me.

10.1 Handwritten notes

• Handwritten notes for client work are minimized.
• If made, they must be:
  • Transcribed into the client’s encrypted container within 7 days, and
  • Securely destroyed (e.g. shredded) immediately after transcription.

10.2 Printed documents

• Printing client materials is avoided.
• If printing is absolutely necessary (e.g. in-person workshop):
  • Prints are labeled only with roles / internal IDs, not names.
  • All copies are collected and destroyed at the end of the session.

10.3 Offline drives

• Offline backup/media containing client data are encrypted at rest and stored in secure physical locations.
• They are not labeled with client names.
• They are periodically reviewed and subject to the same destruction timelines.

11.1 No voluntary third-party sharing

Client data is not:

• Sold.
• Shared with marketing partners.
• Used in public case studies or testimonials without explicit, separate consent and careful anonymization.

If any third-party specialist must see a subset of data (e.g. a local lawyer, tax advisor, or security specialist):

• This is explicitly agreed in advance.
• Only the minimal required subset is shared.
• The third party is expected to operate under equivalent or stricter confidentiality and security standards.

11.2 Client-requested sharing

If you request that data be shared with your internal team or another vendor:

• The request must be authenticated (signed using a known key or made from an established secure channel).
• Only specified subsets are shared.
• Where possible, those subsets are re-encrypted for the recipient’s keys.

11.3 Compelled disclosure

If a lawful order requires disclosure:

• I will comply within the boundaries of applicable law.
• I will disclose only the minimum information required.

I cannot disclose seed phrases, private keys, or passwords, as these are never held.

Where legally permitted, affected clients will be informed that a disclosure request was received and the general nature of any information provided.

Minimization, pseudonymity, and bounded retention are deliberately designed to limit how much can be disclosed under compulsion.

SovStack data is structured to prevent cross-client inference:

• No “referral graph” or cross-client relationship map is maintained.
• Client records do not contain references to other clients (“similar to X’s setup”).
• Aggregated internal metrics, if any (e.g. “number of high-risk clients per region”), are generated without storing per-client identifiers in central lists.

Design patterns and templates are generalized and de-linked from any specific client before reuse.

13.1 Baseline security

For SovStack work:

• All work devices are full-disk encrypted and protected with strong, unique authentication.
• OS and critical software are kept reasonably up to date, without enabling invasive telemetry or surprise cloud features.
• Client workstations and accounts are segregated from personal and public activities.

13.2 Incident definition

A security incident includes, but is not limited to:

• Loss or theft of a client workstation or offline storage medium.
• Detection of malware or unauthorized access on a client workstation.
• Misdelivery or accidental disclosure of client materials.
• Compromise of password vaults or encryption keys used for client data.

13.3 Incident response

When an incident is detected:

1. Containment
   Disconnect affected devices from networks.
   Revoke or rotate affected credentials and keys.
2. Assessment
   Identify which client containers and payment records may be impacted.
   Determine whether an adversary might have obtained meaningful access.
3. Notification
   Inform affected clients promptly if their data or threat posture may have been impacted, within legal constraints.
4. Remediation
   Strengthen device and account security.
   Adjust tools and processes.
   Update this policy and internal SOPs as needed.

Within the bounds of pseudonymity and applicable law, you retain:

14.1 Right to understand what’s held

• Upon authenticated request, you may receive a summary of:
  • What categories of data are held under your internal ID.
  • The retention schedule that applies.

14.2 Right to correction

• You may supply updated technical or threat information.
• Outdated or misleading prior artifacts are replaced and scheduled for deletion.

14.3 Right to accelerated deletion

• You may request early destruction of:
  • Detailed architecture artifacts.
  • Working notes and diagrams.
• The request must be authenticated via known keys or secure channels.
• I may delay or limit deletion if:
  • The request appears inconsistent with the established relationship context, or
  • It conflicts with legal obligations (e.g. required accounting records).

Minimal payment/accounting records may be retained where required by law, but remain pseudonymous where possible.

This policy is versioned and reviewed at least annually, or sooner if:

• There is a significant security incident, or
• New tools or major threat shifts (e.g. regulatory changes, Synthetic Governance regimes) affect handling.

Periodic internal audits verify:

• Where client data resides.
• That retention timelines and deletion procedures have been executed.
• That no unauthorized cloud or AI tools are being used on client data.

Revisions apply to new and ongoing engagements. Existing data and practices are migrated toward the updated policy where feasible.