Open Standards

The blog is where an idea gets introduced. This is where it gets argued.

Each article here takes one claim from the Protocol-Governed Computing Standard and pushes on it until it either holds or breaks. Where it broke, that is written down too — including the places where the standard turned out to be wrong and the implementation turned out to be right.

The draft standard is open and unfinished, which is the point. The strongest test of a specification is whether someone who did not build the reference implementation can implement it anyway.

PGC #1 — Why Software Needs a New Execution Model

We have never been better at building software. We have never been worse at saying what it is allowed to do. Languages, frameworks, cloud platforms, CI/CD, observability, and now AI assistants that write code faster than anyone can review it — and maintaining a large business system over decades remains extraordinarily difficult. The problem is not that we cannot write algorithms. The problem is everything surrounding the algorithms. Business software accumulates rules, policies, workflows, authorizations, constraints, interfaces, exceptions, regulatory requirements, and institutional knowledge — and over time, much of that meaning becomes embedded in implementation code. ...

PGC #2A — How PGC Makes Software Explainable

A trace can show that a branch ran. It cannot show that the branch was allowed to decide. That gap is why software can work for years and still get harder to explain. The PGC Standard sets out to close it. This is not a summary of the standard — it is a test of whether its central picture earns the confidence it invites. ...

PGC #2 — Software Works—So Why Can’t We Explain It?

There is a moment in every old software system when someone asks a reasonable question and the room goes quiet. Why was this request allowed? Which rule made that route available? What would happen if we replaced this service? Usually, the system is still running. The dashboards are green. Customers are being served. The question is not whether the software works. The question is whether anyone can explain what it is doing, in terms that do not depend on remembering a particular codebase. ...

PGC #3 — Build the System, Then Remove the Builder

Here is a severe test for a software standard: Take away the people who built the reference system. Take away its source code. Leave another team with the standard and ask them to build a conforming implementation. Could they do it? If not, the standard may be useful documentation, but it has not escaped the implementation that gave it birth. This is not an abstract concern. Every long-lived system eventually loses its original builders. People change jobs. Vendors disappear. Frameworks are retired. The organization still needs to know what the system means and how to replace the machinery without replacing that meaning. ...

PGC #4 — When Code Becomes the Constitution

Every organization has a moment when the written policy says one thing, the people say another, and the software quietly decides the matter. The software usually wins. Not because anyone voted for it, but because the code is what runs. A rule in a handbook can be outdated. A diagram can be aspirational. A review comment can disappear. The branch condition in production will still determine what happens at 2:00 a.m. ...

PGC #5 — The Rule That Was There but Did Nothing

Imagine opening a compliance report and seeing a rule listed as passed. Now imagine asking a simpler question: when did this rule ever stop anything? That question is uncomfortable because software has several ways to look governed without being governed. A policy can be written down. Code can exist that appears to implement it. A check can run on every build. Yet no violation may be capable of producing a refusal. ...

PGC #6 — What If Refusal Is Success?

We have trained ourselves to treat refusal as a software failure. The request was rejected. The build stopped. The transaction did not complete. The service returned an error. Someone opens an incident and asks how quickly the system can be made to continue. Sometimes that is exactly the right response. But sometimes the system has done its job. It understood the proposal, evaluated the applicable governance, found that the proposal could not proceed, and stopped without leaving a partial result. ...

PGC #7 — Can Software Prove What It Was Allowed to Do?

After an incident, the first question is usually, “What happened?” That is a useful question. It is not the only one. The harder question is, “What was the system allowed to do, and what establishes that answer?” A log can tell us that an account was upgraded. It may not tell us which governance applied, which rules were evaluated, whether the representation had been altered, or whether the upgrade happened without a determination at all. A record of behavior is not automatically evidence of permission. ...

PGC #8 — One Meaning, Many Implementations

Every long-lived software system eventually faces the same bargain. Keep the old machinery because nobody can prove what may change, or replace it and hope the new machinery means the same thing. That is a poor bargain. It confuses a system’s identity with the tools that first realized it. The central promise of Protocol-Governed Computing (PGC) is more ambitious: one semantic meaning, many implementations. The recipe is not the meal Imagine two kitchens preparing the same dish. One uses a gas range and cast iron. The other uses induction and stainless steel. Their tools, timing, and internal arrangement differ. What matters for the shared recipe is the resulting dish and the conditions that define it. ...