PGC on omnibachi

PGC #1 — Why Software Needs a New Execution Model

Sun, 23 Aug 2026 00:00:00 +0000

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

Thu, 27 Aug 2026 00:00:00 +0000

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?

Tue, 25 Aug 2026 00:00:00 +0000

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

Tue, 25 Aug 2026 00:00:00 +0000

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

Tue, 25 Aug 2026 00:00:00 +0000

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

Tue, 25 Aug 2026 00:00:00 +0000

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?

Tue, 25 Aug 2026 00:00:00 +0000

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?

Tue, 25 Aug 2026 00:00:00 +0000

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

Tue, 25 Aug 2026 00:00:00 +0000

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.

Protocol-Governed Computing: An Architecture for Deterministic Declarative Execution

Tue, 11 Aug 2026 00:00:00 +0000

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.

Protocol-Governed Systems: Architecture Inversion Concepts

Thu, 22 Jan 2026 00:00:00 +0000

Contact: mailto:bachipeachy@gmail.com

Preface

Protocol-Governed Systems: Closed-Loop Governed Evolution

Thu, 19 Feb 2026 00:00:00 +0000

Contact: mailto:bachipeachy@gmail.com

Preface

This paper is part of the PGS technical paper series. The paper Protocol-Governed Systems: Conceptual Model established the architectural foundations: constitutional governance, the four-layer stack, and the separation of governance from execution. The paper Protocol-Governed Systems: Compiler Conceptual Model described how the compiler converts protocol declarations into a governed execution boundary called the Protocol Snapshot. The paper Protocol-Governed Systems: Runtime Conceptual Model described how the runtime consumes that snapshot and executes workflow instances without any domain knowledge. The paper Protocol-Governed Systems: Architecture Inversion Concepts established why inverting the traditional relationship between specification and implementation is a structural requirement, not a design preference. Together, those four papers establish that behavior is fully determined before execution begins and that the protocol is the sole source of behavioral truth.

Protocol-Governed Computing: An Architecture for Closed-Loop Governed Transformation

Tue, 11 Aug 2026 00:00:00 +0000

Contact: bachipeachy@gmail.com ORCID Profile: https://orcid.org/0009-0007-3810-6520

Preface

Software changes continuously, yet software engineering has traditionally treated construction, execution, and evolution as largely separate concerns. This paper presents an architecture for software evolution—how running software changes over time while remaining governed, verifiable, and executable—in 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, the question of who governs the act of change becomes the architectural question. It is the second of three companion papers: the first addresses deterministic declarative execution [Ganti, 2026l], and the third addresses realization of the architecture as a functioning normative platform [Ganti, 2026m].

#22 — A Draft Open Standard for Protocol-Governed Computing

Sun, 23 Aug 2026 00:00:00 +0000

The first open draft of the Protocol-Governed Computing (PGC) Standard is now available for public scrutiny. It is an attempt to address a problem that becomes increasingly expensive as business software grows older: how to preserve the governing meaning of a system while allowing its implementation to change.

That picture is the whole idea in one frame. On the left, the governed meaning of a system: stable, explicit, written down. On the right, every language and runtime anyone might choose to realize it in. The protocol is the bridge, and it is deliberately narrow — it says what must be true, and says nothing about which road you take to make it true.

Protocol-Governed Computing: Realizing the Normative Platform and Its Governed Transformation

Tue, 11 Aug 2026 00:00:00 +0000

Bhash Ganti (aka Bachi)

Contact: bachipeachy@gmail.com

ORCID Profile: https://orcid.org/0009-0007-3810-6520

Companion papers

Part 1 — Protocol-Governed Computing: An Architecture for Deterministic Declarative Execution. https://doi.org/10.5281/zenodo.21879516

Part 2 — Protocol-Governed Computing: An Architecture for Closed-Loop Governed Transformation. https://doi.org/10.5281/zenodo.21879948

Abstract

Two companion papers establish the architecture of protocol-governed computing. One defines execution as declarative traversal of a compiled protocol; the other defines evolution as the governed transformation of one executable baseline into the next. Both state what must be true. Neither states what it takes to make it true, nor how one would know it had been achieved.

Protocol-Governed Computing: Field Manual

Sat, 22 Aug 2026 00:00:00 +0000

Author: Bhash Ganti (aka Bachi)

Audience: architects · compiler engineers · runtime engineers · governance engineers · AI coding agents under human supervision

What this manual is

A high-density restoration artifact. Its purpose is to rebuild the correct mental model of Protocol-Governed Computing in under thirty minutes — not to teach it, not to document code, not to walk a codebase.

Protocol-Governed Systems: Architecture Inversion Concepts

Tue, 11 Aug 2026 00:00:00 +0000

Contact: mailto:bachipeachy@gmail.com

ORCID Profile: https://orcid.org/0009-0007-3810-6520

Revision v1. Two changes, neither altering a claim of the paper. The preface was reframed so the paper reads as an entry point rather than as the fourth of a series, which is the role it now serves. A note on the change of name from Protocol-Governed Systems to Protocol-Governed Computing was added. The fifteen inversions and their development are unchanged from v0.

Protocol-Governed Systems: A Conceptual Model

Thu, 29 Jan 2026 00:00:00 +0000

Bhash Ganti Contact: bachipeachy@gmail.com

Purpose: Define the conceptual model for Protocol-Governed Systems, validated through the PGS reference implementation.

Audience: Protocol designers, compiler authors, runtime implementers, conformance engineers

Abstract

Protocol-Governed Systems (PGS) propose a computational architecture in which governance precedes execution. Instead of relying on runtime policies, conventions, or post-hoc validation, PGS defines admissible behavior through governed protocol artifacts that are compiled into deterministic execution structures before runtime begins.

Protocol-Governed Systems: A Constitutionally Constrained Architecture for Autonomous and AI-Generated Software

Thu, 15 Jan 2026 00:00:00 +0000

Bhash Ganti (aka Bachi)

Contact: bachipeachy@gmail.com

Abstract

The rapid acceleration of AI-assisted software generation exposes a fundamental limitation in conventional software architecture: behavior is implicitly defined by implementation, while governance operates reactively and at human speed. This mismatch creates a structural gap in which systems can exhibit unauthorized, non-deterministic, and unauditable behavior. Existing approaches — static analysis, runtime guardrails, policy engines — attempt to constrain behavior after code is produced, but cannot guarantee compliance when implementation evolves faster than governance capacity.

Protocol-Governed Systems: Compiler Conceptual Model

Tue, 11 Aug 2026 00:00:00 +0000

Contact: mailto:bachipeachy@gmail.com

ORCID Profile: https://orcid.org/0009-0007-3810-6520

Revision v1. Two changes, neither altering a claim of the paper. A forward reference to “Paper 6 in this series” was repointed: the authoring pipeline it promised is now developed in An Architecture for Closed-Loop Governed Transformation, which supersedes the earlier treatment of governed change. A note on the change of name from Protocol-Governed Systems to Protocol-Governed Computing was added. The compiler model itself is unchanged from v0.

Protocol-Governed Systems: Runtime Conceptual Model

Thu, 12 Feb 2026 00:00:00 +0000

Contact: mailto:bachipeachy@gmail.com

ORCID Profile: https://orcid.org/0009-0007-3810-6520