Why I'm Publishing an Open Standard for AI Execution Plans
Google had Borg. Borg was their internal cluster management system — the thing that scheduled containers across their data centers before containers were a concept the rest of the world had a name for. Borg was powerful, tightly integrated into Google's infrastructure, and completely inaccessible to anyone outside Google.
Then Google published the Borg paper. A few engineers at Google read it, built an open-source version called Kubernetes, and donated it to the Cloud Native Computing Foundation. Kubernetes became the de facto standard for container orchestration. Every cloud provider supports it. Every tool integrates with it. Google Cloud runs it.
Borg is still better than Kubernetes in some ways. It is more tightly integrated, more mature, more optimized for Google's specific infrastructure. But Kubernetes won the ecosystem. And the ecosystem mattered more than any single feature.
I am telling this story because I am making the same bet with a much smaller scope.
The Problem
When an AI agent executes a task — writes code, refactors a module, deploys a service — it follows a plan. That plan is usually a prompt. A human writes a description of what they want, the LLM generates a response, and that response becomes the plan by default. It lives in a chat log. It is not versioned. It is not structured. It is not reusable.
This creates three problems.
Plans are not reviewable. A chat response is a stream of text. You cannot programmatically check whether it includes a risk assessment. You cannot validate that it has success criteria. You cannot diff it against a previous version to see what changed. The plan exists, but it has no shape.
Plans are not portable. A plan generated by one AI system is unreadable by another. An OpenAI agent's plan, an Anthropic agent's plan, and a local model's plan are all unstructured text. There is no common format. If you switch providers, your plan history is prose locked in someone's chat UI.
Plans are not durable. When the chat session ends, the plan is archived or lost. It cannot be referenced by future planning cycles. It cannot be audited months later to understand why a particular approach was chosen. The reasoning behind a shipped feature disappears.
An execution plan that lives in a chat log is not a plan. It is a conversation that happened to produce one.
The Schema
PlanSpec is a structured document format for execution plans. Version 1.2 is the version I have been using in Planclave — the planning engine that generates these plans — and it is the version I am preparing to publish as an open standard.
A PlanSpec document has these top-level sections:
- Identity — plan ID, session ID, revision number, parent revision, timestamps
- Intent — goal statement, motivation, success definition
- Scope — explicit in-scope and out-of-scope lists, assumptions, open questions
- Approach — ordered steps with dependencies, rationale, complexity estimates, delegation levels
- Constraints — technical, security, compliance, performance conditions that must hold
- Success criteria — testable conditions for plan completion
- Risks — identified risks with mitigation strategies
- Dependencies — external prerequisites
- Delegation — what is authorized for autonomous execution vs. human decision
- Revision history — what changed between versions and why
Every field has defined semantics. Not just "write something here" — the field has a behavioral meaning. success_criteria are conditions that get checked before a plan is marked complete. out_of_scope is a list that gets validated against when scope questions arise during execution. dependencies between steps form a DAG that determines execution order.
The key design choice: a PlanSpec is not a prompt. It is a contract. The difference is that a contract has structure, versioning, and enforceable terms. A prompt has none of those things.
Why Open Instead of Proprietary
Planclave generates PlanSpec documents. Planclave is good at it — it manages review cycles, produces structured plans, tracks revisions, and assesses readiness. It is the engine.
I could keep the format proprietary. Planclave generates plans, Planclave consumes plans, and nobody outside the system ever needs to know the internal format. This is the Borg approach. It works fine until you want an ecosystem.
The ecosystem argument is straightforward. If PlanSpec is open:
Other tools can consume it. A CI/CD system can read a PlanSpec and block deployment if success criteria are not verified. A project management tool can import PlanSpec steps as tracked items. A code review system can check that a pull request addresses the plan's stated scope. None of these integrations require Planclave. They require the format.
Other planners can produce it. A different planning system — a competitor, an open-source project, an internal tool at a different company — can generate PlanSpec documents. This means PlanSpec adoption is not coupled to Planclave adoption. The standard grows independently of the product.
Users are not locked in. A team that adopts PlanSpec-formatted plans can switch planning engines without losing their plan history. The plans are structured data, not proprietary blobs. This reduces the adoption barrier. People try things that do not require rip-and-replace.
The format matters more than the engine. Engines can be replaced. Formats become infrastructure. When the format is open, the ecosystem grows around it instead of around a single vendor.
The Strategy
The business model is simple and not original.
PlanSpec is the open standard. Published specification, reference implementations, no license fee. The goal is adoption. Every team that uses PlanSpec-formatted plans is a potential Planclave customer and a participant in the format's ecosystem.
Planclave is the proprietary engine. It is the best way to generate PlanSpec documents. Deep and thorough review, deterministic readiness assessment, revision tracking — the full planning pipeline. You can write a PlanSpec by hand or use a simpler tool, but Planclave produces better ones faster.
CodeSpec is the narrow wedge — a developer-facing tool that uses PlanSpec under the hood for specific coding workflows. It is the entry point for early revenue and feedback from teams who are not ready for a full planning engine but need structured execution plans for AI-driven development.
This is the Kubernetes play. Give away the format. Sell the best implementation. Let the ecosystem do your marketing.
What Happens Next
The PlanSpec schema document is at version 1.2 and has been stable for six weeks. It is currently a document on my hard drive. For it to function as an open standard, it needs to be out there — a public repository, a specification site, a reference implementation, and eventually a governance process.
The sequence is:
- Publish the schema. A public repo with the full specification, examples, and a validator. No ambiguity about what is and is not a valid PlanSpec.
- Reference implementation. A minimal Python library that parses, validates, and serializes PlanSpec documents. Enough for other tools to consume the format without reverse-engineering it.
- Eat your own dog food. Planclave already produces PlanSpec documents. CodeSpec already consumes them. The standard is proven by the fact that the reference implementation is not a toy.
- Invite contribution. The standard improves when other people use it and find gaps. A governance process — even a lightweight one — makes contribution possible without giving up control of the direction.
A standard on your hard drive is not a standard. It is a document that wants to be one. The gap between those two things is publication, and publication is the hardest step because it means committing to the format in public.
The Bet
The bet is that structured execution plans become a category. As AI agents take on more complex work — writing code, managing infrastructure, executing business processes — the plans they follow will need to be more than prompts in a chat log. Someone will define what a good plan looks like. It might as well be an open standard.
If PlanSpec becomes the format that people reach for when they need to structure an AI execution plan, Planclave becomes the obvious choice for generating those plans. If it does not, I have still published a clear specification that makes my own system better documented and more interoperable than it would be as a black box.
Either way, the standard is more valuable published than hidden. That is the lesson from Kubernetes. That is the bet.
