The Osis Protocol

A system for building products in the intelligence age

A new era of building software is here. From solo builders vibe coding in cafés to engineers at the most prestigious labs, millions of lines of code, never read by humans, ship into production daily. The engineering layer has been abstracted once again, just as assembly gave way to C++ and JavaScript. LLMs have abstracted execution into natural language. In this new era, the leverage of judgement compounds at a scale we are only beginning to understand.

Tools do not replace human judgement; they amplify it. The right architecture compounds more than the code that runs it. Knowing what to build compounds more than flawlessly shipping the wrong thing. Execution costs once obscured this. Now, as they approach zero, judgement becomes the bottleneck.

Software is code. Everything else is an abstraction. Product, design, and engineering are means to an end, and that end is written code. Engineering judgement determines how the code is written, design judgement how it is experienced, and product judgement how it delivers value. Docs, specs, Figma files, and Slack threads are abstractions of that code. The closer each form of judgement lives to the codebase, the faster and more coherently a product evolves.

Engineering judgement already lives in the codebase. GitHub gave it a versioned, collaborative home, and the industry restructured around it. Coding agents build on that foundation. Now design follows as frontier models translate taste directly into code, grounded in design systems.

Product judgement lives everywhere and nowhere. Decisions scatter across Slack, Notion, Jira, agent conversations, and people’s heads. Signal fragments further across interviews, analytics, feedback channels, and screenshots. Tools cover parts of the process, but decisions and execution remain disconnected. In that gap, products drift, contradict themselves, and decay.

What’s missing is a system for product judgement that lives in the codebase.

Osis places product context in the codebase so that humans and agents shape what gets built next from the same source of truth.

What follows are the principles behind Osis:

Part one: where osis lives

Unified. Next to the code. Legible to the agent.

01. Product context belongs in the codebase

The codebase is the only artifact that is always current. Product context that lives anywhere else, Notion, Slack, someone’s head, falls behind the moment code ships. Osis puts it next to the code. Same repo, same history, same review process. Nothing drifts.

your-repo/
  src/                              ← the code
  osis/                             ← product judgement, next to it
    osis.json
    manifesto.md
    brand.md
    design-system.md
    twin.md
    v1/
      thesis.md
      strategy.md
      changelog.md
      core/
        product.md
        iteration-1--activation/
          brief.md
          signals/
          core-ux.impl.md

02. Single source of truth

Engineers solved this decades ago. One source of truth, no parallel copies, no shadow decisions lost across tools. Conversations, research, and planning can happen anywhere, but the signal they produce lands in the repo, versioned and reviewed. Product context outside the repo decays by default. Inside, it’s alive. One place for the whole team and every agent to read from and write to.

03. Structured for agents, legible to humans

PRDs, tickets, and wikis were designed for human readers. Agents write most of the code now, and they need product context they can consume without disambiguation: deterministic file paths, typed documents with fixed semantics, the full product state loadable in a single pass.

Part two: how osis thinks

Product context in the codebase needs a shape agents can reason over.

04. The clarity funnel

Product thinking already moves from why → what → how. Nobody ships a belief, you refine it until it’s buildable, belief → spec → code. The clarity funnel formalizes that path.

Org         "We believe X about the world"         [philosophical]
  Product     "This problem matters"                [philosophical]
    Version     "Here's how we manifest it"         [strategic]
      System      "Here's a distinct surface"       [strategic/tactical]
        Iteration   "Here's the bet right now"      [tactical]
          Phase       "Here's how we build it"      [executable]
            → plan mode → code

Each layer constrains the one below. The structure is recursive, so it scales from one product to twenty.

05. Typed documents, not templates

A template tells you what to fill in. A type tells the agent what the document means, what it answers, and where it connects. Every osis document has a fixed purpose and predictable semantics. The agent never guesses what it’s looking at.

The agent’s output is a function of the context it reads. Shallow product thinking produces shallow code. Rigorous product thinking produces code that inherits that rigor.

06. Signal in, clarity out

Product clarity isn’t invented, it’s distilled. Customer interviews, analytics, support tickets, Slack threads, screenshots, 2am voice memos, and your own ideas. Signal enters the funnel and product clarity distills through the back and forth between the agent’s full context and your judgement.

Part three: why osis compounds

Every decision, signal, and session deepens what the product knows about itself.

07. Every decision has a trail

The thinking behind product decisions is usually invisible. Trapped in conversations that disappear and heads that move on. When you can’t see how you got here, you make the same mistakes twice. In osis, every spec traces to the signal that informed it. Every iteration carries the reasoning behind its bet. The product’s history becomes queryable.

08. The system maintains itself

Keeping product docs current is the first thing teams stop doing when they’re busy. Because every document is typed, the agent knows what it is, where it fits, and when it’s stale. A single change propagates across documents in one pass. The richer the context, the more accurately it propagates.

09. Nothing starts from zero

Every new signal arrives against the full record of prior decisions and rationale. Every new agent session loads product state already in place. Every teammate operates with accumulated context. Nothing has to be re-established between turns. That’s where product velocity comes from, not just faster execution, but never losing what you’ve already figured out.

The core protocol is available today as an open-source Claude Code skill.

Engineering is already in the repo, design is closing the gap, and product was the missing piece. Code once belonged to engineering alone; now the abstraction to natural language means every discipline can shape the product through the same system. Engineers still decide how it’s built, designers how it’s experienced, and PMs what’s worth building. Osis is the intent layer where they meet.

Osis creates a single home for product building across the entire product lifecycle. Codebase, signal, and product context converge. The agent operates on that unified context. One decision, authored once, shapes every artifact that follows and every line of code built against it. That is the leverage.

One day, building without osis feels like coding without version control. You could. But why would you?