Related Atlas entry
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.
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.
Audience and access
- Primary operators: data services and IT reporting owners.
- Consumers: staff and leadership audiences defined per report.
- Required access: source systems (Aeries/HR/Asset systems), reporting surfaces (Sheets, dashboards, Sites).
Report lifecycle (standard operating model)
- Intake and definition
- Capture the request, primary user group, and decision it supports.
- Define the authoritative data source and the refresh cadence.
- Data contract
- Document fields, filters, and business rules.
- Identify owner and approver for the report definition.
- Build and publish
- Implement extract and transformation steps.
- Publish to the chosen surface (dashboard, sheet, or portal).
- Operate and maintain
- Monitor refresh health and data integrity.
- Review usage and adjust scope when needed.
- Deprecate or evolve
- Retire reports that are no longer needed.
- Promote high-use reports into more durable systems.
Patterns in use
Report registry requirements (next-step focus)
Each report must be registered with:
- 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 and validation rules.
Inputs
- SQL extracts or API pulls.
- Business definitions and metric rules.
- Access control lists.
Outputs
- Stable dashboards or report views.
- Self-service access for staff.
- Reduced manual report requests.
Validation checklist
- Data accuracy confirmed against source of truth.
- Refresh cadence is met and visible to users.
- Ownership and support contacts are documented.
- Access scope matches privacy requirements.
Monitoring and observability
- Track last refresh timestamps per report.
- Record failure counts and retry attempts (TBD tooling).
- Capture usage metrics when available.
Failure modes and recovery
- Stale or outdated data
- Mitigation: visible refresh timestamps and alerting (TBD).
- Schema drift from source systems
- Mitigation: schema validation and owner review.
- Report ownership gaps
- Mitigation: require an owner and backup before publication.
Security and privacy
- Ensure only appropriate audiences can access each report.
- Avoid exposing sensitive fields without explicit approval.
- Define data retention and export restrictions (TBD).
Change management
- Log definition changes and update the registry.
- Communicate updates to report consumers.
- Archive deprecated reports with a clear deprecation notice.
Open items and improvements
- Build the formal report registry and publish it in the Atlas.
- Decide on a standard dashboard surface for flagship reports.
- Add lightweight health checks for scheduled refreshes.