Lesson 02 — A1 Specification: Specifying Rollout Workflows and Admin Configs

Generation-time decisions (logged)

Decision	Value	Why
Standard	AIHC.1.A1	Lesson 01 found 0/4 specification elements present on the Grants-team line — the sharpest opening gap
Bloom's	Apply	mastery 0.50 going in (profiled + reconfirmed) — high enough to write specs directly, not just recognize what one is
Structure	PBL	his actual three-workflow rollout plan is the problem, unchanged
Cycles	4
Scaffold level (fade tracker)	heaviest of the six-lesson arc — full worked example given in Cycle 1; later lessons assume this grammar is known
Accommodation	option-suppression	one recommended fix per cycle; alternatives noted, not enumerated
Referents (flavor only)	competition BBQ circuit (constraints = entry rules stated before judging), gospel choir (goal/done = key and tempo stated before rehearsal)

Learning objective

(Bloom's: Apply) Write full specifications — goal, inputs, constraints, done-criteria — for your rollout plan's three pilot workflows, using the platform's actual controls (permission mode, connector, role) as your specification vocabulary instead of task-shaped one-liners.

SSD cycle 1 — the four elements, and what a real one looks like

SAY: AIHC.1.A1: write task requests that state goal, inputs, constraints, and what "done" looks like before handing work to an AI coworker — and when output misses, revise the request, don't just re-roll it. A brisket entry at a BBQ competition doesn't get judged against rules announced after the tasting; a choir doesn't find out the key after it starts singing. Your Grants-team line — "Claude will use Claude to help draft the Outcomes section" — states none of the four.
SEE: A worked, explicitly fictional peer example (not Devon's org): a small clinic's intake-summary spec, annotated with all four elements filled in — Goal: "a summary a case manager can approve in under 2 minutes"; Inputs: "the visit-notes field only, from intake_export.xlsx"; Constraints: "Manual permission mode; no diagnosis codes included"; Done: "case manager marks ✅ or returns with one correction." (Labeled fictional per R5.)
DO: Using that shape, write the full specification for your Grants-team Outcomes-section workflow. Recommended path: work goal → inputs → constraints → done, in that order — it's the order a reviewer will check it in. (Alternatives — constraints-first, done-first — are available on request.) Name real doc-set controls where the spec calls for one: which Cowork permission mode (doc-set §7: Manual / Auto / Skip), which file, which role reviews it.

SSD cycle 2 — "inputs" and "constraints" aren't vague, they're named controls

SAY: Your data-handling-policy draft says "connectors to our shared drive will be enabled for convenience." That is not yet a constraint — a constraint names the actual control and its actual behavior. Doc-set §9: enabling a connector org-wide "doesn't automatically grant anyone access" — each person still authenticates individually, and Claude then "inherits each person's permissions from the connected service." Gap to name, not teach around (R13): the doc-set's page for a specific third-party (e.g., Google Drive/Slack) Cowork setup walkthrough returned a 404 on both fetch attempts (doc-set §10) — this lesson teaches the general connector mechanism above; it does not, and cannot yet, teach a named third-party's specific setup steps.
SEE: A static annotated diagram: your shared-drive connector, enabled at the org level (green gate) → each staffer's own drive permissions (the real gate, per-person) → what Claude can actually reach. The "convenience" framing from your draft is crossed out; the permission- inheritance sentence is written in as the real constraint.
DO: Rewrite the Development-team donor-letter workflow's inputs and constraints lines: name the connector, and state the constraint as "Claude can reach only what the sending staffer's own drive account can reach — over-broad personal drive access is the org's real exposure, not the connector toggle."*

SSD cycle 3 — roles are a specification element too, not an afterthought

SAY: Your plan assigns "three team leads = Admin." Doc-set §4's role table states exactly what Admin grants: "Enable native integrations," "Enable custom integrations," "Enable capabilities," "Enable public projects," "Invite new members," "Remove members/cancel invitations" — org-wide levers, not review-only access. If the Program team lead's actual job is reviewing Claude's monthly board summary, Admin may be over-specified for the task — a right-sized spec names the minimum role the work requires, the same discipline as naming the minimum inputs.
SEE: The doc-set §4 role table (User | Admin | Owner | Primary Owner), with the Program team lead's actual review-only duties checked against each row — every Admin-only permission ("Enable integrations," "Invite/remove members") shown unchecked against what the job needs.
DO: For the Program-team workflow, answer: does the team lead's actual task require Admin, or does User cover it? Write the one-line justification either way — this is the role line of your specification, and it will not be a mystery to a future auditor.

SSD cycle 4 — the revision habit: fix the spec, not just the output

SAY: The second half of AIHC.1.A1 — when output misses, revise the request, don't just re-roll it. Lesson 01 previewed a live case: the grant-report Outcomes section drafted from a vague "help draft the Outcomes section" request. A vague inputs line is exactly the kind of gap that produces a wrong-source or wrong-denominator draft later (Lesson 05 verifies this in full). The fix is upstream: name the exact source now.
SEE: Before/after of the Grants-team spec's inputs line — before: "the program data"; after: "family_services_q3_export.xlsx, columns families_served_q3, families_served_q2, enrolled_q3, attended_session_q3, emergency_assistance_q3 only — not the year-to-date columns."
DO: Rewrite your Grants-team spec's inputs line to name the exact file and exact columns, excluding the year-to-date columns by name. (This single line is what makes Lesson 05's verification pass possible — a vague inputs line can't be checked against anything specific.)

Independent at-bat

Write the complete four-element specification for the Development-team donor-letter workflow, start to finish, folding in Cycle 2's inputs/constraints work — no worked example provided this time.

Exit ticket (Bloom's climbs to Apply; graded against the doc-set + your own rewritten specs)

(Remember) Name the four elements AIHC.1.A1 requires before work is handed off.
(Understand) Why doesn't "connectors enabled for convenience" count as a constraint?
(Apply) Write the goal and done-criteria lines for the Program-team monthly board-summary workflow.
(Apply — objective level) Write the complete, corrected inputs line for the Grants-team workflow, naming the exact file and columns.
(Apply) Using doc-set §4's role table, justify in one line whether the Program team lead needs Admin or whether User is sufficient for their actual task.

Ledger write

ledger_write:
  learner_id: L2-ADMIN-DEVON
  lesson_id: L2-admin-devon-02-a1-specification-20260719
  anchors: [AIHC.1.A1]
  exit_ticket: {score: "", bloom_reached: apply}
  auto_mastery: "0.50 -> "
  auto_score: ""
  self_score: ""
  calibration_gap: " — populates when a learner takes this lesson live"
  journal_prompt: >
    Which of your four rewritten spec elements (goal, inputs, constraints, done) took the longest
    to get right, and what does that tell you about which element your team will skip if you don't
    build a template for it?
  structure_used: PBL
  referents_used: [competition BBQ circuit, gospel choir]
  next_lesson_seed: "Lesson 03 rebuilds the 'Auto mode for all three' line into three separately reasoned delegation decisions, using the specs written here as the object being delegated."

RUBRIC SELF-AUDIT

#	Indicator	Verdict	Evidence
R1	ONE Bloom's-leveled objective, ≥1 named standard	PASS	Single Apply-level objective; AIHC.1.A1 named throughout
R2	Platform claims traced; gaps named	PASS	§7, §9, §4 cited; the third-party-connector-walkthrough 404 (§10) explicitly named in Cycle 2 rather than papered over
R3	3–6 SSD cycles complete	PASS	4 cycles, SAY/SEE/DO each
R4	SEEs ground-truth-verified	PASS	Role table, connector-inheritance sentence, and permission-mode names reproduce doc-set text exactly; the worked peer example is explicitly labeled fictional
R5	DOs on real artifacts	PASS	All 4 DOs rewrite Devon's actual plan lines; only Cycle 1's SEE is a labeled fictional worked example
R6	Media doctrine (static)	PASS	All SEEs static tables/diagrams
R7	Exit ticket climbing, SSOT-graded	PASS	5 Qs, Remember→Apply, graded against doc-set §4/§7/§9 and his own rewritten lines
R8	Ledger: standards + both scores + journal	PASS	present, both scores marked
R9	Band-1 scaffolding with fade; at-bat independent	PASS	heaviest scaffold in the arc (full worked example in C1); at-bat given no worked example
R10	Referents elected + flavor-only	PASS	BBQ/gospel-choir used once each as opening analogies, never load-bearing for a platform claim
R11	Option-suppression honored	PASS	Cycle 1's "goal→inputs→constraints→done order" stated as the one recommended path; alternatives noted, not listed
R12	Non-replication	PASS	every DO rewrites specific lines from Devon's own three-workflow plan
R13	Enforcement gap named, not silently taught around	PASS	Cycle 2 names the 404 gap explicitly and restricts teaching to the general mechanism only

Escalation check: no load-bearing indicator fails → auto-ships.