Project Atlas AetherDev project hub
Atlas project production

BOUSD-Staff-Technology-Dashboard

Provide Technology Services with a planning dashboard for staff-device readiness, replacement tiers, rollout prioritization, and migration-support segmentation.

Internal-only entry. Do not publish externally without review.
Type
System
Lifecycle
Active
Last touched
2026-03-26
Visibility
Internal

Purpose

Give Technology Services a current planning surface for refresh eligibility, replacement tiers, and staff-device readiness.

Current state

The registry now places this dashboard in a concrete production operating model with scheduled refresh evidence: `run.sh` executes every 15 minutes between 06:00 and 23:00, and the dashboard sits alongside the technician-facing refresh portal as the candidate-identification and readiness-confirmation layer.

Next step

Version the canonical staff/device extract contract, document source-of-truth precedence, and publish direct-swap vs migration-support segmentation rules used by operators during rollout waves.

Interfaces

Inputs
  • staff and device extracts
  • role-tier mapping tabs
  • model-mapping tabs
  • user access rules
Outputs
  • dashboard views
  • replacement planning views
  • refresh-readiness summaries

Reality to Action trace

Reality Ingestion

Contributes in this stage.

Canonical Storage

Not in scope.

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

  • The staff and device extracts are canonical for dashboard inputs.
  • Mapping tabs are authoritative for tier and model interpretation.
  • The dashboard is a planning surface and should not silently override source extract data.

Safe handling

  • Restrict sheet and Apps Script access by role.
  • Treat staff-device assignment data as internal operational data.
  • Document current extract ownership and recovery paths internally.

Operational notes

Reliability posture

The dashboard is active and useful, but depends on stable extract contracts and consistent mapping-tab governance.

Observability

  • Apps Script logs
  • sheet refresh timestamps
  • visible stale-data symptoms in dashboard views

Security and privacy

Staff-device assignment and planning data are internal operational records and should remain visible only to approved district staff.

Dependencies

Upstream
  • Aeries Staff Extract SQL Generator
  • device inventory feeds
  • sheet header stability
Downstream
  • Device Refresh Ops Portal
  • refresh campaign planning

Ownership

Owners

Technology Services, Josh Barton

Users

Technology Services, IT leadership

BOUSD-Staff-Technology-Dashboard

Operational Notes

  • This is the leadership and planning surface paired with the technician-facing Staff Device Refresh Operations Portal. The registry now makes that pairing clearer and ties both pages to a shared scheduled extract model.
  • Registry-backed cron evidence points to a 15-minute refresh cadence between 06:00 and 23:00 for the dashboard’s run.sh layer. That is a meaningful shift from older, more manual assumptions about refresh behavior.
  • Operational role in INT-032 workflow: identify upgrade candidates, confirm readiness, and separate users who can complete direct device swaps from users who require migration support.
  • The next maintainability step is not more UI description. It is a versioned extract contract: which staff and device fields are guaranteed, what source system wins when values disagree, and which downstream pages may treat status fields as execution data.

Registry Alignment

  • Mapped registry entry: INT-032.
  • Registry clarified: this is a production planning surface with scheduled refresh behavior and a defined relationship to the technician portal.
  • Validation gaps: live extract contract ownership, source precedence, and write-back expectations still need clearer documentation.