Formal Classification

Architectural Pattern: Constrained Dataflow with Terminal Rendering Boundary

Herald is classified at the same level as MVC, CQRS, or Hexagonal Architecture. It defines how an entire system's components relate, what responsibilities they hold, and what boundaries they cannot cross.

×
Not an Algorithm
Algorithms are finite procedures that transform specific input to output (quicksort, Dijkstra's). Herald defines component relationships and boundaries, not a single computational procedure.
×
Not a Framework
Frameworks are reusable code skeletons other projects import (Django, React). Herald is a specific architectural approach, not a library you install.
×
Not a Paradigm
Paradigms are fundamental computation models (OOP, functional, reactive). Herald operates within existing paradigms -- it doesn't create a new way of "thinking about computation."
×
Not a Design Pattern
GoF patterns (Singleton, Observer, Strategy) are local, single-layer solutions. Herald spans the entire application architecture.

The Three Defining Constraints

01
Deterministic Decision Supremacy
All routing, tool selection, memory management, permission checks, and output coordination are performed by deterministic code across 171 modules. A 5-stage cascade routes to ten specialist model seats. The LLM participates in none of these decisions. Same input, same path, every time.
02
Immutable Fact Boundary
The interface between the deterministic pipeline and the LLM is a frozen data structure containing pre-assembled facts and explicit constraints. The LLM cannot request more facts, call tools, or modify the packet.
03
Static Call Graph Enforcement
The component interaction topology across 171 modules is declared as a frozen set of allowed edges. No component can call another unless that edge is explicitly permitted. Sequential relay enforces VRAM boundaries. Extensions cannot bypass ingress normalization or output coordination.

Comparison to Known Patterns

PatternWhere Herald OverlapsWhere Herald Diverges
Pipes-and-FiltersClosest structural match. Data flows linearly through a chain of transformers.P&F doesn't enforce a static call graph or a capability ceiling on the terminal stage. Herald adds both.
CQRSAll "command" work (tools, memory, routing) in the pipeline. LLM performs only the "query" of rendering facts.CQRS separates read/write models for storage. Herald applies the same split to intelligence itself.
Hexagonal ArchDeterministic pipeline is the domain core. LLM is an external rendering port that can be swapped or degraded.Hex arch doesn't constrain what adapters can do, just where they connect. Herald constrains capabilities.
MVCPipeline = Controller, Memory = Model, LLM = View.MVC allows bidirectional Controller-View interaction. Herald's ten model seats receive immutable packets with zero access back. Sequential relay adds a resource management dimension MVC doesn't address.

Architecture at a Glance

MVC
Controller
↙↘
Model
↔
View
Bidirectional. View updates Controller. LLM equivalent sits at the center.
Hexagonal
Adapter
Adapter
→
Domain Core
←
Adapter
Adapter
Ports surround the core symmetrically
Symmetric. Any adapter can do anything at its port. No capability ceiling.
CQRS
Command
→
Write Model
↕ Store
Query
→
Read Model
Split read/write models. Both sides are intelligent. Separation is about storage, not capability.
Herald · CLLM
Brain
→║→
LLM
Unidirectional · Immutable boundary · Terminal renderer
Linear. LLM at the edge, not the center. Cannot call back. Frozen data in, natural language out.
Herald / CLLM — Full Pipeline Architecture
Input
Ingress
→
5-Stage Cascade
171 modules
→
Fact Compiler
Frozen packet
Immutable
LLM Renderer
10 seats · seq relay
→
Output
Coordinated
◄ Deterministic Brain ►◄ Constrained Renderer ►
Constraint 01
Deterministic Decision Supremacy
Constraint 02
Immutable Fact Boundary
Constraint 03
Static Call Graph Enforcement

The question isn't whether this works.

See the 5-stage cascade in action.

How it works →Back to home