Part 3 | Workflow foundation

Day 61: What Is a Workflow?

Create a workflow foundation note that names trigger, input, steps, decision, owner, output, evidence, exception, and first handoff.

3core rows

3 learner rows

9fields

1artifact

Deep path: improve the same 3 rows with stronger evidence, limits, and repair notes.

V1Scenario

Concrete workplace scenario

After D60 hands over reusable context-template assets, the manager asks: “What exactly counts as a workflow before we automate anything?”

The trap is calling any repeated task a workflow. D61 must define trigger, input, steps, decision owner, output, evidence, and exception path.

Your first reaction before the work-ready move

V2Worked answer before the table

Worked answer

Bad example first: the plausible shortcut fails

Weak example

“Workflow: use AI to create renewal-risk summaries when needed.”

What goes wrong

The weak version contains use AI, when needed, no trigger, no exception path.

Work-ready version: use the day rule

Trigger

What starts the workflow.

Owner / decision

Who decides or approves.

Exception path

When the workflow stops or escalates.

V3Decision fork

Quick decision check

A workflow needs trigger + owner decision + exception path

Use this rule before filling the build table. The goal is a decision-ready artifact, not a broad summary.

Trigger

What starts the workflow.

Owner / decision

Who decides or approves.

Exception path

When the workflow stops or escalates.

Your application today

TRACEToday’s workflow trace

Workflow/SOP foundation week workflow trace

Before

AI move

Human check

After

Tomorrow use

RESULTToday’s visible result

Before / after: what changed in your work?

Before learning

After learning

What AI-in-workflow means today

Q1Case

Workplace case

A team has reusable context-template assets from Part 2, but daily work still repeats in messy ad hoc ways. The worker must define what a workflow is before proposing tools.

Main learning job

Create a workflow foundation note that names trigger, input, steps, decision, owner, output, evidence, exception, and first handoff.

Failure mode

Calling a checklist, tool automation, or vague repeated task a workflow without owner, decision, evidence, or exception path.

VBCore spine

Core lesson spine

Part 3 begins by shifting from improving single outputs to making repeated work easier to run, review, and improve.

Definition: A workflow is a repeatable path from input to output with trigger, inputs, steps, decisions, owners, exceptions, handoffs, and evidence.

Redline: Do not automate an unclear workflow. First make it observable; automation only makes confusion faster.

Micro-example: Meeting follow-up: trigger is meeting end; inputs are notes, attendees, decisions, open questions; steps clean notes, extract actions, assign owners, mark unknowns, send draft; project lead confirms owners and deadlines; evidence is sent email/task list/confirmed comments; unresolved decisions go back to project lead.

Q2Guidance

Row/time guidance

Core: 3 rows; Deep: 3 rows. Use one repeated task and name trigger/input/decision/evidence/exception. D61 examples may vary; D62-D66 will continue with the renewal-risk workflow thread.

Bridge note: D61 may use any repeated task for workflow definition practice; D62-D66 will continue with the renewal-risk workflow thread so the process-map chain remains concrete.

Q3Handoff

Artifact handoff

Previous artifact: D60 context_template_system_pack_and_part3_handoff.md

Next artifact: D62 repeated_task_candidates.md

Learning checkpoint: Keep the handoff useful to the next lesson by naming evidence, limitation, owner, and stop rule.

LCCheckpoint

Learning checkpoint

This page keeps Day 61 connected to the surrounding course path. Use the previous artifact as working input, produce today's artifact, and hand it to the next lesson with limitations visible.

MPMicro-practice

Workflow definition in the wild

A weekly customer-status update starts when Friday reports close, consumes support notes and account changes, moves through draft, owner check, exception label, and manager handoff. The workflow is not the table; it is the repeatable path from trigger to evidence-backed output.

RDDecision

Trigger/input/owner sort

Mark each item: Friday cutoff = trigger; support notes = input; support lead = decision owner; sent summary = evidence; missing priority = exception. If one label is missing, the workflow is not observable yet.

KVExample cards

Static card version of the worked example

Use these cards before the wide table so the example does not depend on horizontal scrolling.

Worked move

Workflow definition in the wild

Decision standard

EXSample

Day-specific completed sample row

No.	Repeated task	Trigger	Required input	Step list / actions	Human decision / owner	Output / handoff	Evidence of completion	Exception / stop rule	D62 candidate signal
`1`	`Weekly customer feedback review`	`Friday feedback cutoff`	`Support tickets, survey comments, sales notes`	`Collect sources; remove duplicates; tag product area; separate urgent items; draft summary`	`Support lead confirms priority`	`Manager-ready feedback note`	`Evidence links and sent summary`	`Unclear priority returns to support lead`	`Repeats weekly with similar inputs and decisions`

No. 1

Repeated task

Weekly customer feedback review

Trigger

Friday feedback cutoff

Required input

Support tickets, survey comments, sales notes

Step list / actions

Collect sources; remove duplicates; tag product area; separate urgent items; draft summary

Human decision / owner

Support lead confirms priority

Output / handoff

Manager-ready feedback note

Evidence of completion

Evidence links and sent summary

Exception / stop rule

Unclear priority returns to support lead

D62 candidate signal

Repeats weekly with similar inputs and decisions

Q4Build

Build workflow_foundation_note.md

Core: 3 rows; Deep: 3 rows. Use one repeated task and name trigger/input/decision/evidence/exception. D61 examples may vary; D62-D66 will continue with the renewal-risk workflow thread. Blank required fields create export warnings.

No.	Repeated task	Trigger	Required input	Step list / actions	Human decision / owner	Output / handoff	Evidence of completion	Exception / stop rule	D62 candidate signal
1
2
3

Q5Summary

Summary / decision

Strongest result

Limitation

Decision

Next focus

Q6Handoff

Downstream handoff field

Selected handoff

Evidence note

Minimum completion

Readiness/repair status

V5Repair pass

Repair one weak row

Use this pass to find the row that would make the artifact look ready while hiding evidence gaps, unclear owner decision, missing exception, or weak handoff.

Repair example

Weak row: Workflow: make renewal-risk summary with AI.

Repair move: Add trigger, required input, steps, owner decision, output, evidence, and exception.

Better row: Trigger: renewal review date within 30 days; input: current CRM source; owner: CS manager; exception: stale source escalates.

Strongest usable row

Choose the row you would be comfortable carrying into the next day.

Weakest or riskiest row

Choose the row most likely to fail before AI use.

Repair note

Sentence starter: The weak row is weak because ___. I will repair it by adding ___ before using AI.

QXExport artifact

Export artifact

This file is today’s work receipt. It should show the exact decision or handoff that the next day can use, not just that you filled a table.

Before you export

Does the export define trigger, input, steps, owner decision, output, evidence, and exception path?
Does it avoid calling a checklist or vague task a workflow?
Would D62 know which repeated task candidate to evaluate?

What this artifact proves: This file proves the learner can define what makes a repeated AI-assisted task a workflow.

Weak export: Workflow: make renewal-risk summary with AI.

Good export: Trigger: renewal review date within 30 days; input: current CRM source; owner: CS manager; exception: stale source escalates.

Click Generate Markdown to create workflow_foundation_note.md.