PGS

Separating What Is Dispensable from What Must Endure Software is changing faster than we can understand it. AI can now generate production-quality code at speeds that dwarf human output. Entire features can be scaffolded in minutes. Refactors that once took weeks are completed in seconds. But there is a growing problem hiding beneath that productivity surge: We no longer know, with confidence, what our systems actually do. When someone asks, “What does this system do?” the answer usually requires reading thousands of lines of code. Business rules, constraints, edge cases, compliance logic — all of it is embedded inside implementation details. ...

Why PGS Exists Traditional systems: embed behavior in code are difficult to audit and reproduce require changes across multiple layers PGS: declares behavior in protocol artifacts compiles it into an execution graph executes deterministically with a full trace This onboarding shows how to work within that model. 1. What You Already Did If you followed the pgs_workspace README, you ran this: ./scripts/bootstrap_pgs.sh source .venv/bin/activate ./scripts/demo_sample_workflow.sh You saw a workflow execute twice. The first run registered an actor. The second run produced ALREADY_EXISTS on one node — and still wrote to the event stream. You examined a trace. ...

© 2026 Bhash Ganti. All rights reserved. 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. ...

In the previous post, I introduced the idea of Protocol-Governed Systems (PGS) — a class of software architecture where behavior is separated from implementation and governance becomes the primary system driver. The response told me something: the concept resonated, but the vocabulary needs grounding. Today, before we move into the mechanics of Paper #2, I want to establish two precise definitions: What exactly is a Protocol-Governed System? What role does OmniBachi play in that landscape? ...

Author: Bhash Ganti (Bachi) Goal: Teach PGS by building something real, not by describing an abstraction. Before You Start This document assumes you have run the bootstrap and seen at least one workflow execute. You do not need to understand everything yet — that is the point of an example. We will build a complete domain from scratch, following the same steps used to build the actual collatz_conjecture domain in pgs_ai_governance. By the end, you will understand how a real spec becomes a running, traceable, transport-accessible PGS domain. ...

Contact: mailto:bachipeachy@gmail.com ORCID Profile: https://orcid.org/0009-0007-3810-6520 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 boundary and executes governed behavior without containing any domain knowledge. ...

In Part 2, we defined what a Protocol-Governed System is and where OmniBachi fits as its reference implementation. We established three architectural commitments: semantic-agnostic execution, linear scalability, and inverted security. Today, we apply those commitments to the most consequential architectural shift in enterprise software: agentic AI. Because the models are no longer just answering questions. They are acting. And acting without structural authority is how systems fail. AI grips power and chaos unfolds ...

(c) 2026 Bhash Ganti 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. ...

In Part 3, we argued that agentic AI needs a constitution, not just guardrails. The core insight: the real enterprise risk is not hallucination — it is ambient authority, the implicit power agent frameworks grant to models without structural boundaries. That post was about why. This one is about how. And we have a concrete protagonist: OpenClaw. OpenClaw: The Agent Enterprises Want OpenClaw is an open-source autonomous AI assistant that is catching fire in the developer community. It runs locally, uses Claude as its reasoning engine, and has capabilities that would have seemed science fiction two years ago: ...

Contact: mailto:bachipeachy@gmail.com ORCID Profile: https://orcid.org/0009-0007-3810-6520 Preface This paper is part of PGS technical paper series. The paper, Protocol-Governed Systems: Conceptual Model, established the architectural foundations: constitutional governance, the separation of governance from execution, and the four-layer stack that makes governed execution possible. This paper focuses on one component of that stack: the PGS compiler. The compiler is the mechanism that converts governance declarations into a structure that execution can consume. Understanding what the compiler does, what it produces, and what it guarantees is essential to understanding how PGS works. No prior knowledge of compilers is assumed. The paper is written for readers who understand the PGS conceptual model and want to understand how its central promise — governance before execution — is actually delivered. ...