OmniBachi™ is the reference implementation of Protocol-Governed Systems (PGS) — software whose behavior is separated from its execution mechanics.
Where system intent becomes durable architecture — not technical debt.
What is OmniBachi?
Protocol-Governed Systems (PGS) is the architecture: a discipline for defining, validating, and executing application behavior through explicit capability declarations rather than imperative business logic. OmniBachi is the reference implementation that makes that architecture concrete.
Instead of embedding rules, flows, and policies in procedural code, OmniBachi treats them as structured protocol artifacts — validated before execution, observed during execution, and reasoned about after execution.
OmniBachi is not a framework, and not a workflow engine in the traditional sense. It is an execution model for building systems whose behavior can be inspected, constrained, and evolved without rewriting code.
The architectural shift
Traditional application development
Most modern applications express behavior through large bodies of imperative code. Even simple system intent — user onboarding, account lifecycle changes, eligibility checks — becomes scattered across services, conditionals, and glue logic.
As systems grow, behavior becomes implicit, correctness becomes probabilistic, and change becomes increasingly risky. The result is not just technical debt, but architectural opacity.
The PGS approach
PGS treats system behavior as declared intent, expressed through protocols that reference reusable capabilities. Rather than writing new logic for each scenario, systems compose existing capabilities under explicit constraints. Execution follows validated structure, not ad-hoc control flow.
This shifts complexity from code paths to protocol design — where it can be reviewed, versioned, tested, and reasoned about. The goal is not fewer steps. The goal is fewer unknowns.
What this enables
Structural scalability
Traditional systems scale by adding more code. PGS scales by reusing structure. As systems grow, capabilities remain stable, protocols grow declaratively, and execution behavior stays predictable — growth that is compositional, not combinatorial.
Determinism by construction
Determinism is an architectural property, not a runtime feature: inputs are explicit, side effects are declared, and execution paths are validated before runtime. If a protocol is valid, execution is reproducible. If execution deviates, it is observable.
Observability without instrumentation
Because behavior is declared structurally, observability does not depend on logging discipline. Execution produces structured traces, capability-level metrics, and explicit causal relationships. Visibility is a consequence of design, not an afterthought.
What OmniBachi is not
Not infrastructure automation
Tools like Terraform or Kubernetes define infrastructure state. OmniBachi defines application behavior that runs on infrastructure — adjacent but fundamentally different problems.
Not a traditional workflow engine
Many workflow platforms still require imperative code, embedded logic, or platform-specific execution models. OmniBachi does not optimize how workflows are written; it questions why behavior must be written as workflows at all. Protocols are not scripts — they are contracts for execution.
Core principles
- Explicit declaration — protocols describe what must occur, not how it is implemented. Implementation details remain interchangeable; intent does not.
- Deterministic execution — given the same inputs and protocol version, execution produces the same observable outcomes. This is a design constraint, not a runtime feature.
- Structural reuse — capabilities are designed once and reused everywhere. Behavior scales through composition, not duplication.
System properties
- Protocol-first validation — structural correctness, capability compatibility, and side-effect constraints are checked before execution. Invalid intent never reaches runtime.
- Domain neutrality — the execution engine contains no domain knowledge; all domain behavior lives in protocols and capabilities. The same engine supports application backends, operational processes, regulated workflows, and long-lived enterprise systems.
- Long-lived architecture — designed for systems measured in decades, not release cycles. Protocols evolve, capabilities stabilize, execution remains inspectable.
Current state
PGS has moved well beyond prototype. The reference implementation spans a multi-repo ecosystem with a working compiler (admissibility construction and conformance generation), a generic runtime execution engine, read-only protocol inspection tooling, and a governed change-management pipeline. Ongoing work focuses on protocol compilation and optimization, authoring and inspection tooling, and multi-environment execution discipline. Details evolve; architectural direction does not.
Why the name OmniBachi?
Omni — universal applicability. Bachi — protocol-driven structure. OmniBachi reflects a belief that systems should be governed by explicit structure, not implicit code paths — regardless of industry or domain.
Vision
Traditional software asks how to manage complexity. PGS asks why complexity is implicit in the first place. When intent is explicit, systems become understandable. When systems are understandable, they become durable.
OmniBachi is not an optimization of existing practices. It is a reframing of how application behavior is expressed, validated, and trusted.