A Manifesto for Sovereign Personal Software

“Your data belongs to you. Your tools should respect your time, preserve your freedom, and remain useful without depending on someone else’s infrastructure.”

Read or print the full text →

Section 01

The Core Manifesto

Software should adapt to people, not force people to adapt to software.

Modern productivity and engineering applications offer remarkable capabilities, yet most increasingly depend on remote cloud infrastructure, recurring subscriptions, opaque interfaces, and features engineered for corporate retention rather than individual utility.

Sovereign personal software represents a deliberate alternative. It rests on the conviction that personal computing tools should be owned, controlled, understood, and shaped by the people who rely on them.

AI-assisted development makes custom, high-craft software increasingly practical for individuals and small teams to build. However, reducing the cost of writing code does not eliminate the laws of software engineering: disciplined architecture, formal verification, boundary security, and sustainable maintenance remain non-negotiable.

Six Foundational Principles Define Sovereign Software:

I. SOVEREIGNTY

Users control their data, infrastructure, cryptographic keys, and migration paths.

II. LOCALITY

Core functionality runs on the user's device, independently of network connectivity.

III. PREDICTABILITY

Critical state transitions and rule engines are deterministic, transparent, and testable.

IV. RESPONSIVENESS

Software respects human attention with sub-100ms feedback and zero artificial friction.

V. INTEROPERABILITY

Applications maintain bounded responsibilities while exchanging data across open formats.

VI. LONGEVITY

Information must outlive individual applications, vendors, and runtime technologies.

Section 02

The Six Foundational Principles

PRINCIPLE I Data Freedom & Custody

Sovereignty: The User Is the Owner

Personal information must never become inaccessible because a subscription expires, an account is suspended, or a service shuts down. Sovereignty requires uninhibited control over data, including native inspection, export, backup, and migration. Because true ownership transfers custodial responsibility to the user, sovereign software must make automated, verifiable backups and cryptographic key recovery a zero-friction part of the core experience.

→ Ownership is meaningful only when you retain both the ability to leave and the resilience to recover.

PRINCIPLE II Local-First • Offline

Locality: The Device Comes First

The network should enhance an application, not determine whether it can function. Creating records, updating states, compiling outputs, and searching locally stored information must remain 100% available offline. Local storage is the primary working environment^[1]; synchronization operates asynchronously with explicit status and deterministic conflict recovery.

→ Offline operation is not an emergency fallback. It is the baseline operating model.

PRINCIPLE III Deterministic Grammar

Predictability: Rules Must Govern

Schedules, financial ledgers, geometry kernels, and state machines represent deliberate commitments. Their behavior must be consistent, explainable, and reproducible. Sovereign software uses deterministic rules for critical operations and explicitly surfaces ambiguous inputs rather than silently guessing. Probabilistic AI may assist at the boundary, but proposed actions must be validated before execution.

→ Intelligence may assist at the boundary. Predictability must govern at the core.

PRINCIPLE IV Sub-100ms Latency

Responsiveness: Respect Human Attention

Software should reduce cognitive effort, not become another source of work. Routine local interactions must provide immediate perceptual feedback within 100 milliseconds on standard hardware. Responsiveness also demands restraint: eliminating unnecessary notifications, telemetry beacons, background churn, and interface bloat.

→ Good software helps users complete their work without becoming work itself.

The 100ms figure follows the widely cited response-time limits of Miller (1968)^[2] and Nielsen (1993)^[3]: about 0.1s feels instantaneous, about 1s keeps flow, about 10s is the limit of focused attention. They are practical guidelines, not precise laws. Nielsen, Response Times: The 3 Important Limits

PRINCIPLE V Anti-Monolith • Composable

Focused Interoperability

Managing operational actions is fundamentally distinct from preserving long-form knowledge or editing raw media. Sovereign tools maintain bounded responsibilities^[4] while connecting through documented interfaces: URI schemes, plain-text sidecars, local sockets, CLI pipes, and open interchange standards, with clean import/export bridges on sandboxed mobile OS environments.

→ Separate responsibilities. Connect information. Preserve freedom of choice.

PRINCIPLE VI Decades-Long Survivability

Longevity: Information Outlives Software

Applications and vendors are transient; human records remain valuable across decades. Sovereign software resolves the tension between high-speed local execution and long-term human readability through dual-layer persistence: pairing fast local indexing (such as SQLite^[5]) with deterministic, human-inspectable plain-text files or sidecars.

→ Applications are temporary. Human information deserves a longer life.

Section 03

The Architecture of Personal Computing

Sovereign systems follow a modular model that decouples high-frequency operational state execution from long-term intellectual preservation while allowing both to cooperate smoothly without vendor lock-in.

Layer 01 • The Execution Layer Taskwarrior, Beancount, Local SQLite State Machines

Responsible for capturing commitments, managing lifecycles, schedules, priorities, and deterministic transactions.

Central Question: “What needs to be done, when, and in what exact state is it?”

↕ OPEN INTEGRATION LAYER: Application URIs (app://) • Sidecars (.xmp / .json) • POSIX Pipes • CLI • .ics ↕

Layer 02 • The Preservation & Knowledge Layer Markdown Vaults, Git Repos, Paperless PDF/A, Raw Assets

Responsible for journals, research notes, documentation, raw creative media, CAD scripts, and decades-long archival reference.

Central Question: “What have I created, experienced, and understood?”

Section 04

AI Without Artificial Dependency

AI coding agents accelerate development, and local or remote models can assist workflows. Sovereign software accepts optional AI assistance only when:

✓ Core functionality remains 100% operational without AI.
✓ The human operator explicitly authorizes proposed state mutations.
✓ Critical pipelines remain deterministic and verifiable.
✓ Privacy, cost, and network boundaries are transparent.
✓ Removing AI never compromises access to existing data.

AI may help create or assist the software. It must never become a hostage-taker.

Section 05

Synchronization Without Surrender

Synchronization is a transport convenience, not a transfer of custody. Because concurrent offline edits across devices inevitably create divergence, sovereign software enforces explicit conflict policies:

Syntactic Convergence: Handled via mathematically verifiable structures (CRDTs^[6] or append-only operation logs).
Semantic Divergence: When concurrent offline changes contradict human intent, both branches are preserved transparently rather than silently overwritten.

Complexity must always justify its existence.

Section 06

The Seven Engineering Evaluation Tests

Launch Interactive Scorer →

Every significant feature, dependency, or architectural decision must pass seven non-negotiable verification gates:

GATE 01 // OFFLINE TEST (AIR-GAP)

Does all primary functionality remain 100% operational with the network interface physically disabled?

GATE 02 // 100ms TEST

Do common local interactions respond within 100 milliseconds on baseline commodity hardware?

GATE 03 // LONGEVITY TEST

Can users recover, inspect, and understand their raw data using standard POSIX tools if the binary disappears?

GATE 04 // RESPONSIBILITY TEST

Does this feature belong in this tool's bounded domain, or should a specialized external utility provide it?

GATE 05 // DEPENDENCY TEST

Does it avoid mandatory third-party cloud accounts, fragile transitive dependency trees, or subscriptions?

GATE 06 // PREDICTABILITY TEST

Are state transitions and conflict resolutions formally specified, reproducible, testable, and free of silent guesswork?

GATE 07 // RECOVERY & SECURITY TEST

Does the design preserve local cryptographic integrity while providing a frictionless, verifiable path for user backup and disaster recovery?

Section 07

What Sovereign Software Refuses to Become

✕ Mandatory Cloud Lock-In: Accounts and subscriptions required for essential local execution.

✕ Unchecked AI Mutation: Non-deterministic inference injected directly into critical state operations.

✕ Invasive Telemetry: Undisclosed tracking or harvesting of personal daily activity.

✕ Monolithic Feature Bloat: Cluttered duplication of specialized editors, suites, or kernels.

✕ Silent Sync Corruption: Opaque synchronization routines that overwrite conflicting offline work.

✕ Unrecoverable Custody: Fragile, complex backup procedures that expose users to data loss.

The ability to add a feature is never sufficient reason to add it.

Section 08

Personal Software in the Age of AI

Historically, software development required substantial capital, forcing products toward mass-market monetization and lock-in. AI-assisted engineering alters that economic relationship: individuals and focused communities can now build durable applications around their exact needs without requiring venture-scale audiences.

Software no longer always needs a large market to justify its existence.

Section 09

The Permanent Standard

Sovereign software is never defined by a transient UI framework, database library, or sync algorithm. Its identity rests on enduring principles: remaining useful when disconnected, understandable when examined, recoverable when hardware fails, and subordinate to human agency.

Above all, it remains a tool under human control.

References

Sources

These sources support specific arguments above. The response-time limits are practical guidelines, not precise laws.

[1]M. Kleppmann, A. Wiggins, P. van Hardenberg and M. McGranaghan, “Local-first software: you own your data, in spite of the cloud,” Onward! 2019, pp. 154–178. DOI: 10.1145/3359591.3359737. Link
[2]R. B. Miller, “Response time in man-computer conversational transactions,” Proc. AFIPS Fall Joint Computer Conference, vol. 33, 1968, pp. 267–277.
[3]J. Nielsen, Usability Engineering, Academic Press, 1993, ch. 5. Link
[4]M. D. McIlroy, E. N. Pinson and B. A. Tague, “UNIX Time-Sharing System: Foreword,” Bell System Technical Journal 57(6), 1978, pp. 1899–1904. Link
[5]SQLite, “Recommended Storage Format for Datasets” (US Library of Congress designation). Link
[6]M. Shapiro, N. Preguiça, C. Baquero and M. Zawirski, “Conflict-free replicated data types,” SSS 2011, LNCS 6976, pp. 386–400. Link