§ 3 — Architecture

Architectural views of the CORTEX 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.

View 00

Orchestrator graph

Figure A0 portrays the orchestrator graph adopted as the canonical reference topology for the framework. A single root agent (CORTEX · 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.

CORTEX · ORCHESTRATORINGESTOPTICNEXUSAEGISEMITINGW_01INGW_02INGW_03INGW_04INGW_05INGP_01INGP_02INGP_03INGP_04INGP_05INGP_06ING_OKING_FAILDOCW_01DOCW_02DOCW_03DOCW_04DOCW_05DOCP_01DOCP_02DOCP_03DOCP_04DOCP_05DOCP_06DOC_OKDOC_FAILSYSW_01SYSW_02SYSW_03SYSW_04SYSW_05SYSP_01SYSP_02SYSP_03SYSP_04SYSP_05SYSP_06SYS_OKSYS_FAILRSTW_01RSTW_02RSTW_03RSTW_04RSTW_05RSTP_01RSTP_02RSTP_03RSTP_04RSTP_05RSTP_06RST_OKRST_FAILEMTW_01EMTW_02EMTW_03EMTW_04EMTW_05EMTP_01EMTP_02EMTP_03EMTP_04EMTP_05EMTP_06EMT_OKEMT_FAILCONSOLIDATE · END
Fig. A0 — Orchestrator graph of the CORTEX 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.
View 01

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.

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

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.

OPTICAcquisitionPDF ProcessingEntity ExtractionStructured OutputNEXUSSource AdaptersConsistency KernelProvenance StoreVerdict EmitterAEGISConstraint CatalogueSymbolic EvaluatorRationale BuilderDecision EmitterPipeline Orchestratortyped channels
Fig. A2 — Component decomposition. Each of the three research modules exposes a symmetric four-subsystem internal topology coordinated by a typed pipeline orchestrator.
View 03

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.

SourcebytesEnvelopetyped[mime,prov]Recordschema-boundVerdictagreement+scoreDecision
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.
View 04

Cross-Source Validation Topology

The validation kernel of NEXUS 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.

Consistency Kernelagreement(R,E)Source S1Source S2Source S3Source S4Verdictconfidence + provenance
Fig. A4 — Validation topology. Sources S₁…Sₙ are projected onto the consistency kernel which emits a confidence-weighted verdict carrying full provenance.
View 05

Architectural invariants

Six 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 AEGIS 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.

View 06

Process automation substrate

The perception–arbitration–restriction core does not operate on isolated documents but inside a documentary regularisation lifecycle: an asset-bound case that accumulates evidence, human interventions and administrative state transitions until a terminal status is reached. Figure A5 projects the framework onto that lifecycle. Typed acquisition adapters abstract over the channel through which each document class arrives — authenticated portal, structured export, machine-readable feed or scanned artefact — so no architectural claim depends on any particular provider. Work is executed in bounded lots with idempotent retry and per-lot quarantine; the workflow kernel advances the case only when AEGIS returns a non-blocking status; and every act, machine or human, is appended to a single immutable ledger that simultaneously serves audit, process mining and model training.

L₁ · ACQUISITION ADAPTERSRegistry recordofficial sourceTransfer evidencesigned artefactInspection reportscanned PDFComplementaryattachmentsLot schedulerbounded · idempotentOPTIC · NEXUS · AEGISagent coreWorkflow kernelphase machine ΦQuarantinetyped error ledgerOperator consolehuman authorisationEvent ledgerappend-only · hashedCopilotgroundedPredictive layerresidual cycle timeranked attention
Fig. A5 — Process automation substrate. Acquisition adapters feed the agent core; the workflow kernel materialises phase transitions; the operator console gates authorisation; the ledger closes the loop into observability, prediction and the analytical copilot.
L₁ · Acquisition adapters

One typed adapter per document class, each exposing fetch, normalise and evidence-hash operations. Channel heterogeneity — interactive portals, bulk exports, machine-readable feeds, scanned artefacts — is absorbed at this boundary and never leaks into the agent core.

L₂ · Lot scheduler

Work is partitioned into bounded lots with per-lot isolation, exponential-backoff retry, deterministic ordering under a fixed seed, and a quarantine sink. Failure of a lot cannot propagate into a global stall, which makes throughput measurable under partial failure.

L₃ · Workflow kernel

A declarative phase machine over the case alphabet Φ. Transitions are guarded by the AEGIS status; identity transitions (origin = destination) update evidence without advancing the case; every transition emits a signed event.

L₄ · Operator console

The authorisation surface. The human selects scope, reviews proposed transitions, and executes with live progress and pause / resume / finalise control. Decision remains human; only technical execution is delegated.

L₅ · Event ledger

Append-only, content-addressed store of every envelope, transition, annotation and decision. It is simultaneously the audit trail, the process-mining substrate and the training corpus of the predictive layer — one surface, three consumers.

L₆ · Analytical copilot

A retrieval-grounded conversational layer that answers managerial questions by composing typed queries over the ledger, returning the query and the aggregated row count alongside every assertion, and refusing to answer where no query supports the claim.

View 07

Observability and predictive feedback loop

Figure A6 renders the closed loop that converts operational execution into scientific measurement and back into operational guidance. Raw events are normalised into a canonical trace, deduplicated at visit granularity — a phase visited n times emits up to 3n event rows carrying the same residence duration, and naive summation inflates waiting time by that multiplicity — and projected into a directly-follows graph over the phase alphabet. From that graph the harness derives cycle time, residence time, rework ratio and queueing delay per phase; the same features drive an interpretable regressor that estimates residual cycle time for open cases. Predictions are not consumed autonomously: they are surfaced to the operator console as ranked attention, closing the loop without removing the human from the decision.

Signed eventse(case, phase, t)Canonical tracenormalisedVisit deduponce per visitDirectly-followsgraph over ΦFeature matrixper open caseEstimatorMAE · RMSE · R²feedback: ranked attention returned to the operator console
Fig. A6 — Observability and predictive feedback loop. Events → canonical trace → visit-level deduplication → directly-follows graph → feature matrix → residual cycle-time estimator → ranked operator attention.