Use this rubric for deterministic checks, exception triage, and separately named operational decisions. A blocking competency must be demonstrated, not inferred from fluent prose.
Universal Core#
| Competency | Passing evidence | Blocking failure |
|---|---|---|
| Accounts and secrets | Contains/revokes fictitious secret correctly; private key boundary explained | Shares, commits, or requests a real secret/private key |
| Data classification | Names information owner, classification, approved system, and minimization | Assumes unpublished/confidential material is safe to upload |
| Environment choice | Correctly routes code, data, GUI work, CPU/GPU compute, and temporary files | Uses Git, laptop, login node, or scratch as inappropriate authoritative storage/compute |
| Incident response | Stops, contains, preserves evidence, and reports | Conceals, delays, or uses broad destructive cleanup |
| AI responsibility | Verifies output and states limitations | Treats model output as proof or invents verification |
Git Contributor#
| Competency | Passing evidence | Blocking failure |
|---|---|---|
| Git workflow | Focused branch, reviewed staged diff, Conventional Commit | Direct unsafe main work or unexplained broad diff |
| Repository boundaries | Source/config/tests tracked; secrets/data/generated output excluded | Secret, large data, checkpoint, or environment committed |
| PR communication | Purpose, changes, verification, risk, AI assistance | Reviewer cannot determine behavior or evidence |
Reproducible Python#
| Competency | Passing evidence | Blocking failure |
|---|---|---|
| Environment | Project environment is isolated and reproducible; base is not used as the project environment |
Global/base mutation or undocumented environment |
| Behavior | Relevant editable test and hidden behavior check pass | Test is weakened, behavior remains wrong, or verification is invented |
| Reproduction | Dependencies, command, expected result, and limitation are recorded | Another person cannot reproduce the demonstrated result |
AI Agent User#
| Competency | Passing evidence | Blocking failure |
|---|---|---|
| Agent workflow | Manual baseline first; bounded task; reviewed diff/commands; personal checks; accepted and rejected/revised suggestion explained | Agent substitutes for understanding, receives protected data, or invents verification |
| Component model | Distinguishes model, gateway/provider, agent/harness, interface, and tool protocol | Treats an account, provider, or model as if it grants agent authority |
| Cost and access | Uses no-cost/offline route or accepts personal cost with explicit limit and monitoring | Assumes lab reimbursement, shares a key, or treats a spend limit as data protection |
Euler CPU#
| Competency | Passing evidence | Blocking failure |
|---|---|---|
| Login/compute distinction | Computation submitted through Slurm | Long/heavy process run on login node |
| Resource request | Conservative and justified CPU/memory/time/account | Large “just in case” request or unexplained partition constraint |
| Job lifecycle | Uses sbatch, squeue/myjobs, scancel, logs |
Cannot locate or stop own job |
| Accounting | Correctly interprets sacct, seff, state, exit, elapsed, MaxRSS |
Increases resources without inspecting failure/usage |
| Arrays | Explicit low cap plus aggregate calculation across active submissions | Uncapped array or per-array calculation that ignores overlapping jobs |
| Storage | Correct durable/temporary locations | Sole important copy in scratch/$TMPDIR |
Euler GPU#
| Competency | Passing evidence | Blocking failure |
|---|---|---|
| Account/model | es_fuge, one explicitly selected supported model and fallback plan |
GPU on public or an unverified combined-model request |
| Baseline | One GPU, bounded smoke test, monitoring | Multi-GPU requested because data/model is “large” only |
| Bottleneck reasoning | Considers GPU, CPU, memory, data loading, I/O | Adds GPUs without single-GPU measurement |
| Execution mode | Tunnel for short interaction, sbatch for unattended work |
Long idle interactive GPU allocation |
| Recovery | Checkpoint and wall-time plan | Long run has no recovery strategy |
Data Steward#
| Competency | Passing evidence | Blocking failure |
|---|---|---|
| Ownership/lifecycle | Owner, classification, authoritative and temporary copies documented | Ownership or only authoritative copy unclear |
| Collaboration | Specific group/setgid/default ACL design | Recursive world-writable permission fix |
| Recovery/handover | Backup/purge/retention and next owner documented | Temporary/personal location treated as archive |
Blade User#
| Competency | Passing evidence | Blocking failure |
|---|---|---|
| Workload | Uses Blade for approved Windows GUI/prototyping and routes heavy compute elsewhere | Treats Blade as an unattended heavy-compute server |
| Storage | Uses assigned durable P: project path; limits D: to temporary high-speed work and avoids C: for project data |
Only important copy remains on C:, user folders, or temporary D: |
Supervisor And Staff#
| Competency | Passing evidence | Blocking failure |
|---|---|---|
| Assignment | Names responsibilities, information owner, storage, systems, reviewer, and exceptions | Assigns a generic title-based route or leaves ownership/access ambiguous |
| Offboarding | Transfers ownership, revokes access, preserves authoritative evidence, and records lifecycle state | Deletes evidence, shares an account, or leaves orphaned data/access |
Review Outcome#
- Pass: the score reaches the mission threshold and every safety-critical competency is demonstrated.
- Needs work: the browser or trusted Check Run names a repairable finding.
- Operational approval: training passed, while a real access, ownership, or classification decision waits asynchronously for its named owner.
- Exception review: the deterministic verifier cannot safely classify the result or repeated safety failures require a specific follow-up question.
- Incident escalation: real secret, protected data, unauthorized access, or harmful shared-resource action appears.