Related Atlas entries
Purpose
Turn recurring report requests into stable, owned, self-service products. This playbook defines how reports are scoped, built, published, and maintained so they stay trustworthy and reduce ad hoc data pulls.
March 2026 alignment note
The BOUSD registry now makes three gaps explicit:
- report-family ownership and cadence are still not published in one place;
- several live BOUSD reports depend on a shared Aeries-to-Google Sheets extract family and should be documented as linked report products rather than isolated dashboards;
- some long-lived Google Workspace report surfaces still need manual-versus-scheduled refresh reconciliation.
When to use this playbook
- Before publishing a new operational report or dashboard.
- When changing a report schema, refresh cadence, or access scope.
- When data consumers report mismatches or stale outputs.
Signals to stop or escalate
- Source system changes invalidate report definitions.
- Refresh failures leave reports stale beyond the promised cadence.
- Access-control issues expose data beyond intended audiences.
- A report has no named backup owner.
Audience and access
- Primary operators: data services and IT reporting owners.
- Consumers: staff and leadership audiences defined per report.
- Required access: source systems, reporting surfaces, and the report registry entry for the report family being changed.
Minimum report registry record
Every live report family must capture:
- Name and purpose.
- Owner and backup owner.
- Source systems and extraction method.
- Refresh cadence and last refresh timestamp.
- Access rules and visibility scope.
- Known caveats, validation rules, and failure contact.
BOUSD report families already evidenced
- Attendance visibility via BOUSD-MonthlyAttendance-Dashboard.
- Funding-sensitive attendance and certification support via BOUSD-PADC-Extract.
- Enrollment and class-load planning via the enrollment, class-size, and worksheet members of the extract family.
- Staff-device readiness and refresh work via BOUSD-Staff-Technology-Dashboard and Staff Device Refresh Operations Portal.
- Data-confirmation support via BOUSD-DataConfDocs-Extract.
Operating model
- Intake and definition
- Capture the request, primary audience, and decision it supports.
- Identify the authoritative source systems and whether an existing extract family already covers the need.
- Data contract
- Document fields, filters, business rules, and validation checks.
- Identify the owner and backup owner for the report definition.
- Build and publish
- Implement or reuse extract and transformation steps.
- Publish to the chosen surface and expose freshness clearly.
- Operate and maintain
- Monitor refresh health, schema drift, and access scope.
- Review usage and retire or consolidate stale reports.
Monitoring and observability
- Track last refresh timestamps per report.
- Record failures and retry expectations where tooling supports it.
- Capture usage or support signals when available.
Failure modes and recovery
- Stale or outdated data
- Mitigation: visible freshness indicators and owner escalation.
- Schema drift from source systems
- Mitigation: contract review and owner sign-off before changes.
- Ownership gaps
- Mitigation: require an owner and backup owner before publication or major change.
Security and privacy
- Ensure each report is role-scoped to the minimum appropriate audience.
- Avoid exposing sensitive fields without explicit approval.
- Define export and retention expectations for each report family.
Open items and improvements
- Publish the formal report registry in Atlas.
- Add lightweight health checks for scheduled refreshes.
- Record the live family-to-dashboard mapping for BOUSD reporting extracts.