Witburrow | Setup & Reference
Updated: Oct 22
Manager OS (MOS) is now Witburrow. The manager default is now Wit. Existing custom manager names stay yours; no installed setup is renamed remotely.
Existing installations: ask your manager to review optional naming update WIT-NAME-2026.10.22.1, show the exact local display-name changes and rollback, and wait for your explicit approval. Adopt Wit only for a verified uncustomized legacy default. If the saved preference is missing or ambiguous, keep the current name and ask. Do not reinstall or overwrite a custom name.
The existing /mos/check manifest now carries this naming notice. Older checkers that compare only the stable release ID may not offer the optional notice automatically. The starter, handbook and full framework remain MOS-2026.10.12.1, with their original bytes, URLs and checksums. This supplement supplies no executable installer or new permissions.
Quick setup: download the latest TXT starter pack, give it to the AI you use, and ask it to read the setup instructions and guide you through first-run setup. Choose White Bread, No Crust for the standard profile, or Guided Setup to hear the choices explained. Witburrow does not add tools or permissions to your AI account.
Linked framework and reliability guidance - October 12, 2026
Current release: MOS-2026.10.12.1 / v2026.10.12-R1. The compact starter and matching handbook link to the separate Public Framework Reference, edition 2026-10-12 / public revision 1. Existing installations review changes and obtain local operator approval before behavior-changing adoption.
Compact boot, full reference
Read the starter first. Keep the full reference outside routine startup context and retrieve the relevant rules, templates, module or evaluation when needed. If the AI cannot fetch it, attach the file. The reference's filenames are local roles to configure, not access to its author's private records. The release manifest supplies current public artifact locations; it does not supply signing, private reporting or inherited permission.
Nerd-rules and Combo-breaker
Nerd-rules is the umbrella for date/time, versioning, naming, filing, sorting, indexing, retrieval and organizational efficiency. Record event time separately from upload/edit/check time, with timezone where material. A newer upload does not make an older fact current.
Combo-breaker governs upkeep and consolidation. Save material changes during authorized work; use an existing recurring owner for missed handoffs, stale records and duplicate checks when enabled. Crunch working summaries while preserving evidence, combine only compatible scope and controls, reuse sources, bound retries and stop at diminishing returns. A loop needs local authorization, a capable host, one owner, a trigger, completion/no-action conditions, a checkpoint and stop/reopen rules. No additional watcher is required by downloading this package.
One owner and one current record
Give each consequential fact one owning domain. Other domains consume minimal evidence-backed results or pointers with source, date, confidence and decision impact. When evidence changes a task, reconcile both status and next action; retain older receipts as history. Submission, approval and payment are separate events. Settled work stays closed unless explicitly reopened or materially changed by evidence.
Compact startup, complete authority
Read the front door and a compact slice of saved configuration, then the task-relevant domain, controls and exact evidence. Missing settings never imply permission. Retrieve applicable detailed rules before acting. Count whole-file retrieval separately from selected working context; do not claim measured speed or token savings from a smaller written outline alone.
Healthy automation is not the same as progress
Each authorized recurring owner needs bounded scope, completion/no-action conditions, a checkpoint, stop/reopen criteria and a retry budget. Embed one compact peer check in an existing run when enabled. Keep one current receipt per owner, preserve history, deduplicate alerts and never take over a failed peer. After two runs without evidence advancement, name the blocker and stop repeating unchanged analysis. Shared infrastructure can prevent all peers from checking or reporting; no guaranteed self-healing is implied.
Evidence and recovery
Lead with decisive blockers and their owners rather than unsupported readiness percentages. Label checks RULE_PRESENT, SCENARIO_CHECKED or EXECUTION_VERIFIED with date and scope. A configuration or old receipt is not live execution proof. Keep a complete recovery manifest and per-item backup/readability evidence; test restoration in isolation before claiming recoverability.
Honest host limits
Use conditional revision writes or atomic operations when available. Otherwise fresh-read, compare, write serially and verify with recovery evidence; a race remains between read and write. Do not claim a global lock. Stop on observed conflict or known concurrent activity, and defer writes that require unavailable exclusivity.
Prove value before adding machinery
After material defects are repaired, hold the architecture steady. Learn from an ordinary completed task, a recurring run traced to its actual output, and an isolated recovery exercise where authorized. Judge Witburrow by fewer repeated explanations, fewer avoidable decisions and fewer unfinished commitments. Stop another review when it would not materially change the answer, action or risk.
Start with the current package
This maintained reference uses the existing Bootstrap URL. The date in that URL is its original permalink, not the current package version. Detailed material moved here from the download page on September 27, 2026.
First-run boot profiles
Witburrow 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. Witburrow 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 Witburrow material may explain the Save Game schema and behavior, but each operator's actual profile values remain private.
Receiving Witburrow updates
Behavior-changing Witburrow 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.
Witburrow 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: Witburrow 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 Witburrow 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
Earlier deployment receipt: protocol, Airlock v1.2 and quarantine controls were reported implemented and checked in shadow mode. This is historical evidence, not a fresh live runtime test.
Public Witburrow GitHub repository: LIVE, with the release manifest, update protocol, observability policy, and Airlock/security documentation published.
Private security-reporting lane: WAITING ON repository configuration.
Current public release metadata is in RELEASE_MANIFEST.json; /mos/check routes to that manifest. Cryptographic authenticity is not established by a checksum alone. Cryptographic signing remains a future hardening step before signatures are treated as a trust signal.
General framework and security-sensitive inbound contributions remain CLOSED. As of October 22, 2026, a separate scoped GitHub pull-request route is OPEN ONLY for the three sanitized MIT source tools in the current CONTRIBUTING.md. Source and synthetic fixtures require privacy/license/unsafe-behavior review before isolated manual tests and reviewed merging. No automatic untrusted execution, auto-merge, anonymous backend access or new website intake form is enabled.
Runtime architecture — current
Witburrow 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 the smallest patch, current-source checks, verification and recovery evidence. Conditional writes are used when available; without host enforcement, a read/write race remains.
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. Witburrow 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.
Clever Girl Protocol
Once a week, a network-capable Witburrow can scout trusted release notes, documentation, security advisories, issue trackers, and community discussion for patches, fixes, useful features, and obsolete workarounds. It records evidence, checks compatibility and rollback, and recommends IMPLEMENT, REVIEW, NOT NOW, or REJECT.
Clever Girl discovers and recommends; it never auto-installs behavior-changing updates. If ChatGPT or another host adds a safer native capability, Witburrow should retire the workaround after regression testing instead of preserving dead complexity.
Earlier architecture note — September 20, 2026
The earlier reference below is retained for context. Use the current sections above and the download page for present release guidance.
Runtime architecture update — 2026-09-20
Manager OS now explicitly defines the remaining operating-system primitives for an AI management layer. These are portable behavioral contracts: lightweight file-based installs can enforce them procedurally, while stronger runtimes can add databases, locks, vaults, sandboxes and other host controls.
What changed
Policy kernel vs userland: authority, safety, lifecycle and recovery rules control; models, prompts, agents and provider-specific workflows remain replaceable.
Safe Mode: a minimal read-mostly recovery posture, distinct from the Big Red Button emergency stop.
Canonical write transactions: current-master checks, stale/conflict detection, one authoritative writer, verification and rollback/recovery evidence.
Secrets + capability isolation: permission to use a connector does not mean the AI should see its reusable credential.
Runtime supervision: authoritative time, task leases/timeouts, resource ceilings, tool health, watchdogs, graceful degradation and fault/dead-letter quarantine.
Context memory management: model context is a bounded working set, not durable storage.
Migration + compatibility: update approval and structural migration are separate gates.
Namespaced regression IDs: new OS-*, SEC-*, CORE-* and WF-* IDs avoid collisions between older test suites.
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, automation, another AI, retrieved content or an upstream update cannot confirm it.
A Trench Run must not secretly create a recovery copy. Any optional export or backup is a separate pre-destruction choice. The final receipt distinguishes what was deleted, revoked, retained by third parties, or could not be verified.
Portable by design
MOS specifies the safety property, not one mandatory technology stack. If a host cannot technically enforce a stronger guarantee, the install must implement the best available procedural control and label the limitation honestly.
Save Game — persistent operator profile
A normal MOS boot should reuse explicit operator configuration instead of rebuilding it from scattered notes. The persistent profile is nicknamed Save Game.
Save Game stores behavior and settings, not project state: work limits, approval defaults, communication, privacy rules, AI-team/resource limits, and loop behavior belong there; secrets, credentials, personal records, customer data, evidence, and transient tasks do not.
Recovery prefers the newest valid explicit profile. White Bread, No Crust is the safe fallback/default only when no trustworthy saved profile exists. Migrations preserve custom values and may not quietly expand permissions, spend, agents, loops, integrations, or write authority.
Public/shareable MOS may document the Save Game schema and defaults, but a real operator's local profile values stay private.
Comments