# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## PLATENCY — Find the missing seconds in the quote API A fictional freight broker sees slow quote responses at dispatch handover. The service looks healthy in average-latency charts, yet a few long requests occupy every worker. Build a small synthetic quote service and controlled dependency stub before taking implementation tickets. **Field:** Performance engineering. **Suggested stack:** TypeScript, Node.js, PostgreSQL, OpenTelemetry, k6. **Engineer value:** Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. **Company value:** Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. **Delivery agreement:** Ten tickets in three phases. Estimates assume the local service and generator already exist; all load runs stay in the owned local environment. Budgets are exercise requirements, not measured platform results. ### Setup prerequisites - Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. - Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. ### Establish trustworthy measurements Define the traffic shape and separate time spent waiting from time spent working. #### PLATENCY-101 — Write down the traffic mix before comparing quote timings **Task · Medium priority · Foundational** noCV practice brief v5 · PLATENCY-101 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish trustworthy measurements. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 70% · Quality engineering 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The last benchmark sent one route repeatedly. Dispatch says the slow period contains mostly unique routes and a small number of expensive multi-stop quotes. Acceptance criteria - Create a seeded mix of 70% single-stop, 25% multi-stop and 5% invalid requests across 1,000 synthetic routes. - Record concurrency, arrival rate, seed, payload sizes, runtime and resource limits in the run manifest. - Count every attempted request, including validation failures and client timeouts, against the expected result class. Implementation constraints - Keep the fixture bounded; random seeds must reproduce both request order and expected quote inputs. Verification - Replay the same seed twice and compare request identities and expected outputs. - Change the seed and confirm the traffic proportions stay within the declared rounding rule. Deliverables - Workload manifest and deterministic request generator Rollout and recovery: Commit the baseline manifest separately; a workload change starts a new comparison series. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PLATENCY-102 — Show quote latency percentiles alongside rejected and timed-out requests **Story · High priority · Intermediate** noCV practice brief v5 · PLATENCY-102 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish trustworthy measurements. Depends on: PLATENCY-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Site reliability 30% · Privacy engineering 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The dashboard median improves when the slowest requests time out and disappear from successful-response measurements. Acceptance criteria - Report p50, p95 and p99 with sample counts for completed requests, and separate timeout, rejection and transport-error counts. - State the observation window and histogram precision; do not average percentiles across workers. - Keep route identifiers, customer IDs and quote payloads out of metric labels. Implementation constraints - Use bounded result-class labels and merge histogram counts before computing aggregate percentiles. Verification - Replay a fixture with known short, long and timed-out requests and reconcile all attempts. - Compare merged-worker results with the same samples processed in one worker, within the declared histogram precision. Deliverables - Latency dashboard definition and aggregation regression fixture Rollout and recovery: Run the new view beside the existing chart for the synthetic workload; keep raw counters if rendering is reverted. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PLATENCY-103 — Separate quote queue time from carrier lookup time **Task · Medium priority · Foundational** noCV practice brief v5 · PLATENCY-103 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish trustworthy measurements. Depends on: PLATENCY-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Site reliability 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A trace labels the entire request as carrier latency, but the stub returns quickly when called outside the API. Acceptance criteria - Record monotonic durations for admission wait, application work and carrier lookup with one request correlation identifier. - Make the phase durations reconcile with total server duration within documented instrumentation overhead. - Record cancellation and missing-span states explicitly instead of inventing zero-duration work. Implementation constraints - Do not put route payloads or credentials into spans; use a bounded synthetic request identifier for this exercise. Verification - Inject 100 ms of queue delay and verify it appears outside the carrier span. - Cancel a queued request and confirm the trace distinguishes waiting from a lookup that never started. Deliverables - Span boundaries and an annotated trace from the controlled stub Rollout and recovery: Enable sampling locally first; disable extra spans independently if instrumentation changes the measured workload. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Remove demonstrated bottlenecks Change one constrained path at a time while checking exact quote outputs. #### PLATENCY-104 — Remove repeated tariff parsing from the quote hot path **Bug · High priority · Advanced** noCV practice brief v5 · PLATENCY-104 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove demonstrated bottlenecks. Depends on: PLATENCY-101, PLATENCY-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 70% · Backend 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A CPU profile shows every quote parsing the same tariff document, including requests that use the same immutable tariff revision. Acceptance criteria - Parse once per tariff revision and cap retained revisions with an explicit eviction policy. - Keep quote totals and rounding behavior identical to the uncached path for the seeded fixture. - Reject a malformed new revision without replacing the last valid parsed tariff. Implementation constraints - Measure before and after with the same revision distribution; do not cache request-specific discounts in the shared tariff object. Verification - Compare every synthetic quote against the uncached implementation across two valid revisions. - Alternate malformed and valid revisions, then force eviction and verify both bounded memory and correct reparsing. Deliverables - Profile comparison, bounded parsed-tariff cache and regression tests Rollout and recovery: Gate parsed-tariff reuse behind a switch; reverting uses the original parser and discards only derived cache entries. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PLATENCY-105 — Stop expired quotes from holding carrier connections **Bug · High priority · Advanced** noCV practice brief v5 · PLATENCY-105 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove demonstrated bottlenecks. Depends on: PLATENCY-102, PLATENCY-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Networking 30% · Backend 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A client disconnects after its deadline, but the carrier lookup continues and consumes one of the few available connections. Acceptance criteria - Propagate the remaining deadline through queue admission and the carrier client. - Release the connection and remove queued work when the request is cancelled, including cancellation before dispatch. - Return one bounded timeout outcome without automatically retrying a request whose caller has left. Implementation constraints - Use the stub to control headers, body completion and connection close separately; wall-clock sleeps alone do not prove cleanup. Verification - Cancel before dispatch, while waiting for headers and during a streamed response; count active work returning to baseline. - Race normal completion against cancellation and confirm one response classification and no unhandled rejection. Deliverables - Deadline propagation and deterministic cancellation tests Rollout and recovery: Canary the deadline path with active-connection counters; restore the previous client only after pending work drains. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PLATENCY-106 — Bound parallel carrier lookups without serializing every quote **Story · High priority · Advanced** noCV practice brief v5 · PLATENCY-106 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove demonstrated bottlenecks. Depends on: PLATENCY-101, PLATENCY-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Backend 30% · Site reliability 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Multi-stop quotes fan out immediately. A burst exhausts the carrier stub connection pool and slows unrelated single-stop traffic. Acceptance criteria - Apply a configurable global in-flight limit and a bounded admission queue. - Remove cancelled entries promptly and define fairness so a large quote cannot monopolize all new slots. - Preserve the required carrier results or return an explicit incomplete-quote outcome; never silently price from a partial result. Implementation constraints - Compare limits using the fixed traffic mix and a stub with a declared service-time distribution. Verification - Run single-stop and multi-stop requests together and verify the configured concurrency ceiling. - Overfill the queue, cancel its head and inject a carrier failure; verify forward progress and no leaked permit. Deliverables - Admission controller, mixed-traffic measurements and permit invariants Rollout and recovery: Start with the current safe connection limit; queue rejection is observable and the feature switch restores the previous dispatch path. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PLATENCY-107 — Check whether quote serialization is blocking unrelated requests **Task · Medium priority · Intermediate** noCV practice brief v5 · PLATENCY-107 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove demonstrated bottlenecks. Depends on: PLATENCY-101, PLATENCY-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 70% · Backend 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The largest multi-stop responses correlate with event-loop delay. The team has proposed adding workers before confirming where time is spent. Acceptance criteria - Capture CPU and event-loop delay measurements for small and maximum-size synthetic quote responses. - Separate JSON serialization cost from database and dependency time in the experiment. - Produce a decision note identifying the measured bottleneck, uncertainty and one bounded next change; report when the hypothesis is unsupported. Implementation constraints - Use three repeated baseline runs after warmup on the same runtime and resource limits; save the measurement commands. Verification - Repeat with a prebuilt response body to isolate serialization while retaining the same payload size. - Run a small health request concurrently and compare its tail latency with and without the large-response workload. Deliverables - Reproducible profiling report and supported next-step decision Rollout and recovery: This investigation changes no serving path; retain the baseline commands for the implementation review. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Protect the improvement Use tail-aware admission and a reversible release gate. #### PLATENCY-108 — Choose an overload policy from the quote deadline budget **Task · High priority · Expert** noCV practice brief v5 · PLATENCY-108 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the improvement. Depends on: PLATENCY-102, PLATENCY-105, PLATENCY-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Site reliability 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. At overload, a larger queue increases completed work but most quotes arrive after the dispatch screen has already given up. Acceptance criteria - Compare at least two admission policies at 0.5, 1.0 and 1.5 times the measured sustainable arrival rate. - Evaluate deadline success rate, rejection rate, p99 and queue depth together; document the selected tradeoff. - Implement the selected bounded policy and retain exact pricing correctness for every admitted request. Implementation constraints - Use an open-loop arrival schedule and account for generator saturation; define sustainable rate from the recorded local baseline, not a guessed production number. Verification - Run three repetitions per load level after fixed warmup and publish spread, request counts and all timeout outcomes. - Inject a carrier slowdown midway through a run and show queue depth remains bounded and recovery does not require restart. Deliverables - Admission decision record, load results and overload recovery regression Rollout and recovery: Canary against the declared deadline-success guardrail; revert policy configuration if correctness or rejection behavior differs from the approved contract. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PLATENCY-109 — Make the quote benchmark fail when the generator cannot keep up **Chore · Medium priority · Intermediate** noCV practice brief v5 · PLATENCY-109 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the improvement. Depends on: PLATENCY-101, PLATENCY-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 70% · Quality engineering 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A promising result came from a generator sharing the API CPU quota. It slowed its own arrivals and reported a workload the service never received. Acceptance criteria - Record scheduled versus actual send time and count requests the generator could not issue. - Invalidate comparisons when dispatch lag exceeds the manifest threshold or achieved load falls below the declared tolerance. - Keep server and generator resource measurements distinguishable even when both run on one development machine. Implementation constraints - Document the local topology and quota allocation; do not require a paid load-testing service. Verification - Throttle the generator deliberately and verify the run is rejected as incomparable. - Run a valid low-load fixture and reconcile planned, sent, completed and failed request totals. Deliverables - Generator health gate and an intentionally invalid benchmark sample Rollout and recovery: Add the gate to the local benchmark command before accepting further performance comparisons. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PLATENCY-110 — Gate quote changes on repeated tail-latency and correctness checks **Chore · High priority · Expert** noCV practice brief v5 · PLATENCY-110 · Find the missing seconds in the quote API Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Protect the improvement. Depends on: PLATENCY-104, PLATENCY-106, PLATENCY-108, PLATENCY-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Quality engineering 30% · Site reliability 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The team can demonstrate one fast run, but it has no rule for accepting noisy results or reverting a change that prices correctly only at low concurrency. Acceptance criteria - Use the fixed workload and three paired runs after warmup; report all runs and median p99 with spread. - For this exercise require unchanged fixture outputs, no higher timeout rate and at least 15% lower median p99 at the declared baseline arrival rate. - Mark an unstable or generator-invalid result inconclusive and stop promotion; retain the prior configuration and a documented rollback command. Implementation constraints - The 15% threshold is an exercise acceptance budget on the declared machine, not a universal performance promise. Verification - Run the candidate and baseline in alternating order and retain raw histograms and output comparisons. - Introduce a known pricing regression and a deliberately slow candidate separately; both must block the release gate for the relevant reason. Deliverables - Repeatable release check, run artifacts and rollback rehearsal notes Rollout and recovery: Promote only within the synthetic environment after the gate passes; restore the previous configuration and repeat the same workload to verify recovery. Project prerequisites: Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied. Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings. Engineer value: Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations. Company value: Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.