Research ↔ production parity
The two arrows from feature-forge carry the same graph — one materialised, one streaming. The boundary is the only place training and serving can diverge, so it gets a schema hash check at every emit.
The components written up under Projects aren't isolated tools. They're one platform, split along the seams a research engineer cares about: where data crosses into research, where research crosses into production, and where production crosses into observability. This hub holds the seams themselves — the contract at each one, and the pages that read its live state.
The platform underneath — every seam has a contract.
The platform components, written up one build at a time.
Every alphakernel HTTP endpoint the site consumes, live ones and sketched ones.
Per-event freshness over the parquet store — shards, dates, lag from now.
Registered symbol sets, static and bitemporal, with today's member counts.
Recent discovery runs and the objective each one was chasing.
The operator workflow — morning standup to weekly review, anchored to pages.
Quick-jump substring search across strategies, features, notes, and runs.
The two arrows from feature-forge carry the same graph — one materialised, one streaming. The boundary is the only place training and serving can diverge, so it gets a schema hash check at every emit.
The registry → signal-stream arrow only fires for an artifact with a signed evaluation report and an explicit human approver. The API enforces both; neither can be argued past at deploy time.
The observability box has two inbound edges (lineage from the registry, metrics from signal-stream) and emits to two owners: freshness pages on call, alpha decay surfaces to research. More on that here.
The same gates that admit a human operator admit an AI research agent: typed identity, citation refusal at the data boundary, named-human promotion gate, and typed refusal slugs so the planner branches on a published vocabulary instead of parsing prose. The platform's safety stack is the agent's safety stack.
The diagram exists because the question "what does the platform do?" has many wrong shapes and one right one. When a teammate or stakeholder asks, this is the shape — not the codebase tour, not the org chart, not the per-project README. A research engineer's job is to keep that shape coherent as the codebase grows and as the people on it rotate.
Drive the platform from the site: /desk is the morning briefing, /strategies is the catalog, /features is the leaderboard (ADR-0059 operator-workspace pattern).