The sprints

The work, in arcs.

Ten build arcs — the sprints behind the system, grouped into four themes. Each theme opens with the foundation it rests on, then the arcs built on top. Each arc is a thesis, not just a feature: the what, the why, what V1 deliberately doesn't do yet, and how it maps to the data, eval, and governance stack that enterprises spend millions standing up.

as of 2026-09-18 · Written before the 2026-09-28 complexity reset. The reset retired the Rigor & Measurement theme outright — the definition-of-done gate, the judge's seats and quorum (it is now one on-demand Sonnet reviewer), build-session telemetry and the weekly rigor review — so those arcs are gone from this page and branch-first change now sits under Distribution. It also retired the trend and voice scanners (role-radar remains), /morning-refresh, and the /ops rigor and market-intel dashboards. The System page shows what is live today.

Intelligence

Sensing the field and turning it into a queryable, evolving viewpoint.

◆ Foundation · The intelligence substrate.

The Market-Intelligence Engine

A signal is an event row with a kind, a cited source, and a confidence. One event links any number of companies, people, and topics through a single join table, so the whole graph is four objects and one hyperedge.

What it is: A Postgres graph where companies, people, topics, and events are first-class objects, and a signal is literally an event with a kind, a cited source, and a confidence. Producers write signals in; the dashboard and a relevance recompute read them out.
Why it exists: New York's AI scene throws off more signal in a week than one person can hold, and it's ephemeral. A queryable substrate turns fleeting encounters into a durable, cross-referenceable memory — lens-agnostic, so the same graph serves content and the job search.
The value: “What's rising × relevant × uncovered” becomes computable, not vibes. Every signal carries provenance, so nothing is unsourced — and the graph tells a one-day spike apart from a sustained trend.
Best practices it draws on: Event-sourcing / activity-stream modeling (event-as-hyperedge). Meadows' stock-and-flow: the signal stock accumulates; the viewpoint is a derived flow, decay-weighted, never wiped. Recency-decay + cross-source corroboration from information retrieval.
What V1 doesn't do yet: Single primary producer; relevance is recency × engagement × confidence with hand-set weights, no learned model; the event-proximity boost stays dormant until attended events populate; manual trigger only.
Where it goes: Next: YED-160 post-event producer · YED-169/170 substrate + retrieval · YED-179 (Q1 2027 slate: unattended scheduling, learned weights, embedding dedup).
Enterprise tie-in: A system-of-record plus lightweight feature-store pattern — the exact shape enterprises build for “signals → decisions,” scoped to one operator. The veracity layer (provenance, honest confidence, pipeline health) mirrors how production ML earns trust.

Built on it

Arc 01 · Clean, connected data at scale.

Knowledge-Graph Data Foundation & Hygiene

Every record is matched before it's created. Confident matches merge and carry their signals with them; uncertain ones are flagged for a human decision instead of being guessed at.

What it is: Backfilling the graph from Notion (172 companies, 153 topics, 240 people → 232 persons), a reusable dedup / normalization toolkit (fuzzy-match, safe-merge, flag-and-import backfill), and a full Notion ↔ graph reconciliation.
Why it exists: A graph is only as useful as it is clean. A single scan fragmented it into near-duplicate topics; the people import carried duplicate pages and unresolved names. Left alone, that noise poisons every downstream ranking — the same failure that kills real production graphs.
The value: One node per real entity; provenance preserved on merge (signals move, they're never lost); human-in-the-loop for the judgment calls — the operator sets the taxonomy, the tooling executes it safely.
Best practices it draws on: Entity resolution / master-data-management (match-before-create, survivorship rules). Idempotent backfills (search-before-insert, safe re-runs). Dry-run-before-write on every destructive op.
What V1 doesn't do yet: Dedup is string-similarity + human-in-the-loop, not embeddings; name-only person dedup can theoretically false-merge two distinct people who share a name; a few entities still lack a company; one name flagged unresolved for later.
Where it goes: Next: YED-47 identity layer (S1b) · embedding merge + survivorship policy after it (YED-179).
Enterprise tie-in: MDM plus data-quality governance in miniature — the unglamorous foundation every production data/AI system lives or dies on, and the layer most often skipped until it causes an outage.

Arc 02 · The evolving viewpoint.

The Progressive Trend Engine

Each run appends what's new and re-derives every topic's ranking from the full history, with a 14-day half-life. Nothing is wiped: a topic with no new signal is reported as Cooled, not removed.

What it is: A daily, manual-trigger delta scan (/morning-refresh) that pulls what's new since the last run — newsletters, HackerNews, web news, events that happened — matches it against the existing graph, auto-logs the new signals, then recomputes a relevance score across every topic and hands back a Farmed / Added / Changed / Cooled report.
Why it exists: A one-shot scan is a snapshot; intelligence is a trend. The real question isn't “what's hot today” but “what's still rising after two weeks, and what cooled.” That demands accumulating signal over time and re-deriving the ranking each day — a snapshot can't tell a blip from a trend.
The value: The viewpoint evolves on its own cadence without ever wiping history. A topic re-engaged today outranks one last touched two weeks ago (14-day half-life), weighted by the strength (summed confidence) of its signals rather than a raw count — so one strong signal outranks a pile of weak ones.
Best practices it draws on: Meadows' two-stock model — the signal stock is append-only (never cleared); the viewpoint is a derived flow, recomputed by decay-weighting instead of deletion. Recency half-life + confidence-mass weighting from information retrieval. The recompute is pure math (no LLM), so the daily reweight costs zero tokens.
What V1 doesn't do yet: Manual trigger — no scheduler yet, deliberately, since unattended runs are the only piece that would burn metered API tokens; the half-life and weights are hand-set, not learned; the event-proximity boost stays dormant until attended events populate the graph.
Where it goes: Next: YED-180 first real approved run · YED-131 v1 recompute · learned weights + coverage penalty gated on outcome rows (YED-179).
Enterprise tie-in: This is the difference between a dashboard and a system — a surface that recomputes its own state on a cadence over an append-only event log. It's the pattern behind every “what's trending / what needs attention” view in production analytics, and the honest-decay math is what keeps such a surface from being gamed by volume.

Arc 03 · Sensing what the locked-down web won't give you.

The Signal Scanners

Trend, voice, and role radars read public sources only, so LinkedIn stays a stated gap rather than a scrape. Everything passes through one taxonomy, which is what lets a topic seen on three sources count as corroboration instead of three topics.

What it is: Three public-source scanners — trend-radar (trends → content topics), voice-radar (voices → outreach), role-radar (roles → job hunt) — that sense AI/tech momentum from HackerNews, HuggingFace, and curated newsletters, normalize it into a shared taxonomy, score it, and feed the graph.
Why it exists: LinkedIn, where the audience is, has no legitimate trend API and scraping is ruled out. But the same trends surface first on HN / HuggingFace / newsletters anyway. The scanners sense from legitimate public sources instead of fighting a locked-down platform — an honest proxy, not a workaround for parity.
The value: Momentum Alex can't otherwise get, ethically sourced, normalized so “AI agents” and “agentic systems” count as one topic, and decayed so last month's hype doesn't outrank this week's signal. Cross-source corroboration — a topic featured across HN + HF + newsletters — is the trust signal.
Best practices it draws on: The whole game is taxonomy (normalization so corroboration is countable) and decay (recency half-life), both borrowed from dedicated skills rather than reinvented per scanner. Source-weighting (papers for substance, newsletters for editorial vote, HN for velocity). Public APIs / RSS / official endpoints only — a hard ethical line, and no fabricated numbers ever.
What V1 doesn't do yet: Three sources, manual trigger; the LinkedIn-native gap is real and unclosable — stated honestly, not papered over; topic over/under-merging still needs a human eye.
Where it goes: Next: YED-149 roles → spine · YED-145 mentions feed (parked) · more sources when a scan misses something real.
Enterprise tie-in: “Social listening” tools are mechanically simple — poll, normalize, score, rank — and the hard part is always normalization + decay, not the fetch. Building the honest version (legitimate sources, stated gaps, measured-not-invented numbers) is exactly the discipline that separates a trustworthy market-intel product from a scraper that lies.

Arc 04 · From a list of topics to a map of the field.

The Topic-Intelligence Modeling Layer

Producers only write raw signal. A scheduled layer owns everything derived from it, with a heartbeat so a stale refresh is visible rather than silent, and the Hub reads the precomputed result.

What it is: A modeling layer over the topic graph — cluster taxonomy, per-topic trend series, and pairwise bridges between topics — materialized on a schedule (pg_cron) with a heartbeat, and read by the Hub.
Why it exists: A flat list of topics tells you what exists, not how the field is structured — which themes are converging, which topics bridge two clusters (the interesting intersection that makes a good post or project), which are rising versus fading. That's a modeling layer, not a query.
The value: The graph starts to answer field-level questions: where the bridges are, what shape the conversation has, which intersections are underexplored. This is the substrate for both content angles and the project-ideation intersection gate.
Best practices it draws on: Materialized views + scheduled refresh (pg_cron) with a heartbeat so staleness is observable, not silent. Precompute-the-expensive-join so read time stays cheap. Strict separation of raw signal (producers write) from derived metrics (this layer owns).
What V1 doesn't do yet: In progress; clustering is taxonomy-driven, not embedding-learned; bridges are computed on current edges only; the Hub render is partial.
Where it goes: Next: YED-131 nightly recompute · YED-114 /system spine node + panels · YED-126 architecture lens.
Enterprise tie-in: This is the semantic/metric layer of a data platform — the models that sit between raw events and the dashboard. Getting the raw/derived separation and the scheduled-refresh-with-heartbeat right is precisely what makes a production analytics layer trustworthy and debuggable.

Arc 05 · The first lens on the graph.

The Interview-Prep Dossier

Events lens

Job-search lens

The job-search lens reuses the event pipeline's four research specialists unchanged. Only the intake, the synthesizer, and a judge gate before review are new — the proof the engine is lens-agnostic.

What it is: /interview-prep — the Market-Intelligence Engine's first product milestone. Takes a company, role/JD, interview stage, and interviewer; fans out the same four research specialists the event pipeline uses; and synthesizes a structured dossier through a judge gate before Alex reviews.
Why it exists: Proves the engine is lens-agnostic — the same graph and the same research machinery that power content also power the job search, just pointed at a different question. One substrate, many lenses was the founding bet; this is the first lens that isn't content.
The value: A researched, judge-checked dossier on the room before an interview — company, role, stage, interviewer, live tensions — from specialists (company / person / topic / signal) already built and battle-tested for events. Reuse, not rebuild.
Best practices it draws on: Parent-thread fan-out + synthesis-only subagent (the SDK constraint that subagents can't spawn subagents, resolved into an orchestration pattern). Judge-gate before human review. Schema-first dossier so the output is consistent and consumable.
What V1 doesn't do yet: Milestone 1 — dossier generation only, not the full job-search core; writing interview outcomes back to the graph is a fast-follow; one lens proven, others still to come.
Where it goes: Next: YED-152 dossier reads the ICP via retrieve.py + writes interview outcomes back · YED-151 resume tailor.
Enterprise tie-in: The lens-agnostic pattern — one intelligence substrate serving multiple downstream products — is how mature data orgs avoid rebuilding the same graph five times. Demonstrating it with two genuinely different lenses (content + hiring) on shared machinery is the strongest possible proof the architecture generalizes.

Surface

Where the work becomes visible — cockpit and portfolio in one.

Arc 06 · Build in public, honestly.

The Empire State Hub

The hub never writes. It reads its systems of record through server-only clients and serves one set of content two ways: a password-gated cockpit, and a public portfolio with contact data designed out.

What it is: A Next.js hub that is both a small ops cockpit (events, entities, content, content performance — read from Notion + Supabase behind a password gate) and a public build-in-public portfolio (the pipeline, the architecture, the changelog, these build arcs), with an editorial/technical lens toggle over shared content.
Why it exists: The work is the credential. A job search targeting AI-native companies is best served by showing an instrumented, honest, running system rather than describing it — and by letting the same content read two ways: a narrative for a hiring manager, the technical detail for an engineer.
The value: One surface that is simultaneously Alex's operating cockpit and his portfolio, with a PII-safety layer so the public side never leaks contacts, and a generated (not hand-maintained) toolbox catalog so the “what I've built” surface can't go stale.
Best practices it draws on: One lens system over one content source (write once, read two ways) instead of two parallel sites. Design tokens + a component system for consistency. A hard PII boundary between the private cockpit and the public portfolio. Generated-not-authored catalogs so the surface can't drift from reality.
What V1 doesn't do yet: Password-gated ops (HTTP Basic, password-only, checked in a proxy); some panels read snapshots, not live; session-replay and public analytics are still backlog.
Where it goes: Next: YED-196 data refresh · YED-197 journal prose · YED-114 spine wiring · YED-113 session replay (parked) · YED-82 launch.
Enterprise tie-in: An internal ops cockpit and an external portfolio sharing one codebase, one content source, and a hard privacy boundary is a real architectural pattern — the “one system, two audiences” problem every company with a status page and an internal dashboard faces. Solving it with a lens abstraction instead of duplication is the maintainable answer.

Distribution

Making the discipline inheritable across every project.

Arc 07 · Change with a paper trail.

Branch-First Governed Change

The hook decides by what changed, not by who is committing: skills, commands, and schemas can't be committed straight to main, while telemetry and content churn still land directly so the guardrail doesn't tax small work.

What it is: Branch-first git discipline enforced in code — a pre-commit hook that blocks build-surface changes on main, so non-trivial work goes branch → PR → merge while trivial churn (content outputs, typos) can still land on main. Plus the governed-batch pattern: a Linear issue before any change to universal/canonical config.
Why it exists: A memory-less agent auto-committing straight to main leaves no review surface and no trail. The diagnosis — an “auto-committer” that turned out to be a human-driven desktop client, not a daemon — led to a durable fix: make the right path the enforced default, in a hook, not a habit to remember.
The value: Every non-trivial build is reviewable before it lands; universal-scope changes require an issue first; content churn doesn't drown the history. The discipline is enforced by the tool, so it survives a forgetful operator.
Best practices it draws on: Protected-branch / trunk-with-guardrails change management. Governance-as-code (a pre-commit hook) over governance-as-documentation. Scope-tiered rules (trivial vs. non-trivial) so the guardrail doesn't tax small work — the same “don't let the brake become the drag” lesson from the execution-focus retro.
What V1 doesn't do yet: A local hook, not server-side branch protection; the trivial/non-trivial line is a convention the operator still applies; PR review is self-review at solo scale.
Where it goes: Next: server-side branch protection.
Enterprise tie-in: This is change management and separation-of-duties in miniature — the exact controls (protected branches, mandatory review for high-blast-radius changes, an issue trail for config) that every regulated or scaled engineering org runs on. Enforcing them as code at operator scale is the paved-road pattern.

Arc 08 · Build the discipline once; inherit it everywhere.

The Three-Layer Architecture Program

A primitive is proven inside one project first, then promoted to the user-scope plugin through a PR with an issue behind it. Every project opened afterward inherits it instead of re-learning it.

What it is: A three-layer program to make “build better, not faster” the default for every project — Distribution (skills/agents/commands ship to all projects via a personal plugin), Discipline (cross-project invariants like Linear-as-source-of-truth and branch-first), and Workspace (project overlays inheriting canonical defaults). Proven primitives are promoted from Empire State to the user-scope plugin via governed PRs.
Why it exists: Discipline that lives in one project's config is discipline you have to remember to re-apply. The leverage is to promote proven patterns to a user-scope plugin so that starting any new project means inheriting all the accumulated discipline automatically — no per-project setup.
The value: What's validated in Empire State (the toolbox skill, the PostHog/Vercel and hook-schema references, branch-first) becomes universal — proven in one project, then promoted, never auto-merged. Every future project starts further ahead than the last.
Best practices it draws on: Project-scope-first-then-promote (validate locally, promote deliberately). Plugin architecture for distribution. Promotion via PR with a Linear issue for canonical changes — never auto-merge to the universal layer. The measurement layer is deliberately not yet promoted, held as the operator's judgment call — which is the discipline working.
What V1 doesn't do yet: Promotion is manual and deliberate (by design); the measurement layer stays project-scoped pending a call; inheritance happens at project-open, not live-synced.
Where it goes: Next: YED-174 CLAUDE.md canonical backport decision · measurement-layer promotion after the loop's first merged fix.
Enterprise tie-in: This is a platform / paved-road strategy — the internal-developer-platform pattern where best practice is codified once and every product team inherits it. Running it as a disciplined promote-from-proven pipeline (not a big-bang framework) is exactly how mature platform orgs avoid shipping abstractions nobody validated.

Craft

The content and voice the whole pipeline exists to produce.

Arc 09 · The output the whole pipeline exists to produce.

The Content & Voice Engine

Voice is a loop rather than a frozen prompt: Alex's inline corrections are mined back into the style guides, so a rule earned on one post applies to every future draft instead of being re-litigated.

What it is: The content side — a multi-agent event-research pipeline (company / person / topic / signal specialists → synthesizer → Notion) feeding pre-event and post-event content, all governed by a living voice-and-style system: a steering interview before generation, inline-comment feedback after, and a skill that mines that feedback back into the style guides.
Why it exists: Distribution is the north star (full-stack GTM = demonstrated, not stated) and content is the vehicle. But voice can't be a static prompt — it has to learn from what Alex actually approves, or every post re-litigates the same corrections.
The value: Researched, on-voice content with a closed quality loop: steer (capture per-event context) → generate → comment (inline in Notion) → mine (feed learnings back to every style file at once). Rules earned this way — stance is earned by space, visuals must add information, name people, define jargon inline — propagate everywhere from one edit.
Best practices it draws on: A living-system voice (feedback mined into durable references) over a frozen style prompt. A front→back quality loop (steer before, comment after, mine continuously). Human-in-the-loop review positioned after generation so it improves output instead of blocking it. Source-check discipline on any public firm/person claim.
What V1 doesn't do yet: Post-event transcript intake is manual (the recording integration is nonoperational and deliberately disabled); voice-mining is a manual skill run; the multi-agent registry is session-frozen, so agent edits need a fresh conversation to test.
Where it goes: Next: YED-177 OBS capture follow-through · YED-193 small fixes · YED-192 visual-selection marker (parked) · YED-178 theme→post index.
Enterprise tie-in: A voice/style system that learns from reviewer feedback and propagates from a single source is the content-ops pattern behind any brand that scales writing without losing its voice — and “review after generation, mine the corrections” is human-in-the-loop RLHF-in-miniature that keeps a generative system on-brand over time.

The through-line

All ten share one thesis: build better, not faster. Architecture before automation; human-in-the-loop until evidence justifies removing it; inspect real data before proposing fixes; every non-trivial build leaves a durable trace. The value isn't any single component — it's an operator running a small, honest, instrumented version of the exact stack enterprises are spending millions to stand up.