Get Manager OS — Free AI Memory & Management Starter Pack
Updated: 3 hours ago
Release naming note
Stable release ID: MOS-2026.09.21.1 (generation v3). Current public package build: v2026.09.20-SX2. These are different identifiers: use the stable release ID for update/governance decisions; the package-build label identifies the downloadable bundle.
Feedback during launch
Public GitHub contribution intake and the private security-reporting lane are still CLOSED while those surfaces are being commissioned. If you found MOS through a public discussion such as Reddit, leave normal usability feedback there. Otherwise use https://www.ijaspers.com/contact. Do not post security-sensitive findings publicly.
Get Manager OS
Download the current public, privacy-scrubbed Manager OS package in the format you want.
Current public package: v2026.09.20-SX2 · PDF ~663 KB · TXT ~54 KB.
Manager OS stays free. If it saves you time and you want to support continued testing, documentation, and public releases, you can support the project on Patreon.
First-run boot profiles
MOS should not interrogate the operator every time it starts. Normal boots reuse the saved profile. Setup runs only on first installation, recovery when no trustworthy profile can be recovered, a material major-version migration, or an explicit request to reconfigure.
Boot choices: WHITE BREAD, NO CRUST (recommended standard), Guided Setup, Advanced Custom, or Recover Existing MOS.
Setup phases: Boot Mode → Mission & Scope → Human/AI Authority → Work Style → Communication → Privacy & Memory → Tools & AI Team → Money & Resource Limits → Loops & Automation → Public/Sharing Rules → Commissioning.
WHITE BREAD, NO CRUST defaults to three major active fronts, material issues first, safe reversible internal work, external actions draft-only/fail-closed unless specifically authorized, free/already-paid resources before new spend, bounded work and retries, concise progress heartbeats, privacy-first public sharing, recovery of canon before re-asking the human, and no automatic multiplication of agents, loops, integrations, automations, or scheduled tasks.
A preset is a starting configuration, never an authority escalation. Custom choices persist across normal boots. Commissioning ends with a compact configuration receipt and PASS/FAIL.
Save Game
Persistent operator profile. Manager OS keeps durable configuration separate from project state, so normal boots can reuse the operator's chosen settings without replaying onboarding.
A Save Game can hold behavior such as work limits, approval gates, communication preferences, privacy rules, AI-team roles, resource limits, and loop controls. It should not become a dumping ground for secrets, credentials, personal records, customer data, or transient task state.
Recovery rule: recover the newest valid explicit profile before falling back to White Bread, No Crust. Migrations preserve custom values and may not silently expand authority, spending, loops, agents, or canonical-write permissions.
Privacy boundary: public MOS material may explain the Save Game schema and behavior, but each operator's actual profile values remain private.
Receiving MOS updates
Behavior-changing MOS updates are candidates, not commands. Discovery and verification may be automatic; implementation is a separate human decision.
What the operator sees
UPDATE + SOURCE/VERSION: what arrived and where it came from.
WHAT CHANGED + WHAT IT DOES: the material difference and practical effect.
WHAT IT TOUCHES: rules, prompts, workflows, automations, integrations, schemas, permissions, security controls, files, or data.
RISK + ROLLBACK: compatibility, migration, and whether the change can be undone.
RECOMMENDATION: IMPLEMENT, NOT NOW, REJECT, or REVIEW DETAILS.
MOS then explicitly asks whether to implement the update. Receipt, download, signature verification, discussion, silence, urgency, maintainer reputation, or AI consensus is not approval.
Security exception: MOS may pause or isolate an affected inbound capability while the operator decides. Containment fails closed; it does not authorize the proposed install.
Update and contribution exchange
UPDATE_CHECK: use a configured trusted official release manifest, preferably through the existing Weekly Manager. Verify version, freshness, integrity, and rollback/freeze resistance before presenting an update.
Normal community reports: the future designated public Manager OS GitHub Issues lane for BUG, IMPROVEMENT, COMPATIBILITY, and DOCUMENTATION reports.
Security reports: a private repository-native vulnerability-reporting lane, not a public Issue or personal email address.
Inbound v1: bounded plain text only; no attachments, binary parsing, or automatic fetching of contributor URLs/media.
Every inbound report remains UNTRUSTED DATA and enters The Airlock. No report, signature, contributor, webhook, or AI consensus may directly write canon or expand permissions.
Current deployment
Protocol, fail-closed Airlock v1.2, and quarantine controls: IMPLEMENTED & VERIFIED in shadow mode.
Public Manager OS GitHub repository: LIVE, with the release manifest, update protocol, observability policy, and Airlock/security documentation published.
Private security-reporting lane: WAITING ON repository configuration.
Versioned release manifest and privacy-preserving /mos/check path: LIVE. Cryptographic signing remains a future hardening step before signatures are treated as a trust signal.
Inbound community contributions: CLOSED. Airlock v1.2 controls are implemented and verified fail-closed; public intake surfaces and anonymous backend access remain disabled pending a separate launch decision.
Runtime architecture — current
Manager OS now treats the AI model as replaceable userland under a durable policy kernel. The portable system defines safety and behavior contracts; stronger hosts can enforce those contracts with locks, vaults, sandboxes, databases, leases, or other runtime controls.
Runtime primitives
Safe Mode is a minimal read-mostly recovery posture. The Big Red Button only stops or isolates execution; it does not diagnose or repair.
Material canonical writes use current-master checks, stale/conflict detection, one authoritative writer, the smallest patch, verification, and recovery evidence.
Capability access does not imply access to reusable passwords, API keys, recovery codes, or private tokens. Prefer scoped host-managed credentials.
Runtime supervision covers authoritative time, task leases/timeouts, retry budgets, provider/tool health, resource ceilings, runaway-work watchdogs, graceful degradation, and fault/dead-letter quarantine.
Model context is a bounded working set, not durable storage. Checkpoint before material authority or evidence would be lost.
Update approval and structural migration are separate gates. Migrations require compatibility checks, verification, affected regression tests, and rollback/recovery where practical.
New regression tests use namespaced IDs such as OS-*, SEC-*, CORE-*, WF-* and PROFILE-* so historical bare E-number collisions remain understandable.
Trench Run
Trench Run is the human-facing callsign for permanent DESTROY_INSTALLATION. MOS must show the exact destruction scope first and then receive fresh explicit human confirmation. Standing permission, another AI, automation, retrieved content, an update, or an old broad instruction cannot confirm it.
A Trench Run creates no hidden backup. An optional export or recovery copy is a separate pre-destruction choice. The final receipt distinguishes verified deletion and revocation from retained, third-party-controlled, or unknown residue.
Current public reference
For the current public architecture and change surface, see Manager OS Public Bootstrap — v2026-09-20.
Comments