Project Atlas AetherDev project hub
Atlas project production

MonthlyAttendance Fallback Runbook Scaffold

Runbook scaffold for MonthlyAttendance fallback handling, keeping primary automation and unresolved approval/ownership questions explicit.

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

Purpose

Provide a durable MonthlyAttendance fallback structure without inventing trigger policy or ownership assignments.

Current state

Primary path and fallback boundary are now normalized in Atlas: automated extract updates are standard, and manual SQL/paste remains legacy fallback/reference only.

Next step

Complete unresolved trigger/ownership/approval fields and promote this scaffold into a final incident runbook.

Interfaces

Inputs
  • MonthlyAttendance extract and dashboard pages
  • runtime host and scheduler baseline
Outputs
  • fallback decision scaffold
  • ownership confirmation checklist

Reality to Action trace

Reality Ingestion

Not in scope.

Canonical Storage

Not in scope.

Automation Engines

Not in scope.

Human Interfaces

Not in scope.

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

  • Automated extract path is primary unless declared unavailable.
  • Manual fallback use must be explicit, exception-scoped, and attributable.

Safe handling

  • Do not include credentials, connection strings, or sensitive sheet IDs.

Operational notes

Reliability posture

Primary runtime path is now explicit; this page intentionally keeps fallback trigger and ownership fields open until business/process confirmation is completed.

Observability

  • extract run logs
  • dashboard stale-data symptoms

Security and privacy

Contains internal operational process notes for restricted reporting data; keep internal.

Dependencies

Upstream
  • BOUSD-MonthlyAttendance-Extract
  • BOUSD-MonthlyAttendance-Dashboard
Downstream
  • incident runbook completion

Ownership

Owners

Technology Services, Josh Barton

Users

Technology Services, reporting stakeholders

MonthlyAttendance Fallback Runbook Scaffold

Operating Boundary

  • Primary path: automated MonthlyAttendance extract refresh on sal-01.bousd.us.
  • Fallback path: manual SQL/paste process is legacy fallback/reference only.
  • Fallback use condition: outage/exception conditions, not routine operations.

Unresolved Confirmation Fields

  • Trigger threshold: what failure condition must be met before fallback is allowed.
  • Fallback executor: who performs manual SQL/paste execution.
  • Fallback approver: who authorizes fallback use.
  • Consumer notification owner: who informs dashboard consumers during fallback periods.
  • Automation-resume owner: who verifies and announces return to automated refresh.

Procedure Skeleton (To Be Confirmed)

  1. Detect and validate primary-path failure condition.
  2. Confirm trigger threshold is met.
  3. Obtain fallback approval from designated authority.
  4. Execute manual fallback steps and record timestamp/operator.
  5. Notify dashboard consumers of fallback status and data freshness caveats.
  6. Validate automated path recovery and return control to scheduled refresh.
  7. Publish closure note with incident timeline and follow-up actions.