Lesson 09 — Governance: Enforceable Config vs. Point-of-Use Rules

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

Learning objective

(Bloom's: Evaluate) For each rule in Bridgeway's real data-handling-policy draft, judge whether your Team plan gives you an enforceable platform control for it or whether it must remain a point-of-use rule — and configure the ones that can be configured.

Standard named: AIHC.2.C2 (Governance), read through X4 (enforcement over advisory): a rule nobody's console enforces is a future incident waiting on someone's memory, not a policy. You already sort flows into permitted / prohibited / needs-a-rule (Lessons 01–06) and you already know retention is Enterprise-gated (Lesson 06). This lesson adds the second sort — who enforces this: the console, or a person — and runs it across your whole real policy draft, not one rule.

Cycle 1 — The second sort: console-enforced, or person-remembered?

SAY — Your data-handling-policy draft, verbatim, reads: "Staff should not upload sensitive donor or client information into Claude. IT will set a 90-day retention window so nothing lingers longer than necessary. Connectors to our shared drive will be enabled for convenience so staff don't have to re-upload files each time." Three sentences, three rules. Before deciding whether each is good policy, ask a narrower question first: does Bridgeway's admin console actually enforce it, or does it depend on a person remembering? Most governance failures aren't bad policy — they're a rule assigned to a person's memory that a console setting could have carried instead, and nobody noticed the console couldn't.

SEE — (static table, pre-worked as the model)

DO — Confirm, in one line, the retention row above using your own Lesson 06 finding — this is a callback, not new discovery. Then read the other two rules and predict, before the next cycles teach it, whether you think each is console-enforceable. Write your prediction; you'll check it.

Cycle 2 — Roles: what's actually assignable at your tier (gospel choir referent)

SAY — A choir director's rehearsal rules only work if the section they govern actually exists — you can't hold the tenor section to a rule written for a section your choir doesn't have. Bridgeway's built-in roles, per the doc-set, are exactly four: "Primary Owner, Owner, Admin, User." Two features that would let you go finer-grained — custom roles and groups — are named Enterprise-only in their own source titles: "Manage custom roles on Enterprise plans" and "Manage groups and group spend limits on Enterprise plans." Your rule 1 ("staff shouldn't upload sensitive info") is really a who-can-touch-what rule in disguise, and there is no fifth role or department-group setting on your tier to carry it.

SEE — (static diagram)

CONSOLE-ENFORCEABLE (Team plan)          NOT AVAILABLE ON TEAM PLAN
────────────────────────────            ────────────────────────────
Primary Owner / Owner / Admin / User    Custom roles ("Manage custom
(assign these four; that's the           roles on Enterprise plans")
enforcement surface you have)           Groups ("...on Enterprise plans")

                                     ↳ Devon's "sensitive info" rule
                                       → becomes a point-of-use rule
                                         instead of a role/group setting

DO — Using your real staffing (Devon = Owner; three team leads = Admin; program staff = User), write which built-in role gets your real staff closest to "shouldn't handle sensitive donor info," and write the point-of-use rule that has to carry the rest of that intent — since no group or custom role can.

Cycle 3 — Retention: the lever that doesn't exist (a one-line consolidation)

SAY — You already resolved this in Lesson 06: custom data retention is Enterprise-only; Team's unconfigurable default is that "data is retained indefinitely." Nothing new to discover here — the discipline of this lesson is applying that same finding structurally, alongside roles and connectors, instead of treating it as one isolated fact.

SEE — (static one-line reminder, not a new diagram) Policy says: delete drafts after 90 days. Console reality: no retention dial on Team plan; default is indefinite. Mismatch stands until Bridgeway upgrades or a manual habit fills it.

DO — Write the one point-of-use rule that has to carry your retention intent today (for example, a recurring calendar task for a named person to manually clear stale chats/projects) — one sentence, naming who owns it.

Cycle 4 — Connectors: the one real lever, and where the real lock actually lives

SAY — Contrast: connector enablement is genuinely available at your tier. Per the doc-set, Organization settings > Connectors → "Browse connectors" → "Add to your team" is a Team/Enterprise capability. But your policy's phrase — "enabled for convenience" — is exactly the ungrounded reasoning Lesson 03 taught you to catch (a convenience reason, not a capability-and-risk reason). The real security floor here isn't a Claude setting at all: "Claude inherits each person's permissions from the connected service. If someone can't access a specific file, channel, or record in the source system, the connector can't reach it from Claude either." Your actual governance lever for donor-data risk on the shared drive is fixing that drive's own* permissions, not a Claude toggle.

SEE — (static diagram) Claude's connector drawn as a window into the shared drive; the lock drawn on the drive's own permission system, not on the window.

DO — Rewrite the policy's connector sentence with a reason, not "for convenience" — name which source-system permission (on the shared drive itself) actually governs what the connector can reach, and state you'll verify it there, not in Claude's settings.

Independent at-bat

Take all three original policy sentences and produce, unscaffolded, a marked-up version of the real data-handling-policy draft: for each rule, label it console-enforceable (name the setting) or point-of-use (name the habit and its owner) — no table provided this time, mark the draft directly.

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

1. (Remember) Name the two features that are Enterprise-only per their own source titles, which Bridgeway's policy draft cannot rely on.
2. (Understand) Why does "no retention dial on Team plan" matter more than it sounds, for an org handling donor data?
3. (Apply) A new rule idea: "only program staff touch grant data." Team plan, no groups. What's the enforceable piece, and what's the point-of-use piece?
4. (Evaluate — objective level) Of your policy's three rules, one is now console-enforceable (roles, partially), one has no console lever at all (retention), and one needed its reasoning fixed, not its config (connectors). Defend, in a short paragraph, whether Bridgeway should write the ungapped rules as point-of-use policy now or wait for a possible Enterprise upgrade — using the platform facts from this lesson, not a hope that Enterprise is coming.

Ledger write

ledger_write:
  learner_id: L2-ADMIN-DEVON
  lesson_id: L2-admin-devon-09-c2-governance
  anchors: [AIHC.2.C2]
  tags: [X4]
  exit_ticket:
    score: ""
    bloom_reached: ""
  auto_score: ""
  self_score: ""
  calibration_gap: ""
  journal_prompt: >
    Of your three policy rules, which one surprised you most once you checked "does the console
    actually enforce this" instead of assuming it did — and what would have happened at Bridgeway
    if you'd never checked?
  structure_used: PBL
  referents_used: [gospel-choir-rehearsal-rules]
  next_lesson_seed: "Lesson 10 (C3 Measurement) asks whether any of this governance work is actually landing — using what the usage-analytics dashboard can and can't tell you."

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).