Historic working paper. An early, DOI-published draft preserved for historical reference. Its implementation terminology predates the current PGS compiler and runtime architecture and is superseded by the current Papers. Figures survive only in the canonical PDF below.

Download PDF (canonical, with figures)

Categories: Software Engineering (cs.SE), Programming Languages (cs.PL), Software Architecture

Keywords: software architecture, declarative systems, deterministic execution, protocol governance, AI-generated code, auditability, separation of concerns, constitutional primitives, architectural layers, behavioral concerns

Motivation: Why Protocol-Governed Architecture is Inevitable

The Imperative Architecture Paradox in the AI Era

The velocity of AI-assisted software development is accelerating beyond human capacity to audit, understand, or govern. Large language models now generate production-quality code at speeds that dwarf human output . Industry analysts project that AI-generated code will constitute the majority of production software within this decade .

This presents a paradox. AI excels at generating and refactoring implementation code—the mechanical translation of intent into executable instructions. Yet what AI cannot reliably preserve is system meaning: the business rules, constraints, invariants, and behavioral contracts that define what a system must do rather than how it does it.

In traditional imperative architectures, business logic is intertwined with execution mechanics. Business rules are scattered across conditional statements, embedded in service boundaries, and encoded implicitly in data flows. There exists no authoritative artifact that declares system behavior independently of implementation.

This coupling creates a fundamental problem: you cannot dispose of code without losing business logic.

Organizations have invested decades in systems whose business processes are encoded implicitly within millions of lines of imperative code . No one possesses authoritative documentation of what these systems actually do—the code is the specification. Redesigning from scratch is infeasible because the business knowledge exists only in working (if poorly understood) implementations.

The result is that AI-assisted development on legacy systems becomes, as practitioners observe, “putting lipstick on a pig.” AI can optimize, refactor, and extend code, but it cannot extract or preserve implicit business meaning. Each AI-generated change risks subtle semantic drift—altered validation rules, shifted edge-case handling, or reordered operations—that tests may not catch .

This requires a new paradigm.

Separating What Is Dispensable from What Must Endure

The core insight of protocol-governed architecture is that software is dispensable; business logic is not.

Implementation code—the Python, Java, Rust, or JavaScript that executes business rules—is a means to an end. It can be rewritten, optimized, migrated to new platforms, or regenerated by AI. What cannot be casually discarded is the authoritative specification of what the system must do: the business processes, compliance requirements, data contracts, and behavioral invariants that define organizational value.

Protocol-governed architecture enforces a strict separation:

• Protocol artifacts declare system behavior in explicit, declarative, version-controlled form. These are the authoritative source of truth—independent of any execution engine.

• Execution engines interpret protocol artifacts deterministically. They are interchangeable components that can be replaced, optimized, or AI-generated without altering system meaning.

This separation aligns naturally with AI-driven software development. AI can freely generate, optimize, and evolve execution engines provided they conform to protocol specifications. Behavioral equivalence is verified mechanically through trace-based conformance testing—not through human code review.

The result is reduced risk when switching implementations. Organizations can adopt new languages, platforms, or AI-generated code with confidence that behavioral contracts remain preserved. The protocol, not the code, defines what must endure.

Proven Patterns: This Is Not New to Technology

The separation of behavioral specification from execution mechanics is novel to mainstream software engineering, but it is a proven pattern in other technology domains. Two analogies illustrate the approach:

Industrial Control Systems and Programmable Logic Controllers

Industrial automation has operated under protocol-governed principles for over fifty years. Programmable Logic Controllers (PLCs) execute ladder logic—declarative specifications of industrial processes—without embedding process knowledge in the controller hardware .

When a manufacturing process changes, engineers modify the ladder logic program. They do not design a new PLC. The controller is a generic execution engine; the specification declares behavior.

This architecture achieves complete separation of concerns. Process engineers define what happens; control engineers ensure the execution platform performs reliably. Neither domain contaminates the other.

Why does software engineering not follow this pattern? Historically, the answer was expressive complexity—business software seemed too varied for declarative specification. Protocol-governed architecture demonstrates that this assumption is incorrect. With appropriate vocabulary design and compositional primitives, complex business behavior can be declared rather than coded.

Operating Systems and Applications

The relationship between operating systems and applications provides another familiar analogy. No one designs a new operating system for each application. Applications declare their requirements; the operating system provides execution services.

Unix, VMS, MVS, DOS, and their descendants established this pattern fifty years ago. Applications are portable across operating system implementations (within compatibility bounds). The operating system—the execution engine—can evolve, optimize, and be replaced without invalidating applications.

Yet mainstream software engineering rebuilds the “operating system” for every business domain. Each enterprise application contains custom runtime infrastructure: database access patterns, transaction management, error handling, observability—all implemented from scratch and intertwined with business logic.

Protocol-governed architecture applies the OS/application separation to business software. The execution engine provides generic interpretation services; protocol artifacts declare domain-specific behavior. Like applications on an OS, protocol artifacts are portable across conformant execution engines.

Architectural Foundations

The WHAT vs. HOW Separation

Software systems conflate two distinct concerns:

• WHAT: system behavior, rules, constraints, and state transitions

• HOW: execution strategy, performance optimization, language, and deployment

Protocol-governed architecture enforces strict separation. Behavior is expressed declaratively; execution engines interpret that behavior using any compliant strategy.

Auditing behavior therefore requires inspecting protocol artifacts—not execution code.

Protocol Artifacts as Constitutional Law

Protocol artifacts are not documentation; they are binding constraints. They declare:

• units of work with explicit inputs and outputs,

• allowed data flows,

• declared side effects,

• failure semantics and determinism requirements.

Execution engines have no discretion to reinterpret protocol meaning. Conformance is defined by observable equivalence, not implementation similarity.

Trace-Based Conformance Verification

Determinism is enforced through trace-based verification:

• Trace Schema defines observable execution events.

• Trace Capture records execution outcomes.

• Replay Verification ensures identical outcomes under replay.

• Conformance Testing validates behavioral equivalence across engines.

This enables verification of AI-generated or optimized implementations without code inspection.

Governance Precedence

Governance defines non-negotiable constraints:

• vocabulary and schema rules,

• structural correctness,

• determinism requirements.

Execution engines that violate governance are non-conformant regardless of performance.

Layers and Concerns: Constitutional Primitives

Protocol-governed systems are organized along two orthogonal axes. The first axis—layers—partitions the system as humans encounter it: as a design artifact to be authored, reviewed, governed, and evolved. The second axis—concerns—partitions the system as machines encounter it: as a set of behavioral primitives to be loaded, validated, executed, and traced. Confusing the two is a categorical error that undermines both design clarity and runtime governance.

Why Two Taxonomies, Not One

In conventional software engineering, the terms “layer” and “concern” are used interchangeably or defined in terms of each other . This conflation is tolerable in systems where human developers perform both design and execution reasoning simultaneously. It becomes intolerable in protocol-governed systems, where design authority (human) and execution enforcement (machine) are constitutionally separated.

A layer may contain artifacts belonging to multiple concerns. A concern may manifest across multiple layers. The relationship is not hierarchical but dimensional. Layers are the rows of the architectural matrix; concerns are the columns.

Conflating these axes produces two characteristic failure modes:

1. Layers treated as concerns: Developers assume that a module’s filesystem location (layer) determines its runtime behavior (concern). This assumption breaks when a single layer houses artifacts with different execution semantics—e.g., the Protocol layer contains both workflow specifications (WF_) and capability contracts (CC_), which carry entirely different execution obligations.

2. Concerns treated as layers: Developers assume that artifacts with the same behavioral prefix belong in the same filesystem location. This assumption breaks when a concern’s artifacts participate in different phases of the system lifecycle—e.g., a workflow (WF_) is authored in the Authoring layer, declared in the Protocol layer, validated in the Governance layer, and executed in the Execution layer.

Formal definitions prevent both failure modes by making the orthogonality explicit and constitutional.

Formal Definition: Layer

Layer (noun): A structurally bounded partition of a protocol-governed system that organizes design-time responsibilities from the human perspective. Each layer encapsulates a coherent set of activities, artifacts, and authorities that humans must reason about when designing, authoring, governing, or evolving the system.

Formally, a layer $L_i$ is a tuple $(N_i, R_i, A_i, \mathcal{A}_i)$ where:

• $N_i$ is the constitutional identifier of the layer.

• $R_i$ is the human-cognitive function the layer serves.

• $A_i$ specifies who (human roles, institutional processes) governs the layer’s content.

• $\mathcal{A}_i$ is the set of artifact types that may reside within the layer.

Layers satisfy the following invariants:

The Eight Canonical Layers

The protocol-governed architecture comprises exactly eight layers, ordered by their position in the design lifecycle—from legislative intent to structural invariant. Figure 1 illustrates the layer structure with velocity characteristics.

Layers 1–3 operate at human speed, requiring institutional deliberation. Layers 4–7 operate at machine speed, performing deterministic enforcement. Layer 8 operates at boot time, establishing structural invariants before protocol discovery. The authority gradient flows from maximal human authority at Layer 1 to fully encoded machine enforcement at Layer 7, with Layer 8 providing the axiomatic substrate.

Layer 1: Authoring

Responsibility: The human legislative process. Authoring is where human stakeholders—domain experts, product owners, architects—express behavioral intent in protocol-declarative form. Authoring produces the raw material of governance: intent declarations, workflow specifications, capability definitions, and actor registrations.

Authority: Domain stakeholders, product governance, architectural review.

Artifacts: Template instances, draft protocol artifacts, build registry entries, conformance test specifications.

Authoring is deliberately positioned as the first layer because all system behavior originates in human intent. No artifact exists in the system that was not authored by a human stakeholder. AI may assist in generating implementations, but the authoring of behavioral law is a human institutional act.

Layer 2: Governance

Responsibility: Law validation, constitutional enforcement, and compliance verification. Governance validates that authored artifacts conform to constitutional schemas, vocabulary constraints, and institutional policies. Governance does not create behavioral law; it validates that authored law is well-formed and admissible.

Authority: Constitution validators, schema enforcement engines, compliance officers.

Artifacts: Constitutional schemas, validation rules, conformance test frameworks, vocabulary registries.

Governance follows Authoring because authored artifacts must be validated before they become protocol law. The relationship is legislative: Authoring proposes; Governance ratifies.

Architectural property: Governance is evaluated at authoring time and load time, never at execution time. By the time execution begins, all artifacts are known-valid.

Layer 3: Protocol

Responsibility: The declaration of lawful behavior. The Protocol layer houses the ratified, version-controlled artifacts that constitute the system’s behavioral law. These artifacts specify—in declarative, machine-readable form—what the system is permitted to do, what actors may participate, what workflows are sanctioned, and what capabilities are available.

Authority: Version-controlled protocol repository, institutional change management.

Artifacts: Workflow specifications (WF_), intent declarations (IN_), capability contracts (CC_), runtime binding declarations (RB_), actor registrations (AC_), event definitions (EV_).

Protocol is the specification layer. It stands between governance (which validates) and execution (which enforces). Protocol artifacts are the constitutional law of the system; everything below this layer is enforcement mechanics.

Versioning: Each artifact carries an explicit version identifier. There is no “version 3.1.4” semantic drift—every artifact version is independently addressable and immutable. Behavioral change requires new versions, not in-place modification.

Layer 4: Execution

Responsibility: Deterministic enforcement of protocol-declared behavior. The Execution layer contains the runtime engine that compiles protocol artifacts into executable DAGs, routes execution through declared intents and capability contracts, and produces structural traces that prove compliance.

Authority: Execution engine implementation, DAG compiler, node router.

Artifacts: DAG construction logic, workflow executor, execution context, node router, trace sink.

Execution is the enforcement boundary. Above this layer, humans author and declare. Below this layer, the system interacts with the world. Execution ensures that world-interaction occurs only as protocol permits.

Key properties:

• Semantic blindness: The execution engine has no knowledge of business domain meaning. It interprets protocol structure, not business semantics.

• Determinism: Given identical artifacts and inputs, execution produces identical observable results.

• Replaceability: Multiple execution engines may exist. Conformance is verified through trace comparison.

Layer 5: Capability Transforms

Responsibility: Pure, deterministic computation. Capability transforms perform data transformations—hashing, formatting, validation, calculation—without producing side effects. They are the system’s pure functions: given the same inputs, they produce the same outputs, unconditionally.

Authority: Capability contract specifications, transform atom registry.

Artifacts: Transform executor, transform atoms (individual pure-computation implementations).

Purity guarantees:

• Identical inputs always produce identical outputs

• No side effects (memory, disk, network, time)

• No dependency on external state

• Deterministic execution

Compositional property: Pure transformations compose freely. Complex behaviors emerge from combining simple, testable primitives.

Separation rationale: Capability transforms are separated from capability side effects to enforce a constitutional distinction between computation (pure, replayable, safe) and mutation (world-affecting, governed, irreversible). This separation is not an organizational convenience; it is a governance invariant.

Layer 6: Capability Side Effects

Responsibility: Governed interaction with the external world. Capability side effects perform mutations—database writes, file operations, API calls, message publication—under the governance constraints declared in capability contracts. Every side effect is traced, bounded, and attributable.

Authority: Capability contract specifications, side effect governance declarations.

Artifacts: Persistent storage implementations (CS_MUTABLE_JSON_V0, CS_APPENDONLY_JSONL_V0, CS_REGISTRY_V0).

Side effect types:

• Mutable storage: JSON document updates, database writes

• Append-only storage: Immutable event logs, audit trails

• Registry operations: Actor registration, configuration updates

• External interactions: API calls, message publication

Ordering guarantees: Side effects execute in protocol-declared order. Non-determinism (e.g., network latency) is bounded and observable.

Auditability: All side effects are traced. The complete effect history is reconstructible from execution traces. A system’s risk profile is proportional to its side-effect surface, and that surface is constitutionally bounded by this layer’s contents.

Layer 7: Transport

Responsibility: Ingress and egress mechanics. The Transport layer manages how external actors and systems communicate with the protocol-governed system. It handles protocol translation (HTTP to internal representation), input validation at the system boundary, and output formatting. Transport is delivery, not behavior.

Authority: Interface specifications, API contract definitions.

Artifacts: CLI runner, HTTP/REST server, ingress handlers, egress formatters.

Transport is positioned as a late layer because it is mechanically necessary but behaviorally inert. Transport does not determine what the system does; it determines how external actors access what the system does. Behavioral authority resides in the Protocol layer, not in Transport.

Architectural constraint: Transport adapters contain no business logic. They perform only protocol invocation and response formatting.

Layer 8: Structure

Responsibility: Structural invariants required for protocol discovery, resolution, and deterministic execution, independent of domain or implementation. The Structure layer houses the system’s foundational infrastructure: canonical path resolution, environment invariants, and protocol loading mechanics. These are not business-specific artifacts; they are the axiomatic substrate upon which all other layers depend.

Authority: System architecture, constitutional path governance.

Artifacts: Path registry (canonical filesystem resolution), environment facts (invariant configuration), protocol loading (lawful protocol discovery and materialization).

Formal definition:

Structure contains the structural invariants required for protocol discovery, resolution, and deterministic execution, independent of domain or implementation. It is the axiomatic substrate of the system—loaded first, modified never at runtime, and required by all other layers.

The contents of this layer are:

• Declarative: They describe invariants, not behavior.

• Authority-bearing: Path registry is the single source of truth for all artifact resolution.

• Pre-protocol: They are loaded before any protocol artifact can be discovered.

• Domain-independent: They do not change with business domain or deployment context.

• Non-replaceable: Unlike implementations, structural invariants cannot be swapped per deployment.

Naming rationale. This layer was previously designated “Common”—a name that resists nothing. Any artifact can plausibly claim to be “common.” The name provides no exclusion criteria, no semantic boundary, and no governance leverage. Names in a constitutional architecture carry normative force: they signal what belongs and, equally important, what does not. “Structure” actively resists misuse: a utility function is not structural; a helper class is not structural; a shared type is not structural. The name itself enforces governance by making inappropriate additions semantically incoherent. Alternative names considered and rejected: common (implies grab bag), utils (trivializes authority), core (overloaded), foundation (vague), kernel (implies OS-level execution), constitution (would blur design vs. law), axioms (too abstract for engineering teams).

Separation guarantee: Structure tools are resolved at boot time. They are never modified during execution and carry no domain-specific semantics.

Layer Ordering and Lifecycle Position

The eight layers follow a deliberate ordering that mirrors the system lifecycle, as summarized in Table 1.

Layers 1–3 operate at human speed: they require institutional deliberation and human authority. Layers 4–7 operate at machine speed: they are deterministic, automated, and enforcement-driven. Layer 8 operates at boot-time: it is resolved once during system initialization and remains invariant throughout execution.

This ordering produces a natural authority gradient: human authority is maximal at Layer 1 (where intent originates) and decreases through the layers as behavioral law is progressively compiled into executable form. By the time execution reaches Layers 5–7, human authority has been fully encoded in protocol artifacts; no further human judgment is required.

Formal Definition: Concern

Concern (noun): A behaviorally typed category of protocol artifact that carries specific execution semantics within the runtime engine. Each concern defines a class of entities that the machine loads, validates, routes, executes, and traces according to concern-specific rules.

Formally, a concern $C_j$ is a tuple $(P_j, N_j, S_j, \Lambda_j)$ where:

• $P_j$ is the canonical two-letter prefix used in all artifact naming (e.g., WF_, CC_, EV_).

• $N_j$ is the human-readable concern name.

• $S_j$ specifies the execution behavior associated with artifacts of this concern.

• $\Lambda_j$ describes how the runtime engine discovers, loads, validates, and executes artifacts of this concern.

Concerns satisfy the following invariants:

The Ten Canonical Concerns

The protocol-governed architecture recognizes exactly ten concerns, grouped by their behavioral role in the execution lifecycle. The ordering reflects execution dependency—earlier concerns establish context that later concerns consume. Figure 2 illustrates the causal flow.

An Actor (AC_) initiates execution with an Intent (IN_), which is routed to a Workflow (WF_) that invokes Capability Contracts (CC_). Contracts resolve to implementations via Runtime Bindings (RB_), which execute as pure Transforms (CT_) or governed Side Effects (CS_). Execution produces Events (EV_) as trace evidence. External access enters via Transport Ingress (TI_) and exits via Transport Egress (TE_).

Concern Group I: Authority and Intent

These concerns establish who acts and what they intend.

Concern Group II: Orchestration and Binding

These concerns establish how intents are fulfilled and with what resources.

Concern Group III: Execution Mechanics

These concerns perform the work—computation and world interaction.

Concern Group IV: Observation and Delivery

These concerns handle evidence of execution and access to the system.

Concern Prefix as Vocabulary Control

The concern prefix system (AC_, WF_, IN_, etc.) serves as a vocabulary control mechanism. Every protocol artifact’s name begins with its concern prefix, making the artifact’s behavioral type lexically visible:

• WF_CREATE_WALLET_V0 — a workflow (orchestration)

• CC_HASH_SHA256_V0 — a capability contract (world-facing permission)

• CS_MUTABLE_JSON_V0 — a capability side effect (controlled mutation)

• AC_SYSTEM_ADMIN_V0 — an actor (authority-bearing principal)

This naming convention is constitutional. The prefix is a machine-parseable declaration of behavioral type that enables automated routing by the execution engine, concern-scoped governance validation, trace-level behavioral attribution, and vocabulary-bounded security (artifacts with unknown prefixes are rejected).

The Layer-Concern Orthogonality Matrix

Layers and concerns intersect but do not align. Table 2 illustrates which concerns manifest in which layers.

Key observations:

1. Governance spans all concerns. Governance validates every type of artifact regardless of concern—this is the constitutional function of the Governance layer applied uniformly.

2. Structure spans no concerns. Structure is pre-concern: it provides the invariants that make concern-based execution possible but does not itself participate in any concern’s execution semantics.

3. Most layers span multiple concerns. This confirms that layers and concerns are genuinely orthogonal; layers cannot be reduced to concerns or vice versa.

4. Capability Transforms and Capability Side Effects are concern-aligned. These two layers each house exactly one concern, reflecting the architectural decision to give world-interaction mechanics their own structural boundaries for governance purposes.

The matrix resolves a common architectural question: “Where does this artifact belong?” The answer requires two coordinates: layer (where in the design lifecycle does this artifact’s responsibility reside?) and concern (what behavioral type is this artifact?). A workflow specification (WF_) resides in the Authoring layer as a draft, in the Protocol layer as ratified law, in the Governance layer during validation, and in the Execution layer as a compiled DAG. Its concern does not change across layers; its layer changes as it moves through the lifecycle.

Extension Protocol

The sets of layers and concerns defined here are canonical but not eternal. Institutional evolution may require new layers or concerns. The extension protocol is:

Adding a layer: Requires constitutional amendment. The new layer must satisfy all four layer invariants (I-L1 through I-L4). The layer’s position in the lifecycle ordering must be justified. All existing governance rules must be reviewed for impact.

Adding a concern: Requires constitutional amendment and vocabulary extension. The new concern must be assigned a unique two-letter prefix. The concern must satisfy all four concern invariants (I-C1 through I-C4). The execution engine must be extended to handle the new concern’s lifecycle semantics.

Both extensions are deliberate, institutional acts—not implementation decisions. Layers and concerns are governance primitives, not engineering conveniences.

Architectural Properties

Complete Separation of Concerns

The orthogonal layer-concern model achieves complete separation. Each layer addresses exactly one design-time responsibility; each concern carries exactly one set of execution semantics. No layer bleeds into another, and each can be modified, replaced, or AI-generated independently.

The separation is enforced at two levels:

• Design-time (layers): Artifact placement is governed by layer invariants. A transport adapter cannot reside in the Protocol layer; a governance schema cannot reside in the Capability Transforms layer.

• Runtime (concerns): Artifact routing is governed by concern prefixes. The execution engine routes WF_ artifacts to the workflow executor, CT_ artifacts to the transform pipeline, and CS_ artifacts to the side-effect handler. Routing is determined by prefix, not by filesystem location.

Vocabulary-Bounded Attack Surface

Security emerges from architectural constraint rather than defensive programming. The protocol vocabulary defines the complete space of possible behaviors. Behaviors not expressible in the vocabulary cannot occur.

The concern prefix system reinforces this property: only artifacts with recognized prefixes (AC_, IN_, WF_, CC_, RB_, CT_, CS_, EV_, TI_, TE_) are admissible. Artifacts with unknown prefixes are rejected at load time. The behavioral space is bounded by the ten canonical concerns, and expansion of that space requires constitutional amendment.

Implications:

• No undeclared side effects

• No ambient authority

• No implicit control flow

• Attack surface remains bounded as system grows

Vocabulary expansion requires explicit governance approval, providing structural security review.

Granular Version Control

Traditional software versioning operates at coarse granularity: application version 3.1.4, library version 2.0.1. Semantic drift accumulates invisibly within version boundaries.

Protocol-governed systems version at artifact granularity:

• Each workflow has an independent version

• Each capability contract has an independent version

• Each intent definition has an independent version

Benefits:

• Behavioral change is always explicit

• Compatibility is mechanically verifiable

• Rollback operates at behavioral unit granularity

• No “what changed in this release?” ambiguity

Extreme Scalability Through Composition

Protocol-governed systems scale through composition rather than code duplication. Complex behaviors assemble from stable, tested primitives.

This compositional approach exhibits sub-linear complexity growth: new behaviors compose from existing vocabulary rather than introducing novel interactions.

Case Studies

Cryptographic Workflow System

A prototype system implements hierarchical cryptographic workflows entirely through protocol artifacts. The system manages cryptographic key derivation, wallet creation, and actor verification.

Validation: Identical protocol artifacts produce identical key derivations across execution engine variants. Behavioral equivalence is proven through trace comparison without cryptographic code inspection.

Immutable Append-Only System

An append-only ledger system demonstrates protocol-governed state evolution. The system maintains immutable event logs with cryptographic integrity verification.

Property demonstrated: State evolution is auditable through protocol artifact inspection. No implementation knowledge is required to verify ledger integrity.

Protocol Evolution Without Implementation Change

The prototype demonstrates behavioral evolution through protocol versioning. New workflow versions introduce modified business rules while execution engines remain unchanged.

Legacy and new protocol versions coexist. Clients migrate at their own pace.

Evaluation

Determinism Verification

Repeated executions with identical inputs produce equivalent traces across engine variants, validating deterministic guarantees.

Result: Complete trace equivalence across tested engine variants for workflows without declared non-determinism.

Auditability Assessment

Domain experts can determine system behavior by inspecting protocol artifacts alone, without code inspection.

Result: Experts correctly identified workflow behavior, decision points, and side effects from artifact inspection.

Implementation Replaceability

Execution strategies can change without behavioral re-certification, provided conformance verification succeeds.

Result: Execution engine replacement achieved with conformance verification only. No behavioral re-certification required.

Related Work

Workflow engines such as those based on Petri nets and BPMN govern orchestration and control flow but typically delegate semantic authority to the code invoked at each step. Protocol-governed systems extend governance to the behavioral semantics of each step, not merely their sequencing.

Low-code platforms abstract coding but embed logic in proprietary representations . Behavior remains implementation-coupled, hidden behind visual abstractions.

TLA+ , Alloy , and Z enable rigorous behavioral specification but traditionally separate specification from execution. Protocol-governed architecture requires that specifications are the execution authority.

Microservices distribute implicit behavior across independently evolving components . System behavior becomes emergent and non-local. Protocol-governed architecture maintains behavioral authority in explicit artifacts regardless of deployment topology.

The OMG’s Model-Driven Architecture separates platform-independent models from platform-specific implementations . However, MDA focuses on code generation—the generated code becomes authoritative. Protocol governance inverts this: the model remains authoritative throughout execution.

Programmable Logic Controllers demonstrate long-standing separation of behavioral specification from execution hardware . Protocol-governed architecture applies this proven industrial pattern to business software.

Separation of concerns in software architecture. Parnas established that modular decomposition should be based on design decisions likely to change. Our layer decomposition follows this principle: each layer encapsulates a coherent set of design decisions. Dijkstra introduced separation of concerns as a principle for managing intellectual complexity. Our concern taxonomy operationalizes this principle by assigning machine-enforceable prefixes to each concern, making separation not merely a design aspiration but a runtime invariant. Buschmann et al.  cataloged architectural patterns including layered architectures. Our layer model differs in a critical respect: conventional layered architectures define dependency relationships between layers; protocol-governed layers define lifecycle relationships—each layer represents a phase in the progression from human intent to machine execution, not a dependency in the call graph. Kiczales et al.  identified cross-cutting concerns as aspects that span multiple modules. In our framework, concerns are not cross-cutting—they are orthogonal to layers. The Governance layer validates all concerns, but this is the constitutional function of the layer applied uniformly, not aspect-oriented cross-cutting.

Discussion

Limitations

Governance overhead: Protocol authoring requires explicit behavioral specification, imposing upfront cost that may not be justified for exploratory or short-lived systems.

Expressiveness constraints: Vocabulary-bounded behavior may prevent expression of legitimately needed capabilities until governance approves vocabulary expansion. The governance process for vocabulary extension must be efficient without being permissive.

Tooling maturity: The ecosystem for protocol-governed development is nascent compared to imperative programming environments.

Concern taxonomy granularity: The ten-concern taxonomy may prove insufficient as the architecture encounters new domains. The extension protocol (Section 3) addresses this, but extending the concern set is constitutionally expensive by design.

Layer-concern matrix stability: The orthogonality matrix (Table 2) reflects the current reference implementation. As the architecture evolves, some cells may change. The matrix should be treated as a constitutional snapshot, not an eternal truth.

Appropriate Domains

The architecture is optimized for systems requiring long-term auditability and compliance, deterministic and reproducible behavior, multi-stakeholder governance, resistance to semantic drift under evolution, and AI-assisted development with behavioral guarantees.

Examples include financial systems, healthcare records, regulatory compliance systems, and critical infrastructure.

Names as Governance

The renaming of “Common” to “Structure” illustrates a broader principle: names in a constitutional architecture carry normative force. They signal what belongs and, equally important, what does not belong. “Common” is a name that resists nothing—any artifact can plausibly claim to be common. “Structure” actively resists misuse: a utility function is not structural; a helper class is not structural. Only artifacts that define the system’s invariant substrate qualify. The naming principle for constitutional architectures is that names should resist misuse by their semantics, not by their documentation.

Future Work

• Formal semantics enabling mechanical proof of behavioral properties

• Standardized conformance suites for engine certification

• Enhanced protocol authoring tooling

• Cross-organization governance for federated systems

• Systematic study of AI code generation under protocol constraint

• Formal proof that protocol-governed enforcement satisfies specific regulatory frameworks

• Empirical measurement of the governance deficit in AI-accelerated development environments

Conclusion

As AI accelerates code generation, implicit system behavior becomes untenable. Code evolves faster than humans can audit, while the business meaning embedded in that code drifts beyond reliable governance.

Protocol-governed architecture provides a path forward: systems whose behavior remains explicit, deterministic, and governable across implementation change. By separating what is dispensable (execution code) from what must endure (behavioral specification), organizations can embrace AI-driven development without sacrificing comprehension, auditability, or control.

The architecture is organized along two orthogonal constitutional primitives. Layers—Authoring, Governance, Protocol, Execution, Capability Transforms, Capability Side Effects, Transport, and Structure—partition the system as humans encounter it, following the lifecycle from legislative intent to structural invariant. Concerns—Actors, Intents, Workflows, Capability Contracts, Runtime Bindings, Capability Transforms, Capability Side Effects, Events, Transport Ingress, and Transport Egress—partition the system as machines encounter it, following the causal chain from actor initiation to evidence emission. Layers answer where a design responsibility resides; concerns answer what behavioral type an artifact carries. Conflating them produces systems that are neither clearly designed nor reliably governed. Formalizing them as independent primitives enables precise governance rules, unambiguous artifact placement, and machine-enforceable behavioral boundaries.

Each layer evolves independently; each concern carries deterministic execution semantics; neither contaminates the other. This achieves complete separation of concerns—not as a design aspiration but as a constitutional invariant enforced by the architecture itself.

This is not merely an architectural improvement—it is an architectural necessity for the AI era. When AI generates the majority of production code, the question “What does this system do?” cannot be answered by reading that code. It must be answered by consulting authoritative behavioral specifications that exist independently of any implementation.

Protocol-governed architecture provides those specifications—and the enforcement mechanisms to ensure they remain authoritative as implementations evolve.

License and Use

This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (CC BY-NC-ND 4.0).

You are free to share and redistribute this material in any medium or format, provided that: appropriate credit is given to the author, the material is not used for commercial purposes, and the material is not modified, transformed, or built upon.

The paper does not grant rights to implement patented methods, systems, or workflows that may be covered by pending or future patent claims.

For licensing inquiries or permissions beyond the scope of this license, contact the author.

Author Information

Bachi (aka Bhash Ganti)
Contact: bachipeachy@gmail.com

Conflict of Interest: The author is developing commercial implementations of the described architecture.