# 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. ## AADMIT — Design admission control for scheduled report generation A fictional analytics product lets customers schedule expensive reports at the top of the hour. The API remains available only if report work is admitted and cancelled predictably. **Field:** System design. **Suggested stack:** TypeScript, PostgreSQL, BullMQ. **Engineer value:** Practice workload modeling, fairness and cancellation architecture. **Company value:** Review controllable operating costs and predictable customer-facing overload behavior. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a local scheduler model and synthetic report jobs. - Use fake execution providers; no customer queries or candidate code run on worker hosts. ### Define load and fairness Make demand and service objectives explicit. #### AADMIT-101 — Build a report arrival model that includes top-of-hour bursts **Task · Medium priority · Foundational** noCV practice brief v5 · AADMIT-101 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define load and fairness. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Performance engineering 50%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Average reports per minute looks harmless, but nearly every customer chooses 09:00 for its daily report. Acceptance criteria - Separate average arrival rate from burst size. - State hypothetical report duration and size classes. - Include timezone scheduling assumptions. Implementation constraints - Create a deterministic synthetic one-day schedule. Verification - Count average arrivals and the largest one-minute burst. - Move all schedules to one instant and show the peak changes despite equal daily volume. Deliverables - Arrival model and reproducible schedule generator Rollout and recovery: Review the model before queue sizing; revise assumptions when schedule usage is measured. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-102 — Define customer-visible report states and overload responses **Task · Medium priority · Intermediate** noCV practice brief v5 · AADMIT-102 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define load and fairness. Depends on: AADMIT-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · System design 30% · Backend 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 API returns accepted for jobs that may wait indefinitely, so customers repeatedly click generate. Acceptance criteria - Distinguish rejected, queued, running and terminal states. - Specify bounded queue age and a retryable admission response. - Define what acceptance durably guarantees. Implementation constraints - Use explicit state transitions and stable job identities. Verification - Trace an admitted report to its durable queue state. - Reject an over-capacity request without creating a phantom report. Deliverables - Admission response contract and state table Rollout and recovery: Review the contract before accepting schedules; keep overload behavior explicit in the prototype. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-103 — Record the fairness decision for small and large report tenants **Task · Medium priority · Foundational** noCV practice brief v5 · AADMIT-103 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define load and fairness. Depends on: AADMIT-101, AADMIT-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Distributed systems 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 single tenant's weekly exports occupy every available slot while small interactive reports wait behind them. Acceptance criteria - Compare FIFO, per-tenant limits and weighted scheduling. - Define fairness and starvation expectations. - Document how unknown report cost is classified. Implementation constraints - Use a small synthetic tenant set and avoid hiring or user scoring. Verification - Evaluate a mixed small/large workload against the chosen rule. - Show the behavior when one tenant continuously submits work. Deliverables - Fairness decision record Rollout and recovery: Review the chosen policy with the workload model; retain configuration for bounded tuning. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. ### Specify admission and work ownership Bound queues, retries and cancellation. #### AADMIT-104 — Specify transactional report admission with deterministic job identities **Story · Medium priority · Advanced** noCV practice brief v5 · AADMIT-104 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify admission and work ownership. Depends on: AADMIT-102, AADMIT-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 40% · Database 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. A scheduler creates report rows but loses queue publication, leaving accepted work with no execution path. Acceptance criteria - Commit admission and outbox fact atomically. - Bind job identity to schedule occurrence or request key. - Make repeated dispatch resolve one logical job. Implementation constraints - Keep lifecycle authority in the durable service boundary. Verification - Crash after admission commit and recover dispatch. - Replay the same scheduled occurrence and count one report. Deliverables - Admission/outbox contract and crash probe Rollout and recovery: Prototype with a fake executor; stop new admission if durable dispatch cannot be recorded. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-105 — Design cancellation ownership for queued and running reports **Task · Medium priority · Expert** noCV practice brief v5 · AADMIT-105 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify admission and work ownership. Depends on: AADMIT-102, AADMIT-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Distributed systems 30% · Storage systems 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. A user cancels a report, but the worker later publishes a completed artifact and overwrites the cancellation status. Acceptance criteria - Define cancellation request versus confirmed stop. - Fence stale completion against current generation and state. - Specify cleanup ownership for incomplete artifacts. Implementation constraints - Use a provider cancellation contract; do not kill host processes arbitrarily. Verification - Cancel queued work and verify no execution begins. - Race cancellation with completion and preserve the declared single terminal outcome. Deliverables - Cancellation protocol and race model Rollout and recovery: Canary cancellation in the local provider; retain unresolved stop status when provider confirmation is unavailable. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-106 — Bound retries so failing reports cannot consume the entire service **Task · Medium priority · Advanced** noCV practice brief v5 · AADMIT-106 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify admission and work ownership. Depends on: AADMIT-103, AADMIT-104, AADMIT-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Site reliability 30% · Platform 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. A malformed report fails immediately and retries faster than healthy reports can start. Acceptance criteria - Define retry count, backoff and elapsed-time budgets. - Classify permanent versus retryable failure explicitly. - Keep retry work inside tenant and global admission limits. Implementation constraints - Use deterministic fake time and bounded jitter inputs. Verification - Retry a transient failure within the declared budget. - Feed a permanent failure and verify it cannot form a tight retry loop. Deliverables - Retry-budget model and scheduling probe Rollout and recovery: Enable bounded retries for synthetic jobs; suspend a failing class if classification is uncertain. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-107 — Choose where report artifacts become authoritative **Story · Medium priority · Intermediate** noCV practice brief v5 · AADMIT-107 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify admission and work ownership. Depends on: AADMIT-104, AADMIT-105. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · System design 30% · Security 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. A worker uploads a partial file and the API exposes its object key before completion checks finish. Acceptance criteria - Stage artifacts under a job generation. - Publish only after verified storage identity and guarded completion. - Keep incomplete or stale-generation artifacts inaccessible. Implementation constraints - Separate object upload from user-visible report publication. Verification - Publish a verified synthetic artifact for the active job. - Complete an older generation and verify it cannot replace the visible result. Deliverables - Artifact publication boundary and contract probe Rollout and recovery: Prototype with local storage; keep staged objects private until finalization succeeds. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. ### Challenge overload behavior Model burst recovery and review operating limits. #### AADMIT-108 — Calculate burst drain time with fairness and retry reservations **Task · Medium priority · Expert** noCV practice brief v5 · AADMIT-108 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge overload behavior. Depends on: AADMIT-101, AADMIT-103, AADMIT-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · System design 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. Operations wants a queue-age target, but the capacity spreadsheet assumes every slot is always available for first attempts. Acceptance criteria - Model concurrency, service-time classes and reserved retry capacity. - Calculate per-tenant wait under the selected fairness rule. - Show when queue-age targets cannot be met. Implementation constraints - Use hypothetical durations and an executable deterministic simulation. Verification - Simulate the declared top-of-hour burst. - Double expensive reports and report target violations without inventing a speedup. Deliverables - Queue simulation and capacity worksheet Rollout and recovery: Use the model to propose reviewed limits; validate assumptions with real isolated measurements before deployment. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-109 — Rehearse scheduler restart while reports are queued and running **Task · Medium priority · Advanced** noCV practice brief v5 · AADMIT-109 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge overload behavior. Depends on: AADMIT-104, AADMIT-105, AADMIT-107, AADMIT-108. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 40% · 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 scheduling process restarts during a burst, and the design must explain which work is resumed, reconciled or left uncertain. Acceptance criteria - Recover queued ownership from durable identities. - Reconcile running jobs through provider status before retry. - Preserve accepted artifacts and terminal outcomes. Implementation constraints - Inject failures in a local state model and fake provider. Verification - Restart with queued and completed synthetic jobs and converge correctly. - Restart with an unknown provider outcome and keep it unresolved instead of duplicating work. Deliverables - Restart drill and recovery trace Rollout and recovery: Run before accepting real schedules; pause admissions if recovery cannot establish work ownership. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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. #### AADMIT-110 — Write the report-service operating contract for design approval **Chore · Medium priority · Foundational** noCV practice brief v5 · AADMIT-110 · Design admission control for scheduled report generation Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge overload behavior. Depends on: AADMIT-102, AADMIT-108, AADMIT-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 70% · Site reliability 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 launch checklist says scalable reporting without naming admission limits, cancellation guarantees or unavailable-provider behavior. Acceptance criteria - Summarize admitted workload, fairness and bounded queue behavior. - Link each guarantee to a model or probe. - List deferred execution-provider and production-measurement work. Implementation constraints - Keep design approval separate from production readiness. Verification - Trace a queue-age target to its simulation assumptions. - Trace provider unavailability to a documented pending or rejected outcome. Deliverables - Operating contract and architecture review notes Rollout and recovery: Review before infrastructure commitment; update limits when measurement evidence replaces assumptions. Project prerequisites: Create a local scheduler model and synthetic report jobs. Use fake execution providers; no customer queries or candidate code run on worker hosts. Engineer value: Practice workload modeling, fairness and cancellation architecture. Company value: Review controllable operating costs and predictable customer-facing overload behavior. 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.