PGC

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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

© 2026 Bhash Ganti Contact: bachipeachy@gmail.com ORCID Profile: https://orcid.org/0009-0007-3810-6520 Preface This paper describes an architecture for software execution within a fundamentally redesigned software architecture suited to an era in which AI and LLM-based coding assistants can automate software implementation at increasing scale. When implementation can be generated, modified, and regenerated automatically, conventional assumptions about where software behavior resides—and how that behavior remains governed—no longer suffice. This paper presents Protocol-Governed Computing (PGC), an architecture in which behavioral authority is moved out of implementation and into explicit, validated, executable protocols. It is the first of three companion papers: the second addresses governed transformation, and the third addresses realization of the architecture as a functioning normative platform. ...