Engineering · System

Where The Daily sits in a real agentic-analytics pipeline.

Five layers, two execution states. Solid lines are wired today. Dashed lines are the production sketch: code committed under dbt/ and airflow/dags/, but it doesn't execute in the MVE.

00 · The picture

System at a glance

The Daily architecture: interview → preferences.md → dbt + Airflow → Python builder → JSON → Worker UI

Solid stroke + filled chip = wired. Dashed stroke + outline chip = sketched.

Wiring legend

Every layer below carries one of three states. The mix matters as much as the picture. Most of the user-visible pipeline runs end-to-end. The warehouse plumbing is the one place that stays sketched for the MVE.

5
Layers
onboarding → chat
4
Wired now
onboard · build · surface · chat
1
Sketched
warehouse + scheduler
4
Up next
phase-2 surfaces
wiredRuns in the demo, end to end.sketchedCode committed, doesn't execute in the MVE.phase 2Phase 2 surfaces, scoped not built.
01 · Onboard

Onboarding & preferences

Runs once per personawired

The /onboarding form captures Priya's frame in her own words, then writes a per-user preferences file the priority engine reads.

ui

/onboarding form

Captures Priya's frame: cadence, attention thresholds, the metrics she watches.

artifact

preferences.md

Per-user file the priority engine reads. Compiled by lib/preferences-compiler.ts.

02 · Warehouse

Warehouse & marts

Production target · sketched todaysketched

A Databricks workspace plus Unity Catalog is the physical home for the marts. dbt models materialize against it. Profiles are templated, credentials are placeholders.

warehouse

Databricks + Unity Catalog

Physical home for the marts. Catalog and schema mapping in dbt/profiles.yml (placeholder creds today).

dbt

dbt-databricks adapter

Materializes mart_* tables against Unity Catalog. The eight models live under dbt/models/marts/.

scheduler

Airflow DAG

airflow/dags/decision_builder_dag.py schedules dbt plus the builder end-to-end. Today the builder runs by hand.

03 · Build

Decision builder

Manual run · emits the JSON contractwired

Reads preferences.md plus a fixture mart and emits one decision_board.json per scenario. Deterministic Python. No LLM at the seam.

offline

scripts/decision_builder.py

Reads preferences plus a fixture mart and emits decision_board.<scenario>.json. Same shape every consumer parses.

the seam

decision_board.json

Single contract between data, agent, and UI. Validated against lib/schema.ts at build time.

04 · Surface

Static SPA & priority engine

Next.js 15 · static exportwired

The SPA fetches the JSON, ranks it client-side with the priority formula, and renders the bento. Zero server-side rendering at request time.

client

lib/priority.ts

Sorts decisions on $-at-risk × urgency × time-fit. Reads the user's weights from preferences.md.

ui

The bento

1 hero, 2 medium, 5 small cards. Peach attention pulse on the urgent ones, classified by lib/attention.ts.

05 · Chat

Worker & chat handler

Cloudflare Worker · streamed via SSEwired

The Worker's /api/chat handler streams Claude responses with the persona profile plus company KB bundled as a cached system prompt.

edge

src/index.ts (Worker)

Single fetch handler. /api/chat routes first; everything else falls through to the static SPA.

streamed

/api/chat

Anthropic SDK called direct from the Worker. System prompt cached (ephemeral) so the persona context stays warm.

Phase 2 · What comes next

The four surfaces that would make this a product.

A

Feedback loop

Capture decision outcomes and re-weight the priority formula per persona over time.

B

Act layer

Write-back to a price engine or Slack, so recommended actions don't end at "open decision."

C

Governance + audit log

Every decision board snapshot, preferences edit, and chat trace stored for review.

D

Multi-persona deployment

The contract is persona-generic. Adding Morgan (growth) or Dana (ops) is a preferences-file change, not a code change.