# 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. ## ABATCH — Aggregate parallel risk checks without losing partial outcomes A fictional vendor portal runs format, policy and duplicate checks in parallel. A slow checker blocks completion, while duplicate callbacks can produce contradictory final summaries. **Field:** Distributed systems. **Suggested stack:** TypeScript, PostgreSQL, Provider interfaces. **Engineer value:** Practice fan-out/fan-in, deadline policies and immutable aggregation. **Company value:** Review trustworthy partial-result handling and controllable parallel work. **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 synthetic document identities and three fake check providers. - No real risk scoring, hiring decisions or candidate execution is included. ### Define independent check facts Specify input identity, required checks and result states. #### ABATCH-101 — Freeze the required check set when a document review run starts **Task · Medium priority · Foundational** noCV practice brief v5 · ABATCH-101 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define independent check facts. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Backend 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 configuration change adds a checker while a run is in progress, so the completion predicate changes halfway through. Acceptance criteria - Record exact checker identities and versions per run. - Bind the set to immutable document input identity. - New configuration affects only new runs. Implementation constraints - Use three deterministic fake checks with no capability scoring. Verification - Start runs before and after a check-set change. - Finish the older run using its original required set. Deliverables - Review-run manifest Rollout and recovery: Publish frozen manifests before parallel dispatch; retain prior checker versions for replay. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-102 — Define pass, fail, unavailable and not-applicable check outcomes **Task · Medium priority · Intermediate** noCV practice brief v5 · ABATCH-102 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define independent check facts. Depends on: ABATCH-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · API 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. A timed-out policy checker returns an empty findings list, which the aggregator interprets as passed. Acceptance criteria - Use explicit outcome states with bounded structured details. - Require justification for not-applicable under the declared contract. - Keep unavailable distinct from an empty successful result. Implementation constraints - Reject unsupported fields and prohibit demographic or personality inferences. Verification - Accept a valid empty successful check. - Timeout a checker and retain unavailable rather than pass. Deliverables - Check-result schema and semantic cases Rollout and recovery: Deploy result validation before aggregate updates; quarantine incompatible provider output. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-103 — Bound parallel check fan-out per organization and run **Task · Medium priority · Foundational** noCV practice brief v5 · ABATCH-103 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define independent check facts. Depends on: ABATCH-101, ABATCH-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Performance engineering 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. One tenant submits many documents and the coordinator starts every check immediately, exhausting provider slots. Acceptance criteria - Set explicit per-run and per-tenant in-flight limits. - Persist queued attempts instead of dropping them. - Return admission status separate from check completion. Implementation constraints - Use documented synthetic limits and a fake provider counter. Verification - Dispatch a permitted number of synthetic checks. - Exceed the tenant limit and verify excess work remains queued without provider calls. Deliverables - Fan-out admission guard Rollout and recovery: Canary conservative limits; pause admission when provider capacity is unknown. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. ### Coordinate parallel outcomes Dispatch, deduplicate and finalize with explicit deadlines. #### ABATCH-104 — Dispatch each check through a durable deterministic attempt identity **Story · Medium priority · Advanced** noCV practice brief v5 · ABATCH-104 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate parallel outcomes. Depends on: ABATCH-101, ABATCH-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Database engineering 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. The coordinator crashes after dispatching one checker and cannot tell which of the three still needs to start. Acceptance criteria - Persist check-attempt identity and outbox dispatch per required checker. - Keep dispatch retries bound to the same input and checker version. - Reject contradictory reuse of an attempt identity. Implementation constraints - Call providers outside the database transaction. Verification - Crash after one dispatched check and resume remaining work. - Replay an outbox fact and keep one logical provider attempt. Deliverables - Check dispatch transaction and crash probe Rollout and recovery: Prototype with fake providers; stop new runs if attempt identity cannot be persisted. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-105 — Deduplicate callbacks without accepting contradictory check results **Task · High priority · Advanced** noCV practice brief v5 · ABATCH-105 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate parallel outcomes. Depends on: ABATCH-102, ABATCH-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Integrations 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 provider retries its callback and later sends a changed result for the same attempt ID. Acceptance criteria - Identical callback retries resolve one recorded result. - Different terminal content for the same attempt creates a conflict. - Validate run, input and checker identities before recording. Implementation constraints - Use canonical result hashes and authenticated fixture callbacks. Verification - Deliver the same terminal callback twice. - Alter a terminal result or input hash and keep the accepted result plus a visible conflict. Deliverables - Callback ingestion guard Rollout and recovery: Canary callback handling; quarantine contradictory provider output without rewriting terminal facts. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-106 — Finalize aggregates only from the frozen required check set **Task · High priority · Expert** noCV practice brief v5 · ABATCH-106 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate parallel outcomes. Depends on: ABATCH-101, ABATCH-102, ABATCH-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Backend 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. An optional checker finishes quickly and accidentally satisfies a counter-based completion condition while a required checker is missing. Acceptance criteria - Evaluate completeness by exact required identities. - Compute aggregate state from validated immutable check facts. - Reject finalization when required results are missing or conflicting. Implementation constraints - Define aggregate output as review status, never an opaque hire/reject score. Verification - Finish all required checks and produce the expected status. - Complete extra optional checks while omitting one required check and block completion. Deliverables - Aggregate reducer and completeness tests Rollout and recovery: Enable guarded finalization before publishing results; retain pending state on missing authority. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-107 — Apply a run deadline without rewriting late check facts **Story · Medium priority · Intermediate** noCV practice brief v5 · ABATCH-107 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Coordinate parallel outcomes. Depends on: ABATCH-102, ABATCH-106. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Backend 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 slow checker returns after the review deadline and overwrites a summary already shown to the user. Acceptance criteria - Define a deadline terminal state with explicit incomplete checks. - Preserve late results as appended facts without mutating the frozen summary. - Allow a new run or reviewed amendment under an explicit policy. Implementation constraints - Use an injected clock and exact boundary cases. Verification - Complete required checks before deadline. - Return one check after deadline and retain the original summary plus late-result visibility. Deliverables - Deadline finalization and late-result cases Rollout and recovery: Canary synthetic short deadlines; create new runs when a policy change requires reevaluation. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. ### Recover incomplete runs Replay work and explain aggregate provenance. #### ABATCH-108 — Recover outstanding checks by querying provider attempt identity **Task · Medium priority · Expert** noCV practice brief v5 · ABATCH-108 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover incomplete runs. Depends on: ABATCH-104, ABATCH-105, ABATCH-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Integrations 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. After a restart, several attempts are marked dispatched but have no callback; immediate resubmission may duplicate costly work. Acceptance criteria - Reconcile each unresolved attempt through its provider identity. - Redispatch only under the adapter's declared idempotency contract. - Keep unknown provider state visible and bounded. Implementation constraints - Use fake providers that model lost callbacks and unavailable lookup. Verification - Recover a completed check whose callback was lost. - Make provider lookup unavailable and verify no unsupported success or duplicate attempt. Deliverables - Outstanding-attempt reconciler Rollout and recovery: Start recovery with bounded batches; suspend affected adapters when identity guarantees fail. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-109 — Produce a result provenance view that names missing and conflicting checks **Story · Medium priority · Foundational** noCV practice brief v5 · ABATCH-109 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover incomplete runs. Depends on: ABATCH-105, ABATCH-106, ABATCH-107, ABATCH-108. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · API design 30% · Privacy 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. Users receive only a summary label and cannot inspect whether every required checker actually ran. Acceptance criteria - List frozen checker versions and input identity. - Show outcome, unavailable and conflict states separately. - Keep internal prompts, secrets and raw provider traces out of the view. Implementation constraints - Use public practice facts only; this is not noCV assessment evidence. Verification - Inspect a complete synthetic aggregate. - Inspect a deadline result and clearly identify the missing checker. Deliverables - Safe provenance projection Rollout and recovery: Publish read-only provenance with aggregate status; hide fields that fail schema review. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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. #### ABATCH-110 — Exercise the parallel-check coordinator under reordered failures **Chore · Medium priority · Advanced** noCV practice brief v5 · ABATCH-110 · Aggregate parallel risk checks without losing partial outcomes Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover incomplete runs. Depends on: ABATCH-105, ABATCH-106, ABATCH-107, ABATCH-108, ABATCH-109. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Distributed systems 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. Happy-path tests always complete checks in the same order and miss a race between deadline finalization and the last callback. Acceptance criteria - Run permutations of declared completion, timeout and conflict events. - Assert one immutable summary and complete retained check history. - Record any unsupported adapter guarantee as a failing readiness condition. Implementation constraints - Use a deterministic event scheduler; no arbitrary sleeps. Verification - Run all required checks in several completion orders with equal final semantics. - Race final callback with deadline and verify the declared single outcome. Deliverables - Deterministic coordinator fault harness Rollout and recovery: Require the harness before adapter changes; retain the prior coordinator version if invariants fail. Project prerequisites: Create synthetic document identities and three fake check providers. No real risk scoring, hiring decisions or candidate execution is included. Engineer value: Practice fan-out/fan-in, deadline policies and immutable aggregation. Company value: Review trustworthy partial-result handling and controllable parallel work. 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.