Purpose
Provide a deterministic guardian invite reconciliation tool that can be safely previewed before applying Google Classroom guardian changes from Aeries-derived contact data.
Current state
The workflow is functional and in use, but it is not currently evidenced as a scheduled run. Registry context now treats this as the live Aeries-to-Guardian-Invite sync record: Aeries contact exports feed guarded API actions, while failed invites and contact exceptions still require school-office and Technology Services follow-up. Cross-repo wiring is clear: `aether/google-classroom-guardians.sh` runs SQL extract plus guardian apply in `add` mode and sends a summary email, but active trigger ownership remains unresolved.
Next step
Close unresolved role boundaries using the [Owner, Escalation, and Fallback Matrix](../owner-escalation-and-fallback-matrix/): trigger owner/runtime operator path, escalation owner for failed runs/invite issues, business sign-off owner for contact corrections, and mode-approval authority for `sync`.
Interfaces
Inputs- CSV with student_email and guardians
- Service-account credentials
- Impersonated admin subject
Outputs- Guardian invitation/create/delete API calls
- Dry-run action plans (JSON/CSV)
Reality to Action trace
Reality IngestionNot in scope.
Canonical StorageNot in scope.
Automation EnginesNot in scope.
Human InterfacesContributes in this stage.
Operational AdoptionContributes in this stage.
Core workflow
TBD. Document the 5-10 steps that define the core workflow.
Artifacts
- CSV source files
- Optional JSON/CSV dry-run plans
Operational notes
Constraints and scars
- Classroom API rate limits can increase runtime for large batches.
- Input CSV quality directly controls safe reconciliation.
Reliability posture
Implements paging, state diffing, and retry/backoff for transient API failures. Dry-run and add-only modes reduce accidental destructive changes. Current wrapper evidence in `aether/google-classroom-guardians.sh` runs `add` mode (non-destructive) with CSV min-record and no-diff guards.
Observability
- CLI logs via env_logger
- Exit codes
- Optional dry-run report artifacts
Security and privacy
Handles student/guardian PII and privileged Google API credentials. Restrict file access, avoid credential commits, and manage artifact retention intentionally.
Dependencies
Upstream- Google Classroom API
- Upstream CSV generation workflow
Downstream- Guardian communication readiness workflows
Ownership
OwnersJosh Barton
UsersTechnology Services
Aeries to Guardian Invite Sync
Flow Summary
- Read desired guardian state from CSV.
- Query current guardians and pending invites per student.
- Build action plan (invite/remove/skip).
- Apply actions (or emit plan only in dry-run mode).
Why This Matters
This tool narrows a high-risk workflow into one explicit CLI boundary with non-destructive preview support.
Validation Needed
- Trigger ownership remains unresolved: no current evidence in
saw-01 Task Scheduler CSV and not listed in aether/docs/cron-example.txt, so confirm whether execution is manual, alternate scheduler, or undocumented cron path. - Operational mode boundary remains unresolved: current wrapper uses
add (non-destructive), and approval authority for any full sync removal mode is not documented. - Escalation/sign-off boundary remains unresolved: document Technology Services runtime escalation owner versus school-office/business owner for invite failures and contact-correction acceptance (tracked in the matrix page).
Registry Alignment
- Mapped registry scope:
INT-043, with former INT-017 now merged into the same guardian-invite integration. - Registry clarified: this page represents the active guardian invite workflow even though it is not currently evidenced as a scheduled run.
- Validation gaps: trigger ownership, approval authority for full
sync mode, and contact-correction governance still need documentation.