Semester 1 Portfolio Artifact
Required Output Classification
| Required output | Classification | Public/private guidance |
|---|---|---|
| README orienting a reviewer to what the artifact proves | Portfolio required | Polish for external readers and verify every link, command, screenshot, and claim. |
| Evidence folder with notes, diagrams, code, logs, screenshots, benchmark outputs, or review comments | Portfolio required | Publish only sanitized, curated evidence; keep raw logs, credentials, private comments, and sensitive screenshots in private coursework storage. |
| Decision log, ADRs, or tradeoff notes | Portfolio required | Rewrite for a public audience when possible; keep speculative, confidential, or personally identifying details private. |
| Verification evidence such as tests, worked examples, traces, peer review, or self-checks | Portfolio required | Prefer reproducible commands and summarized results; keep bulky raw traces and non-public review threads private. |
| Reflection and carry-forward notes | Checkpoint evidence | Keep candid reflection private by default; publish only a short, professional learning summary if useful. |
A proof and problem-solving notebook with corrected solutions, counterexamples, diagrams, and a short index of reusable techniques.
Why This Artifact Exists
A large roadmap needs visible proof of learning. This artifact is the semester's durable evidence: something a future reviewer, mentor, or employer can inspect without trusting your memory or completion checklist.
Required Contents
- README: one-page orientation explaining the artifact, how to inspect it, and what semester outcomes it proves.
- Evidence folder: notes, diagrams, code, logs, screenshots, benchmark outputs, or review comments that support the claims.
- Decision log: short entries for meaningful tradeoffs, mistakes, and corrections.
- Verification: tests, worked examples, traces, peer review, or self-checks that prove the artifact is not only decorative.
- Reflection: 300-600 words explaining what became easier, what still feels weak, and what should be revisited next semester.
Quality Bar
| Level | Standard |
|---|---|
| Needs repair | Artifact exists but cannot be inspected independently or lacks evidence. |
| Solid pass | Artifact proves the main semester outcomes and includes verification. |
| Strong pass | Artifact is reviewable, well-organized, and includes honest tradeoffs and corrections. |
| Portfolio-ready | Artifact could be shown externally after minor cleanup and tells a coherent engineering story. |
Carry Forward
Before starting Semester 2 Algorithms and Data Structures, create a short handoff note:
- Which ideas from Math Foundations are now reliable?
- Which skills still require spaced review?
- Which artifact should be reused, extended, or retired next?
- What one mistake from this semester should not repeat?
Evidence index for the revised core
Link the five module gate records, E01–E10 first attempts and repairs, six project category records, and delayed rechecks. Include the working graph investigation and interactive view. Existing module artifacts can be cited repeatedly without rewriting them. Publish curated evidence only; keep private assessment material and candid repair logs separate. Record self-assessment and independent review distinctly.
Integer arithmetic evidence
Include the integer module gates and reuse the cycle audit. Recheck one signed Bezout certificate, one invalid cancellation and one complete solution list on a changed case. Explain the difference between logarithmic arithmetic-operation counts, bit cost and time proportional to the number of returned solutions.