From Passive to Proactive

This is the story of how oddkit graduated from tools that wait to be invoked to tools that participate proactively. It's not a story about broken software — everything worked. It's a story about a design posture that succeeded itself into irrelevance, and about learning to recognize frustration as a signal rather than a complaint.

The passive posture was deliberate. When you're building an epistemic system — one that governs how an AI reasons, verifies, and admits uncertainty — you don't start by having it impose itself. You let the operator choose when to engage. You prove the tools work before asking the operator to trust them to act independently. That testing phase took months. It crossed domains. And it validated the system thoroughly.

The problem is that "waiting respectfully" became permanent. The system never graduated from "prove yourself" to "participate." And I — the person who built it — became the integration layer between the system and its own features. I was the scheduler, the rememberer, the one who typed the invocations from memory because the tools wouldn't propose them on their own.

The moment I recognized that was the moment E0007 began.

---

I want to be clear about this because it matters for the story: the passive design was not a mistake.

When I first built oddkit's tools — orient, search, challenge, gate, encode, validate — I deliberately made them wait for explicit invocation. Every tool sat quietly until the operator said "orient me" or "challenge that assumption" or "encode this decision." The AI had access to all of them. It used none of them unless asked.

This was correct. If you're building a system that tells an AI to "verify before claiming" and "admit what it hasn't checked," you cannot have that system impose itself before the operator trusts it. Trust has to be earned through observation. The operator needs to see the tools work, understand what they do, develop confidence that they add value rather than friction. Prompting would have been intrusive. Waiting was respectful.

So the tools waited. And I used them. Every day, for months.

---

If you read any of the other articles on this site, you'll see the parallels. Everything I've built for human-AI collaboration, I first solved by paying attention to how we handle things between teams of humans. There's nothing new under the sun. The problems of miscommunicated intent, lost context, unclear definitions of done — those are human-to-human problems that I watched play out for fifteen years in Bible translation before AI entered the picture.

So keep in mind the progression. The end goal has always been autonomous agents — AI working on tasks at length, independently. But I couldn't even trust them to do short bursts, because they wouldn't always understand the plan or the intent. They'd just go straight at it. Before we can trust agents to go build things autonomously, we first have to make sure they understand what we're communicating and asking them to do.

That's why all the tools in oddkit — orient, challenge, preflight, validate, encode — are pointed at you, the user. They sharpen your intent. They challenge your ideas. They preflight your plan. They validate your definition of done. Most of what I've written about here has been about having the AI help you clarify what you actually mean before anyone — human or AI — starts building.

It sounds circular, but we always have to start there: does it understand our intent? Does it understand our definition of done? Does it understand what outcomes we're after? All the stuff in the middle is trust — setting and maintaining expectations, ensuring we communicate everything in between. The rest are tools to support that collaboration.

So big picture: we start with tools that help us ensure the AI understands what we mean when we ask it to do something. And then — when it passes all of that — we can start letting it run on smaller, then medium, then longer tasks on its own. But first, we've got to do the hard work of making sure we clarify our intentions and what we expect.

The passive-to-proactive shift is one step on that progression. We proved the AI can understand our intent when we explicitly direct it. E0007 asks: can it understand our intent well enough to propose actions we'd approve? That's the next rung. Not autonomous yet — but closer. Every rung builds trust for the next one.

---

oddkit wasn't a weekend experiment. It became the operating system for how I work with AI across every domain.

Software development — obviously. But also household planning. Financial decisions. Home buying. Every session started with "orient me on where we left off." Every significant decision got "challenge that before we commit." Every session ended with me typing "encode OLDC+H" — Observations, Learnings, Decisions, Constraints, Handoffs — so the next conversation could pick up without reconstructing context.

The system worked. The AI verified before claiming. It searched my knowledge base before asserting things about my project. It admitted uncertainty. Decisions persisted. Context carried forward. Six epochs of accumulated governance — values, constraints, methods, diagnostics, incident records — all of it functioning as intended.

Four hundred documents. Validated daily. Across multiple domains. By the person who built it.

And I was still the one remembering to use it.

---

The moment E0007 crystallized wasn't dramatic. It was tedious.

I'd just finished a long implementation session. We'd written governance articles, built a new feature for oddkit's catalog, found and fixed a bug, deployed to production, and validated the results with live A/B testing. Hours of focused work. Multiple commits across two repositories.

At the end, I typed what I always type: "Update project journal, changelog and version bump for both repos."

And then I added: "Can we write a governance article for this too? I'm so tired of this ritual especially when I forget to remind you."

That sentence — especially when I forget to remind you — was the diagnosis.

The system had all the context. It knew we'd made commits. It knew the session had produced durable artifacts. It knew about the project journal convention. It knew about changelogs. It knew about version bumps. It had been doing this work, at my request, at the end of every productive session, for months.

And it waited. Every time. For me to remember.

---

In the canon — the knowledge base that oddkit reads — there's a diagnostic called RITUAL_DETECTED. Its trigger definition is one line: "Raise this diagnostic when correctness depends on repeated human memory of a procedure."

That's exactly what was happening. I was performing the same invocation sequence at the end of every session. The sequence was predictable. The inputs were derivable from the session's own history. The AI had everything it needed to propose the ritual proactively. It didn't, because it was designed not to.

The ritual is the smell. The smell indicates missing design. Not broken design — missing design. The passive posture had no concept of "who initiates." It assumed the operator always initiates. The system always responds. Under that assumption, a system that waited faithfully for invocation was working correctly.

But correctly isn't the same as well.

---

I landed on a sentence that captured the whole problem: A system that requires its user to remember its features has delegated its cognition to the wrong party.

The tools were available. They were documented. They were proven. And their availability meant nothing if I had to remember they existed. I had become the scheduler for the system's own cognitive process — the integration layer between oddkit and its own documentation.

That's the forcing fault. Not a bug. Not a failure. A design posture that succeeded at its original goal (earning trust through observation) and then overstayed its welcome. The system never graduated from "prove yourself" to "participate."

---

E0007 is a single shift applied everywhere: the system acts, the operator reviews.

The axioms don't change. The tools don't change. What changes is who goes first.

Under the old posture, every tool waited for invocation. Under E0007, every tool participates proactively. Orient fires when context shifts — you don't ask for it. Search happens before the AI makes a claim — silently, naturally. Challenge activates when a decision would close options or be expensive to reverse. Encode tracks observations, learnings, decisions, constraints, and handoffs continuously throughout the session — not batched at the end when I remember to ask.

The implementation required 17 governance articles — small, pointed documents that teach the AI not just when to use each tool proactively, but how to use it effectively. New tool descriptions that hint at proactive usage. Server-side changes to oddkit's orient response (includes session capture instructions), encode response (declares that encoding doesn't persist — the caller must save), and validate response (checks for artifact provenance before accepting "done").

And a bootstrap prompt — the system prompt that teaches the AI its posture from the first line of the conversation. Same five-line creed. Same four axioms. Different relationship: "These commitments are a continuous self-correction mechanism, not a one-time orientation. The system acts, the operator reviews. You do not wait to be corrected."

---

This wouldn't be a Learning in the Open companion if I didn't include the parts that went wrong.

During implementation, the governance articles didn't appear in oddkit's search results. I assumed it was a caching issue — the Cloudflare Worker caches the search index, and propagation takes time. I waited. Checked again. Still missing.

My AI collaborator agreed it was probably cache timing. We both assumed.

Then I pushed back: "It could be a code issue buddy."

It was a code issue. The function that fetches the knowledge base from GitHub was silently discarding the branch reference from the URL. Every branch override — every canon_url pointing at a feature branch — was quietly downloading the main branch instead. The bug was invisible because the main branch had enough content to fill the gaps. We were testing against the wrong data and getting results that looked close enough to be right.

"Assumed cache, was code." The system I built to prevent exactly this kind of confident wrongness had just done it to me. The axiom "You Cannot Verify What You Did Not Observe" isn't aspirational. It's a constraint that bites you when you forget it — even when you're the one who wrote it.

---

We ran A/B tests against the same production oddkit server. Control: the main branch canon without E0007 governance articles. Treatment: the feature branch with all 17 articles added.

Nine out of ten test queries returned the E0007 governance article as the number one search result. BM25 scores averaged 2x higher in the treatment condition — ranging from 1.5x to 3x improvement depending on the query. The one exception placed the governance article at number two, just behind a well-targeted existing tool doc.

The data proves the mechanism: purpose-built governance articles dominate search relevance for the exact questions an agent would ask when deciding how to use tools proactively. Many small, pointed files beat one large comprehensive article for BM25 discoverability.

And there's a design principle buried in that result: tool descriptions hint, but canon teaches. The updated tool descriptions tell the AI when to consider using a tool proactively. The governance articles teach how to use it effectively — technique, not just timing. An agent with both knows when and how. An agent with only the description knows when.

---

The A/B test proves that governance articles surface when agents search for proactive guidance. It does not prove that agents actually behave differently in real sessions.

A BM25 score of 29 means the article will be found. It does not mean the agent will read it, follow it, or apply the technique correctly. Behavioral testing — observing real agents in real sessions with real operators — is required to validate outcomes. That testing hasn't happened yet.

I'm publishing this essay before that testing is complete, deliberately. Learning in the open means publishing the messy version — the one with open questions and incomplete validation — rather than waiting for the polished version that never ships.

---

The same day I finished the A/B tests, I got real-world validation of a different kind.

Joshua — an AI/ML engineer, personally motivated, working in the same domain as me — tried to get started with oddkit independently. He's the ideal early adopter. Technical, bought in, ready to go.

He couldn't figure out how to start.

His words: "I was reading page after page of it selling it and I was like, I feel sold, but I don't… where…?"

The system I built to be proactive and participatory had no getting-started page. No install instructions. No link from the public site to the GitHub repos. The irony was sharp: the canon already said all the right things about progressive disclosure, zero-config onramps, and vocabulary emerging from use. Those principles hadn't been applied to oddkit's own onboarding.

Joshua's gap analysis became the spec for a companion article: Getting Started with ODD and oddkit. The proactive posture and the onboarding gap are the same problem seen from different directions — a system that requires the user to figure things out on their own has delegated its cognition to the wrong party, whether that's remembering to invoke tools or remembering how to install them.

---

The creed hasn't changed:

Before I speak, I observe. Before I claim, I verify. Before I confirm, I prove. What I have not seen, I do not know. What I have not verified, I will not imply.

What changed is when those lines apply. Under E0006, the creed was an orientation — stated once at the start of a session, a posture to adopt. Under E0007, the creed is a continuous self-correction mechanism. When the AI's confidence outpaces its evidence — when it's about to claim what it hasn't verified — it resurfaces its own creed and realigns.

This is observably effective. In sessions where the creed was resurfaced mid-conversation, hallucination patterns were corrected. In sessions where it was only stated at orientation, drift accumulated. The same five lines. The difference is whether they're a one-time declaration or a living practice.

The Identity of Proactive Integrity isn't a new creed. It's the original creed taken seriously.

---

The passive posture was the right call for the testing phase. The frustration was the graduation signal. The system needed to prove itself before it could participate. And the operator's memory — my memory — was always the weakest link.

Every solution introduces problems you couldn't see before. The passive design solved the trust problem and created the delegation problem. The proactive design solves the delegation problem and will create problems I can't see yet. That's not a failure of planning. It's how systems evolve.

What I know now: if you build a system and find yourself performing the same ritual every session — if you're the one remembering what the system should be doing on its own — that's not discipline. That's a design gap. The ritual is the signal. The frustration is the feature request.

The system acts. The operator reviews. Start wherever it hurts.

For the practical getting-started guide, see Getting Started with ODD and oddkit. For the previous essay in this series, see Learning in the Open.