Recovery OS

The problem

Recovery environments depend on repeated structure: reliable information, daily orientation, private reflection, clear responsibilities, and communication that can survive stress. Software can help organize those functions, but it can also distort them. A check-in can become a compliance signal. A journal can become an institutional record. A workflow can become a ranking system. An automated response can acquire authority it has not earned.

Generic wellness software often flattens the specific realities of recovery, while institutional software can over-collect data and turn participation into monitoring, compliance, or scoring. A single application with progressively broader access would make it difficult to know what is public, what belongs to the individual, what an organization can see, and which decisions must remain human.

Recovery OS began from a different premise: structure should support agency without converting a person into a monitored object. The product problem is therefore not how to accumulate more recovery data, but how to organize distinct contexts without creating an invisible bridge between them.

The system

Recovery OS uses a mode-separated architecture rather than one shared data model.

Public Packet Mode: live-static public mode, with output generated from reviewed sources rather than live private data. It compiles public information into a canonical briefing used by reading, print, spoken-presentation, and diagnostic surfaces. Public summaries remain tied to their sources and the final rendered packet remains subject to human review.

Individual Mode: synthetic interactive design — no runtime. It demonstrates reflective sequences, journaling, intentions, routines, educational lenses, and privacy-control concepts using fixed fictional examples and temporary page-local state. Reloading clears the state. There is no account, persistence, analysis, memory, transmission, or organization visibility.

Organization Mode: synthetic interactive design and architecture — no runtime. It demonstrates configuration, role and workflow templates, visibility policy, operational accountability, and communication drafting. It creates no tenant, identity, role assignment, workflow record, submission, review queue, staff decision, placement, or analytics stream.

Human support remains outside the present product. The current system does not detect crisis, infer risk, route support, notify an organization, score recovery, or replace professional care.

How it works

Public Packet Mode

The public pipeline separates source fetching, parsing, normalization, freshness and source-quality checks, safety and section fit, duplicate suppression, diversity, optional source-bound summarization, final-output validation, and canonical compilation. Print and spoken views derive from the same accepted selection rather than rebuilding the packet independently.

The operator surface exposes source health, section counts, warning categories, timing, and generation mode as read-only evidence. Those diagnostics do not override the rendered output. A parser or automated test can pass while a packet remains repetitive, stale, thin, or editorially unsuitable, so human review of what will actually be read remains part of acceptance.

When safe source material is insufficient, the pipeline may underfill a section rather than manufacture fluent filler. Optional AI assistance is limited to public, supplied source context and remains behind schema, budget, and output validation. Source-only output remains available as the fallback.

Individual Mode

The Individual design explores optional morning and evening check-ins, a journal, self-review before feedback, intentions, routines, private-accountability concepts, human-support planning, and privacy and control. Current feedback is fixed design copy and does not read or analyze a draft. The person encounters their own review before any feedback surface appears.

Interaction is real enough to evaluate sequence, language, skip and reset paths, keyboard behavior, mobile behavior, and coercion risk, but it is not a private-data application. The temporary controls do not submit, store, transmit, score, remember, or share anything. Consent, deletion, inventory, and export are inspectable interface concepts rather than live operations.

Organization Mode

The Organization design explores how settings, roles, shared tasks, blockers, accountability, and community communication might be represented without turning operational status into recovery status. Fixed fictional examples and page-local state allow the workflows to be reviewed without creating organizational records.

Drafting and visibility previews stop before submission. Accountability examples stop before evidence upload, approval, discipline, or scoring. Organization Mode has no default access to Individual Mode content or activity, and the two designs do not share a hidden user record, memory layer, or analytics stream.

Architecture

Recovery OS is an Astro static application supported by Node-based generation and validation and Playwright-based browser, interaction, print, and deployment evidence. The public system compiles one canonical packet for multiple presentation surfaces and keeps source evidence, transformations, warnings, and readiness distinguishable.

A narrow public packet-history design can retain sanitized public runs and diagnostic state when configured. It is not a private recovery database and provides no foundation for Individual or Organization Mode records. The current synthetic modes contain no network request, browser persistence, telemetry, identity field, or submission behavior.

The safety model is layered. Ordinary public routes retain strict static boundaries. Explicitly marked synthetic routes use a separate interaction contract that permits temporary controls while rejecting persistence, network activity, telemetry, identity, and runtime claims. Cross-mode rules prohibit a shortcut that would join individual reflections, organization workflows, identities, support activity, public packet use, billing, analytics, or AI history.

Automated tests, structural scans, build output, deployment markers, rendered screenshots, and human acceptance remain different kinds of evidence. One does not silently stand in for another, and none establishes clinical, privacy, security, legal, accessibility, adoption, pilot, or launch approval.

Decisions and tradeoffs

Mode-specific boundaries require more architecture and more qualification language than a single privacy claim, but they make visibility and authority inspectable. Public information, individual reflection, organizational workflow, AI assistance, and human support are separated by default rather than connected first and restricted later.

Keeping source material separate from interpretation can produce shorter or less polished public sections when evidence is thin. That tradeoff keeps fluency subordinate to truth. Requiring self-review before feedback reduces conversational immediacy, but it prevents fixed or future automated responses from becoming the first authority over a person’s writing.

Temporary synthetic interaction cannot demonstrate continuity, deletion, consent, or security behavior in a future runtime. It does allow interaction, accessibility, and coercion risks to be examined without collecting private information or prematurely authorizing accounts, storage, AI analysis, memory, or organization workflows.

The system treats unresolved and underfilled states as legitimate results. That refusal limits the appearance of completeness, but protects the boundaries the project is designed to study: what the software knows, who can see it, what authority it claims, and what must remain human.