Risk DimensionsPublic systems map · R8

Operating architecture / combined public view

What runs Risk Dimensions.

The hardware, tooling, data, jobs and products behind Risk Dimensions and Kestrel.

01

Hardware & access

Mark's desk, the primary runtime, Luke's support machine and the future observer.

Hardware names follow Mark's labels. Pink support relationships are Mark-described, not a fresh SSH access test. The dashed Dell lane is planned. On a small screen, swipe the map sideways.

Risk Dimensions hardware and private operating connections Macbook4 is Mark's operating desk. Spark is the primary runtime. M4c is Luke's support machine with Mark-described SSH connections into Spark and Macbook4. Dell is planned for independent telemetry, not an active runtime. Cloudflare is an off-machine service layer for published delivery. MARK'S DESKPRIMARY RUNTIMEOFF-MACHINE SERVICES operate SSH support SSH delivery future observation only MARK · OPERATORMacbook4Mark's MacBookDaily desk, browser and approvalsLocal interfaces and exportsHuman control stays here RISK DIMENSIONS · RUNTIMESparkDGX SparkAlfred / Hermes and local modelsPostgreSQL, n8n and workersAPIs, brokers and application data SHARED DELIVERY LAYERCloudflareNot another physical machinePages, Workers and DNSTunnel / access boundariesProduct publishing and edge logic LUKE · TECH SUPPORTM4cSSH support into Spark & Macbook4Support lane, not data authority PLANNED · TELEMETRYDellIndependent health observerNot the current production host
Operating relationshipMark-described support accessPlanned, not commissioned

The hardware labels are display names, not new DNS names. Support access is described at role level, not published as an access grant. It does not reopen the retired Dell production topology.

02

Next: the shared tooling

These are the rails that run and connect the system. Keep them separate from the products they support.

Open the operational tooling inventory → Search components, locations, owners, dependencies and evidence status.

Documented runtime

n8n & native scheduling

n8n schedules workflow calls. Native systemd services and timers also run jobs; scheduler ownership is specific to each job.

  • Workflow inventory is not a Python worker count.
  • A running scheduler is not proof of successful output.
Estate documented

Cloudflare

Pages publishes sites. Workers run edge/proxy and intake logic. DNS and Tunnel connect approved product surfaces to their backends.

  • Separate deployment, routing and access controls.
  • Do not count each route as a separate service.
Access roles mapped

Tailscale & SSH

Private machine-to-machine transport for operating and support. Mark retains administrative control; Luke's support lane is shown separately.

  • Network access is not database or credential access.
  • No key, policy or forwarding changes in this draft.
Working tooling

Jujutsu, GitHub & workspaces

Source history, isolated development, reviewed changes and release handoffs. A local build, a push and a production deployment are separate events.

  • Use an isolated workspace for a new build.
  • Keep installed bytes and source history distinguishable.
Protected access

Bitwarden & governed brokers

Workload credentials stay in the protected service lane. Provider-specific brokers expose bounded operations, not unrestricted account access.

  • Secret custody is distinct from permission to act.
  • No tokens, PINs or credentials are part of this map.
Documented runtime

Mark, Coach, Alfred & Hermes

Mark sets direction and retains final authority. Coach is his subject-matter expert and strategic thinking partner, helping test assumptions, interpret evidence and develop strategy. Alfred is the COO, coordinating and executing approved work. Hermes provides the shared framework for running and coordinating agentic work across these roles and specialist agents. The roles remain distinct from—and more enduring than—the harness, models and tools that implement them.

  • Agent tools and MCP connections are not the whole estate.
  • Research/scoring remains distinct from infrastructure operation.
03

Data, datasets and API boundaries

Storage, provider integrations and serving interfaces are distinct parts of the operating system.

Shared data plane

PostgreSQL and data families

Market history, securities reference, risk analytics, company financials, macro/fiscal history and research context support approved consumers.

Resource map

Data Resources catalogue

The retained inventory links feeds and datasets to their consumers. Protected aggregate Equity research includes the country-level Equity audit, without ticker or issuer disclosure.

Serving boundaries

Product data and dispatch APIs

Product interfaces serve approved data. Dispatch interfaces connect approved jobs to workers. These are different functions—not one undifferentiated API.

Bounded access

Business and browser assistance

Governed read and assistance boundaries separate permitted context retrieval from unrestricted account or administrative access.

Provider integrations

Market, macro and business sources

Documented integrations include financial-data vendors, official economic sources, business platforms and model adapters. A documented adapter is not a live-connection guarantee.

Retained context

Research memory and indexes

Canonical research, retained evidence and local working indexes complement relational data. Original-provider provenance and capture times remain important.

04

Jobs turn sources into usable outputs

Map the executable chain, not just the job title. Each job needs an owner, input, route/entry point, output, schedule and freshness check.

n8n workflow inventoryRetained snapshot · 24 October 2026, 07:05 ET · not live health
62total workflows
56non-archived
6archived
53active flags in snapshot
Source / scheduleProvider observation; n8n or native schedule.
DispatchWebhook route or approved direct entry point.
Python workerFetch, normalize, calculate or reconcile.
Tables / filesPersisted output, provenance and audit evidence.
Data APIRead contract, access scope and serving layer.
Product surfaceKestrel component or another approved consumer.

This is a reading order, not a claim that every job follows exactly one route. Some jobs use native timers; not every workflow maps one-to-one to a worker. The map does not certify individual job execution or current permissions.

05

Kestrel & its components

The product layer consumes the shared system. It should not be confused with the machinery that supplies it.

Shared fifth component

Intelligence Engine

The documented shared curation/scoring component behind the product suite—not necessarily a fifth standalone public application. It joins curated data, Security Master tags, Themes, Couplets and frameworks to the interpretation surfaces.

Pulse

Observation: what is happening.

Rationale

Interpretation: why it matters through the selected frameworks.

Coach

Dialogue: questions and answers grounded in the permitted data and framework context.

Kestrel is the umbrella, not a claim that every unified feature is finished. The five-component suite is documented; the current public Kestrel surface is recorded as a landing page with one-pagers. This is a component map, not certification that every unified feature is complete.

Shared components and the documented Kestrel UI plan

Practical dependency: curated provider data + table-backed analytics + Security Master / Themes / Couplets / framework canon → Intelligence Engine → Pulse / Rationale / Coach and product views.

The older UI specification names Brief, Sunday Read, Scorecard, Players and Analyzer, with RHYMES and The Trim as interpretation controls. Those interface plans are not the same list as the five product components above; their current implementation state is not asserted here.

Cloudflare delivery, API contracts, data lineage, scheduled jobs and model/scoring versions remain separately inspectable dependencies—not hidden inside a single “Kestrel” box.

06

Distribution and CUNY access

Research users consume approved data without gaining access to the underlying operating infrastructure.

CUNY / mentorship tooling — WIP Historical analyst-seat foundations do not certify a completed CUNY-specific rollout.

Curated API rail

Scoped REST access

Approved research applications consume curated, read-only endpoints. Cohort onboarding, scope and per-seat acceptance remain explicit work.

Analyst rail

Read-only data and private scratch

Approved analysts can work through an allowlisted data rail with their own analytical workspace. Shared contributions require separate approval.

Documented foundations

The analyst workbench

Orientation, Jupyter / Colab / Excel, starter notebooks and versioned calculations support research. Manager and cohort tooling are shown as WIP, not finished capabilities.

Explore the public catalogue → · Read the intelligence and memory architecture →

↳

Reading the combined map

Role descriptions, documented components, planned work and WIP are different kinds of evidence.

DocumentedRecorded operating or product design; not a blanket health certification.Role describedHuman-supplied machine or support role; not a published access grant.WIPNot yet a completed rollout.PlannedFuture work, not running capability.

The catalogue is a public-safe grouped view of the reviewed system. Full operational identifiers, service health, permissions, credentials and private records stay outside this public site. The workflow figures retain their source date and are not a live monitor.

Intelligence architecture · Compounding engine · Space between · Regime sentinel