13 The Integrated Target Architecture

Author: Todd B. Adams Reinforces: Proposal §3 — High-Level Architecture · Reading order: doc 06 of the research-platform package

The claim of this doc. This is the vision-forward view: the fully integrated future state in which the proposal’s network engine runs inside SBFoundation. Everything network-specific here is PROPOSED — it is the PhD. 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 a dozen times.

13.1 The target architecture

flowchart LR
    subgraph BUILT["Built today"]
      A["Gold<br/>point-in-time"] --> B["Factor layer<br/>fact_factor_value"]
    end
    subgraph PROPOSED["Proposed research engine"]
      C["Supra-Adjacency<br/>Tensor Builder"] --> D["ST-GNN / HGT<br/>message passing"]
      D --> E["Spectral Analyzer<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 (doc 03); the whole PROPOSED block is the research.

13.2 Mapping the proposal’s subsystems onto platform seams

Proposal subsystem (§3)	Proposed home	Attaches to (built seam)	Status
Data Ingestion Engine (L1/L2/L3)	Keymap datasets + EDGAR/FINRA ingestion	`sbbronze`/`sbsilver`/`sbgold`, EDGAR client (F-319)	`PARTIAL` (L1 built)
Supra-Adjacency Tensor Builder	New leaf pkg (e.g. `sbnetwork`) reading Gold	`gold.fact_factor_value`, `gold.fact_eod`	`PROPOSED`
Geometric Deep-Learning Framework (ST-GNN / HGT)	New engine pkg on PyTorch Geometric	consumes the tensor; runs as a research-day producer	`PROPOSED`
Physics Evaluation Engine (Supra-Laplacian spectrum)	Spectral producer → `ops.research_*` + sidecar	the `sbcrowding` report-only producer pattern	`PROPOSED`

13.3 Why the mount points are credible

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

One method per package. sbpbo, sbic, sbpermtest, sbcrowding each isolate a single statistical method. A sbnetwork / sbspectral leaf fits this precedent.
Report-then-enforce. New signals ship report-only first — computed, persisted, surfaced, but gating nothing — behind a default-OFF switch. The Supra-Laplacian early-warning signal would start as pure observability, never touching portfolio construction until evidence earns it.
ops.research_* → sidecar → dashboard card. Every producer writes an ops table, emits a per-run JSON sidecar, and renders one dashboard view. sbcrowding (doc 05) is the literal template.
The X7 boundary is respected. Portfolio and allocation are compliant-by-construction, not optimizers (the universe-and-allowlist decision-record family). A network signal enters as risk observability, not as a covariance-optimizer input — keeping the research clear of a settled architectural stance (see the DY-connectedness findings §2.2).

13.4 The one genuinely new dependency

The engine introduces torch / torch-geometric (proposal §4) — a real, GPU-accelerated dependency the platform does not carry today. It would live only in the research engine package, isolated from the nightly production path, and run on research-day cadence rather than every night. That isolation is itself a design decision the roadmap (doc 07) makes explicit.

Cross-links: proposal §3 · crowding groundwork · gap & roadmap · architecture packages