Project Atlas AetherDev project hub
Atlas project production

Perpetual Data Reports Portal

Turn recurring district report requests into stable, owned, self-service reporting products with visible refresh and ownership discipline.

Internal-only entry. Do not publish externally without review.
Playbook available

Operational guidance is available for this system.

Open playbook
Type
System
Lifecycle
Active
Last touched
2026-03-26
Visibility
Internal

Purpose

Document the operating model that turns recurring data requests into stable, owned reporting products instead of ad hoc pulls.

Current state

The reporting umbrella is active across multiple BOUSD views, and Atlas now has stronger runtime-path evidence for key extract families with host normalization: Linux cron-driven extracts are primarily on `sal-01.bousd.us`, while Windows runner workloads center on `saw-01.bousd.us` (Integr8r). The biggest remaining gap is governance clarity: technical runtime/operator context is increasingly explicit, but business sign-off, delivery ownership, fallback execution, and escalation ownership are still fragmented across report families.

Next step

Use the [Owner, Escalation, and Fallback Matrix](../owner-escalation-and-fallback-matrix/) as the staging layer for report-family role closure, then publish the finalized report inventory with confirmed owner/sign-off/fallback/escalation fields.

Interfaces

Inputs
  • recurring extracts
  • report definitions
  • access-control rules
  • report ownership metadata
Outputs
  • stable report views
  • self-service access surfaces
  • named report inventory

Reality to Action trace

Reality Ingestion

Contributes in this stage.

Canonical Storage

Contributes in this stage.

Automation Engines

Not in scope.

Human Interfaces

Contributes in this stage.

Operational Adoption

Contributes in this stage.

Core workflow

TBD. Document the 5-10 steps that define the core workflow.

Data integrity and contracts

Source of truth rules

  • Upstream source systems remain canonical for report data.
  • The report registry is authoritative for report ownership, cadence, and access rules.
  • Published dashboards mirror the latest available extract state and must display freshness clearly.

Safe handling

  • Restrict each report by role and data sensitivity.
  • Keep extract locations and refresh metadata internal when reports contain restricted data.
  • Require owner and backup owner before publishing a report broadly.

Operational notes

Reliability posture

The umbrella model is active, but the missing formal report registry remains the biggest maintainability and support risk.

Observability

  • per-report refresh timestamps
  • failure counts and exception logs where available
  • consumer-visible stale data symptoms

Security and privacy

Report content varies from internal-only to highly restricted. Access rules, refresh logs, and exports must be scoped per report family.

Dependencies

Upstream
  • Aeries, HR, asset, and other reporting source systems
  • stable extract contracts
Downstream
  • leadership reporting
  • self-service staff access
  • planning workflows

Ownership

Owners

Technology Services, Josh Barton

Users

district leadership, staff data consumers, Technology Services

Perpetual Data Reports Portal

Operating Model

  • This page is the umbrella reporting layer for recurring BOUSD report products, not a single dashboard. The registry now makes that clearer by tying together attendance, PADC, enrollment planning, staff-device readiness, and other repeat-consumption views under one operating model.
  • The portal depends on stable upstream feeds such as the Aeries-to-Google Sheets Reporting Extract Family and on named downstream owners who can answer freshness, access, and definition questions for each live report family.
  • The main Atlas gap is inventory discipline rather than architecture. The Owner, Escalation, and Fallback Matrix now provides the shared structure for runtime owner, business sign-off owner, fallback operator, and escalation owner fields.
  • Runtime normalization baseline for this portal: Linux extract feeds are primarily sal-01 cron workloads; Windows runner-driven reporting feeds are primarily saw-01 Task Scheduler workloads through Integr8r.

Documented BOUSD Report Families

Minimum Report Registry

  • Report family name and business purpose.
  • Owner and backup owner.
  • Source systems and extraction method.
  • Refresh cadence and visible last-refresh indicator.
  • Access rules and visibility scope.
  • Known caveats, validation rules, and failure contact.

Registry Alignment

  • Registry context: former INT-029 and INT-036 are no longer counted as standalone integrations in the BOUSD registry.
  • Registry clarified: this is not just a portal concept. It is the umbrella operating model for recurring district report families, many of which now have stronger production-backed upstream documentation.
  • Validation gaps: current report inventory, owner/backup-owner coverage, exception mapping where runtime is not sal-01/saw-01, and unresolved role fields in the Owner, Escalation, and Fallback Matrix still need human confirmation.

Related playbooks