§ 3 — Architecture

Architectural views of the DOCBOT Framework.

The framework is documented through five complementary architectural views that together constitute a 4+1 style description tailored to research-grade intelligent document processing: (i) the orchestrator graph, which captures the unidirectional choreography of agents; (ii) the high-level pipeline, exposing the macroscopic dataflow between enterprise ingestion and decision-support emission; (iii) the component decomposition, projecting each agent onto its internal subsystems; (iv) the typed data-flow view, formalising the algebra of envelopes, records and verdicts that cross stage boundaries; and (v) the cross-source validation topology, where consistency analysis is treated as a first-class kernel rather than a post-hoc quality check. Each view is presented at the level of formal abstraction required for independent evaluation, ablation, and reproducible engineering.

Orchestrator graph

Figure A0 portrays the orchestrator graph adopted as the canonical reference topology for the framework. A single root agent (DOCBOT · ORCHESTRATOR) dispatches typed action tokens to five action branches — ingestion, document intelligence, cross-source validation, restriction analysis and emission — each of which is internally bifurcated into a wrapper rail (declarative adapters) and a python rail (numerical kernels). Cross-rail validation hops materialise the consistency checks described in §3.4; OK and FAIL terminals encode the typed result envelope, whose disjoint sum is consolidated at the END node. Animated cyan pulses depict the traversal of in-flight messages and are derived from a synthetic execution trace.

Fig. A0 — Orchestrator graph of the DOCBOT Framework. Root agent dispatches to five action branches; each branch decomposes into a wrapper rail and a python pipeline rail with cross-rail validation hops, terminated by OK/FAIL status nodes and consolidated at END.

High-Level Architecture

At the macroscopic scale the framework reduces to a five-stage unidirectional pipeline. Enterprise documents enter through a typed acquisition boundary and traverse three cooperating agents whose responsibilities are mutually disjoint by construction. The pipeline is intentionally acyclic: feedback is expressed through provenance annotation and reprocessing, never through back-edges, which preserves the algebraic properties required for compositional reasoning and replay-based audit.

Fig. A1 — High-level five-stage pipeline. Boxes denote pure typed transformations; arrows denote typed channels with explicit envelope schemas.

Component Decomposition

Each agent admits an internal decomposition into four canonical subsystems. The decomposition is intentionally symmetric across modules: an interface boundary (acquisition / adapters / catalogue), a computational kernel (extraction / consistency / symbolic evaluator), a provenance fabric (store / tracker / rationale builder) and an emission boundary (structured output / verdict / decision). Symmetry across modules enables reusing the same orchestration, observability and benchmarking infrastructure for all three agents and admits a single uniform ablation protocol.

Fig. A2 — Component decomposition. Each of the three research modules exposes a symmetric four-subsystem internal topology coordinated by a typed pipeline orchestrator.

Typed Data Flow

Information crossing stage boundaries is materialised as a small algebra of typed envelopes: Source bytes → Envelope[mime, provenance] → Record (schema-bound) → Verdict (agreement, confidence, evidence) → Decision (status, violations, rationale). Each transition is a total function over its declared input type; partial failure is encoded inside the envelope itself rather than expressed through exceptional control flow, eliminating an entire class of silent corruption observed in monolithic pipelines.

Fig. A3 — Typed data-flow view. Each arrow is annotated with the algebraic type that crosses the boundary; nodes are total functions over their declared input type.

Cross-Source Validation Topology

The validation kernel of SYSTEMBOT is parameterised by an agreement function a(R, E) over the extracted record R and an indexed family of independent evidence sources E = {S₁,…,Sₙ}. Sources are weighted by an empirically calibrated reliability prior, and the kernel returns both a scalar confidence and a provenance tree that records every contributing source, transformation, and arbitration. The topology is deliberately fan-in/fan-out: it admits redundant sources to attenuate the variance of any individual extractor and supports principled disagreement resolution under heterogeneous reliability profiles.

Fig. A4 — Validation topology. Sources S₁…Sₙ are projected onto the consistency kernel which emits a confidence-weighted verdict carrying full provenance.

Architectural invariants

Five invariants are preserved at every stage of the framework and constitute the contract under which formal reasoning, ablation studies and audit-grade traceability remain valid.

I₁ · Acyclicity

The runtime call-graph is a directed acyclic graph. Feedback is expressed through provenance and replay, never through back-edges, preserving the algebraic structure required for compositional reasoning.

I₂ · Type totality

Every stage is a total function over its declared input envelope; partial failure is represented inside the typed result rather than as exceptional control flow.

I₃ · Provenance closure

For every emitted decision δ there exists a closed provenance subgraph G(δ) admitting full causal replay against a stored evidence snapshot.

I₄ · Restriction monotonicity

The constraint satisfaction problem solved by RESTRICTIONBOT is monotone in the set of active restrictions; adding a constraint never converts a reject into an approve.

I₅ · Stage isolation

Transient failures are contained at stage granularity through bounded queues, time-outs and bulkheads, eliminating the global stall modes characteristic of monolithic pipelines.

I₆ · Observability completeness

Every typed envelope crossing a stage boundary is observable at a single instrumentation surface, enabling closed-loop SLO enforcement and post-hoc analysis without re-execution.