# 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. ## AARCHIVE — Design a searchable audit archive with retention boundaries A fictional procurement platform keeps append-only action records. Operators want fast recent search and affordable old records without losing provenance or leaking tenant data. **Field:** System design. **Suggested stack:** PostgreSQL, Object storage, TypeScript. **Engineer value:** Practice storage tradeoffs, provenance and data-lifecycle decisions. **Company value:** Review archive cost and retrieval guarantees before committing to infrastructure. **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 audit events and local storage/search adapters. - Use an explicit fictional retention policy, not legal advice. ### Define archive guarantees Specify access, retention and search expectations. #### AARCHIVE-101 — Define which audit questions require indexed search versus archive retrieval **Task · Medium priority · Foundational** noCV practice brief v5 · AARCHIVE-101 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define archive guarantees. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Storage systems 20% · 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. The design says all audit history must be instantly searchable, but reviewers usually inspect the last week and rarely retrieve older cases. Acceptance criteria - List recent search and older retrieval use cases separately. - State hypothetical latency and date-range targets. - Identify fields that may be indexed without exposing payload contents. Implementation constraints - Use fabricated events and a named review workflow. Verification - Map a recent actor search to its target. - Map an old case retrieval to the declared slower path without claiming instant search. Deliverables - Archive access-pattern inventory Rollout and recovery: Review the inventory before choosing storage; keep unapproved fields out of indexes. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-102 — Calculate archive storage growth from event size and retention assumptions **Task · Medium priority · Intermediate** noCV practice brief v5 · AARCHIVE-102 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define archive guarantees. Depends on: AARCHIVE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Storage systems 30% · Cloud infrastructure 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 budget proposal counts raw event bytes but omits index, replica and manifest overhead. Acceptance criteria - Model events per day, average bytes and retention duration. - Show raw, index and redundancy components separately. - Label compression and growth factors as assumptions. Implementation constraints - Provide a small executable worksheet with no claimed measured savings. Verification - Calculate the baseline synthetic scenario. - Double event volume and vary compression to show sensitivity. Deliverables - Storage-growth model Rollout and recovery: Use the model for a reviewed budget proposal; update it after real storage measurements. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-103 — Choose hot and cold archive boundaries with a reviewable decision record **Task · Medium priority · Foundational** noCV practice brief v5 · AARCHIVE-103 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define archive guarantees. Depends on: AARCHIVE-101, AARCHIVE-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Database 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. The team proposes a new search cluster before checking whether bounded PostgreSQL search and object retrieval satisfy the workload. Acceptance criteria - Compare existing database search with a separate index option. - Include consistency, operational and restore costs. - Choose the smallest option meeting the stated requirements. Implementation constraints - Do not provision speculative infrastructure for this design exercise. Verification - Evaluate both options against recent and old queries. - Identify the threshold or query need that would reopen the decision. Deliverables - Archive storage decision record Rollout and recovery: Review the decision against the workload model before implementing new infrastructure. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. ### Model archive boundaries Make manifests, indexing and retrieval verifiable. #### AARCHIVE-104 — Define an immutable archive segment manifest **Task · Medium priority · Advanced** noCV practice brief v5 · AARCHIVE-104 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model archive boundaries. Depends on: AARCHIVE-103. Difficulty: Advanced. Estimated focused work: 210 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. An exported audit file has no trusted count or content identity, so operators cannot tell whether a partial upload is complete. Acceptance criteria - Manifest binds segment ID, record count, range and byte hash. - Publish a segment only after verifying its stored identity. - Retain original event identifiers across archival. Implementation constraints - Use canonical synthetic serialization and exact object versions. Verification - Archive and verify a complete segment. - Truncate bytes or alter count and reject publication. Deliverables - Segment contract and integrity probe Rollout and recovery: Prototype manifests alongside synthetic exports; keep unverified segments out of search. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-105 — Specify search indexing as a rebuildable projection of archived events **Story · Medium priority · Advanced** noCV practice brief v5 · AARCHIVE-105 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model archive boundaries. Depends on: AARCHIVE-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Data engineering 30% · 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 search result is edited directly to correct an event, creating a version of history absent from the source archive. Acceptance criteria - Treat the index as a projection with source segment identity. - Corrections append new events rather than rewrite archived facts. - Define checkpoint and duplicate-indexing semantics. Implementation constraints - Use an in-memory search adapter for the contract probe. Verification - Rebuild the index from named manifests and preserve event identities. - Replay a segment and verify no duplicate search records. Deliverables - Index projection model and replay test Rollout and recovery: Build a shadow index generation; switch only after source-count reconciliation. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-106 — Authorize archive retrieval before issuing object capabilities **Task · High priority · Expert** noCV practice brief v5 · AARCHIVE-106 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model archive boundaries. Depends on: AARCHIVE-104, AARCHIVE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · System design 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. An audit search hit contains a raw object key; clients can request other tenants' segments by changing that key. Acceptance criteria - Resolve event and segment within the caller's authorized tenant. - Issue a capability scoped to the exact object version. - Avoid exposing neighboring events through shared-segment retrieval. Implementation constraints - Choose per-tenant segments or a server-side filtered retrieval contract. Verification - Retrieve a permitted synthetic event through the chosen boundary. - Alter tenant or segment identity and verify no capability is issued. Deliverables - Archive access contract and cross-tenant probe Rollout and recovery: Keep raw objects private; enable retrieval only after the projection isolation checks pass. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-107 — Define archive query pagination across hot and cold boundaries **Story · Medium priority · Intermediate** noCV practice brief v5 · AARCHIVE-107 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Model archive boundaries. Depends on: AARCHIVE-103, AARCHIVE-105, AARCHIVE-106. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Database engineering 30% · Storage 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. A query spanning the archive cutoff repeats recent events and misses records moved between stores during pagination. Acceptance criteria - Bind the cursor to a declared snapshot or generation. - Specify stable ordering and deduplication by event identity. - Return explicit partial or unavailable states for missing segments. Implementation constraints - Model movement with local fixtures rather than live archive jobs. Verification - Page across a cutoff while a segment moves and retain complete ordering. - Make one segment unavailable and report the gap without a complete-result claim. Deliverables - Cross-store query contract and boundary cases Rollout and recovery: Canary bounded date queries; fall back to separate hot/cold retrieval if completeness is uncertain. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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 long-term behavior Rehearse retention, restoration and cost changes. #### AARCHIVE-108 — Model retention as a policy decision separate from audit immutability **Task · Medium priority · Expert** noCV practice brief v5 · AARCHIVE-108 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge long-term behavior. Depends on: AARCHIVE-104, AARCHIVE-106, AARCHIVE-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · System design 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. Stakeholders confuse append-only records with keeping every payload forever, while the archive has a fictional bounded retention agreement. Acceptance criteria - Specify retention scope, expiry and hold behavior. - Preserve authorized deletion facts without claiming deleted bytes remain available. - Identify which policy decisions need external approval before implementation. Implementation constraints - Use a fictional policy and synthetic data; make no legal compliance claim. Verification - Apply expiry to an eligible segment in the model. - Apply a hold and show that deletion remains blocked. Deliverables - Retention model and policy-state probe Rollout and recovery: Review policy before any delete implementation; keep proposed deletion plans read-only. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-109 — Rehearse archive restoration from manifests after index loss **Task · Medium priority · Advanced** noCV practice brief v5 · AARCHIVE-109 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge long-term behavior. Depends on: AARCHIVE-104, AARCHIVE-105, AARCHIVE-108. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 40% · System design 30% · 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. The search projection is lost, but the recovery plan assumes an index backup rather than using the authoritative archive. Acceptance criteria - Restore a new index generation from verified segments. - Report corrupt or missing segments separately from indexed count. - Keep queries from mixing partial and complete generations. Implementation constraints - Use a small synthetic archive with one intentionally damaged segment. Verification - Rebuild from complete manifests and compare query identities. - Include the damaged segment and block a complete-generation claim. Deliverables - Restoration drill and completeness report Rollout and recovery: Run the drill before archive activation; retain the old searchable generation until reconciliation succeeds. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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. #### AARCHIVE-110 — Prepare the archive architecture review with explicit retrieval limits **Chore · Medium priority · Foundational** noCV practice brief v5 · AARCHIVE-110 · Design a searchable audit archive with retention boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge long-term behavior. Depends on: AARCHIVE-102, AARCHIVE-107, AARCHIVE-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 70% · Storage 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. A roadmap summary promises unlimited search and permanent audit availability despite the bounded design. Acceptance criteria - Summarize workload, retention and recovery assumptions. - Link claims to manifest, authorization and restore probes. - List deferred infrastructure and unresolved provider capabilities. Implementation constraints - Avoid presenting the local simulator as production storage readiness. Verification - Trace a recent-query guarantee to its contract. - Trace a missing-segment scenario and document the user-visible limitation. Deliverables - Archive design review packet Rollout and recovery: Review before storage commitment; revise the packet when retention or retrieval requirements change. Project prerequisites: Create synthetic audit events and local storage/search adapters. Use an explicit fictional retention policy, not legal advice. Engineer value: Practice storage tradeoffs, provenance and data-lifecycle decisions. Company value: Review archive cost and retrieval guarantees before committing to infrastructure. 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.