{ "version": "1.0", "editorialStatus": "Eight authored foundation capstones; other paths remain existing syllabi, not certified curricula.", "capstones": [ { "id": "systems-foundation", "title": "Trace a failing HTTPS request", "time": 60, "prerequisites": "Complete the nine Systems Foundation learning objects, especially DNS, routing, Linux permissions, and RTO/RPO.", "scenario": "A fictional service named portal.example.test is intermittently unreachable. A teammate says that because the name resolves, the website must be healthy. You are the incident investigator. Your task is to separate evidence from assumptions before proposing a fix.", "concept": "Name resolution, routing, transport, TLS, and HTTP are different failure domains. A correct DNS response does not prove the TCP connection, TLS handshake, application, or any embedded resource works. A successful HTTP 200 can still return an unusable app if its JavaScript or images fail to load. Test one boundary at a time and record exactly what the observation supports.", "example": "Suppose nslookup returns 192.0.2.25, curl reports 'connection timed out' to TCP port 443, and another workstation succeeds. The resolver answered, but no successful transport connection has been demonstrated from the failing workstation. The data do not establish whether a firewall, routing problem, service outage, or path-specific filtering caused the timeout. The address 192.0.2.25 is documentation-only; do not probe it.", "steps": [ "Draw the request path: URL parsing → DNS → local gateway → routing → TCP → TLS → HTTP → dependent resources.", "For a domain you control or a documented public test endpoint, inspect DNS with nslookup or dig, inspect HTTPS status with curl -I, and note what each command cannot prove. Alternatively, use the fictional observations above.", "Write two distinct hypotheses for the timeout; name a discriminating, read-only test for each.", "Create a five-column incident log: observation, layer, hypothesis, next test, and reversible action.", "Select an appropriate RTO and RPO for a fictional 30-minute outage and explain the business assumption behind each." ], "check": { "question": "DNS resolves, but HTTPS times out. Which conclusion follows?", "options": [ "The HTTP app is definitely broken", "DNS succeeded; later network or server stages still need investigation", "The remote server certificate is definitely invalid" ], "correct": 1, "reason": "A DNS answer identifies an address. It does not establish transport reachability, TLS or HTTP success." }, "rubric": [ "Request-stage diagram distinguishes DNS, transport, TLS and HTTP", "At least two hypotheses are compared with discriminating tests", "Evidence is not confused with an inferred cause", "RTO and RPO are separately justified", "Retain a notebook result, a failed or perturbed case, and a source locator; separate measured output from interpretation" ], "companions": [ { "notebook": "prefix.ipynb", "download": "assets/downloads/engineering-foundations-3.1.zip" }, { "notebook": "recovery.ipynb", "download": "assets/downloads/engineering-foundations-3.1.zip" } ] }, { "id": "advanced-systems", "title": "Find the bottleneck before adding cores", "time": 70, "prerequisites": "Complete the From CPU to HPC path through memory locality, concurrency and performance measurement.", "scenario": "A numerical job needs ten seconds on one worker. Eight seconds can be parallelized, but two seconds must remain serial. A proposal says eight workers will make the entire job eight times faster.", "concept": "Amdahl's law gives an upper bound when the parallel fraction is fixed: speedup S(N)=1/[(1-p)+p/N]. For p=0.8 and N=8, S=1/(0.2+0.1)=3.33, so ideal runtime is about three seconds. Real systems have communication, synchronization, scheduling and memory-bandwidth costs; the measured speedup may be lower. More workers are not a substitute for performance profiling.", "example": "For p=.8, one worker takes 10 s, eight take 3 s in the ideal model, and infinitely many cannot beat 2 s. The 2 s serial portion is the fixed bottleneck. If a profiler instead shows cache misses dominate, the useful intervention may be data layout or fewer memory transfers rather than more threads.", "steps": [ "Compute ideal runtime and speedup at 1, 2, 4, 8 and 16 workers using the equation above.", "State the theoretical limit as worker count grows without bound.", "Sketch two ways bandwidth contention could make the real runtime worse than the ideal bound.", "Write a reproducible benchmark plan: workload, machine, warm-up, repetitions, timing method, and uncertainty.", "Recommend the next measurement, not a new machine, and explain what result would change your decision." ], "check": { "question": "With 80% parallel work and eight workers, the ideal speedup is closest to:", "options": [ "8×", "3.33×", "1.25×" ], "correct": 1, "reason": "1 / (0.2 + 0.8/8) = 1/0.3 ≈ 3.33." }, "rubric": [ "Includes equation, assumptions and correct numerical table", "Distinguishes ideal upper bound from measured speedup", "Names at least two physical or software overheads", "Benchmark plan is reproducible", "Retain a notebook result, a failed or perturbed case, and a source locator; separate measured output from interpretation" ], "companions": [ { "notebook": "hpc.ipynb", "download": "assets/downloads/engineering-studies-3.2-3.6.zip" } ] }, { "id": "software-core", "title": "Design and test a reliable parser", "time": 75, "prerequisites": "Complete the Software Engineering Core path through data structures, APIs and automated testing.", "scenario": "A small telemetry service receives lines such as 'sensor-17,21.4'. Write a parser that returns a sensor ID and a finite numeric reading. A malformed line must not silently become a valid measurement.", "concept": "A function's contract specifies valid input, normal output, and failure behavior. Parsing is not the same as validation: splitting on a comma can succeed even when an identifier is empty or the measurement is NaN. Tests should include boundaries, malformed data and repeated executions. Keep parsing pure so it can be tested without external systems.", "example": "A valid result for 'sensor-17,21.4' is {id:'sensor-17', value:21.4}. Reject 'sensor-17,NaN', 'sensor-17,21.4,extra', ',21.4', and 'sensor-17,'. In Python, use math.isfinite after float conversion; in JavaScript use Number.isFinite(Number(value)). Decide whether whitespace and negative readings are allowed, then encode that decision in tests.", "steps": [ "Write the parser contract and an explicit error type or error result.", "Implement the smallest pure parser in Python or JavaScript; do not call real APIs or store identifying data.", "Run tests for valid, empty, extra-field, nonnumeric, infinity, leading-space and negative inputs.", "Refactor for readability without changing the contract; rerun tests.", "Explain how the caller should record rejected readings without logging sensitive production payloads." ], "check": { "question": "Why is split(',') by itself insufficient?", "options": [ "It always raises an exception", "It does not validate field count, identifier or finite numeric value", "It cannot read strings" ], "correct": 1, "reason": "Syntactic splitting does not establish that the resulting fields satisfy the data contract." }, "rubric": [ "Contract states acceptance and rejection rules", "Pure function has explicit failure behavior", "At least seven meaningful edge tests", "No unverified claim that tests cover every possible input", "Retain a notebook result, a failed or perturbed case, and a source locator; separate measured output from interpretation" ], "companions": [ { "notebook": "ingestion.ipynb", "download": "assets/downloads/engineering-foundations-3.1.zip" } ] }, { "id": "security-foundation", "title": "Design a least-privilege access review", "time": 60, "prerequisites": "Complete Security Foundations through identity, least privilege, logs and recovery.", "scenario": "A fictional team has a developer, a production operator and an auditor. A shared account currently has administrator access to code, production configuration and audit logs. Redesign access without relying on the shared account.", "concept": "Least privilege grants only the access needed for an approved task, for the required period, with accountability for who used it. Separation of duties can prevent a single account from making a sensitive change and silently hiding its evidence. Controls need a practical break-glass procedure so security does not make recovery impossible.", "example": "Developers may propose changes and view nonsecret diagnostics; operators deploy reviewed changes; auditors read immutable or independently controlled event records. Temporary emergency access should have a named person, a reason, a short lifetime and a post-incident review. This is a fictional design exercise, not a claim that any particular organization currently uses these policies.", "steps": [ "Draw the three-role × four-resource access matrix; mark read, write, approve or no access.", "Document one approval workflow and the audit event needed to review it.", "Write a break-glass procedure with identity verification, expiration and retrospective review.", "Describe two failure modes: permission creep and an unavailable identity provider.", "Define how you would test the access matrix in a staging environment without touching live systems." ], "check": { "question": "Which approach gives the clearest accountability?", "options": [ "One permanent shared administrator login", "Named short-lived privileged sessions with approval and audit", "Turn off logs for sensitive changes" ], "correct": 1, "reason": "Named, bounded sessions support attribution and review while reducing standing privilege." }, "rubric": [ "Every role has a documented minimum set of permissions", "Privileged actions have approval and independent audit", "Break-glass procedure preserves availability and accountability", "Tests do not modify production", "Retain a notebook result, a failed or perturbed case, and a source locator; separate measured output from interpretation" ], "companions": [ { "notebook": "security.ipynb", "download": "assets/downloads/engineering-studies-3.2-3.6.zip" } ] }, { "id": "it-leadership", "title": "Lead a blameless service-restoration review", "time": 60, "prerequisites": "Complete IT Leadership in Practice through incident roles, change management and communication.", "scenario": "A routine software update causes a fictional internal service to fail for 45 minutes. The rollback restores service, but no one is sure when users first noticed the problem. You are the incident lead.", "concept": "Separate the immediate goal of restoring service from the later goal of understanding how the system and process allowed the failure. A good review preserves a timeline, observable facts, decision owners, relevant contributing conditions and testable follow-up actions. Avoid treating a person as the root cause; examine the conditions under which their decision made sense.", "example": "A useful action is 'Add a synthetic sign-in check and alert the on-call engineer when three successive checks fail; owner: platform lead; due: next sprint; verify using a controlled test.' 'Tell people to be more careful' is not testable. Clearly label inferred times or assumed user impact.", "steps": [ "Create a timeline with confirmed facts, estimated times and unknowns visibly separated.", "Assign an incident commander, communications lead and technical owner, with backups.", "Draft a 90-word stakeholder update stating impact, current status and next update time.", "Write three follow-ups with named owners, completion checks and dates.", "Define how you will measure restoration time and detect repeat failures without rewarding hidden incidents." ], "check": { "question": "Which corrective action is measurable?", "options": [ "Remind the team to try harder", "Add a tested synthetic login check with a named owner and acceptance criteria", "Assume the update author caused the outage" ], "correct": 1, "reason": "It names a concrete control, an owner and a verification method." }, "rubric": [ "Timeline distinguishes observed, estimated and unknown information", "Communication describes impact without speculation", "Three follow-ups have owner, due date and acceptance check", "Restoration and learning phases are distinct", "Retain a notebook result, a failed or perturbed case, and a source locator; separate measured output from interpretation" ], "companions": [ { "notebook": "slo.ipynb", "download": "assets/downloads/engineering-foundations-3.1.zip" } ] }, { "id": "math-for-computing", "title": "Verify a transformation from first principles", "time": 75, "prerequisites": "Complete Math for Advanced Computing through vectors, matrices, norms and complex amplitudes.", "scenario": "You are checking a two-dimensional rotation that will later be used in graphics and as a mathematical prerequisite for understanding qubit states.", "concept": "For rotation θ, the real 2×2 matrix is [[cosθ,−sinθ],[sinθ,cosθ]]. A rotation should preserve Euclidean length because the matrix is orthogonal: RᵀR=I. This fact is useful for testing a geometry program. Quantum amplitudes instead use complex vector spaces and unitary transformations; the analogy is mathematical, not a claim that a planar arrow is an entire qubit.", "example": "Rotate (1,0) by 90°: cos90°=0 and sin90°=1, so R(1,0)=(0,1). The input norm is 1 and the output norm is 1. Rotating by 90° four times returns the starting vector (up to floating-point rounding). Degrees must be converted to radians for most software trig functions.", "steps": [ "Derive R(θ) from the images of the standard basis vectors e₁ and e₂.", "Compute R(90°)(1,0) and R(45°)(1,1) by hand.", "Prove RᵀR=I using sin²θ+cos²θ=1.", "Write a short script or spreadsheet checking norm preservation at five angles, including a negative angle.", "Explain why finite-precision output can differ slightly from an exact value and how to choose a justified tolerance." ], "check": { "question": "A 90° counterclockwise rotation maps (1,0) to:", "options": [ "(0,1)", "(1,1)", "(0,−1)" ], "correct": 0, "reason": "Apply the rotation matrix with cos90°=0 and sin90°=1." }, "rubric": [ "Derivation and two worked rotations are correct", "Norm preservation is proved, not merely asserted", "Numerical test includes an explicitly chosen tolerance", "Distinguishes real rotations from general quantum unitary operators", "Retain a notebook result, a failed or perturbed case, and a source locator; separate measured output from interpretation" ], "companions": [ { "notebook": "eigen.ipynb", "download": "assets/downloads/engineering-foundations-3.1.zip" } ] }, { "id": "physics-foundation", "title": "Build and challenge a two-path interference model", "time": 70, "prerequisites": "Complete Physics Foundation through waves, phase, superposition and energy.", "scenario": "A classical wave reaches a detector by two coherent paths. One path has a controllable phase shift Δφ. Predict when the two contributions reinforce or cancel before using interference as an analogy in later quantum study.", "concept": "For equal-amplitude coherent classical waves E₁=Acos(ωt) and E₂=Acos(ωt+Δφ), the combined amplitude is 2A|cos(Δφ/2)| and intensity is proportional to 4A²cos²(Δφ/2). At Δφ=0 interference is constructive; at Δφ=π it is destructive. Unequal amplitudes or loss of coherence change the visibility. Quantum probability amplitudes can interfere, but a classical beam drawing does not establish quantum entanglement.", "example": "At Δφ=π/2, cos²(π/4)=1/2, so the intensity is half the maximum for the ideal equal-amplitude model. At π the ideal intensity is zero. In a real optical experiment, noise, unequal path losses and imperfect mode overlap can leave a nonzero minimum.", "steps": [ "Write both sinusoidal path contributions and use a trigonometric identity to derive the envelope.", "Calculate normalized intensity at phase differences 0, π/2, π and 3π/2.", "Plot the predicted intensity versus phase using a browser calculator or script.", "Identify which assumptions are necessary for complete cancellation.", "Describe one observation that would challenge the model and distinguish measurement noise from a model mismatch." ], "check": { "question": "In the equal-amplitude coherent model, Δφ=π gives:", "options": [ "Maximum intensity", "Ideal cancellation", "Exactly half the maximum intensity" ], "correct": 1, "reason": "The wave contributions have opposite phase and equal amplitude, so they cancel in the ideal model." }, "rubric": [ "Derivation explicitly states coherence and equal-amplitude assumptions", "Normalized intensity values are correct", "Plot and limiting cases agree with the equation", "No claim that classical interference demonstrates entanglement", "Retain a notebook result, a failed or perturbed case, and a source locator; separate measured output from interpretation" ], "companions": [ { "notebook": "pde_inverse.ipynb", "download": "assets/downloads/engineering-studies-3.2-3.6.zip" } ] }, { "id": "quantum-onramp", "title": "Distinguish a Bell state from two separate qubits", "time": 80, "prerequisites": "Complete the Quantum Computing On-Ramp path, including complex amplitudes, single-qubit measurement and tensor products.", "scenario": "Two experimental teams report matching bit strings after measuring paired systems. Does this alone establish that the systems were entangled? Design a mathematical comparison using the ideal Bell state Φ⁺=(|00⟩+|11⟩)/√2 and a separable correlated mixture.", "concept": "Entanglement means a joint quantum state cannot be written as a product of independent single-system states (or, for a mixed state, as a probabilistic mixture of product states). The Bell state Φ⁺ gives perfectly matching 0/1 results in the Z basis and also matches in the X basis. A classically correlated mixture ½|00⟩⟨00|+½|11⟩⟨11| matches in Z but has no X-basis correlation. The Y/Y outcomes of Φ⁺ are perfectly anti-correlated in the ideal model. A polished beam animation is an illustration, not a signal traveling between measured qubits.", "example": "For Φ⁺ in Z/Z, probabilities are P(00)=P(11)=1/2 and P(01)=P(10)=0. For X/X the same joint probabilities hold. For Z/X every pair has probability 1/4. For Y/Y, P(01)=P(10)=1/2. These are ideal predictions; finite samples fluctuate and actual experiments have noise and calibration limits.", "steps": [ "Write the four amplitudes of Φ⁺ in the computational basis and verify their squared magnitudes sum to one.", "Use basis change |±⟩=(|0⟩±|1⟩)/√2 to rewrite Φ⁺ in X/X and compare the predicted outcomes.", "Compare a Bell pair and the separable correlated mixture in Z/Z and X/X; explain why Z matches alone are insufficient.", "Use the interactive Bell model to simulate 1,000 shots each in Z/Z, X/X, Y/Y and Z/X; record approximate frequencies rather than expecting exactly 500/500.", "Explain why joint correlations alone do not allow faster-than-light messaging or prove that the glowing beams are real." ], "check": { "question": "Which observation distinguishes ideal Φ⁺ from the correlated mixture described here?", "options": [ "Matching Z/Z outcomes", "Matching X/X outcomes as well as Z/Z outcomes", "A bright cyan beam in an illustration" ], "correct": 1, "reason": "Both models match in Z. The separable mixture lacks the ideal Bell state's X/X correlation." }, "rubric": [ "Normalizes Φ⁺ and computes the four Z/Z outcome probabilities", "Uses two bases to contrast entanglement with classical Z correlations", "Interprets sampling noise appropriately", "Explicitly rejects literal-beam and faster-than-light interpretations", "Retain a notebook result, a failed or perturbed case, and a source locator; separate measured output from interpretation" ], "companions": [ { "notebook": "qubit.ipynb", "download": "assets/downloads/engineering-foundations-3.1.zip" }, { "notebook": "bell.ipynb", "download": "assets/downloads/engineering-foundations-3.1.zip" } ] } ] }