# 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. ## AINGEST — Recover a partner telemetry ingestion pipeline A fictional energy dashboard receives hourly device batches. Corrupt archives and late corrections leave operators unsure which readings reached reports. **Field:** Data engineering. **Suggested stack:** Python, PostgreSQL, Object storage. **Engineer value:** Practice batch integrity, replay and data-quality boundaries. **Company value:** Review whether operational data can be traced, corrected and recovered. **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 device batches and local object-store fixtures. - Understand checksums and bounded streaming. ### Validate batch boundaries Reject unsafe or ambiguous inputs before loading. #### AINGEST-101 — Record a manifest before decoding a telemetry batch **Task · Medium priority · Foundational** noCV practice brief v5 · AINGEST-101 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate batch boundaries. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Storage 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. Operators see a failed file name but cannot identify the original bytes or the parser version used. Acceptance criteria - Record object version, byte hash and declared format. - Bind each ingestion attempt to one manifest. - Reject a changed object version on retry. Implementation constraints - Use synthetic object metadata; avoid storing credentials in manifests. Verification - Retry unchanged bytes against the same manifest. - Replace bytes under the same object key and report identity mismatch. Deliverables - Manifest schema and identity checks Rollout and recovery: Start manifests for new batches; retain earlier records as explicitly untracked. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-102 — Cap decompressed telemetry bytes before archive expansion **Bug · High priority · Advanced** noCV practice brief v5 · AINGEST-102 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate batch boundaries. Depends on: AINGEST-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 40% · Performance engineering 30% · Security 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 tiny compressed batch expands far beyond the ingestion worker's memory budget. Acceptance criteria - Enforce compressed, expanded-byte and row limits. - Stop streaming as soon as a bound is crossed. - Quarantine with a reason without loading partial rows. Implementation constraints - Do not unpack paths or execute files from archives. Verification - Ingest a valid compressed synthetic batch. - Exercise excessive expansion and path-like entry names without writing outside staging. Deliverables - Bounded decoder and hostile archive fixtures Rollout and recovery: Enable bounded decoding before partner intake; keep rejected objects quarantined. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-103 — Normalize sensor units through a versioned conversion table **Task · Medium priority · Intermediate** noCV practice brief v5 · AINGEST-103 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate batch boundaries. Depends on: AINGEST-101. Difficulty: Intermediate. Estimated focused work: 150 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. Two device models emit watt-hours and kilowatt-hours under the same field name. Acceptance criteria - Require a known unit and conversion version. - Preserve raw numeric value and declared unit in lineage. - Reject unsupported units and nonfinite measurements. Implementation constraints - Use decimal arithmetic for documented conversions. Verification - Convert synthetic Wh and kWh to equal canonical readings. - Reject missing units and nonfinite input. Deliverables - Unit conversion contract and cases Rollout and recovery: Publish conversion revisions for new runs; retain old mappings for replay. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. ### Load traceable records Preserve lineage and deterministic corrections. #### AINGEST-104 — Commit telemetry rows and the batch checkpoint atomically **Story · High priority · Advanced** noCV practice brief v5 · AINGEST-104 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Load traceable records. Depends on: AINGEST-102, AINGEST-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Database 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. A process dies after inserting rows but before marking the file complete; replay doubles reported usage. Acceptance criteria - Persist rows and committed checkpoint in one transaction. - Use source reading identity to reject duplicate insertion. - Retries return committed counts without adding readings. Implementation constraints - Bound transaction size; larger batches require explicit sub-batch identities. Verification - Kill the test process at modeled commit boundaries. - Replay a completed sub-batch and compare row counts and totals. Deliverables - Atomic batch loader and crash probe Rollout and recovery: Canary small batches; pause loading and inspect manifests if reconciliation diverges. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-105 — Quarantine malformed readings with usable row coordinates **Story · Medium priority · Foundational** noCV practice brief v5 · AINGEST-105 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Load traceable records. Depends on: AINGEST-102, AINGEST-103. Difficulty: Foundational. Estimated focused work: 90 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 malformed timestamp makes the ingestion job fail with a stack trace and no indication of the source row. Acceptance criteria - Report manifest ID, row number and stable reason code. - Keep rejected values out of generic logs. - Publish accepted and rejected counts under the declared partial-load policy. Implementation constraints - Choose and document all-or-nothing versus row quarantine for this dataset. Verification - Load a batch containing valid rows under the chosen policy. - Insert malformed timestamps and verify coordinates and count invariants. Deliverables - Quarantine report and policy tests Rollout and recovery: Enable reports before changing load policy; replay corrected manifests as new attempts. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-106 — Apply corrected readings without overwriting source history **Story · Medium priority · Expert** noCV practice brief v5 · AINGEST-106 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Load traceable records. Depends on: AINGEST-104, AINGEST-105. Difficulty: Expert. Estimated focused work: 300 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 device sends a corrected cumulative reading two days late; a blind upsert destroys the value used in yesterday's report. Acceptance criteria - Append corrections linked to source reading and revision. - Define the effective reading deterministically. - Reject contradictory equal-revision corrections for review. Implementation constraints - Preserve original ingestion time separately from measurement time. Verification - Apply a higher revision and inspect both historical values. - Submit equal revision with changed value and retain the last valid projection. Deliverables - Correction model and conflict cases Rollout and recovery: Enable corrections for one synthetic device; rebuild projections from retained history on rollback. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-107 — Use event-time watermarks without discarding late telemetry silently **Task · Medium priority · Advanced** noCV practice brief v5 · AINGEST-107 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Load traceable records. Depends on: AINGEST-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 70% · Real-time systems 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 hourly aggregate closes by arrival time and quietly ignores a delayed batch from an offline device. Acceptance criteria - Define watermark advancement and allowed lateness. - Route late readings to a visible correction path. - Report aggregate revision when late data changes a result. Implementation constraints - Test with a controlled clock and explicit event timestamps. Verification - Deliver an in-window late reading and update the expected aggregate. - Deliver beyond the lateness window and verify visible deferred correction. Deliverables - Watermark logic and late-arrival fixtures Rollout and recovery: Run alongside the prior aggregate; switch readers only after discrepancy review. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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 ingestion gaps Reconcile committed batches and repair derived data. #### AINGEST-108 — Reconcile uploaded telemetry manifests against committed checkpoints **Chore · Medium priority · Intermediate** noCV practice brief v5 · AINGEST-108 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover ingestion gaps. Depends on: AINGEST-104, AINGEST-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 50% · Storage systems 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. Object storage contains yesterday's batches, but dashboard totals are low and no worker currently owns the missing jobs. Acceptance criteria - List missing, pending and committed manifests by bounded window. - Schedule replay only for eligible uncommitted identities. - Make repeated reconciliation produce no duplicate committed data. Implementation constraints - Require explicit organization and time bounds. Verification - Find a synthetic uploaded batch without a checkpoint. - Rerun reconciliation after commit and schedule nothing additional. Deliverables - Manifest reconciler and bounded replay command Rollout and recovery: Dry-run first; stop replay dispatch while preserving the discrepancy report. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-109 — Verify a telemetry backfill against immutable aggregate snapshots **Task · Medium priority · Expert** noCV practice brief v5 · AINGEST-109 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover ingestion gaps. Depends on: AINGEST-106, AINGEST-107, AINGEST-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 80% · 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 conversion fix requires rebuilding a week of energy totals without obscuring what the previous dashboard showed. Acceptance criteria - Build a new aggregate generation from named manifests. - Compare counts, units and totals against frozen previous output. - Atomically select the generation only after review. Implementation constraints - Use a synthetic seven-day corpus with declared correction cases. Verification - Backfill the corpus and reconcile every changed aggregate. - Interrupt before activation and keep previous dashboard reads consistent. Deliverables - Backfill runner and generation difference report Rollout and recovery: Activate one synthetic tenant; restore the old generation pointer on discrepancy. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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. #### AINGEST-110 — Add an ingestion freshness report that distinguishes missing data from zero **Task · Medium priority · Foundational** noCV practice brief v5 · AINGEST-110 · Recover a partner telemetry ingestion pipeline Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover ingestion gaps. Depends on: AINGEST-108, AINGEST-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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 site with no recent readings is displayed as consuming zero energy, misleading dashboard consumers. Acceptance criteria - Show last event time and last committed arrival separately. - Represent missing intervals as unknown rather than numeric zero. - Define stale thresholds from a documented expected schedule. Implementation constraints - Do not claim zero consumption without a reading. Verification - Report a genuine zero reading as zero. - Remove a scheduled batch and show unknown with stale status. Deliverables - Freshness projection and missing-data cases Rollout and recovery: Introduce freshness beside existing totals; revert display wiring while preserving unknown semantics. Project prerequisites: Create synthetic device batches and local object-store fixtures. Understand checksums and bounded streaming. Engineer value: Practice batch integrity, replay and data-quality boundaries. Company value: Review whether operational data can be traced, corrected and recovered. 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.