Reliable computing for teaching
Discussion draft · no award, staffing or budget approved

Use ACCESS for the large CPU and GPU allocation and the classroom pilot. Use campus UITS/AWS only to test CPU components, and free GPU resources to benchmark workloads before piloting. Size the ACCESS request from measured demand; consider CloudBank through ACCESS only if its managed service can meet the confirmed requirements.

COURSE CONCEPTS

Data science
Build a reproducible data-cleaning and exploratory-analysis notebook, then fit a small CPU model with held-out validation. Explain missingness, leakage, uncertainty and data provenance.
Generate a synthetic civic-service dataset with no real residents; keep core CSV inputs below 250 MB and test peak memory against the awarded workspace. Real/public datasets require a rights and data-classification check.
Requested: Python, JupyterLab, pandas, scikit-learn, matplotlib and an approved reproducible package manifest; R/RStudio only if the course requires it.
Acceptance: Run the whole assignment from a fresh student workspace; require execution without out-of-memory errors at the approved spec, reproducible key outputs and a complete exported submission.
Optional: GPU model training/evaluation can enter the ACCESS pilot after free-resource benchmarking and reproduction on the allocated GPU system, with a CPU-equivalent assessed route. Free notebooks are benchmark tools, not promised semester GPU capacity.

MLIS / Library and information science
Audit a collection catalog, normalize names/dates/identifiers, document a metadata crosswalk, query an embedded catalog database and export a preservation-ready package with README, schema, provenance and checksums.
Use a synthetic 10,000–100,000-record collection catalog with Dublin Core-style fields. Add public/licensed records only after rights review; exclude patron, circulation, donor and restricted collection records.
Requested: JupyterLab/Python, CSV/JSON/XML parsing and embedded SQLite; optional MARC parsing packages after approval. OpenRefine or other hosted applications require a separate provider fit check.
Acceptance: Execute the complete workflow in a fresh workspace; validate schema, record counts, identifiers and query results; reopen the exported package using the fallback environment.
Optional: MESA/CyVerse can demonstrate a data/workflow component after per-user Pro/TRIF, app, save/exit and export checks. It does not add quota or become a required dependency of this pilot.

PHASES

Before piloting · preparation weeks 1–2 | Test components and benchmark GPUs
Use already-authorized campus UITS/AWS CPU component tests and free Kaggle/Colab GPU notebooks. Pin synthetic inputs, run bounded measurements and retain correctness/export/failure evidence before any student canary. Greg’s total work, including grant preparation, is capped at four hours/week; no cash, purchases or new paid accounts are available.
Exit evidence: Reproducible CPU/GPU component results and a workload envelope, within available time. Local functional checks do not replace AWS/CUDA provider measurements.

After benchmarks · before canary | Submit a sized ACCESS CPU + GPU request
Use benchmark measurements and course demand to justify the large CPU/GPU allocation, storage, concurrency and resource exchanges. Disclose campus AWS test access. Select the appropriate ACCESS tier and approved educational project structure. Check CloudBank only as a managed alternative if capacity and scope fit; provider review may extend preparation.
Exit evidence: Complete PI/course/term attachments and approved CPU/GPU resource configuration; request submission and award remain human/provider actions.

After award · preparation weeks 3–4 | Run a ten-person component canary
After approved access, recruit up to ten consenting volunteers, five per course concept. Run one DS notebook and one metadata/database/export workflow with synthetic inputs. Measure setup, package/memory fit, save/restart/export and support effort. No real grades or private library data are needed.
Exit evidence: Both workflows succeed; actual service limits and unresolved defects are recorded. Stop or revise if core fit fails.

After canary · preparation weeks 5–6 | Rehearse the whole class and recovery
With provider approval, rehearse 80 student workspaces plus agreed staff use. Test account isolation, grading receipts, accessible instructions, independent restore and the CPU fallback. Update the usage and effort forecast from observed runs and actual weekly hours. Keep Greg’s total within four hours; TA/lead support is separate.
Exit evidence: All thirteen applicable checks have evidence, term support and any needed grant-funded costs confirmed; otherwise narrow or defer the classroom scope.

Weeks 1–15 | Teach the two-course pilot
Teach on the awarded ACCESS CPU/GPU environment after readiness sign-off. Review quotas, queue/session behavior, usage, storage, tickets and backups weekly. GPU activities use the benchmarked workload and a CPU-equivalent assessed route; MESA/OSPool extensions have separate checks. Campus AWS remains a component-testing route. Do not admit a course with unfunded necessary expenses or missing backup/support coverage.
Exit evidence: Record aggregate completion/access outcomes and actual costs; pause a failing component without removing the CPU course route.

Term end + two weeks | Export, close and decide
Provide learner exports and reconcile grades before closure. Preserve approved public outputs with suitable metadata; apply the institutional retention/deletion schedule to private records. Do not assume educational allocation extension. Decide whether next term needs a new project or confirmed renewal.
Exit evidence: Verified exports, measured restore, closed accounts, final report and a costed continuation decision.

HOURS AND GRANT DEPENDENCIES
Hours only. Greg has four hours/week total across this work and EduCloud. Over the illustrative six preparation + fifteen teaching + two close weeks, 92 hours is an upper bound, not reserved project time. The earlier role estimates still total 230 hours, a 138-hour gap before other commitments. They are unrevised demand estimates, not a feasible four-hour plan or committed staffing. Narrow the work or confirm distinct support before proceeding. No salary math, cash envelope or finance role.
Allocation and coordination (Greg): 22.0 potential hours over the modeled period. ACCESS request, provider scope, course dates and demand review.
Benchmark and component work (Greg): 34.0 potential hours over the modeled period. CPU/GPU runs, package/environment checks and reproducible result review.
Service operations (Greg): 78 potential hours over the modeled period. Accounts, monitoring, backups, export and issue triage; hours must be measured.
Instructional design and accessibility (Greg): 14.5 potential hours over the modeled period. Accessible instructions and equivalent CPU activities; institutional approval is separate.
Data, rights and recovery review (Greg): 25 potential hours over the modeled period. Coordinate rights/privacy destinations, recovery rehearsal and closeout; no authority to self-approve institutional requirements.
EduCloud grant preparation (Greg): 23 potential hours over the modeled period. Distinct stewardship/training/evaluation work packages; no grant submission or award implied.
Planning and incident buffer (Greg): 33.5 potential hours over the modeled period. Earlier incident/planning demand estimate; reduce scope or confirm distinct support when the four-hour envelope is exceeded.
Two course support TAs (Not appointed; grant-supported if funded): 102 potential hours over the modeled period. Per TA: 4 prep + 3/week × 15 + 2 close = 51 hours. Outside Greg’s four hours. No salary/rate assumed.
Two course leads (Course leads; named commitments pending): 70 potential hours over the modeled period. Per lead: 16 prep + 1/week × 15 + 4 close = 35 additional pilot hours. Outside Greg’s four hours. No salary requested; regular teaching/grading excluded.
Available cash budget is zero. Work needing paid support, storage, hosting, development or recovery must have a confirmed eligible EduCloud grant and allowable work package before spending. ACCESS is CPU/GPU resource allocation, not payroll. No grant award is asserted. Existing campus test access and free GPU resources must stay within their authorized no-purchase scope.
The earlier 230-hour demand exceeds the 92-hour upper bound by 138 hours across the modeled 23 weeks. Greg cannot be his own independent backup. The earlier separate backup estimate is 27 hours; no distinct person is committed. TA/course-lead hours are separate and unconfirmed. Institutional privacy/accessibility approval remains separate from Greg’s coordination.

PRE-CLASS READINESS (ALL PLANNED / NOT RUN)

scope | Greg + course leads | Before request
Confirm eligible PI, actual courses/leads, Greg’s four-hour/week total envelope, separate TA/lead hours, distinct backup and full-term coverage. No cash budget; fund any necessary expenses only from a confirmed eligible grant.
Evidence: Named owners, realistic hours log, separate support commitments and confirmed grant/allowable-cost evidence if paid resources are needed.
Stop if: Counting four hours per role, assuming grant award, missing backup, or unfunded necessary spending.

benchmark | Greg (operator) + course leads | Before student canary / request sizing
Complete campus AWS CPU component tests and free-resource GPU benchmarks; retain failures, correctness, measured memory/runtime, checkpoint/export results and workload scope. Reproduce representative GPU work on awarded ACCESS hardware before class.
Evidence: Versioned workload/environment manifest, dataset checksums, dated result rows, actual GPU/account limits and target-resource comparison. No measurements recorded yet.
Stop if: Unmeasured GPU amounts, treating free quota as guaranteed classroom capacity, or assuming benchmark timings transfer unchanged to ACCESS.

provider | Allocation lead + selected ACCESS provider | Before request / gate to class
Confirm ACCESS CPU/GPU allocation, separate resource exchanges, actual quotas/storage, course dates and project structure; campus AWS stays test-only. If CloudBank is selected, confirm service type, CPU/GPU availability and accounting.
Evidence: Provider response and approved award/resource configuration, recorded privately.
Stop if: Assuming unspecified limits, general broker terms or automatic renewal.

accounts | Operator + course leads | Canary; repeat before week 1
Every approved student/staff test account authenticates; student A cannot read/write student B files or instructor grading areas; removal/revocation works.
Evidence: Access matrix and dated test results; no passwords or roster identifiers in public reports.
Stop if: Access leakage, shared credentials or unverified removal.

software | Each course lead | Canary
Both complete representative assignments run on the approved CPU image from fresh workspaces; no paid account or GPU is required. Pin the approved environment and input checksums.
Evidence: Clean-run outputs, environment manifest, resource measurements and a known-good baseline.
Stop if: Missing packages, memory failure, unapproved app or required GPU dependency.

capacity | Operator + provider | 2–4 weeks before term
With provider permission, rehearse 80 simultaneous students plus agreed staff use in three representative sessions. Proposed p95 login-to-workspace ≤5 minutes; no unresolved assignment-blocking launch failure.
Evidence: Dated latency distribution, workspace success count, quota/usage forecast and provider-agreed concurrency.
Stop if: No permission/capacity evidence; peak spec exceeds awarded limits.

save | Course leads + TAs | Canary; repeat after image update
Edit, save, stop/restart and recover a notebook/data package; verify filesystem location and retention. Export and re-import it into the CPU fallback.
Evidence: Saved-file checksums, restart/export receipt and fresh-environment reopen.
Stop if: Student work depends on an unsaved session or cannot be exported.

grades | Course leads | Before graded use
Distribute a versioned assignment, collect it, reconcile all test submissions, preserve student authorship and instructor judgment, and import/export a test grade receipt through the approved LMS workflow. If Classroom 50 is selected, verify Team/Enterprise organization eligibility, permissions, billing controls and an independent export; Codespaces and Actions quotas remain separate.
Evidence: Submission manifest and grade reconciliation results in the approved institutional destination. Classroom 50 canary and quota/fallback records if selected; no additional Codespaces allocation assumed.
Stop if: A leaderboard/auto-score substitutes for the authoritative grade, or a missing receipt goes undetected.

data | IT/privacy reviewer + Libraries | Before student data
Approve provider and backup data destinations, lawful/appropriate datasets, access roles and retention. Keep grades/rosters in the approved LMS/institutional systems; publish only aggregate results.
Evidence: Approved data map, rights notes, retention schedule and service/accessibility review.
Stop if: Assuming research storage or this public site is approved for private student records.

accessibility | Greg (design coordination) + course leads | Before course admission
Rehearse keyboard and screen-reader access, readable instructions and equivalent small-data CPU/offline activity; resolve barriers in essential workflows.
Evidence: User/task review and course-lead sign-off, with accommodations and fallback instructions.
Stop if: An essential assessed activity is inaccessible without an equivalent route.

recovery | Primary + backup operators | Before course admission
Make independent copies in approved destinations and restore onto a different host/environment. Proposed RPO ≤24 hours and RTO ≤one business day; measure both.
Evidence: Restore logs, independent file checksums, recovery timing and backup-operator runbook rehearsal.
Stop if: No independent copy or unmeasured recovery; relying only on snapshots or cold archival retrieval.

support | Owner + TAs + operators | Before week 1; weekly
Publish actual staffed help windows and escalation route; rehearse an outage with CPU/small-data fallback. Proposed first response within one staffed business day; do not promise 24/7 support. Keep actual Greg hours within four/week across all duties; reduce scope when demand exceeds coverage.
Evidence: Coverage schedule, ticket routing, outage exercise and fallback delivery proof.
Stop if: Unfunded coverage, unreachable operator or missed class deadline without substitution.

exit | Service owner + course leads + Libraries | Before start; execute near term end
Schedule alerts 60/30/14/7 days before expiry; decide continuation at least 30 days before. Rehearse learner/grade export, retention and deletion; verify closure on the approved dates.
Evidence: End-of-term runbook, sample exports, provider confirmation of exit window and deletion/renewal decision.
Stop if: Relying on grace periods, unconfirmed education extension or archival deposits of private coursework.

EVALUATION
Access: login/spawn success and latency, plus interruptions that blocked coursework.
Teaching: clean-run assignment success, reproducible outputs, export/grade-receipt completeness and completion barriers.
Operations: actual staff-hours, ticket categories, service/storage consumption, recovery timings and cash charges.
Continuity: working CPU fallback, independent restore, learner exports and verified end-of-term closure.
Decision: compare results with the approved gates and local alternatives before adding courses or optional GPUs; improvement in educational outcomes is a question to evaluate, not a finding.