Environment isolation
For the first beta participants, each corpus, identity, credentials, logs, jobs, backups, support path, export, and deletion path belongs to one isolated environment.
Security and privacy boundaries
Name the control. Name the limit.
Substrate uses isolation, authenticated ingress, private evidence storage, publication checks, and deletion workflows in the current beta. These are specific controls—not a blanket claim that every deployment is secure, private, or compliant.
Implemented controls
Concrete boundaries in the current service.
Controls below describe the current isolated application architecture. Their effectiveness still depends on correct deployment, operations, provider configuration, and participant behavior.
External access gate
Current VM deployments use Caddy Basic Auth as the external gate. The application itself has no customer session, user-identity, or role model for HTML routes.
Private evidence boundary
Detailed source contributions and provenance stay in the private ledger. Published pages and memory cards are narrower projections intended for retrieval.
Publication checks
Publication paths reject configured secrets and credential-shaped material, bound exposed quality diagnostics, and audit searchable surfaces for credential residue.
Credential containment
A fail-closed cleanup control, not a guarantee.
One deterministic detector protects capture redaction, derivation and ledger validation, projection and revision writes, and search/read responses. A coordinated startup sweep also checks private ledger state, published pages, revisions, search units, memory cards, and projection data, removes flagged active content, and records completion.
Containment reduces known exposure paths. It cannot prove that every secret format will be detected, reverse disclosure to an external system, replace credential rotation, or guarantee that no credential ever entered logs, provider systems, backups, screenshots, or human-controlled copies.
Before serving
Configured production credentials are validated, and the destructive containment phases run in fail-closed order before the coordinator marks completion.
At publication
Secret-shaped fields and known exact secrets are rejected or redacted from customer-facing quality output and published memory surfaces.
On detection
Treat the finding as an incident: remove affected memory, rotate the credential at its issuer, inspect applicable logs and providers, and verify containment again.
Privacy deletion
Delete from the source model, then rebuild the views.
Privacy deletion is an implemented idempotent, fail-closed state machine—not a page-hide operation. It records deletion intent, suppresses retrieval, purges generated copies and revisions, unlinks the raw event, and rebuilds only from remaining safe support.
Retained raw conversation payloads otherwise follow the current 90-day event-store policy. Immediate erasure from every infrastructure backup or external provider is not claimed; deployment-specific retention and support procedures still apply.
Record deletion intent first
Before unlinking a raw event, the service durably records content-free deletion intent and event-alias tombstones so a crash can resume the same request safely.
Suppress affected memory
Dependent claims and relationships are emptied and marked deleted, with per-entity retrieval suppressions applied before the raw event is removed.
Purge every generated copy
Affected page bodies, metadata, complete revision history, snippets, search results, and automatic cards remain unavailable while the projection is rebuilt from remaining safe support.
Prevent replay resurrection
The durable tombstone is reconciled on retry, including when the raw event is already absent, and retained source replay is blocked from restoring the deleted event.
What is not claimed
The beta boundary remains narrow.
A complete customer-facing privacy and security review, final retention schedule, incident commitments, access lifecycle, and shared workspace model are still beta work.
No blanket assurance
No general “secure,” “private,” “enterprise-ready,” or compliance claim is made. No certification is represented on this page.
No shared tenancy
Isolation between separately deployed environments is not the same as a proven multi-tenant authorization architecture.
No control is absolute
Authentication, redaction, containment, backup, and deletion controls all require correct configuration and operations. They reduce specific risks rather than eliminate them.
Deploy deliberately
Define the data and support boundary before ingestion.
Closed-beta onboarding should identify authorized sources, provider use, retention, support access, export, and deletion handling for the specific isolated environment.