[Epic][MLOps] Maximize GitHub Student Pack for RunSift engineering and learning

[Dyu20705]

Outcome

Turn GitHub Student Developer Pack into a cost-bounded, production-like MLOps learning and engineering environment around RunSift.

The objective is not to add infrastructure for its own sake. Every claimed benefit or external service must produce one of the following:

1. stronger RunSift engineering evidence (reproducibility, CI/CD, release quality, observability, security, rollback);
2. a reusable MLOps skill demonstrated by code/configuration/runbooks in this repository;
3. reduced local/cloud cost compared with an equivalent paid learning setup.

This issue is an epic / execution plan, not permission to activate every service immediately.

---

Why this belongs in RunSift

RunSift already owns progressive CI quality gates in #15, a reproducible release gate in #35, post-MVP validation in #36, and MLOps relevance/documentation in #16/#21.

The missing layer is a disciplined plan for using student resources to practice the surrounding production lifecycle:

Code / PR
   ↓
GitHub Actions
   ↓
quality + security + deterministic fixtures
   ↓
build package/container
   ↓
GitHub Packages / GHCR
   ↓
staging deployment (only when justified)
   ↓
metrics / traces / errors
   ↓
incident + rollback exercise
   ↓
evidence recorded back in RunSift

This epic must extend existing RunSift contracts, not duplicate or weaken them.

---

Principles / guardrails

• No benefit is activated just because it is free. Activate only when there is a concrete learning or repository objective.
• Verify the current Student Pack offer, quota, eligibility, expiration, and billing behavior immediately before activation; benefits change over time.
• Never assume a free credit means unlimited usage.
• No always-on paid VM, GPU, Kubernetes cluster, database, or observability ingestion without an explicit budget guard.
• Prefer local/open-source equivalents first; use student cloud credits for the parts that cannot be learned realistically offline.
• Do not create CI runs solely to consume quota or demonstrate activity.
• Preserve [CI/CD] Add progressive quality gates for package, static checks, tests, fixtures, and reports #15 concurrency cancellation, least-privilege permissions, deterministic local reproduction, and pinned actions.
• Do not turn optional infrastructure into an MVP dependency.
• Product-facing GitHub integration, ML, metrics, dashboards, or service infrastructure remain subject to [Release] Verify and publish RunSift CLI v0.1.0 MVP #35/[Validation] Evaluate MVP evidence and choose RunSift's next phase #36 activation gates.
• Secrets, private logs, tokens, telemetry, and external storage remain subject to [Security] Implement pre-persistence secret redaction and redaction reporting #33 and [Security] Enforce untrusted-input path, resource, and rendering boundaries #37.
• No unsupported claim such as “production-ready” or “MLOps platform” without measured evidence.

---

Student Pack utilization map

A. GitHub Pro — primary engineering platform

Use GitHub itself as the default control plane before introducing another CI/CD system.

Targets

• Audit repository settings and available student GitHub quotas before changing workflows
• Keep PR checks aligned with [CI/CD] Add progressive quality gates for package, static checks, tests, fixtures, and reports #15
• Add reusable workflows only when duplication exists
• Use workflow concurrency to cancel superseded PR runs
• Cache only safe dependency/build inputs with measurable benefit
• Upload only bounded, sanitized artifacts
• Publish release artifacts from the release workflow rather than ad-hoc local builds
• Use GitHub Environments for staging/production gates if deployment is activated
• Keep workflow permissions least-privilege
• Pin third-party actions to immutable revisions
• Record CI duration and usage budget before/after optimizations

Evidence

• workflow YAML;
• local reproduction commands;
• CI timing/usage comparison;
• release provenance;
• documented rollback path.

---

B. GitHub Packages / GHCR — artifact and container registry practice

RunSift should use GitHub-native artifact distribution before adding a third-party registry.

Targets

• Evaluate whether RunSift needs only wheel/sdist release artifacts or also a container image
• If containerization has a real use case, add a minimal multi-stage Dockerfile
• Build the image from the same tested source revision
• Push versioned images to GHCR only from trusted release/tag workflows
• Add OCI labels: source, revision, version, license
• Generate SBOM/provenance where practical
• Scan dependencies/container before publication
• Define immutable version tags and a deliberately managed convenience tag
• Document pull/run commands
• Define retention/cleanup rules so old artifacts do not consume quota indefinitely

Non-goal

Do not containerize the offline CLI merely to say the project “uses Docker”.

---

C. Codespaces — disposable reproducible development environment

Use Codespaces as a clean-room verification and onboarding environment, not as permanent compute.

Targets

• Add a minimal devcontainer only after local toolchain from [Foundation] Create installable package, source layout, and reproducible toolchain #32 is stable
• Verify a fresh Codespace can install/run the documented development commands
• Keep prebuild/dependency choices small enough to avoid wasting quota
• Stop/delete unused Codespaces
• Use it for clean-environment release reproduction and contributor onboarding tests

Evidence

A reviewer can open a clean environment and reproduce the documented RunSift workflow without hidden machine state.

---

D. LocalStack + OpenTofu/Terraform — cloud/IaC learning without cloud spend

Use local emulation for AWS-style infrastructure exercises before consuming real cloud credit.

Learning lab

OpenTofu/Terraform
       ↓
LocalStack
       ├── object storage experiment
       ├── queue/event experiment
       └── IAM/configuration exercise

Targets

• Keep this lab under an explicitly separated labs/ or infrastructure/labs/ boundary
• Add reproducible up, test, and destroy commands
• Demonstrate idempotent IaC plans
• Add tests for expected resources/configuration where practical
• Ensure no real AWS endpoint or credential is required for the default lab
• Document differences between emulator behavior and real cloud behavior

Non-goal

Do not make AWS emulation a RunSift runtime dependency.

---

E. Azure student credit — real cloud deployment exercise

Treat cloud credit as a scarce experiment budget, not a permanent hosting plan.

Activation gate

Do not spend Azure credit until:

• [Release] Verify and publish RunSift CLI v0.1.0 MVP #35 has produced a reproducible release; and
• there is a concrete deployment/operations learning objective; and
• a local/container version already works; and
• budget alerts and teardown instructions exist.

Product-facing deployment must also respect #36.

Candidate exercise

GitHub Actions
      ↓
GHCR / cloud registry
      ↓
small staging service/job
      ↓
health check
      ↓
observability
      ↓
rollback
      ↓
destroy infrastructure

Targets

• Use the smallest suitable managed/serverless compute option
• Use IaC where it improves reproducibility
• Configure spending/budget alerts before deployment
• Record expected maximum experiment cost
• Prefer scale-to-zero / ephemeral resources where possible
• Test rollback to previous artifact/version
• Destroy unused resources after the exercise
• Record actual spend and lessons learned

---

F. Heroku or equivalent student deployment benefit — long-lived lightweight demo only if justified

Use a student deployment benefit only if RunSift gains a legitimate service/demo surface after validation.

Targets

• Verify current Student Pack eligibility and recurring credit before use
• Prefer this for a small portfolio/demo service rather than expensive cloud infrastructure
• Keep the core CLI usable without the service
• Add /health and version/build metadata if a service exists
• Define deployment and rollback commands
• Prevent secrets from being logged or exposed

Activation gate

Blocked unless #36 selects a direction that actually needs a running service or a separately documented learning lab is used.

---

G. Datadog — production observability learning

Use the student observability benefit to learn real metrics/logs/traces only after there is something meaningful to observe.

Candidate signals

• process/service health;
• request/job latency;
• execution counts;
• error counts;
• release/version identity;
• resource usage;
• bounded RunSift domain metrics only when [Validation] Evaluate MVP evidence and choose RunSift's next phase #36 justifies them.

Targets

• Define an operator action for every alert
• Prevent high-cardinality labels/tags
• Apply log redaction before external ingestion
• Set ingestion limits/retention awareness
• Create one minimal dashboard from real signals
• Create one actionable alert
• Run one controlled failure exercise and verify the signal
• Document what Datadog adds beyond local logs/tests

Constraint

#26 remains authoritative for any Prometheus-compatible RunSift product output; this section is an external observability learning/integration exercise, not permission to bypass #19/#36.

---

H. Sentry — exception and release diagnostics

If a deployed service exists, use the student benefit for application error tracking.

Targets

• Attach release/version metadata to errors
• Verify secret and PII scrubbing
• Capture a controlled test exception
• Confirm stack trace maps to the correct release
• Document triage → fix → release workflow
• Avoid duplicate noisy reporting already handled adequately elsewhere

---

I. MongoDB Atlas or other student data benefit — optional metadata lab

Do not add a database to the RunSift product merely because credits exist.

Possible learning use:

• versioned run metadata experiment;
• structured experiment metadata;
• retention/deletion exercise;
• query/index benchmarking on synthetic/sanitized data.

Activation gate

• A database use case is documented first
• Local equivalent is tested first
• Data classification/retention rules are defined
• No raw private CI log or secret is uploaded
• Teardown/export path exists

---

J. Deepnote / Camber / student compute — bounded experimentation

Use temporary compute for notebooks, data experiments, or CPU-heavy learning jobs that are inappropriate for CI.

Targets

• Never make hosted notebook state authoritative
• Move reusable code into version-controlled Python modules
• Record environment/dependency versions
• Export only sanitized/reproducible outputs
• Do not use CI minutes as a free training cluster
• Prefer student compute before spending general-purpose cloud credit when the workload fits

---

K. Student learning subscriptions — schedule activation, do not redeem simultaneously

Benefits with short validity windows should be activated just-in-time.

Learning sequence

1. software/backend/Linux fundamentals if needed;
2. data/ML engineering;
3. distributed systems/cloud/system design;
4. immediately apply each module to RunSift or a versioned lab artifact.

Rule

No course counts as progress without one of:

• merged code/configuration;
• reproducible lab;
• ADR/design note;
• benchmark;
• test suite;
• incident/rollback exercise;
• documented technical decision.

---

Suggested execution phases

Phase 0 — Inventory and budget ledger

• Record currently available Student Pack benefits and expiry dates
• Record quotas/credits and whether unused credit expires
• Record whether billing can continue after credit exhaustion
• Create a simple docs/student-pack-ledger.md or equivalent
• Assign each benefit one concrete RunSift/MLOps learning objective
• Reject benefits with no objective

Exit criterion: every activated benefit has an owner, purpose, quota, expiry, and teardown strategy.

---

Phase 1 — GitHub-native CI + packaging

Depends primarily on #32 and #15.

• Optimize existing GitHub Actions rather than replacing them
• Verify clean package builds
• Establish release artifact provenance
• Measure CI consumption before/after cache/concurrency changes
• Evaluate GHCR/container need

Exit criterion: RunSift has reproducible local/CI commands and bounded CI usage.

---

Phase 2 — Reproducible MLOps/IaC labs

• Add a clearly isolated LocalStack/OpenTofu lab
• Exercise plan/apply/test/destroy
• Add clean-environment verification with Codespaces where useful
• Keep labs optional and non-blocking for RunSift users

Exit criterion: a reviewer can reproduce the lab without paid cloud resources.

---

Phase 3 — Release engineering

Blocked by the actual completion criteria of #35.

• Produce release artifact(s)
• Add security/provenance metadata where justified
• Exercise install/upgrade/rollback paths
• Record release evidence for [Docs] Publish reproducible quickstart, architecture, examples, limitations, and MLOps case study #16/[Epic] Portfolio Polish and Demo #21

Exit criterion: release behavior is reproducible from source revision to published artifact.

---

Phase 4 — Real cloud + observability exercise

Only after a justified use case exists.

• Deploy the smallest viable staging workload
• Add Datadog/Sentry only for real signals
• Inject one controlled failure
• detect → diagnose → remediate → redeploy → rollback if necessary
• destroy resources when exercise completes unless a validated long-lived use case exists

Exit criterion: the repository contains an evidence-backed operations case study, not screenshots of unused dashboards.

---

Phase 5 — Post-MVP MLOps expansion

Blocked by #36 for product-facing changes.

Possible directions only if evidence supports them:

• model/heuristic experiment tracking;
• versioned evaluation datasets;
• data/model lineage;
• drift or reliability analysis;
• scheduled evaluation;
• service deployment;
• production metrics.

Do not pre-commit to MLflow, feature stores, Kubeflow, Airflow, Kubernetes, or other platforms until the problem requires them.

---

Cost and quota safety policy

Maintain a lightweight ledger:

Resource	Purpose	Free quota/credit	Soft limit	Hard action	Expiry	Teardown
GitHub Actions	CI	VERIFY CURRENT	project budget	cancel/skip nonessential jobs	VERIFY	n/a
GHCR/Packages	artifacts	VERIFY CURRENT	retention target	delete superseded artifacts	VERIFY	cleanup workflow/manual
Codespaces	clean env	VERIFY CURRENT	per-session limit	stop/delete	VERIFY	delete environment
Azure	cloud lab	VERIFY CURRENT	experiment budget	destroy resources	VERIFY	destroy/portal check
Datadog	observability	VERIFY CURRENT	ingestion budget	disable excess sources	VERIFY	remove integration
Sentry	errors	VERIFY CURRENT	event budget	sampling/disable	VERIFY	remove DSN/integration
Other Pack benefit	explicit objective	VERIFY CURRENT	explicit	stop	VERIFY	documented

VERIFY CURRENT is intentional: do not freeze rapidly changing Student Pack quotas into project assumptions.

---

CI anti-spam / fair-use rules

• PR workflows use concurrency cancellation where safe
• Expensive jobs have path/event filters
• Scheduled workflows exist only with a documented operational reason
• No schedule more frequent than required by the actual signal being measured
• No artificial commits/reruns to consume benefits
• No matrix explosion solely for portfolio appearance
• Full cross-version/release matrices run at appropriate gates rather than every trivial edit when equivalent safety can be preserved
• Cache hit rate and CI duration are measured before adding complex caching
• Training/benchmark workloads do not run on every PR
• Manual dispatch for costly experiments requires explicit parameters and bounded defaults

---

Security requirements

• OIDC/short-lived credentials preferred over long-lived cloud keys when supported
• Never commit student-service tokens, DSNs, cloud credentials, or billing identifiers
• Environment-specific secrets live in GitHub Environments/secrets or equivalent secret stores
• External telemetry receives only data allowed by [Security] Implement pre-persistence secret redaction and redaction reporting #33/[Security] Enforce untrusted-input path, resource, and rendering boundaries #37
• Fork PRs cannot access privileged deployment secrets
• Deployment workflows have minimum required permissions
• Dependency and container provenance are reviewable
• Teardown removes credentials/integrations no longer needed

---

Learning evidence / portfolio outputs

By the end of this epic, the project should be able to demonstrate the following with artifacts rather than claims:

• reproducible Python packaging;
• deterministic CI gates;
• GitHub Actions optimization and quota discipline;
• package/container registry lifecycle;
• supply-chain/security basics;
• IaC plan/apply/destroy lifecycle;
• clean-environment reproducibility;
• cloud deployment with explicit budget controls;
• metrics/logs/traces/error diagnostics;
• controlled incident and rollback exercise;
• cost/quota ledger;
• ADRs explaining rejected over-engineering choices.

---

Definition of Done

• Current Student Pack benefits have been inventoried and time-sensitive details verified at activation time
• Activated benefits each have a concrete technical objective and evidence artifact
• [CI/CD] Add progressive quality gates for package, static checks, tests, fixtures, and reports #15 remains the source of truth for RunSift CI quality gates
• [Release] Verify and publish RunSift CLI v0.1.0 MVP #35 remains the source of truth for MVP release readiness
• [Validation] Evaluate MVP evidence and choose RunSift's next phase #36 remains the activation gate for post-MVP product/platform expansion
• [Security] Implement pre-persistence secret redaction and redaction reporting #33/[Security] Enforce untrusted-input path, resource, and rendering boundaries #37 security boundaries apply to every external integration
• CI usage is measured and bounded; no spammy workflows are introduced
• Cloud resources have budget limits and teardown procedures
• At least one complete build → release/deploy → observe → failure → diagnose → rollback/repair exercise is documented if a deployment is justified
• Optional labs remain optional and do not increase RunSift's core runtime requirements
• No short-lived student benefit is wasted through premature activation without a learning schedule
• README/case-study claims distinguish implemented, measured, planned, and hypothetical capabilities

---

Explicit non-goals

• adopting every Student Pack service;
• running paid infrastructure continuously because credits exist;
• adding Kubernetes, Airflow, Kubeflow, MLflow, a database, or a service without a demonstrated requirement;
• bypassing [Validation] Evaluate MVP evidence and choose RunSift's next phase #36 to make RunSift a cloud/ML platform prematurely;
• replacing deterministic fixture-based CI with live external-service tests;
• storing private/raw CI data in third-party student services;
• optimizing for dashboard screenshots rather than engineering evidence;
• maximizing quota consumption. The target is maximum learning and engineering value per unit of free quota/credit.

---

Related issues

• [CI/CD] Add progressive quality gates for package, static checks, tests, fixtures, and reports #15 — progressive CI/CD quality gates
• [Docs] Publish reproducible quickstart, architecture, examples, limitations, and MLOps case study #16 — reproducible documentation and MLOps case study
• [Epic] Portfolio Polish and Demo #21 — portfolio polish/demo
• [Observability] Add optional Prometheus-compatible metrics output #26 — optional Prometheus-compatible output (post-validation scope)
• [Foundation] Create installable package, source layout, and reproducible toolchain #32 — reproducible package/toolchain foundation
• [Security] Implement pre-persistence secret redaction and redaction reporting #33 — secret redaction
• [Release] Verify and publish RunSift CLI v0.1.0 MVP #35 — v0.1.0 release gate
• [Validation] Evaluate MVP evidence and choose RunSift's next phase #36 — post-MVP evidence/next-phase decision
• [Security] Enforce untrusted-input path, resource, and rendering boundaries #37 — untrusted-input/resource/rendering security boundaries