• Technical Overview for Implementers and Support Teams
• System Architecture (High Level)
• Identity and Authorship
• Supported Content Types (Current)
• Local Storage vs Public Sharing
• Publishing Model
• Security & Risk Profile
• Design Philosophy
• Terminology Note

§Technical Overview for Implementers and Support Teams

Andrew G. Stanton - Jan. 30, 2026

Continuum is not a platform.

It is a local publishing system that allows content to be created, verified as authentic, and shared publicly without depending on centralized services.

§System Architecture (High Level)

Continuum runs locally on a single machine using a Linux-compatible container environment.

It has been tested and is known to run on:

• macOS using Docker
• Windows using Docker with WSL

Continuum has not yet been tested on native Linux systems, although no Linux-specific dependencies are known.

There is no hosted backend and no external service dependency.

§Identity and Authorship

Continuum uses a simple but powerful idea:
each piece of content is cryptographically tied to the identity that created it.

In practical terms, this means:

• Every published item includes proof of who authored it
• That proof cannot be altered without detection
• Readers and systems can independently verify authenticity

You can think of this like a digital seal attached to each publication.

No passwords are sent anywhere.
No external service is required to confirm authorship.

§Supported Content Types (Current)

Continuum currently supports creating, editing, deleting, and locally storing:

• Profiles — identity metadata
• Notes — short-form posts
• Articles — long-form writing
• Delete records — explicit retractions (“tombstones”)

Delete records are preserved intentionally so that removals are clear and verifiable rather than silent.

Direct Messages (DMs) can be sent and received, but are not archived yet.

§Local Storage vs Public Sharing

Continuum always stores authored content locally.

Public sharing is explicit and intentional. Nothing is automatically uploaded, mirrored, or archived.

Long-term public archiving requires:

1. Running a deliberate export process
2. Configuring a destination (such as a static site or repository)

This ensures:

• No accidental exposure
• Clear operational boundaries
• Independence from third-party platforms

§Publishing Model

Publishing is a conscious action.

Continuum does not:

• auto-publish
• auto-sync
• auto-backup to the cloud

This keeps behavior predictable and auditable.

§Security & Risk Profile

Continuum minimizes risk by design:

• No browser-based authentication
• No remote credentials
• No central account database
• Small, inspectable system footprint

It can be run offline or in restricted environments.

§Design Philosophy

Continuum favors:

• Explicit actions over automation
• Ownership over convenience
• Integrity over abstraction
• Durability over growth mechanics

It is infrastructure for people who want to own their publishing workflow end-to-end.

§Terminology Note

Under the hood, Continuum uses a protocol (Nostr) that refers to authorship verification as “signing” events.

You do not need to understand Nostr to operate or evaluate Continuum.

The important idea is simple:

Content can be proven authentic without trusting a platform.