# 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. ## ABOUND — Design an isolated document-processing boundary A fictional procurement portal extracts metadata from uploaded documents. Product wants a responsive upload flow; security wants parser failures isolated from customer-facing processes. **Field:** System design. **Suggested stack:** TypeScript, PostgreSQL, HTTP, Provider interfaces. **Engineer value:** Practice boundary decisions backed by executable consistency and failure checks. **Company value:** Review architecture tradeoffs with explicit assumptions before infrastructure commitment. **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 upload metadata and a fake processing provider. - Treat diagrams as proposals; implement only local contract probes. ### Frame the boundary Define workload, authority and state ownership. #### ABOUND-101 — Translate document-processing expectations into a bounded workload model **Task · Medium priority · Foundational** noCV practice brief v5 · ABOUND-101 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Frame the boundary. 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. A design request says uploads should be instant but does not separate transfer time from extraction completion. Acceptance criteria - Define upload acceptance and extraction completion separately. - State hypothetical size, arrival and concurrency assumptions. - List unresolved product constraints with owners. Implementation constraints - Use a synthetic scenario of 2 MiB median and 20 MiB maximum documents; label it an assumption. Verification - Calculate transfer time under two named bandwidth assumptions. - Show how a maximum-size document changes the completion budget. Deliverables - Workload worksheet and clarified latency definitions Rollout and recovery: Review assumptions before design approval; revise the worksheet when constraints change. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-102 — Draw the document trust boundary with authoritative state owners **Task · Medium priority · Intermediate** noCV practice brief v5 · ABOUND-102 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Frame the boundary. Depends on: ABOUND-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Security 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 first sketch lets the API parse uploaded documents and write arbitrary worker status into the upload row. Acceptance criteria - Identify storage, API, coordinator and isolated parser boundaries. - Assign one owner to each lifecycle transition. - Mark untrusted bytes and privileged credentials on data flows. Implementation constraints - Parsing belongs behind an explicit isolated provider; no candidate code runs in product processes. Verification - Trace a valid upload through every boundary. - Trace a malformed document and show that parser failure cannot mutate API memory. Deliverables - Trust-boundary diagram and state-ownership table Rollout and recovery: Review the boundary before implementation; reject paths that collapse isolation. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-103 — Write the decision record for direct-to-storage document upload **Task · Medium priority · Foundational** noCV practice brief v5 · ABOUND-103 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Frame the boundary. Depends on: ABOUND-101, ABOUND-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Storage systems 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. The team is choosing whether large document bytes should pass through the API or go directly to controlled object storage. Acceptance criteria - Compare bandwidth, authorization and retry responsibilities. - Specify capability scope, expiry and finalization checks. - Name conditions that would justify revisiting the choice. Implementation constraints - Use a provider-neutral capability contract and hypothetical costs. Verification - Trace a successful capability upload and verified finalization. - Trace expired capability and changed-object cases without accepting an unverified document. Deliverables - Upload architecture decision record Rollout and recovery: Review the decision with a local capability fixture; defer provider rollout until its checks exist. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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 the interactions Make contracts and failure semantics executable. #### ABOUND-104 — Specify a document lifecycle that survives parser retries **Story · Medium priority · Advanced** noCV practice brief v5 · ABOUND-104 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the interactions. Depends on: ABOUND-102, ABOUND-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Backend 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. A retry currently moves a completed document back to processing because delivery events are mistaken for authoritative transitions. Acceptance criteria - Define legal transitions and terminal-state behavior. - Bind processing attempts to one immutable upload generation. - Reject stale provider completion for a replaced generation. Implementation constraints - Express the transition table as executable tests against a small pure model. Verification - Replay valid completion twice and retain one terminal result. - Deliver an older generation result after replacement and reject it. Deliverables - State model and transition probes Rollout and recovery: Use the model to gate implementation review; create a new model version for changed semantics. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-105 — Design the transactional dispatch contract for extraction work **Task · Medium priority · Advanced** noCV practice brief v5 · ABOUND-105 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the interactions. Depends on: ABOUND-104. 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. An accepted upload can be stranded if the API commits metadata and crashes before calling the processing provider. Acceptance criteria - Commit upload acceptance and an outbox fact together. - Derive a deterministic dispatch identity from the accepted generation. - Specify claim, retry and duplicate-delivery behavior. Implementation constraints - Use PostgreSQL plus a local provider fake, without adding a broker topology. Verification - Crash after transaction commit and recover dispatch from the outbox. - Repeat provider delivery and prove one accepted completion. Deliverables - Outbox contract and interruption probe Rollout and recovery: Prototype on synthetic uploads; halt new acceptance if durable dispatch cannot be recorded. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-106 — Define extraction-provider deadlines and uncertain completion semantics **Task · Medium priority · Expert** noCV practice brief v5 · ABOUND-106 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the interactions. Depends on: ABOUND-104, ABOUND-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 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. A provider times out after accepting work; blindly retrying may launch duplicate expensive processing. Acceptance criteria - Separate rejected, accepted, completed and unknown outcomes. - Use an idempotent provider request identity and status lookup. - Define bounded retry and operator-visible unresolved states. Implementation constraints - Model uncertain responses explicitly rather than interpreting timeout as failure. Verification - Timeout after acceptance and reconcile by request identity. - Return an unresolved status until the deadline and keep completion unclaimed. Deliverables - Provider contract and uncertainty state probe Rollout and recovery: Use the fake provider to validate behavior; fail closed when a real adapter lacks required identity guarantees. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-107 — Choose the read model for pending document status **Story · Medium priority · Intermediate** noCV practice brief v5 · ABOUND-107 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify the interactions. Depends on: ABOUND-104, ABOUND-106. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Backend 30% · Real-time 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. Product wants frequent status updates, but the proposal polls the external parser on every customer request. Acceptance criteria - Serve status from authorized durable local state. - Specify freshness and pending-state wording. - Compare bounded polling and push updates under the assumed workload. Implementation constraints - Keep raw parser diagnostics outside customer projections. Verification - Read one pending and one completed document through the local model. - Request another tenant's document and verify no provider lookup occurs. Deliverables - Read-model decision and scoped contract probe Rollout and recovery: Prototype the local status route; retain polling until push delivery has a measured need. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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 the design Test alternatives, failure modes and migration steps. #### ABOUND-108 — Estimate document backlog growth during a provider outage **Task · Medium priority · Expert** noCV practice brief v5 · ABOUND-108 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge the design. Depends on: ABOUND-101, ABOUND-105, ABOUND-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · System design 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. The design has no answer for how long a backlog takes to drain after the parser is unavailable for an hour. Acceptance criteria - Calculate arrivals, stored bytes and queued work during outage. - Model recovery with explicit service-time and concurrency assumptions. - Identify when admission must slow or stop. Implementation constraints - Use a spreadsheet or executable script with hypothetical values, not invented measurements. Verification - Calculate backlog for the declared baseline assumptions. - Increase arrival rate above recovery capacity and show the queue does not drain. Deliverables - Capacity model and outage sensitivity script Rollout and recovery: Use the model to set a reviewed admission proposal; revise with real measurements before production sizing. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-109 — Compare synchronous and asynchronous extraction against the same failure cases **Task · Medium priority · Advanced** noCV practice brief v5 · ABOUND-109 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge the design. Depends on: ABOUND-103, ABOUND-106, ABOUND-108. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 70% · Distributed 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. Stakeholders disagree about queueing because one alternative is evaluated only on its happy path. Acceptance criteria - Compare both alternatives under identical workload assumptions. - Include timeout, duplicate request and parser isolation cases. - Record accepted tradeoffs and rejected assumptions. Implementation constraints - A decision matrix must link to the already-created local probes. Verification - Score each alternative against documented correctness requirements. - Demonstrate the case where synchronous processing exceeds the request deadline. Deliverables - Alternative comparison and reviewed decision record Rollout and recovery: Use the comparison for architecture review; revisit when workload or provider guarantees change. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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. #### ABOUND-110 — Plan a reversible migration from inline document parsing **Task · Medium priority · Intermediate** noCV practice brief v5 · ABOUND-110 · Design an isolated document-processing boundary Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge the design. Depends on: ABOUND-105, ABOUND-107, ABOUND-109. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Platform engineering 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. An existing local prototype parses in its request handler; the team needs an incremental path to the agreed boundary. Acceptance criteria - Sequence durable metadata, dispatch and status-reader changes. - Define comparison checkpoints and rollback boundaries. - Keep uploaded bytes and completed results bound to original generations. Implementation constraints - Only local prototype migration is in scope; do not provision production execution. Verification - Walk a synthetic upload through each migration stage. - Rollback before activation and show existing completed documents remain readable. Deliverables - Migration plan and staged local walkthrough Rollout and recovery: Move one synthetic route at a time; pause migration when old and new status projections disagree. Project prerequisites: Create synthetic upload metadata and a fake processing provider. Treat diagrams as proposals; implement only local contract probes. Engineer value: Practice boundary decisions backed by executable consistency and failure checks. Company value: Review architecture tradeoffs with explicit assumptions before infrastructure commitment. 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.