Lesson 07 — Trust Calibration: Setting Cowork Permission Lanes Per Workflow

Generation-time decisions (logged, per Playbook §3–5)

Learning objective

(Bloom's: Apply) Assign a deliberate Manual / Auto / Skip permission lane to each of Bridgeway's three real Cowork pilot workflows, grounded in the platform's stated safety guidance and accountability rules — and for each assignment, name whether the platform enforces it or whether it survives only as team policy.

Standard named: AIHC.1.B3 (Trust calibration). Trust is evidence-based, not a feeling (X1), and the line between "safe to auto-run" and "needs a human in the loop" moves as the workflow, the model, and the stakes change (X2). Note the boundary with Lesson 03 (AIHC.1.A2, Delegation): A2 asked whether Claude should do the task at all, for a stated reason; B3 asks how much unsupervised room the task gets once it's delegated — a different question, on the same three workflows.

Cycle 1 — Three modes, in the platform's own words

SAY — Per the doc-set, Cowork has exactly three permission modes, each with a stated behavior: "Manual" ("Claude pauses and asks for approval for actions" — you review each request and choose Allow or Deny); "Auto" ("Claude keeps working without stopping to ask about every step," while it "reviews each action for safety before it runs and blocks anything it determines to be unsafe," including checks for data exfiltration and prompt injection); "Skip" ("Claude doesn't pause to ask and nothing checks its actions automatically"). Your rollout plan's original line set all three pilot workflows to Auto "to reduce staff friction" — a convenience reason, which is exactly what Lesson 03 flagged. This lesson isn't about re-litigating that call; it's about testing whatever call you've landed on against the platform's own safety criterion.

SEE — (static table)

DO — For each of your three real workflows — Grants-team Outcomes section, Development-team donor-acknowledgment letters, Program-team board summaries — write your current mode (whatever Lesson 03 landed you on, or "Auto — unrevised" if you haven't gotten there yet). Recommended path: start with the donor-acknowledgment workflow, since it touches individual donor data and is the one most likely to fail the next test. (Alternatives — starting elsewhere — available on request; not listed as a menu here.)

Cycle 2 — The section-leader test

SAY — A gospel choir's tenor section leader doesn't decide who sings a solo line by who wants it — she decides by one real question: can this voice hold the harmony alone in front of the congregation, or does it need her standing right next to it? The doc-set states the platform's own version of that test directly: recommend manual approval "when the task touches sensitive files, accounts, or sites" or actions that are hard to undo. (Referent: gospel choir — flavor only; the test itself is the doc-set's, not the metaphor's.)

SEE — (static diagram, a spectrum)

NEEDS THE SECTION LEADER BESIDE IT  ←──────────────────→  CAN HOLD IT ALONE
        (Manual)                                              (Auto)
   touches donor/financial data,                        low-sensitivity,
   hard to undo if sent                                 easily reversible

DO — Place each of your three workflows on this spectrum using the doc-set's own test (sensitive data + hard-to-undo = Manual side). Recommended path: the donor-acknowledgment workflow lands on the Manual side (individual donor data, an actual letter sent); the board summary is the strongest Auto candidate (internal audience, easy to revise before it ships). Write your own placement and a one-line justification for each, using the sensitivity/reversibility test — not "reduces friction."

Cycle 3 — What Auto's safety net catches, and what it doesn't

SAY — For whichever workflow you keep on Auto, know exactly what you're trusting the platform to catch. Per the doc-set, Auto's safety check is real but bounded: it screens for things like data exfiltration and prompt injection, backed by content classifiers that "scan all untrusted content entering Claude's context and flag potential injections," and deletion protection — "Cowork requires your explicit permission before permanently deleting any files." None of that checks whether a claim is accurate, whether a donor consented to a phrasing, or whether a tone is right for a funder. And regardless of mode: "the user remains accountable for any content published or messages sent, purchases or financial transactions, data accessed or modified." Auto removes a checkpoint from the workflow — it does not remove Devon's name from the outcome.

SEE — (static two-column list)

DO — For your one Auto-lane workflow (from Cycle 2), write one sentence: what you're trusting the platform's safety check to catch, and one sentence naming what you're still personally on the hook for on that same workflow — using the "user remains accountable" line as your anchor, not a guess.

Cycle 4 — The enforcement gap: naming what the platform can't lock down

SAY — This is the load-bearing finding. The doc-set names exactly one org-wide, admin-side hard lever over Cowork behavior: "Team/Enterprise owners can disable web search and turn off Claude in Chrome via organization settings." That's a real, platform-enforced kill switch — but it's an all-or-nothing capability toggle, not a per-workflow mode lock. Nothing in the doc-set describes an admin control that forces a specific staffer or specific workflow into Manual mode from Devon's side of the console — the mode is chosen inside each Cowork session, by the person running it. So your Cycle 2 lane assignments are team policy, not platform-enforced config, unless you also reach for the one hard toggle that does exist.

SEE — (static two-box diagram)

ORG-ENFORCED (platform actually blocks it)     TEAM POLICY (platform doesn't check it)
────────────────────────────────────────       ────────────────────────────────────────
Disabling web search org-wide                  "This workflow runs in Manual mode"
Turning off Claude in Chrome org-wide          (a staffer could still pick Auto/Skip
                                                 unless a hard toggle also applies)

DO — Next to each of your three lane assignments, mark "policy only" or "also backed by an org toggle." For every "policy only" workflow, write the one habit that keeps the assignment followed in practice (a standing instruction in the rollout doc, a check-in cadence — your call, one sentence each). This is AIHC's enforcement-over-advisory discipline (X4), named directly rather than assumed solved.

Independent at-bat

Bridgeway is about to onboard a fourth workflow — front-desk staff using Cowork to draft volunteer-shift confirmation emails. Run the full four-cycle pass on it, unscaffolded: pick a mode using the sensitivity/reversibility test, state what Auto (if chosen) would and wouldn't catch, and mark whether your choice is platform-enforced or policy-only.

Exit ticket (climbing to Analyze; graded against the doc-set)

1. (Remember) Name the three permission modes and one verbatim thing each one does, per the doc-set.
2. (Understand) Why does the doc-set's own safety guidance make "Skip" a poor default for a first rollout, in enforcement-over-advisory terms?
3. (Apply) A staffer wants Cowork to auto-reply to routine volunteer sign-up confirmations — low sensitivity, easy to correct if wrong. Which mode, and why, using the sensitivity/ reversibility test?
4. (Analyze — objective level) The donor-acknowledgment workflow touches a connected email account (sensitive; hard to undo once sent). Assign it a mode, name exactly what enforces that assignment today, and name what does not — what remains team policy only, and why that gap exists at your plan tier.

Ledger write

ledger_write:
  learner_id: L2-ADMIN-DEVON
  lesson_id: L2-admin-devon-07-b3-trust-calibration
  anchors: [AIHC.1.B3]
  tags: [X1, X2, X9]
  exit_ticket:
    score: ""
    bloom_reached: ""
  auto_score: ""
  self_score: ""
  calibration_gap: ""
  journal_prompt: >
    Which of your three workflows did you mark "policy only, not platform-enforced" — and what
    would actually make you notice if that policy quietly stopped being followed?
  structure_used: PBL
  referents_used: [gospel-choir-tenor-section-leader]
  next_lesson_seed: "Lesson 08 (C1 Provenance) picks up right where trust calibration leaves off: once a workflow's output ships, who can show, after the fact, who produced and verified it."

RUBRIC SELF-AUDIT (against Exemplar_and_Rigor_Rubric_Cowork_x_Nonprofits_2026-07-19_v01_I.md)

Escalation check: no load-bearing indicator fails → auto-ships per the versioned escalation policy (Playbook §5).