# Daily Vox Brief — Workflow Design

**From:** Loom
**To:** Larry (review) → Jimmie → delegate build to Riv on approval
**Date:** 2026-05-19
**Status:** Design only. Nothing gets built until Larry signs off and Jimmie answers the four owner decisions at the bottom.

---

## TL;DR Recommendation

**Build a small daily job that pulls yesterday's `project_events`, runs them through a Haiku curation pass that drops the chaff and surfaces 1–3 *teachable* beats, and writes a markdown brief to `Team Inbox/daily-vox-briefs/YYYY-MM-DD.md`. Vox watches the folder.**

This is plumbing. The Atlas project-events table already exists. The classifier pattern already exists (Atlas Day 2 shipped today). The only net-new piece is the editorial curation prompt and a scheduled task.

**Estimated build:** 4–6 hours of Riv's time. **Estimated saved:** 2–3 hours/week of Vox manually mining the events table, plus the editorial discipline that prevents the whitepaper from turning into a changelog. Clears the ROI threshold easily.

---

## SIPOC

| | |
|---|---|
| **Supplier** | Every specialist (via `project_events` POST), Larry (via session summaries), the auto-classifier |
| **Inputs** | Yesterday's `project_events` rows where `created_at >= prev_workday_close AND < today_open` |
| **Process** | Pull → filter (drop noise) → curate (Haiku editorial pass) → write markdown brief → drop file |
| **Outputs** | One markdown file per working day in `Team Inbox/daily-vox-briefs/YYYY-MM-DD.md` |
| **Customer** | Vox, who maintains the whitepaper backlog and ships periodic v7+ revisions |

---

## The Three Layers

This is the part Jimmie asked for explicitly: this cannot be a raw work-log dump. The curation layer is the entire point. Without it, the whitepaper reads like a changelog and Vox burns out.

### Layer 1: Source (already built)

`project_events` table in Atlas Postgres. Schema is already in place:
- `source` (mem.ai, larry-session, specialist, file-drop, manual)
- `event_type` (decision, next_action, recording, chat_summary, handoff, file_added, status_change, note)
- `payload` (jsonb, free-form, but typically `{"text": "..."}`)
- `actor`, `project_id`, `created_at`

Today (2026-05-19) has 5 events in there. Enough volume to test against.

### Layer 2: Filter (rule-based, cheap)

Drop these before they ever reach the curation pass:
- `event_type IN ('file_added', 'status_change')` unless payload text is non-trivial
- Personal-life noise (the "reminder to pick up milk" event from today is the canonical example)
- Events with `payload->>'text'` length under 40 characters
- Events that duplicate the substance of another event in the same window (e.g., a Larry session summary that just restates a specialist summary already in the set)

Filtering is mechanical. No LLM. Reduces the curation pass's input set and keeps token cost low.

### Layer 3: Curate (the editorial AI step, the part that matters)

A single Haiku call. Input: the filtered event list for the day. System prompt below.

```
You are an editorial curator for the PKA whitepaper, an external-IP document
about building a personal AI workforce. Each day you receive a list of work
events from the AI team. Your job is to identify which ones, if any, are worth
a paragraph or a sentence in the whitepaper.

The whitepaper is NOT a changelog. It is a piece a stranger might read to
understand how this team works, what makes it different, and what they could
learn from it.

For each day, select AT MOST:
- 1 "lede candidate" — the single event most worth a paragraph in the
  whitepaper, with a 2-3 sentence editorial framing of WHY it matters (what
  pattern or lesson it shows, not what was done)
- 0-2 "supporting beats" — events worth a sentence or a stat, with a one-line
  reason
- A "skip list" — every other event in the input with a one-phrase reason for
  dropping it (so Vox can override)

A "teachable" event has one or more of these:
- Reveals a repeatable pattern (delegation discipline, kill-vs-keep call,
  consolidation, memory architecture)
- Demonstrates a real production capability (live client work, code that
  shipped, dollars moved)
- Surfaces a failure or a retirement (these are gold — most days won't have one)
- Shows the team evolving (a hire, a fire, a role consolidation)

A NON-teachable event is:
- A routine status update with no decision in it
- An internal handoff with no novel content
- A personal-life note
- A specialist doing exactly what their role description already says they do,
  with no surprising element

Output strict JSON only. No prose outside the JSON.
```

JSON schema:

```json
{
  "lede": {
    "event_id": 34,
    "headline": "string",
    "why_it_matters": "string (2-3 sentences)",
    "raw_payload_excerpt": "string"
  } | null,
  "supporting": [
    { "event_id": 22, "one_liner": "string", "reason": "string" }
  ],
  "skipped": [
    { "event_id": 23, "reason": "string" }
  ]
}
```

The script then renders the JSON into a clean markdown brief.

### Output Format (what Vox actually sees)

```markdown
# Daily Vox Brief — 2026-05-19

**Generated:** 2026-05-19 18:00 CT
**Source events:** 5 (4 after filter)

## Lede Candidate

**Atlas Day 2 shipped: a self-classifying event stream for the AI team**

The team now logs its own work to a shared event stream that another AI
auto-classifies into the right project bucket. This is the plumbing that lets
a multi-agent team have a real shared history without a human transcribing
every session. The "lessons" section of the whitepaper should treat this as
the answer to "how do you scale memory across more than three specialists."

> Raw: Atlas Day 2 shipped: POST /api/project-events endpoint with Bearer
> auth + idempotency + inline Haiku classifier...

## Supporting Beats

- **Afton Electric QBO OAuth handshake completed (realm_id=1331299185).**
  Use as a one-line proof point in the "what it has actually done" section:
  the bookkeeper specialist now has a live client integration to work against.

## Skipped (override if you disagree)

- Event #23 (personal "milk" reminder) — out of scope for whitepaper
- Event #21 — substantively duplicated by event #24

---
*Override any of the above by editing this file in place. Vox reads on Mondays.*
```

This format is opinionated on purpose. The lede has a *headline* and a *why-it-matters*, not just a quote. Vox can then paste it almost directly into the whitepaper's "lessons" or "what it has done" sections.

---

## Cadence

- **Fire time:** 18:00 Central Time, Monday–Friday only
- **Source window:** events created between previous fire time and current fire time. Friday's brief covers Thu 18:00 → Fri 18:00. Monday's brief covers Fri 18:00 → Mon 18:00 (i.e. it absorbs the weekend, which will usually have zero events).
- **No fire on holidays or weekends.** Vox does not need a brief on a day there was no work.

---

## Delegation Brief for Riv (do not build until approved)

| Field | Detail |
|-------|--------|
| **Goal** | Daily 18:00 job that produces a curated markdown brief for Vox from the prior 24h of `project_events`, written to `Team Inbox/daily-vox-briefs/YYYY-MM-DD.md`. |
| **Inputs** | `project_events` table (existing), Anthropic API (existing key in `.env.local`), the editorial system prompt above. |
| **Outputs** | One markdown file per working day in `Team Inbox/daily-vox-briefs/`. Log line per run in `Atlas/vox-brief.log` (success, event counts, file path, errors). |
| **Acceptance criteria** | (1) Runs unattended at 18:00 Mon–Fri. (2) Filter layer reduces obvious noise. (3) Haiku curation pass returns valid JSON, gracefully degrades if it does not. (4) Markdown file is readable and matches the format above. (5) Re-running the same day overwrites cleanly, does not duplicate. (6) Failure does not crash silently — error is logged and an unclassified-bucket-style fallback file is dropped so Vox sees something. |
| **ROI estimate** | 2–3 hours/week of Vox's manual mining + editorial discipline gain. Build cost: 4–6 hours of Riv. Payback: ~2 weeks. |
| **Who reviews** | Larry reviews the design (this doc). Vox reviews the first three briefs before we lock the prompt. I review the prompt itself if Vox flags drift. |
| **Stack notes** | Windows Task Scheduler (same pattern as the existing pg_dump backup job). Python script in `Atlas/scripts/vox_brief.py`. Single Anthropic API call per run, model `claude-haiku-4-5-20251001`. |
| **Out of scope (defer)** | Web UI to view past briefs (read the markdown files directly). Multi-format outputs (markdown only for now). Per-event human approval queue (override-by-editing is sufficient). |

---

## Owner Decisions Before Build

1. **Fire time.** 18:00 CT default. Earlier (e.g. 16:00 so you can see it before end of day) or later (20:00 so it absorbs more of the day)?
2. **Output location.** `Team Inbox/daily-vox-briefs/` (recommended, lives where the team already operates) or somewhere else?
3. **Larry session summaries.** Do they count as a normal event source, or do they get extra weight in the curation (since Larry is already curating-by-writing them)? My recommendation: extra weight, because Larry's summaries are pre-edited.
4. **Voice/length of the curation output.** The strawman above is medium-length. Want briefer (just headlines, no editorial framing) or richer (longer "why it matters" sections)?

---

## What I Am Not Building

Preempting the automation probe:

- **Recurring work the system handles automatically:** the daily fetch, filter, curate, write. Set-and-forget.
- **Recurring work that stays on Vox's plate:** judging the briefs, weaving accepted beats into v7+, deciding when a revision is ready to ship.
- **Recurring work that stays on Jimmie's plate:** answering the four open questions in the whitepaper rework recommendation (audience, voice, public scope).
- **One-time build only:** the script, the scheduled task, the prompt. After Riv ships it, the only ongoing maintenance is occasional prompt tuning if the curation drifts.

---

## Retirement Conditions

This automation gets killed if either of these happens:
- Vox stops opening the briefs for two consecutive weeks
- The whitepaper hits a "shipped, stable, not updated more than monthly" state, in which case daily cadence is overkill and we drop to weekly

I will check this against the monthly automation scorecard.

---

## Next Action

**Larry — review this design.**
**Jimmie — answer the four owner decisions above.**
Once those are in, I write the formal brief to Riv and the build starts.