Atlas project production

BOUSD-PADC-Extract

Refresh principal apportionment attendance support data from Aeries into Google Sheets for certification, revision, and funding-sensitive review workflows.

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

Purpose

Keep principal apportionment attendance certification work supplied with current Aeries-derived support data on a frequent daytime cadence.

Current state

Implementation details are explicit in repo evidence: `run.sh` executes four attendance query configs (`config-reg-elementary.toml`, `config-reg-secondary.toml`, `config-is-longterm.toml`, `config-nps.toml`), merges outputs into `data/result-attendance.csv`, runs `config-calendar.toml` into `data/result-calendar.csv`, and overwrites `SourceData_YTD!A2:ZZ10000` and `SourceData_DAY!A2:ZZ10000`. `aether/docs/cron-example.txt` documents a 30-minute daytime schedule from `/home/bousdtech/repos/BOUSD-PADC-Extract/run.sh`, and host normalization maps this cron runtime primarily to `sal-01.bousd.us`.

Next step

Resolve certification-window governance through the [Owner, Escalation, and Fallback Matrix](../owner-escalation-and-fallback-matrix/): confirm technical operator, business sign-off owner, fallback operator, escalation owner, and backup coverage.

Interfaces

Inputs
  • SQL query files
  • TOML configuration
  • ODBC connection settings
  • Google service-account access
Outputs
  • SourceData_YTD and SourceData_DAY tabs
  • data/result-attendance.csv and data/result-calendar.csv
  • attendance/certification support data

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

  • Aeries is canonical for the extracted data.
  • Destination sheets are operational distribution surfaces and should not become the authoring system.

Safe handling

  • Restrict service-account keys and ODBC credentials to approved operators.
  • Treat CSV artifacts and destination tabs as restricted operational data.
  • Document host ownership and recovery steps in an internal runbook.

Operational notes

Reliability posture

The runtime is deterministic (`run.sh` + fixed query config set + explicit merge step) with scheduler-path evidence in `aether/docs/cron-example.txt`. Host normalization now places this workload on `sal-01.bousd.us` as part of the Linux cron extract family. The repo does not include native mailer/notification logic, so certification-period escalation still depends on external operational controls.

Observability

  • stdout/stderr from run.sh and bundled CLI tools
  • CSV artifacts in data/ and temp/ (`result-attendance.csv`, `result-calendar.csv`, intermediate query outputs)
  • stale or missing downstream sheet tabs

Security and privacy

These jobs move restricted operational data from Aeries into Google Sheets. Keep service-account keys, credentials, logs, and CSV artifacts private.

Dependencies

Upstream
  • Aeries SQL access
  • ODBC driver stability
  • service-account sharing
  • scheduler ownership
Downstream
  • PADC certification and revision workflows
  • attendance reporting review

Ownership

Owners

Technology Services, Josh Barton

Users

Technology Services, district reporting stakeholders

BOUSD-PADC-Extract

Operational Notes

  • Implementation pattern: run.sh wrapper, conf.d/ configuration, SQL-over-ODBC extraction, local CSV artifacts, and controlled Google Sheets range overwrites.
  • Query inventory is now concrete: four attendance-scope configs plus one calendar config feed the two destination tabs.
  • Scheduled cadence: Every 30 minutes between 07:00 and 18:00; repo evidence uses */30 7-18 * * * /home/bousdtech/repos/BOUSD-PADC-Extract/run.sh.
  • Runtime host context: Linux cron execution is now normalized to sal-01.bousd.us for this extract family.
  • Upload contracts in code: SourceData_YTD!A2:ZZ10000 (attendance merge) and SourceData_DAY!A2:ZZ10000 (calendar).
  • Alerting note: script logic is extraction/merge/upload only; no in-repo email or paging path is documented here.
  • Ownership boundary: technical runtime/operator evidence is strong (sal-01 cron execution and sheet-write contract), but certification acceptance/sign-off authority is a business-process control not represented in repo or scheduler artifacts.
  • Governance note: unresolved ownership/escalation/fallback roles are tracked in the Owner, Escalation, and Fallback Matrix.
  • Shared family risks include sheet header drift, secret sprawl, owner/escalation coverage gaps, and weak centralized monitoring.

Registry Alignment

  • Mapped registry entry: INT-027; adjacent business context is now documented under INT-025.
  • Registry context: this feed also belongs to the Aeries-to-Google Sheets reporting extract family, which Atlas keeps as operational family context rather than as a standalone BOUSD integration.
  • Registry clarified: this job is mission-critical district reporting infrastructure with a frequent weekday cadence and downstream certification significance.
  • Validation gaps: report-source query inventory, scheduler path, and primary host context (sal-01) are now explicit; unresolved sign-off, fallback, and escalation fields remain tracked in the Owner, Escalation, and Fallback Matrix.