14 The Integrated Target Architecture

Author: Todd B. Adams Reinforces: Proposal §3 — High-Level Architecture · Reading order: chapter 06 of this part; follows systemic-risk & crowding groundwork, precedes the gap analysis & research roadmap.

What this chapter establishes. This is the vision-forward view: the integrated future state in which the proposal’s network engine runs inside the platform. Everything network-specific here is proposed — not yet built; it is the research programme’s forward agenda. What is deliberate is that each proposed component attaches to an existing, built platform seam rather than a green field, and follows a grammar the platform has used repeatedly.

14.1 The target architecture

flowchart LR
    subgraph L0["Built today"]
      A["Point-in-time<br/>analytical layer"] --> B["Factor layer<br/>stock ↔ factor edges"]
    end
    subgraph L1["Proposed research engine"]
      C["Supra-Adjacency<br/>Tensor Builder"] --> D["Spatial-temporal graph<br/>message passing"]
      D --> E["Spectral Analyser<br/>Supra-Laplacian eigenspectrum"]
      E --> F["Phase-transition<br/>early-warning signal"]
    end
    B --> C
    G["Supply-chain layer (L2)"] -.-> C
    H["13F ownership layer (L3)"] -.-> C
    F --> I["Report-only sidecar<br/>+ dashboard card"]

Solid = built and feeding the engine; dashed = proposed data layers (chapter 03); the entire research-engine block is proposed, not yet built.

14.2 Mapping the proposal’s subsystems onto platform seams

Proposal subsystem (§3)	Proposed home	Attaches to (built seam)	Build status
Data ingestion engine (L1/L2/L3)	Declarative datasets plus EDGAR and FINRA ingestion	the ingestion and analytical layers, and the existing EDGAR client	partially built (Layer 1 built)
Supra-adjacency tensor builder	A new leaf package reading the point-in-time analytical layer	the factor and end-of-day stores	proposed — not yet built
Geometric deep-learning framework	A new engine package on a graph-learning library	consumes the tensor; runs as a research-day producer	proposed — not yet built
Physics evaluation engine (Supra-Laplacian spectrum)	A spectral producer writing a research table and sidecar	the report-only crowding-producer pattern	proposed — not yet built

14.3 Why the mount points are credible

The platform has a repeated, deliberately boring grammar for adding an analytical producer, and the network engine would follow it exactly:

One statistical method per package. The overfitting, information-coefficient, permutation, and crowding producers each isolate a single method; a network or spectral leaf fits that precedent.
Report-then-enforce. New signals ship report-only first — computed, persisted, and surfaced, but gating nothing — behind a default-off switch. A Supra-Laplacian early-warning signal would start as pure observability and touch portfolio construction only once evidence earned it.
A research table, a per-run sidecar, and a dashboard card. Every producer writes an operational table, emits a structured per-run sidecar, and renders one dashboard view. The comomentum producer (chapter 05) is the literal template.
The compliant-by-construction boundary is respected. Portfolio construction and allocation are compliant by construction, not optimisers — a settled architectural stance recorded in the platform’s decision records. A network signal would enter as risk observability, not as an input to a covariance optimiser, keeping the research clear of that boundary (see the connectedness-spike findings).

14.4 The one genuinely new dependency

The engine introduces a graph-learning stack (a GPU-accelerated tensor library and its geometric extension, proposal §4) that the platform does not carry today. It would live only in the research-engine package, isolated from the nightly production path, and run on a research-day cadence rather than every night. That isolation is itself a design decision the roadmap (chapter 07) makes explicit.

Cross-links: proposal §3 · crowding groundwork · gap & roadmap · platform capability map