A public, working implementation of a remote-first operating system designed for decision visibility, workflow clarity, and execution across a fully distributed team.
Watch the Decision Capture Pipeline run (4 min) | Explore the live Notion workspace
Remote-first companies face a compounding challenge: as teams grow, decisions scatter across threads, calls, and ad hoc documents. Context evaporates. Alignment erodes. Tools multiply without governance. The result is operational entropy; not from lack of effort, but from lack of structure.
This project addresses a deceptively simple question:
How do you design a system where decisions are visible, documentation stays fresh, automation has guardrails, and growth does not create chaos?
This is not a theoretical framework. It is a structured, working system designed to be readable, extensible, and auditable. Every component was built with three constraints in mind:
- Adoptable within 30–60 days by a small cross-functional team.
- Async-first - every artifact is designed to be consumed without a meeting.
- Governance over chaos - automation is introduced with human override at every stage.
Remote-OS-Architecture/
├── 00_principles/
│ ├── operating-principles.md # Core async-first operating principles
│ └── governance-matrix.md # Automation vs. autonomy tradeoffs and guardrails
│
├── 01_information-architecture/
│ ├── notion-ia-map.md # Notion structure blueprint and SSOT rules
│ └── content-lifecycle.md # Draft → Active → Archived → Retired lifecycle
│
├── 02_decision-visibility/
│ ├── decision-log-schema.md # Decision Log database schema (14 properties)
│ └── decision-template.md # Standard decision document template
│
├── 03_workflows/
│ ├── slack-linear-notion-loop.md # Cross-tool orchestration: Slack → Linear → Notion → AI
│ └── mermaid-diagrams.md # System flow visualizations
│
├── 04_people-metrics/
│ ├── metrics-dictionary.md # Definitions, sources, cadence, privacy tiers, Goodhart risks
│ └── dashboard-mock.md # Narrative-driven operational health dashboard concept
│
├── 05_tooling-and-access/
│ ├── tool-stack-map.md # Tool registry: ownership, lifecycle stages, evaluation criteria
│ └── joiner-mover-leaver.md # Provisioning and deprovisioning design with audit trail
│
├── 06_automation-prototypes/
│ ├── n8n-flows.md # Automation prototypes: triggers, approvals, failure modes
│ └── prompts-used.md # AI prompts used for reproducibility
│
├── 07_rollout-and-governance/
│ ├── 30-60-90-rollout.md # Three-phase rollout: pilot → scale → institutionalize
│ └── change-management.md # Adoption plan, training, feedback loops, and sunset criteria
│
└── assets/
└── demo-links.md # Canonical index of live demo and workspace links
Every meaningful decision is logged with context, rationale, owner, reversibility classification, and a scheduled review date. Decisions are classified as Strategic, Operational, or Tactical, with routing rules for each. The decision log is the foundational layer; every workflow, metric, and automation prototype links back to it.
A single-source-of-truth model assigns every domain exactly one canonical location. A content lifecycle (Draft → Active → Archived → Retired) prevents documentation debt by making freshness a structural property, not a cultural aspiration.
Three fully documented cross-tool workflows cover Slack → Linear → Notion → AI handoffs. Each workflow specifies its trigger, inputs, outputs, decision logging point, automation level, failure modes, and human override mechanism.
Metrics are defined with privacy classifications (Public, Internal, Restricted), Goodhart risk assessments, and narrative context requirements. The system measures what matters; decision velocity, strategic alignment, team sustainability - without enabling surveillance.
A tool registry tracks every tool's purpose, owner, lifecycle stage (Adopt → Maintain → Replace → Retire), and source-of-truth responsibility. Adoption and sunset criteria prevent tool sprawl.
Three automation prototypes are designed with a four-stage maturity model (Manual → Assisted → Semi-Automated → Automated). No prototype advances without a completed pilot, documented feedback, explicit approval, and updated failure modes. Every AI output requires human review before becoming a decision.
A three-phase, 60-day pilot plan with measurable success criteria, identified failure modes, and explicit sunset conditions. If the system does not prove its value, it gets retired - not defended.
This repository documents the architecture. The system itself runs as a live Notion workspace, and the decision capture pipeline has a full recorded walkthrough.
Watch the pipeline run end to end (4 min)
The video shows a Slack reaction becoming a structured Notion decision record with an audit trail in about four seconds, then a second decision logged live so you can watch the audit log grow.
| Layer | Implementation | Status |
|---|---|---|
| Full OS Architecture | Notion Workspace → | Complete and navigable |
| Decision Capture Pipeline | n8n: Slack ✅ → Notion Decision Log + Audit Log | Built and demonstrated (walkthrough) |
| Architecture Repository | This GitHub repo | Documenting |
A companion automation pipeline transforms ephemeral Slack signals into structured, auditable knowledge assets. When a team member reacts to a Slack message with a ✅ emoji, the pipeline:
- Captures the message content, author, channel, and thread context.
- Normalizes the data into a structured decision format.
- Deduplicates against existing entries to prevent redundant records.
- Persists the decision into the Notion Decision Log as a draft with full metadata.
- Logs the automation activity to a separate Audit Log for traceability.
The pipeline is designed with idempotent persistence - the same Slack message processed twice produces the same result, not a duplicate entry. It runs across five execution paths: success, duplicate prevention, validation failure, error recovery with a Slack notification, and idempotency confirmation. Every path writes an audit trail entry, so nothing fails silently.
Current stage. Stage 2 - Assisted, per the four-stage maturity model in 00_principles/governance-matrix.md. The pipeline was built and demonstrated on n8n Cloud; the recorded walkthrough above is the canonical record of it running.
The system is built on seven operating principles:
| Principle | What It Means |
|---|---|
| Async by default | Meetings are the exception, not the starting point |
| Decisions are artifacts | A decision does not exist until it is findable |
| Automate mechanics, protect judgment | Repeatable tasks get automated; nuanced calls stay human |
| Single source of truth | Every domain has exactly one canonical location |
| Documentation has a lifecycle | Content is created, maintained, and retired - never abandoned |
| Metrics guide, not punish | Measurement informs narrative; it does not replace it |
| Ship small, learn fast | Pilot before scaling; sunset what does not prove value |
- Decision Visibility: Decisions don't exist until they're easy to find later.
- Execution: Reduce friction without over-structuring.
- Automation with judgment: Automate repeatable mechanics; protect autonomy and nuance.
- Documentation: Knowledge stays fresh via lifecycle rules, not heroic effort.
- Metrics that guide (not punish): Privacy-aware, narrative-driven, resistant to Goodhart's Law.
This system is designed for operations leaders, chiefs of staff, and systems-minded builders at remote-first companies who want to:
- Make decisions visible and retrievable across timezones.
- Introduce automation without losing human judgment.
- Build an information architecture that scales without creating noise.
- Measure operational health without enabling surveillance.
Built by Angie.O - a technical operations specialist focused on information architecture, workflow automation, and building realistic systems for distributed teams.
This project is shared publicly for demonstration and portfolio purposes. You are welcome to reference the architecture for inspiration. Please credit the source if adapting the structure for your own organization.