Context
Project context is a living thing, not a document. It includes what features shipped at what stage, the reasoning behind each decision, how each piece fits the whole system, alignment with founding vision, business and time impact — and all of it is in constant flux. The "why" behind decisions disappears into Slack threads, stale docs, and people's heads. When someone leaves, institutional memory walks out with them. When a new hire joins, they spend months reconstructing context that should already exist.
Problem
The deeper problem has two layers. The retirement problem — no system tracks the half-life of a decision; nothing flags when a piece of context is no longer load-bearing or when a design choice has been silently superseded. And the drift / query-failure problem — when a query about project state gives unsatisfying answers, it is usually one of three things: the node exists but is stale, the edge between two concepts was never captured, or the query is operating at the wrong scope. No existing system diagnoses which. Notion, Confluence, Linear, Coda all treat AI as a feature; none of them have a versioned decision graph.
Approach
ETHOS treats AI as the substrate. Every decision is an immutable event. The current state is derived by replaying the event log — versioning, RCA, time-travel, and undo/redo are structural properties of the store, not features bolted on later. Two products share the same internal model: a Core System for early-stage teams (cold-started by a founding conversation), and an Integration Layer that bootstraps a context graph from years of GitHub, ClickUp, and Slack history. The trust inversion: instead of "trust me and I will learn," ETHOS says "here is what I inferred from your own sources — is this right?"
System
/ the things actually shipped
- 01
Event-sourced decision graph in Postgres — every context update, direction change, and autonomous observation is an immutable, versioned event.
- 02
pgvector layer over the event log for semantic retrieval — "find decisions related to scaling" walks both structure and meaning.
- 03
A continuous background loop that samples recent events, checks alignment against root context, detects drift, and surfaces flags with a full traceback to the misaligned node.
- 04
Human-as-judge interface — every flagged drift becomes a verdict (confirmed, false positive, intentional pivot) that itself enters the graph as a new event.
- 05
LiteLLM abstraction routes routine extraction to cheap fast models and alignment / RCA to expensive ones. No hard dependency on any single provider.
- 06
Active context layer with decay rules — founding nodes evergreen, strategic decisions long half-life, implementation decisions shorter and explicitly pinnable.
- 07
Two entry points sharing one core: Core System (conversational, like Claude Code) for founders, Integration Layer (GitHub, ClickUp, Slack) for established companies bootstrapping from real history.
How the pieces fit.
Architecture
- Conversational CLI
- Decision-graph viewer
- Drift inbox
- Verdict surface
- LiteLLM router
- Alignment loop
- Drift detector
- RCA traversal
- Postgres event store
- pgvector semantic layer
- Derived graph view
- Active context with decay
- GitHub history bootstrap
- ClickUp planning bootstrap
- Slack decision bootstrap
- LLM-agnostic by contract
- Per-tenant isolation
- Auditable autonomous observations
Outcome
ETHOS is being built by dogfooding itself — the first project ETHOS manages is ETHOS. Every architecture decision, every change of direction, every autonomous observation lands in the graph and remains traversable. Founders stop being context custodians and become context validators. The vision-to-execution gap closes because the gap itself is now first-class data. The data flywheel — accumulated decision graphs as training data for better alignment models — is the second-order moat.
Learnings
/ what would be different next time
- /01
Cold start is the only problem worth solving first. Directed context — pointing the system at existing artifacts — kills the "trust me and I will learn" failure mode that every memory product dies on.
- /02
Event sourcing is not a database choice. It is the only architecture that makes versioning, RCA, time-travel, and undo/redo structural properties instead of features.
- /03
The system should be a first-class actor in its own graph. Autonomous observations are events; they are auditable, traversable, and themselves subject to drift detection.
- /04
LLM-agnostic is a product requirement, not a nice-to-have. The system's value cannot be held hostage to a single model's pricing or availability.