# 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. ## PIPE — Make parcel tracking survive messy carrier events A fictional delivery marketplace receives JSON batches from three carriers. One uses local timestamps, another retries whole batches, and a third corrects delivery scans. Customer support needs a stable timeline rather than the last payload received. **Field:** Data engineering. **Suggested stack:** TypeScript, PostgreSQL, BullMQ, S3-compatible storage. **Engineer value:** Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. **Company value:** Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. **Delivery agreement:** Ten tickets in three phases; hand off synthetic carrier fixtures, a replay procedure, and a support-readable tracking projection. ### Setup prerequisites - JSON schema validation - SQL queries - Event-time concepts ### Receive and quarantine Keep valid events and explain rejected input. #### PIPE-101 — Validate carrier events without discarding a whole batch **Task · High priority · Foundational** noCV practice brief v5 · PIPE-101 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Receive and quarantine. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 80% · API design 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 200-event batch contains one scan with an empty parcel reference. The importer rejects all 200, leaving valid deliveries invisible until the next carrier export. Acceptance criteria - Classify each row as accepted or rejected with a source position. - Require carrier event ID, parcel reference, event code, and timestamp. - Accepted and rejected counts sum to the received count. Implementation constraints - Publish the partial-acceptance contract; never silently drop malformed rows. Verification - Process 199 valid rows and one malformed row with exact counts. - Reject oversized batches and invalid JSON without accepted events. Deliverables - Batch validation contract and mixed-validity fixtures Rollout and recovery: Enable partial acceptance for one synthetic carrier; retain rejection reports if the route is disabled. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-102 — Attach source lineage to every accepted scan **Chore · Medium priority · Foundational** noCV practice brief v5 · PIPE-102 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Receive and quarantine. Depends on: PIPE-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 80% · 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. Support found a delivery scan that neither carrier recognizes. The normalized table contains no batch hash, row position, or parser version to trace its origin. Acceptance criteria - Store batch hash, row position, carrier identity, receipt time, and parser version. - Link normalized records to a bounded source artifact reference. - Restrict artifact retrieval to ingest support permission. Implementation constraints - Use synthetic data; do not copy full payloads into logs. Verification - Trace two accepted rows to their exact source positions. - Deny a tracking viewer direct source-artifact access. Deliverables - Lineage migration and trace example Rollout and recovery: Populate new imports first and mark untraceable legacy rows explicitly. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-103 — Deduplicate carrier retries and surface changed duplicates **Bug · High priority · Intermediate** noCV practice brief v5 · PIPE-103 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Receive and quarantine. Depends on: PIPE-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. Carrier Cedar retries yesterday's batch. Most event IDs are identical, but one delivery timestamp changed from 14:03 to 14:30 and is overwritten silently. Acceptance criteria - Identical carrier-scoped event IDs and content replay without duplicate scans. - Changed content under an existing ID enters a conflict record. - Concurrent duplicate imports converge to one accepted event. Implementation constraints - An event ID from another carrier is a separate identity. Verification - Replay the batch twice and compare accepted counts. - Submit changed content and concurrent duplicates; inspect originals and conflicts. Deliverables - Deduplication constraint and conflict handling contract Rollout and recovery: Observe duplicate classifications before enforcement; preserve originals if conflict routing is rolled back. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. ### Build the tracking timeline Resolve time, order, and corrections explicitly. #### PIPE-104 — Stop interpreting offset-free scans as server-local time **Bug · High priority · Advanced** noCV practice brief v5 · PIPE-104 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the tracking timeline. Depends on: PIPE-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 100%. 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 carrier sends 2025-11-02 01:30 in its configured New York time zone. The importer guesses one occurrence during the clock change and displays delivery before pickup. Acceptance criteria - Normalize explicit-offset timestamps to UTC. - Quarantine ambiguous or nonexistent local times instead of guessing. - Preserve original timestamp text and normalization policy version. Implementation constraints - Use explicit carrier time-zone configuration; process time zone cannot define event meaning. Verification - Normalize equivalent UTC and offset timestamps to one instant. - Quarantine repeated-hour and skipped-hour local timestamps. Deliverables - Timestamp normalization policy and clock-change fixtures Rollout and recovery: Shadow-normalize historical fixtures and review differences before switching timeline timestamps. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-105 — Keep a late pickup scan from undoing delivered status **Bug · High priority · Intermediate** noCV practice brief v5 · PIPE-105 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the tracking timeline. Depends on: PIPE-103, PIPE-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 80% · 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. A DELIVERED scan arrives at 16:00, followed by a delayed PICKED_UP scan from 08:00. The tracking card switches back to In transit because it uses receipt order. Acceptance criteria - Build the timeline from event time with a documented deterministic tie-breaker. - Retain late scans without regressing current delivery state. - Represent inconsistent event sequences with a visible anomaly reason. Implementation constraints - Receipt time remains diagnostic information, not a substitute for event time. Verification - Import pickup and delivery in both arrival orders and compare projections. - Add a pickup dated after delivery and inspect the anomaly. Deliverables - Tracking projection and out-of-order fixtures Rollout and recovery: Compare projections in a shadow table; switch reads after reviewing differences. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-106 — Apply an explicit carrier correction without erasing the scan **Story · High priority · Advanced** noCV practice brief v5 · PIPE-106 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Build the tracking timeline. Depends on: PIPE-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Database 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 driver scanned the wrong parcel as delivered. The carrier now sends corrections referencing the original scan; support must see why Delivered became In transit. Acceptance criteria - Require a same-carrier, same-parcel target event. - Keep the original scan and append the correction relationship. - Recompute the projection and expose the withdrawn delivery scan. Implementation constraints - Missing targets become pending references with bounded retry, never permission to delete arbitrary events. Verification - Apply a valid delivery withdrawal and inspect history and state. - Reject a cross-parcel target and resolve a target that arrives later. Deliverables - Correction contract and deferred-reference recovery Rollout and recovery: Enable the configured correction-capable carrier; retain history if projection readers are rolled back. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. ### Replay and monitor Repair data safely and detect silent ingestion gaps. #### PIPE-107 — Replay a parser fix into a new projection generation **Task · High priority · Expert** noCV practice brief v5 · PIPE-107 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Replay and monitor. Depends on: PIPE-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 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. Parser v3 mislabeled ARRIVED_AT_DEPOT as DELIVERED. Operations needs to rebuild 100,000 synthetic scans while fresh batches continue arriving. Acceptance criteria - Replay immutable sources into an isolated projection generation. - Capture a high-water mark and include arrivals through the documented cutover boundary. - Switch readers atomically only after counts and anomaly checks pass. Implementation constraints - Record parser and projection versions; rebuilding cannot mutate sources. Verification - Replay twice and compare deterministic output hashes. - Interrupt replay and add events during catch-up; prove no cutover gaps. Deliverables - Replay command, generation cutover, and recovery runbook Rollout and recovery: Keep the previous generation readable and revert its pointer if comparison fails. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-108 — Throttle ingestion without losing accepted batches **Task · High priority · Advanced** noCV practice brief v5 · PIPE-108 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Replay and monitor. Depends on: PIPE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Performance engineering 30% · Distributed 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. After an outage, one carrier sends a day's events in 30 seconds. Memory pressure restarts workers and the API cannot tell which batches were accepted. Acceptance criteria - Bound request size and active ingest concurrency. - Acknowledge only after durable source and dispatch intent exist. - Return retryable overload before accepting work above the backlog limit. Implementation constraints - Distinguish rejected-before-acceptance from delayed-after-acceptance responses. Verification - Burst synthetic batches and account for every acknowledged batch. - Fail storage and saturate the queue; assert no false acceptance. Deliverables - Backpressure limits and accepted-batch accounting test Rollout and recovery: Start with conservative limits; reduce intake while draining accepted work if lag grows. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-109 — Detect a quiet carrier feed independently of queue health **Chore · Medium priority · Intermediate** noCV practice brief v5 · PIPE-109 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Replay and monitor. Depends on: PIPE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Site reliability 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. Every worker is healthy, but Carrier Elm has not sent a batch since morning. No alert fires because all dashboards measure processing failures. Acceptance criteria - Track last accepted receipt separately from event-time freshness. - Apply each carrier's configured operating schedule and lateness budget. - Feed-gap alerts name the integration and diagnostic step without parcel data. Implementation constraints - Empty valid batches count as receipts but do not imply fresh parcel scans. Verification - Advance the clock during operating hours to trigger a feed-gap alert. - Suppress quiet-window paging and distinguish stale event times. Deliverables - Freshness metrics, alert rule, and escalation notes Rollout and recovery: Review a simulated week in report-only mode before enabling paging. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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. #### PIPE-110 — Expire raw tracking payloads while retaining minimal lineage **Task · Medium priority · Advanced** noCV practice brief v5 · PIPE-110 · Make parcel tracking survive messy carrier events Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Replay and monitor. Depends on: PIPE-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Data engineering 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. Carrier payloads contain recipient notes unnecessary after the exercise's 30-day debugging window. A cleanup script removes artifacts still used by an active replay. Acceptance criteria - Delete eligible raw artifacts after configured retention. - Protect artifacts referenced by an active authorized replay lease. - Retain minimal hashes, deletion receipts, and normalized non-sensitive facts. Implementation constraints - Thirty days is a fictional exercise policy; expired leases cannot pin data forever. Verification - Expire an eligible artifact and verify its deletion record. - Protect an active replay artifact, then expire the lease and delete it. Deliverables - Retention job and replay-lease cleanup cases Rollout and recovery: Review a dry-run deletion manifest before enabling deletion on synthetic artifacts. Project prerequisites: JSON schema validation SQL queries Event-time concepts Engineer value: Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair. Company value: Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events. 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.