Cloud Run + Google Workspace — Beneficiary Care subsystem migration sketch

1. Why a separate sketch from the media-line plan

The media-line cloud-migration sketch (cloud-run-migration-sketch) handles the Area-2 storytelling pipeline. This document handles Area 1 — Beneficiary Care. They share a GCP project, a Workspace, and the same auth pattern, but the workloads, data sensitivity, user roles, and cadence are different enough that one document covering both would obscure both.

The contrasts that matter:

• Different folder, same Drive. Media and Beneficiary Care live on the one Foundation Shared Drive (phamj.com). Care is the restricted folder 10_Ho-so-thu-huong/, gated by folder-level permission to the administrator only. The access boundary is the folder permission, not a second Drive. (Team-scale target: a separate private Drive; deferred — see the override banner.)
• One user for the trial. One administrator holds every hat (coordinator, editor, safeguarding, principal, trustee). The five-role read-shape model is the team-scale target, deferred.
• Different cadence. Media line is event-driven (an upload triggers a pipeline run). Beneficiary Care is heavily scheduled (nightly index rebuild, monthly watchlist, monthly Area-4 emission, quarterly archive) with on-demand bursts from the dashboard.
• Different UX surface. Media line ships a static review site + Chat approval cards. Beneficiary Care ships a real FastAPI dashboard behind one simple login, with inline data entry. The dashboard is the administrator's operational surface for the cohort. (Role-aware views + side-by-side PDF review are the team-scale target.)

The good news: every cloud primitive used in the media-line plan applies here too. So this sketch concentrates on what is different and treats the shared infrastructure (Artifact Registry, Secret Manager, Cloud Logging, Workload Identity Federation) by reference.

2. Where Area 1 is today

Two simultaneous baselines, per the subplan:

• Operational (Foundation side). Six (and growing) partner schools. Each school has a designated Coordinator who records observations in paper notebooks, Zalo threads, photo libraries, and shared notes. Nothing is lost — but the record is distributed, sometimes duplicative, and not retrievable by anyone other than the notebook's owner.
• Workspace side. B1 (data shapes + registry migration) and B2-scaffold (intake + promotion prose path) landed on 2026-05-28 — see the status tracker. Three tools (beneficiary_registry_migrate.py, beneficiary_validate.py, beneficiary_promote.py) plus the beneficiary-recorder agent and the /record skill are real. The 01_Ho-so-thu-huong/ directory holds the placeholder layout: Ho-so/ (profiles), So-phuc-loi/ (benefits ledger), Tai-lieu-vao/ (intake), Bao-cao/ (reports), Chi-muc/ (indexes), Danh-sach-an-toan/ (safeguarding watchlist), nguon-tai-tro.yaml (funding-source enum), tu-khoa-canh-bao.yaml (watchword list).

Everything that runs today runs on the operator's Windows box, against an in-repo placeholder directory. No real children's data has entered the system yet. Real data has never been on the operator's machine and is not intended to be — the operational store is the restricted 10_Ho-so-thu-huong/ folder on the one Foundation Shared Drive, separate from this repo, gitignored in the placeholder. The data files live on Drive when provisioned; the same tools drive both surfaces via path flags.

That last point matters for the migration. The cloud move is not "lift the laptop into Cloud Run." It is "give the existing tools a real home with the access controls the subplan already specifies." The architectural seams are clean enough to do this without a rewrite.

3. Six things that make this subsystem different

If you have read the media-line sketch, here is the delta in one screen.

4. Target architecture on ‹gcp-project›

Trial shape (2026-05-29): one Workspace, one Shared Drive. Care is not a second Drive — it is a restricted folder (10_Ho-so-thu-huong/) on the single existing Foundation Shared Drive, gated by folder-level permission. Same project, same region, one service account, additive on top of the media-line components.

The dashboard is the centre of operational gravity for Area 1. Trustees and Principals never touch Claude Code; the dashboard is their entire interface. The Coordinator uses both Drive (for raw drops + reading approved profiles) and the dashboard (for promotion, school-doc review, benefit entry, sponsorship-view generation). The Safeguarding lead lives in the dashboard's /watchlist + child profile pages.

5. Auth model: one Drive folder, one SA, one login (trial)

Trial auth (current)

• One SA. Reuse ‹foundation-service-account› via workload identity (no key download) for both the dashboard service and the care jobs. Grant it Storage Object Admin on the care bucket + Secret Manager Accessor. No hmt-care-sa.
• One Drive, folder permission. The existing media-line impersonation subject already reaches the Shared Drive; the 10_Ho-so-thu-huong/ folder is permission-restricted to the administrator at the folder level. No care@ subject, no second DWD entry, no second Drive.
• One login. The dashboard sits behind a single user/password login. No IAP allowlist, no Apps-Group role routing, no role_assignments table, no audience filter — one administrator sees everything in the folder they already have permission to.

6. End-to-end walkthroughs (six flows)

The media-line sketch had one canonical flow (an event from upload to post). Area 1 has six flows. For the trial they collapse onto one operator (the administrator wears every hat), and Flows A and B auto-convert with no per-note human commit — see the override banner at the top. Each walkthrough below carries a trial-shape note; the role tags (Coordinator / Safeguarding / Trustee / Principal) are the team-scale labels, all held by the one administrator for now.

Flow A — Administrator Prose drop → auto-converted memory entry

The everyday flow. The administrator visits THCS Tân Khánh, writes up notes about journey-0042's reading progress, then drops the file when back at a laptop.

1. Drop. They upload 2026-05-18__truong-1__tham-truong.md (a note, a .docx, or a direct text paste — not necessarily Markdown) into 10_Ho-so-thu-huong/Tai-lieu-vao/2026-W21/journey-0042/ on the one Foundation Shared Drive. Drive UI; phone or laptop.
2. Auto-pickup. The scheduled intake-convert-job (and, if wired, a Drive changes.watch nudge) finds the new drop. No "optional push vs Monday review" distinction any more — the schedule run is the pickup.
3. Auto-sanitise. The job runs media_sanitise.py on the artefact (EXIF/GPS strip for images; no-op for text). Safeguarding measure 1 still mandatory.
4. Auto-convert. The job invokes the beneficiary-recorder agent (Claude Opus, ANTHROPIC_API_KEY from Secret Manager): raw drop in, a structured Block-3 memory entry in the canonical shape out. It infers the petal anchor (default petal 1 for a school visit), writes the entry to Block 3 of the profile via Drive API, and writes the matching profile_entry row. The raw drop is kept beside the entry; the entry's *(file gốc: ...)* line points back to it.
5. Auto-register + validate. beneficiary_validate.py runs on the updated profile. On a clean pass the entry is live in the internal memory — done, no human touched it.
6. Flag-on-failure (the only human path). If conversion fails its confidence/quality bar — the text is unreadable, can't be extracted to a coherent entry, the file won't open, OCR is garbage, or the agent returns low confidence — the job does not write a half-baked entry. It files a review request (10_Ho-so-thu-huong/Tai-lieu-vao/2026-W21/_needs-review.md + a notification) describing what it couldn't process, and leaves the raw drop in place for the administrator to fix or re-drop. Quiet on success; loud only on genuine failure.
7. Safeguarding carve-out (kept). Independently of conversion quality, if the entry text trips a watchword (tu-khoa-canh-bao.yaml: đánh, bỏ học, bạo hành…), the entry is still written to memory but is also surfaced to the administrator (the safeguarding hat) the same day — see Flow D. Auto-write does not silence a safety signal.

Why auto-write is allowed here. The internal beneficiary memory is not an egress; writing a progress note to a private profile sends nothing outside the workspace. Phase A stays absolute at the output boundary (a Facebook post, a sponsor email, a website figure — all still need /approve). This mirrors the gate-8 single-administrator relaxation: the discipline moves to where data actually leaves, not to every internal keystroke. Reverts to a review-before-commit gate when a second person joins.

Flow B — Administrator School PDF → auto-extracted, flag-on-failure

The term-2 học bạ for journey-0042 arrives as a PDF.

1. Drop. The administrator uploads 2026-04-10__hoc-ba-hk2.pdf into Tai-lieu-vao/2026-W15/journey-0042/. The __hoc-ba token routes it to the structured extractor.
2. Auto-extract. school-doc-extract-job (scheduled, same pickup as Flow A) pulls the PDF via Drive API, sends it to Claude Opus as a document input with the hoc-ba Pydantic schema, gets back the structured record (gpa_overall, class_rank, subject_grades[], teacher_comment, attendance_pct, conduct_rating).
3. Validation bounds (the auto safety net). Pydantic enforces ranges that catch the obvious OCR slips: a 10-point-scale grade must be 0–10 (so 75 fails and flags), attendance_pct 0–100, class_rank ≤ class_size, conduct_rating in the fixed enum. A value outside bounds → the record is held and flagged, never committed.
4. Auto-commit on clean extract. If the record validates and the model's confidence is high, the job writes one school_report row per child (SQLite, confirmed_by = auto), composes a short Block-3 note keyed to the fields, writes it to the profile via Drive API, links the two via school_report.profile_entry_id.
5. Flag-on-failure. If extraction fails, a bound trips, confidence is low, or the document is a multi-child sheet (class-wide ranking/attendance — ambiguous which row maps to which HMT child), the job files a review request to _needs-review.md + notifies the administrator, with the PDF and the draft fields attached for a quick fix. The multi-child split stays a human decision because mis-attribution is worse than delay.
6. Audit artefact. The PDF stays in Tai-lieu-vao/; the note footer and the row's source_pdf column both point to it.

The same flow handles so-diem, chuyen-can, hop-phu-huynh with their per-type schemas + bounds. Pydantic models live in tools/school_doc_extract.py.

Flow C — Administrator Benefit delivered → ledger row

A scholarship cheque is handed over. The ledger records it the same day, because Area-4 transparency depends on the ledger being complete in real time.

1. From the child profile page (trial dashboard, /child/journey-0042), click "record benefit".
2. Fill the form: date, category (scholarship), petal (1), amount in VND (2,500,000), funding source (tet-2026-quy-cong-dong; dropdown validated against nguon-tai-tro.yaml), delivered by, handover signed by (Mẹ — Nguyễn Thị Hoa). Optionally upload the signed receipt PDF.
3. Commit. Dashboard calls POST /benefit/record. Server-side: writes a markdown ledger entry into 10_Ho-so-thu-huong/So-phuc-loi/journey-0042/2026-04-12__hoc-bong-hoc-ky-2.md (Drive API), uploads the receipt into the same folder, writes a benefit row to SQLite with benefit_id = ben-2026-0042-003 (auto-sequenced). benefit_record.py does the validation and the writes (B3 surface).
4. Done. Returns to the child profile page; the ledger panel shows the new row. The Area-4 monthly report draft picks it up automatically on the 28th.

Flow D — Administrator Monthly watchlist → alert notification

The 1st of the month, after the schedule runs:

1. Job runs. watchlist-monthly-job reads the registry + profiles, applies the §7 signal rules, writes 10_Ho-so-thu-huong/Danh-sach-an-toan/<YYYY-MM>__watchlist.md.
2. Alert. The job sends the administrator one notification summarising the run: "Watchlist 2026-06: 7 signals — 2 absence, 1 keyword ('bỏ học', journey-0058), 1 grade-drop (journey-0042, HK2 GPA −1.2), …", with a link to the full markdown. That markdown is the readable queue for the trial; the administrator scans it and follows up on whatever warrants it through the normal flow.
3. Daily keyword pass. A narrower watchlist-keyword-job sends an alert only on a non-empty day — the genuinely-can't-wait signals. Most days: no notification at all (silence = clear).

The job is fully automated; the administrator's judgement is the action. Nothing auto-resolves a signal — an alert stays until the administrator has dealt with it, the same way the gate-8 dignity check is never auto-set.

Flow E — Administrator Report generation → reader-friendly HTML

End of quarter. The administrator opens the dashboard.

1. Lands on the trial dashboard (one login). Sees the cohort summary, school list, every child by name + journey-id.
2. Clicks Reports → "Per-cohort report". Picks programme Cùng em tiến bước, cohort year 2026, window "trailing 3 months". Generate.
3. report-cohort-job launches. Reads the SQL (child, benefit, profile_entry, school_report for the cohort), calls the report-writer agent (Claude Opus) for the narrative, then renders three artefacts from one run: a reader-friendly HTML page (the primary, brand-styled, charts inline), plus markdown and PDF as the audit/archive copies, plus HXL-CSV for the financial cuts.
4. All artefacts save to 10_Ho-so-thu-huong/Bao-cao/2026/2026-06-30__cohort__cung-em-tien-buoc-2026.{html,md,pdf}. The dashboard opens the HTML directly. ~10s SQL + ~15–30s Claude narrative.
5. Per-school and per-child reports are the same backbone, different SQL view + template; the administrator picks the kind from the same Reports screen.

Reports are deterministic-given-state — same data, same SQL output; only the Claude narrative drifts slightly between runs. The rendered HTML+md+PDF are written to the Drive at generation time for audit.

Flow F — Parked Sponsorship quarterly view

7. Service + job mapping

8. Where data lives (Drive vs GCS vs SQLite)

9. When things run

Cron (Cloud Scheduler — the dominant pattern here)

• care-cache-refresh-job — nightly 04:00 ICT. Pulls profile markdown from the Care folder into GCS for fast dashboard reads.
• intake-convert-job / school-doc-extract-job — scheduled (e.g. hourly). Auto-convert new drops (Flows A & B); flag-on-failure.
• index-rebuild-job — nightly 02:00 ICT. Rebuilds the three indexes (by-cohort, by-school, by-child/_search.md) in the Care folder.
• consistency-check-job — nightly 02:30 ICT. Drive-vs-SQL drift; alerts on findings.
• watchlist-keyword-job — daily 07:00 ICT. Narrow keyword pass; alerts the administrator if anything fires.
• watchlist-monthly-job — 1st of month, 06:00 ICT. Full signal sweep → alert (Flow D).
• area4-emit-job — 28th of month, 06:00 ICT. Monthly Area-4 financial transparency emission (HXL-CSV; later IATI XML quarterly).
• Deferred (team-scale): iap-allowlist-sync-job (one login instead) and drive-membership-audit-job (one operator, one folder).

Push-triggered (event-driven, optional)

• Drive changes.watch on Tai-lieu-vao/ → a webhook on the dashboard service → runs the convert job sooner than the schedule. Convenience only; the scheduled run works without it.

On-demand (dashboard-initiated)

• Benefit-record + report generation — launched from dashboard clicks. Jobs queue and return; the dashboard polls for completion via HTMX swap. (Intake convert/extract are scheduled + auto, not click-driven.)

Never (Phase-A invariant for Area 1)

• No scheduled job ever pushes anything about a child to a public or external surface. The output boundary is the absolute line (§11). A care job may write to the internal store (auto-convert intake does), but no job posts to Facebook, emails a sponsor, or renders a public page — the Scheduler SA holds no Graph-API / publish permission, the same way channel-publisher has none in Phase A.
• (Legacy, reverts with a second person.) No scheduled job commits a profile entry, benefit row, status change, or watchlist action; Scheduler SA holds no roles/run.invoker on the commit endpoints. The trial replaces this with the output-boundary line above plus the flag-on-failure + watchword backstops.

10. The dashboard service (B7 expanded)

The dashboard is the most substantial new build. The subplan (§B7) gave it 5–8 days; that estimate is pre-cloud and assumes a localhost FastAPI. On Cloud Run behind one simple login, plan ~10 days for the first cut, ~3 more for polish after the pilot.

Pages and views (Role column = team-scale target; trial = one administrator sees all)

Stack choices

• FastAPI for the routing + async I/O; the same Python the rest of the codebase uses, so the tools import naturally.
• HTMX for inline updates (Save buttons, side-by-side review, watchlist triage actions). No SPA framework. Server-rendered Jinja templates.
• Pydantic for request/response shapes. Already in the toolchain.
• SQLite via gcsfuse — same as the media-line registry. WAL mode; the dashboard reads; jobs serialise writes per child profile.
• No JavaScript framework. The brief is "principals and trustees on their phone." Small page weight; no build step.

Audit logging

Every read of a child profile by a non-Coordinator role writes one line to the audit log:

{ "ts": "2026-06-15T08:32:14+07:00",
  "viewer": "bac.binh@hmtfoundation.org.vn",
  "role": "trustee",
  "path": "/child/journey-0042",
  "fields_visible": "trustee_filter",
  "ip": "..." }

The Safeguarding lead can see this audit at /audit/role/trustee. Trust-by-transparency — the people whose data is in the system can be shown that access is recorded.

11. Phase-A invariants for this subsystem

Inherit the media-line invariants (no channel-publisher cron, gate-8 manual, etc.). On top of those:

• Output boundary is absolute. Nothing about a child reaches a public or external surface without an explicit human /approve. Outputs leave the subsystem only via Area 2 (Stream C with the gate-8.5 leakage check) or Area 4 (aggregated finance, programme-not-child level). Both keep their own approval gates. This is the invariant that does not relax.
• Auto-write to the internal store is allowed, with two human backstops. (1) Conversion that fails its quality/confidence bar flags a human instead of writing a half-baked entry (flag-on-failure, Flows A/B). (2) A watchword hit still surfaces to the administrator the same day even though the entry is written (safeguarding carve-out). The dignity check itself (gate 8) is still never auto-set.
• No public surface. No URL beyond the single-login trial dashboard, no donor portal, no parent portal, no website page rendered from the private store.
• The administrator owns the canonical record. The dashboard is a convenience layer; the markdown profile on the Drive is the source of truth. Any write — auto or human — writes the markdown via Drive API, never just the SQLite. Drive revision history is the audit trail, and it records the auto-writes too.
• (Legacy, reverts with a second person.) No automated profile / ledger / status writes; every commit human-initiated through the dashboard or /record; cron reads, humans write; Scheduler SA holds no roles/run.invoker on commit endpoints.

12. Migration plan, in phases

Assumes the media-line cloud migration is done first (it provides the project, the Artifact Registry, Secret Manager, the base image, IAM patterns). If Area 1 goes first, fold the media-line C0–C2 into the front of this plan.

D0 — Pre-flight (1 day) — trial

• Create the restricted folder 10_Ho-so-thu-huong/ on the existing Foundation Shared Drive; set folder-level permission to the administrator only. (No second Drive for the trial.)
• Confirm the existing SA hmt-media-ingest reaches the folder; grant it Storage Object Admin on the new care bucket + Secret Manager Accessor. (No care@ subject, no hmt-care-sa.)
• Create the new GCS bucket ‹gcp-project›-care-db.
• Dashboard URL: the default Cloud Run URL behind one login is fine for the trial; a custom domain is a later nicety.

D1 — The Drive seam (2 days)

• Build tools/profile_store.py — the Drive-API-shaped layer that lets existing tools keep their path-style calls (profile_store.read("Ho-so/journey-0042.md") ↔ Drive API).
• Port beneficiary_promote.py and beneficiary_validate.py behind it.
• Tests with a FakeProfileStore — same pattern as FakeDriveClient in ingest_watch.py.

D2 — Bucket + migration on the existing SA (1 day) — trial

• Reuse hmt-media-ingest (no new SA, no new DWD entry — the existing impersonation already reaches the Drive).
• Run beneficiary_registry_migrate.py as a one-shot Cloud Run job — creates the five tables on the GCS-mounted SQLite.
• Run gworkspace_check.py — must pass against the existing SA.
• (Team-scale: provision hmt-care-sa + a care DWD entry + add care@ to a separate private Drive. Deferred.)

D3 — School-doc extraction (3 days)

• Build tools/school_doc_extract.py with Pydantic schemas for the four doc types.
• Wire school-doc-extract-job.
• Pytest fixtures: one anonymised PDF per doc type (synthetic, no real children).
• Acceptance: a real hoc-ba PDF round-trips to structured fields + a draft Block-3 note.

D4 — Cron jobs + watchlist (4 days)

• Build tools/safeguarding_watchlist.py (B6).
• Build tools/beneficiary_index_rebuild.py + tools/beneficiary_consistency_check.py (B4).
• Wire all four as Cloud Run jobs + Scheduler entries.
• Wire care-cache-refresh-job for the read-through cache.
• Acceptance: nightly run on synthetic data produces the indexes; monthly run produces a watchlist with at least one signal of each type.

D5 — Reports (4 days)

• Build tools/report_child.py, tools/report_cohort.py, tools/report_school.py (B5).
• Three jobs + the report-writer agent prompt.
• Golden-file tests against synthetic data.
• Add tools/benefit_report.py + area4-emit-job (B3, the Area-4 monthly).

D6 — The dashboard, first cut (8 days)

• Scaffold app/: FastAPI, Jinja templates, HTMX, Pydantic schemas, the read views (child, school, cohort, watchlist, intake, reports, audit).
• Wire the write endpoints (promote, extract, benefit, watchlist action).
• Audience filter as a single decorator on the view functions; renders different templates per role.
• Deploy as hmt-care-dashboard Cloud Run service.
• IAP in front; allowlist seeded manually with Foundation accounts.
• Acceptance: a Coordinator can promote + record-benefit; a Safeguarding lead can triage; a Trustee can generate a cohort report — all from the browser.

D7 — Allowlist sync + audit + domain (3 days)

• iap-allowlist-sync-job + drive-membership-audit-job.
• Audit log sink and the /audit pages.
• DNS for care.hmtfoundation.org.vn; Cloud Run custom domain mapping.
• Penetration check: confirm that issuing arbitrary HTTP requests as a trustee account does not return Coordinator-scoped data, and vice versa.

D-zero — Operational pilot, parallel

Per subplan §B-zero: one school, one Coordinator, five real children, hand-rolled profiles + five weeks of intake, walked end-to-end on the pre-cloud setup first. Do this before D3 lands. Findings feed the dashboard's first cut. The pilot proves the operational discipline, not the cloud infrastructure.

Total: ~27 working days of build, plus the pilot operational time. Most of it is the dashboard (D6) and the watchlist/reports/extraction trio (D3–D5). Pure cloud plumbing is ~5 days (D0–D2 + D7).

13. Cost estimate

Steady state, six partner schools, ~150 children active across the cohort, ~30 benefit rows/month, ~15 progress notes/week, monthly watchlist + daily keyword pass:

On top of the media-line ~$20–25/month + ~$10–30 Anthropic, the all-Foundation monthly is ~$65–115. Order of magnitude smaller than any SaaS case-management tool, and the Foundation owns the code and the data.

14. Risks and rollback

Risks specific to Beneficiary Care

• Care-folder permission drift. Trial: with one administrator and folder-level permission, the surface is small — the risk is the folder being accidentally shared wider. Mitigation: the administrator checks the folder's sharing on the quarterly cadence. (Team-scale: drive-membership-audit-job + iap-allowlist-sync-job against a separate private Drive's member list; deferred.)
• Audience filter bug leaks data the role should not see. Mitigation: the filter is a decorator on every view function with default-deny semantics. D7 includes a penetration check. Audit log captures every read; a leak would be visible after the fact.
• SQLite-vs-Drive drift. A failed write mutates the markdown but not the SQL projection, or vice versa. Mitigation: consistency-check-job nightly; the dashboard's profile page also runs a lightweight check on-load and shows a warning banner if drift is detected.
• OCR errors in school-doc extraction. A grade of 7.5 read as 75. Mitigation: the side-by-side review is mandatory before commit; the extractor never auto-commits. confirmed_by column in school_report is non-null by schema.
• The Coordinator stops populating the benefits ledger. Mitigation: the Area-4 monthly draft surfaces this-month-by-school benefits totals; an unusually low number is visible to trustees, who ask. (Same mitigation as subplan §13.)
• Identifying detail leaks into a Stream-C piece. Mitigation: journey_leakage_check.py (subplan §10) is a hard QC gate. The check runs against the canonical profile on Drive; the media-line job pulls it via Drive API.
• Sponsor accidentally seeing another sponsor's data. Mitigation: sponsor outputs are read-only files generated and sent personally by the Coordinator (manual step, Phase A). No multi-sponsor portal in initial scope.

Rollback per phase

• D0–D2 (Drive seam, SAs, migration). Reversible. The placeholder local setup still works. Delete the bucket; revoke the SA; no permanent impact.
• D3 (school-doc extract). Additive. Local school_doc_extract.py would also work if needed.
• D4 (cron jobs). Disable the Scheduler entries; the local equivalents are not yet built, so revert means "no watchlist for now," which matches today's state.
• D5 (reports). Additive.
• D6 (dashboard). First phase that creates real Coordinator habit. Reverting after launch is operationally painful (the Coordinator now expects the dashboard); pre-launch the rollback is free. Recommend the dashboard ships only after D-zero pilot signals "ready."
• D7 (allowlist sync + domain). Reverting is "switch back to manual allowlist + default Cloud Run URL"; minimal disruption.

15. Open questions for the Editor

Resolved by the 2026-05-29 Editor review (see the override banner): one Workspace + one Shared Drive (Care = restricted folder, no second Drive); one SA (hmt-media-ingest, no care@, no hmt-care-sa); one administrator (no five-role model, no role_assignments table, no audience filter); one simple user/password login (no IAP allowlist sync); dashboard on the default Cloud Run URL for the trial; Flows A & B auto-convert; Flow D is an alert; Flow E renders HTML; Flow F parked. The questions below are the ones still genuinely open.

1. Auto-convert failure threshold. How aggressive should "low confidence → flag a human" be? Too loose risks a bad entry in memory; too tight defeats the labour-saving. Tune during the pilot.
2. Alert channel for Flow D + the failure flag. Email? A dashboard banner? Zalo/Telegram? Not yet pinned for the Care side.
3. Drive change push for intake. Optional — the scheduled convert run works without it. Recommend leaving it off at launch; turn on later if the lag annoys.
4. Anthropic budget cap. The care-side adds $15–40/month at steady state, spiking in school-doc-heavy months. Confirm headroom on top of the media-line cap. (Carried from the original list.)
5. When does this happen?
   • Subplan order: B1 done, B2-scaffold done. The natural next builds are B2-full (school-doc extract) → B3 (benefits) → B4 (indexes) → B5 (reports) → B6 (watchlist) → B7 (dashboard).
   • The D-zero pilot is the unlock for any cloud commit. Recommend: D-zero on the local pre-cloud setup first, then choose between (a) finishing B2–B7 on local, then a single cloud push, or (b) D2–D4 cloud plumbing in parallel so the dashboard ships natively cloud-hosted. The (b) path is faster to a usable trustee dashboard; the (a) path is lower-risk.
   Editor's call.

16. Glossary delta

Read the media-line glossary first. New here:

Care folder (10_Ho-so-thu-huong/)

Trial: a permission-restricted folder on the one Foundation Shared Drive holding every child's record. Folder-level permission to the administrator is the access boundary. (Team-scale target: a separate private Shared Drive with its own membership list; deferred.)

Audience filter (§6.5 of the subplan) — deferred

A render-time narrative filter that limits what a report or profile page includes based on the viewer's role. Not used in the one-administrator trial (one viewer sees everything); returns with a second role.

Cloud IAP allowlist sync — deferred

Team-scale: a daily job that reads the Drive's member list and writes it to the dashboard's IAP allowlist. The trial uses one simple user/password login instead.

Read-through cache

A GCS mirror of the canonical markdown on Drive, refreshed nightly. Lets the dashboard answer queries in <100 ms instead of waiting on Drive API. Stale-tolerant.

Audit log sink — deferred

Team-scale: a Cloud Logging sink capturing every read of a child profile by a non-Coordinator role, for the Safeguarding lead's cross-user review. Not needed in the one-administrator trial (one viewer); Drive revision history already records writes.

Profile store

A small library (tools/profile_store.py) that hides Drive API calls behind a path-shaped interface. Lets the existing tools keep their filesystem-style reads / writes without rewriting to a Google API client.

Gate 8.5

The journey-leakage check (tools/journey_leakage_check.py), specific to Stream-C pieces sourced from a real profile. Asserts no Block-1 identifying field survives into the published draft.