It starts with the customer
The best product decisions start with what customers actually said — the first signal to get buried. I built a working surface that keeps that evidence at the center of every decision and answers product questions in seconds, cited. What makes it durable is an AI-native operating system underneath — engineering in service of the customer.
A solo build, ~2 weeks · product strategy + the infrastructure underneath it
Structural counts are real. The PR figure reflects small, frequently-merged docs & infra changes in a solo repo — a working style, not 327 features. Outcome figures further down are labelled illustrative.
The shape of the story
This isn’t an engineering project with a customer bolted on — it’s the reverse. The system exists to keep the customer at the center; the engineering — an AI-native operating system where hooks observe, policies judge and skills execute — is simply what keeps that durable.
Read straight down, or jump to whatever you care about — the nav up top brings you back any time.
The problem
Customer evidence, design, code reality, strategy and analytics each live somewhere different — and drift apart the moment they’re written. Decision quality ends up depending on who’s in the room and what they remember.
“I think we decided that because of something a customer said” — but the quote, the trade-off and the reasoning are gone.
Every decision re-opens with someone spending half a day re-assembling context that already existed, somewhere.
Strategy changes; the roadmap, specs and briefs don’t. Nobody notices until they contradict each other in a review.
Who it’s for
A system like this earns its keep in a specific situation. Naming who it’s for — and who it isn’t, yet — kept it from sprawling into a tool that does everything and decides nothing.
Built around one real team’s way of deciding, then generalized to teams that share its shape — not every org or tool. That focus is the point.
The bet
A docs folder decays. A system maintains itself. The insight: if the context the team decides with is also structured for an AI agent to read, you can wrap it in light infrastructure that keeps it fresh, flags its own drift, and compounds with every use.
Where it fits
The obvious reaction to “treat knowledge as a system” is “we already have tools for that.” We do — and this doesn’t replace them. It fills the gap they leave: the connective tissue that keeps decisions grounded while everything else drifts.
Great at storing what someone wrote down. But a page is read once and rots — it can’t notice when it’s stale or pull fresh source itself. This maintains the knowledge instead of just holding it.
Excellent at their slice — feedback, or tickets. But each owns one stage, so the thread from evidence to shipped work breaks at the seams. This is the connective layer across them, not another silo.
Answers from whatever it’s pointed at — stale and contradictory included, with no sense of what should govern a decision. Here observe / judge / execute stay distinct, and answers are cited and governed.
The wedge in one line
It sits alongside the wiki, the tracker and the warehouse — reading from them, keeping them honest, and closing the loop from customer insight to execution that no single one owns.
The architecture · the centerpiece
The idea worth stealing: a clean separation between what observes, what judges, and what executes — plus a governance layer whose only job is to stop the system drifting from its own description.
Deterministic shell scripts the harness fires on session start / end / prompt. They pull fresh source, detect drift, and load memory. They notice and surface — they never decide.
Plain-language rules loaded only when their trigger fires. “When a PR touches strategy, walk these alignment signals.” Judgement encoded once, applied consistently.
Reusable multi-step procedures invoked on demand — turn an interview into a brief, critique a feature, audit strategy drift. Tools, not instructions.
Those three primitives sit inside a fuller stack — bookended by the anchors that frame every session and the memory and governance that make it compound and stay honest. The operating-system map lays out all six layers in one diagram.
The idea I’d put on a whiteboard in an interview
Every new primitive — hook, policy, skill, folder — must update every registry that names it, including the system’s own visual self-portrait. Skip a registration and the change fails its own audit: a drift check flags it at session start, a review gate blocks the merge. The map can’t quietly fall out of sync with the territory — the difference between a project that decays when its author leaves and one that explains itself to the next person.
How it works · three ways the team actually used it
The same system answers across the whole product lifecycle — understanding the user, understanding the build, driving the work. Three of the most common asks:
On example 03: the tracker integration is designed but not yet wired up — where the system was headed: closing the loop from insight to execution status. Examples 01 and 02 ran live.
What changed
What this is meant to show
Seeing a recurring people-problem (context loss) and solving it with durable infrastructure rather than another doc or meeting.
Designing the human↔AI division of labour deliberately — what the machine should observe, judge and execute — instead of bolting a chatbot onto a workflow.
Anti-drift discipline, ownership and a maintenance cadence — the unglamorous rigor that keeps a system honest over time.
Evidence → strategy → roadmap → execution, end to end — and the design sense to make the whole thing legible at a glance.
Honest trade-offs
23 policies is arguably over-governance for a project this young — a smaller team would start with five and let the rest earn their place. Some primitives were built ahead of need. The lesson isn’t “build all of this” — it’s “build the observe / judge / execute spine, then let the system tell you what it’s missing.”
You’ve got the whole picture. Three doors from here — the nav up top brings you back.