Semester 6: Databases and Distributed Systems: Rubric and Passing Standards
The World-Class Strand evidence is non-compensatory: every required category must pass even when the rest of the submission is strong.
This rubric applies to the semester-level checkpoint, exam, and project. Use it with the answer key and solution outlines to keep grading consistent and learner-visible.
Minimum Passing Standard
To pass Semester 6: Databases and Distributed Systems, the learner must satisfy all of the following:
- Checkpoint: at least 80% of checkpoint prompts are answered correctly and independently, with no critical gaps in schema design, query planning, transactions, storage, replication, and distributed consistency tradeoffs.
- Exam: overall score is at least 70%, and no major section that tests a core semester outcome is below 60%.
- Project: all required deliverables are present, the artifact can be inspected or reproduced by another person, and the learner can defend the main tradeoffs.
- Integrity: sources, collaboration, generated assistance, and borrowed code or examples are acknowledged.
- Remediation: every failed required gate is repaired and independently retested before completion.
Failure in any one of these categories means the semester should not be marked complete yet, even if the other artifacts look strong.
Grading Rubric
| Dimension | Needs repair | Minimum pass | Strong pass | Excellent / portfolio-ready |
|---|---|---|---|---|
| Concept command | Uses terms loosely or confuses core ideas. | Defines and applies the required concepts with minor gaps. | Explains concepts through examples, counterexamples, and constraints. | Teaches the ideas clearly and connects them across semesters. |
| Reasoning quality | Jumps to answers; hides assumptions. | Shows enough steps to inspect correctness. | Makes assumptions, invariants, and tradeoffs explicit. | Compares alternatives and anticipates edge cases or objections. |
| Evidence | Claims are unsupported or impossible to reproduce. | Provides basic proofs, tests, diagrams, traces, or outputs. | Evidence targets the riskiest claims and is easy to verify. | Evidence is organized as a review packet a third party can audit. |
| Semester integration | Treats modules as unrelated topics. | Connects the main semester themes to the assessment. | Synthesizes multiple modules in one coherent explanation or artifact. | Shows how mastery of schema design, query planning, transactions, storage, replication, and distributed consistency tradeoffs shapes engineering judgment beyond the course examples. |
| Communication | Hard to follow; missing context. | Understandable and complete enough to grade. | Clear structure, named decisions, and concise explanations. | Professional presentation with honest limitations and next steps. |
Strong Submission Traits
Strong submissions usually demonstrate these traits:
- concise explanations that reveal the mental model, not just the final answer
- concrete artifacts that can be run, checked, reviewed, or traced
- explicit handling of edge cases, constraints, and failure modes
- visible revision: mistakes were found, corrected, and documented
- appropriate connections between schema design, query planning, transactions, storage, replication, and distributed consistency tradeoffs and prior semester foundations
Common Weak Submission Patterns
Watch for these patterns during self-review:
- vocabulary recognition without the ability to apply the idea to a new prompt
- impressive-looking diagrams, code, or prose with no verification evidence
- hidden dependencies on tutorials, solution videos, or AI-generated answers
- project scope that is too broad to inspect or too narrow to prove the required skill
- missing reflection about tradeoffs, limitations, or what would be done differently
Calibration Decision Guide
- Pass: all minimum standards are met and weak patterns are minor.
- Repair required — incomplete: repair every failed requirement and pass an independent retest before Semester 7.
- Repeat / revisit: a core concept, core deliverable, or integrity requirement is missing.
When uncertain, grade against evidence rather than effort. Time spent is useful context, but the semester is complete only when the learner can demonstrate the outcomes.
Relational-contract evidence
Require every SQL1–SQL6 gate at level 2 or above. Reuse schema constraints, exact result predictions, adversarial fixtures and transaction failure evidence. SQLite checks do not replace PostgreSQL plans or multi-session observations. A failed gate remains incomplete regardless of aggregate marks. See the reconciled workload.
Storage-contract evidence
Require all ST1–ST6 gates at level 2 or above. Reuse bounded-record traces, recovery-prefix cases, compaction-scope counterexamples, disk/index integration and publication assumptions. Replay and reopen checks do not establish hardware durability. Missing gates remain incomplete regardless of aggregate marks.
Replica-session evidence
Require all RP1–RP6 gates at level 2 or above. Reuse received/applied-prefix traces, monotonic session tokens and explicit blocked/unavailable outcomes. The single-history model does not prove failover safety, cross-shard snapshots or ownership transfer; original migration evidence remains required. Failed gates remain incomplete regardless of aggregate marks.
Transaction-delivery evidence
Require all TX1–TX6 gates at level 2 or above. Reuse producer/outbox and consumer/inbox failure traces, duplicate delivery and retention/ordering limits. Local database effects do not establish exactly-once external actions. Original isolation, WAL and saga evidence remains required; failed gates are incomplete regardless of aggregate score.
Distributed-clock evidence
Require all DS1–DS6 gates at level 2 or above. Reuse event graphs, independent reachability checks, scalar-order counterexamples and immutable timestamp evidence. Clock calculations do not replace failure-detector, Raft or retry-safety evidence. Missing gates remain incomplete regardless of aggregate score.
Integrated completion contract
Use the 512–743-hour workload and progression contract. All 33 module gates (including DB1–DB3) and all four D1–D4 privacy/retrieval categories must pass independently alongside original project, exam, checkpoint and integrity requirements. Reuse evidence and count time once; independent review and timing pilots remain pending.
Engine-boundary evidence
Reuse the DB1–DB3 packet for process exit, overlapping transactions and guarantee limits. Each gate requires level 2. Its work is counted in Module 4, not again in integration. PostgreSQL sessions remain separately required.