Reference Architecture

Both of Jay's systems are Claude routines that run in the cloud on a clock. Each run starts cold, cannot stop to ask a question, and has nobody watching it.

The vocabulary comes from Mike Gardon, who splits any automation into a trigger that starts it, inputs and a workflow that do the work, and an action that leaves something behind. His action ladder, draft, file, notify, and send, names how far an action reaches.

YOUR BRIEF
a clock -> Brief prompt + corpus folder
  -> a brief that waits for you

JAY'S DAILY BRIEF
early, weekdays -> procedure file + calendar,
  email, tasks, practice files
  -> a filed brief, one copy to his inbox

JAY'S POST-MEETING SWEEP
five passes, weekdays -> transcripts, calendar,
  relationship history, a ledger
  -> drafts and a review task, never a send

The trigger is a clock early each weekday morning. The inputs are Jay's calendar, recent email, open tasks, summaries of the previous day's meetings, the sweep's meeting drafts, labeled as unreviewed, and the practice files in his repository, the store that holds what his system knows. The workflow is a procedure file the scheduled task points to. It composes the brief in a fixed section order, including one called "What I Could Not Resolve."

The action is a brief filed in his repository, which a publishing step puts in his own reader app, plus one copy emailed to him. On the ladder, the brief files, and its one email reaches only Jay.

Corrections persist through standing instructions. Jay writes a correction once on the Review tab of his reader app, a scheduled workflow copies the active instructions into the repository, and the next run reads them. An instruction can shape voice and framing but can never widen what the brief may do. A conflicting one is ignored and named in "What I Could Not Resolve."

The trigger is a clock again: five passes each weekday, spread across the working day. The inputs are the calendar, that day's meeting transcripts, the day's brief, relationship history from Jay's files, and a ledger of meetings already handled, which makes an extra pass harmless. The workflow reads each transcript once and drafts two things from it: a summary for the people Jay met with and a journal entry for his own record. If anyone else was on the calendar invite, the summary becomes an addressed email draft, and otherwise it becomes a private recap.

The action is the summary, as a Gmail draft with a matching PDF or as a private recap, plus a review task due that day and the journal draft, held apart from his permanent record. Jay sends what he approves at an end-of-day block. On the ladder, the sweep drafts and files, and it notifies only when something goes wrong. Its email connection has no send capability, so that limit is structural.

Those checks exist because the sweep's failures have been quiet. In early October an environment change stopped it from rendering summaries, and for nine days it staged nothing while its warnings sat in a log nobody read. Since mid-October, a pass that cannot account for a meeting must reach Jay directly with a top-priority task and a notification. That alarm has not yet fired live.

Corrections persist in two ways. The sweep reads standing instructions the same way the brief does. When an instruction proves durable, Jay moves it into the procedure file and retires it. Each journal draft also appears on the Review tab, where he can edit, hold, reject, or accept it with typed feedback. Once a day a workflow gathers accepted entries into one proposed change, and Jay's merge is the only way an entry joins his record.

Jay grades his system on the five Elements by what happens.

Set your build beside Jay's and the parts line up. Your Brief prompt is his procedure file. Your corpus folder is his repository. Your scheduled task does the job of his routine, on your own computer rather than in the cloud. Your four-line boundary is his list of forbidden actions, written shorter. When you fix the prompt or the corpus after a bad brief, you are doing what his standing instructions do: putting the correction where the next run will read it.

His extra machinery exists for two reasons, and neither applies to a brief that only you read. The first is scale. His sweep runs five times a day across client meetings and writes for other people, so it needs a ledger and checks that make a quiet failure loud. The second is the audit trail. He handles client material, so every instruction is kept word for word and no journal entry becomes part of his record until he merges it. Your brief reads your own documents and has one reader, so sampling it on the schedule in your boundary tells you what you need to know.

Look at Jay's fourth line, too. He has no true emergency brake, because neither system can reach anyone outside his own systems until he has read what it made. He has automation, but none of it faces outward. That holds only while the automation stays inside. When a job starts sending, posting, or committing on your behalf, the stakes rise, and you need a way to stop it the moment it exceeds your intent. That is when the pull-the-plug line stops being a formality.