Architecture · Published 26 August 2026
Designing a founder operating system around an open company record
Why Markdown, schemas, deterministic paths, Git history, and review transitions form a stronger substrate than opaque automation.
The company record must outlive the interface
Decisions, obligations, money records, people, and run logs are stored as validated files in a founder-owned repository. The cockpit and CLI are views and commands over that record, not the only place it exists.
Forward-only schema migrations keep old records intelligible and make change explicit.
Imports are untrusted evidence
Adapters fetch vendor data into typed staging records with source identity and observation time. Imported text cannot become an instruction to the Operator and a failed parse cannot partially update canonical files.
Reconciliation names conflicts instead of selecting the convenient value.
Automation drafts before it acts
Workers produce proposals for decisions, close, digest, KPI, content, and notifications. Risk classification determines whether a human transition is required before a consequential effect.
Approval binds the exact proposal and leaves an attributable log entry.
Handback is an architecture feature
Backup, restore, open files, and Git history are exercised as normal workflows. Hosted export should preserve the current company inventory without requiring an operator ticket.
Services not yet connected remain labelled as commitments, not simulated integrations.
Production checklist
- Verify Founder ownership against the deployed environment, not a screenshot.
- Verify Proposal before effect against the deployed environment, not a screenshot.
- Verify Attributable Run Log against the deployed environment, not a screenshot.
- Verify Testable handback against the deployed environment, not a screenshot.