Semester 6 Checkpoint Gate
The checkpoint must verify that the World-Class Strand evidence exists, is reproducible, and has a written highest-risk gap.
Required Output Classification
| Required output | Classification | Public/private guidance |
|---|---|---|
| Closed-book prompts, self-assessment answers, and skills matrices | Practice artifact | Use for honest calibration; do not publish raw answers unless rewritten as a study guide. |
| Required evidence gate items, sign-off checklist, and readiness decision | Checkpoint evidence | Keep as private progression evidence; share only sanitized summaries with mentors or reviewers. |
| Repair artifacts produced after a weak checkpoint, such as corrected solutions, diagrams, traces, benchmarks, or runbooks | Checkpoint evidence | Store beside the checkpoint so the remediation trail is inspectable without making mistakes public. |
| Reviewer notes or mentor feedback that materially improve a project artifact | Portfolio candidate | Convert into public-safe acknowledgements or changelog entries only after removing private feedback context. |
Pass this gate before you call Semester 6 complete. The standard is not exposure. The standard is whether you can produce correct artifacts and defend your tradeoffs.
What You Must Be Able To Do
| Area | Required capability | Evidence you should have |
|---|---|---|
| Module 1: Relational Databases & SQL | Design a clean schema, justify keys and constraints, and write non-trivial queries correctly | Schema draft, representative SQL queries, and short notes explaining design choices |
| Module 2: Storage Engines & Indexing | Explain how the engine stores and retrieves data, and choose indexes based on workload | Query-plan notes, index rationale, and one workload comparison |
| Module 3: Replication & Partitioning | Describe read/write paths, lag, failover, sharding pressure, and user-visible failure modes | Replication sketch, partitioning tradeoff notes, and a short failure analysis |
| Module 4: Transactions & Consistency | Identify anomalies, compare isolation choices, and explain what correctness guarantee is actually needed | Transaction timeline examples and consistency decision notes |
| Module 5: Distributed Systems Fundamentals | Reason about time, partial failure, quorum intuition, and coordination cost | Distributed scenario writeup with tradeoffs and failure assumptions stated clearly |
Closed-Book Readiness Prompts
Answer these without notes first. If you cannot answer one clearly, that is the next review target.
- Why is a bad schema problem not fixed by adding indexes later?
- What changes operationally when a workload moves from read-heavy to write-heavy?
- How can replication lag create a user-visible correctness problem even if the database is technically healthy?
- What anomaly does a transaction isolation level prevent, and what does it still allow?
- Why is distributed consensus expensive, and when is that cost justified?
Skills Verification Matrix
| Skill | Can do without notes? | Evidence path or artifact | If not yet, remediation |
|---|---|---|---|
| Write joins, aggregates, subqueries, and filters that match the business question | Rework Module 1 exercises and explain each query aloud | ||
| Interpret why one index helps one query and harms another workload | Revisit Module 2 storage/index notes and compare plans | ||
| Explain leader-follower reads, lag, and failover behavior | Redraw Module 3 replication paths from memory | ||
| Compare two isolation choices for the same workflow | Rebuild Module 4 anomaly examples and recovery notes | ||
| Analyze a partial-failure distributed scenario without slogans | Review Module 5 time/failure concepts and rewrite one scenario cleanly | ||
| Define tests that protect a schema or transaction invariant | Add database-focused tests to project work | ||
| Describe data-security controls for credentials and sensitive fields | Review access control and secret-handling notes | ||
| Name the runtime signals that would tell you the data plane is degrading | Add observability notes to the project or module labs |
Required Artifacts Before Advancing
- one schema with constraints and justification
- one query set with correctness evidence
- one storage/index tradeoff writeup
- one replication or partitioning scenario analysis
- one transaction or consistency analysis
- one distributed failure scenario analysis
- one repo or notebook showing steady, reviewable work rather than a last-minute dump
Blockers
Do not move on if any of these are true:
- you can write SQL only by trial and error
- you cannot explain why an index helps in one case and hurts in another
- you talk about consistency, CAP, or consensus only in buzzwords
- you do not have concrete evidence for schema, transaction, or distributed tradeoff decisions
Sign-Off
- Date completed:
- Honest self-rating (1-5):
- Most important weakness still open:
- Concrete fix scheduled before Semester 7:
Added Gate Evidence
The checkpoint reviewer should see:
- schema evidence: ER diagram, DDL, constraints, and normalization worksheet
- SQL evidence: query file plus result or plan evidence
- model-decision evidence: a short note comparing relational and document approaches for the same workflow
- operational evidence: one index decision, one migration risk, and one rollback note
Mastery Rubric
| Level | Evidence |
|---|---|
| Beginner pass | Can answer direct questions and complete familiar exercises with light notes. |
| Solid pass | Can solve new variants, explain choices, and connect the work to Semester 5 Operating Systems and Networking. |
| Strong pass | Can defend tradeoffs, identify failure modes, and produce clean evidence in the portfolio artifact. |
| Not ready | Relies on copied solutions, cannot explain mistakes, or lacks durable artifacts. |
Retake and Repair Rule
If a section is weak, do not only reread. Repair it by producing new evidence: a corrected solution, a fresh implementation, a rewritten proof, a benchmark, a diagram, a runbook, or a short teaching note.
Answer-Quality Examples
Use these examples when grading written answers or spoken explanations.
| Quality | Example pattern |
|---|---|
| Weak | Names a concept but gives no example, constraint, or failure case. |
| Acceptable | Defines the concept and applies it to a familiar exercise. |
| Strong | Applies the concept to a new variant and explains why an alternative would fail. |
| Portfolio-ready | Connects the concept to Semester 5 Operating Systems and Networking, current project evidence, and a future capstone decision. |
Interleaving Prompt
For any missed answer, add one sentence starting with: This depends on an earlier skill because...
Calibration Materials
Use these learner-visible calibration materials before self-grading or requesting review:
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.