# 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. ## AREGION — Design regional reads without promising impossible failover A fictional logistics dashboard serves distant customers from one primary region. Stakeholders want faster reads and outage recovery but have not agreed which data may be stale. **Field:** System design. **Suggested stack:** TypeScript, PostgreSQL, HTTP. **Engineer value:** Practice consistency tradeoffs, failover authority and recovery assumptions. **Company value:** Review regional availability proposals with explicit data-loss and staleness limits. **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 a local primary/replica simulator and synthetic shipment records. - Use local models; no multi-region infrastructure is provisioned. ### Classify regional behavior Define which reads and writes need freshness. #### AREGION-101 — Classify shipment reads by tolerated staleness **Task · Medium priority · Foundational** noCV practice brief v5 · AREGION-101 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Classify regional behavior. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 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. The regional-read proposal treats a public tracking estimate and an address-change confirmation as equally cacheable. Acceptance criteria - List read classes with explicit hypothetical freshness limits. - Require fresh authority for security and mutation confirmation. - Document unknown product requirements separately. Implementation constraints - Use a synthetic status timeline with version numbers. Verification - Assign a declared budget to public tracking. - Show why address-change confirmation needs its accepted version. Deliverables - Read-consistency matrix Rollout and recovery: Review the matrix before routing changes; leave unresolved classes on primary reads. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-102 — Calculate regional latency contributions with stated assumptions **Task · Medium priority · Intermediate** noCV practice brief v5 · AREGION-102 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Classify regional behavior. Depends on: AREGION-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · System design 30% · Networking 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 proposal promises a faster dashboard without separating network time, database time and sequential request dependencies. Acceptance criteria - Break one page load into serial and parallel operations. - Use named hypothetical network and service-time values. - Show sensitivity to an additional cross-region round trip. Implementation constraints - Label every unmeasured input as an assumption. Verification - Calculate two routes with the same service-time assumptions. - Add a required primary check and show its effect on the budget. Deliverables - Latency worksheet and dependency diagram Rollout and recovery: Use the calculation to prioritize probes; replace assumptions with observations before choosing deployment. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-103 — Record the decision between regional caching and replica reads **Task · Medium priority · Foundational** noCV practice brief v5 · AREGION-103 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Classify regional behavior. Depends on: AREGION-101, AREGION-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Database 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. The team jumps to database replicas when a scoped cache might cover the tolerated-staleness tracking view. Acceptance criteria - Compare invalidation, freshness, failure and operational costs. - Keep sensitive and read-after-write paths explicit. - Name a workload or consistency change that revisits the choice. Implementation constraints - Do not assume an additional region is free or already configured. Verification - Evaluate both options against one tracking read. - Evaluate an authorization change and reject an option that cannot enforce it. Deliverables - Regional-read architecture decision Rollout and recovery: Review using the consistency matrix; implement only the smallest local prototype selected. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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 routing authority Make routing, failover and retry contracts testable. #### AREGION-104 — Define a read-after-write token for shipment changes **Story · Medium priority · Advanced** noCV practice brief v5 · AREGION-104 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify routing authority. Depends on: AREGION-101, AREGION-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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 user changes a delivery note, then a regional read immediately shows the previous text. Acceptance criteria - Mutation returns an accepted version token. - A subsequent read must meet that version or use a fresh source. - Tokens are bound to tenant and resource. Implementation constraints - Implement a small local routing model, not a new replication engine. Verification - Write version 4 while the replica has version 3 and route correctly. - Reuse another tenant's token and reject it without exposing state. Deliverables - Read-version contract and routing tests Rollout and recovery: Canary the routing model in a local client; fall back to primary reads when freshness cannot be established. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-105 — Fence regional write authority before promoting a standby **Task · High priority · Expert** noCV practice brief v5 · AREGION-105 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify routing authority. Depends on: AREGION-104. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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. An outage runbook says promote the standby but never explains how the unreachable former primary loses authority. Acceptance criteria - Define one durable authority epoch and promotion preconditions. - Reject commands using an old epoch. - Describe the availability tradeoff when fencing cannot be confirmed. Implementation constraints - Use a local two-writer model; do not claim split-brain prevention without enforced fencing. Verification - Promote a new epoch and accept only the new writer. - Let the old writer recover and reject its stale-epoch command. Deliverables - Failover authority protocol and fencing probe Rollout and recovery: Require the probe before any real failover procedure; refuse promotion when authority is ambiguous. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-106 — Preserve command identity across a regional routing retry **Task · Medium priority · Advanced** noCV practice brief v5 · AREGION-106 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify routing authority. Depends on: AREGION-104, AREGION-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · System design 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. A gateway retries an update in another region after losing the response, potentially applying the shipment change twice. Acceptance criteria - Use a stable command key across routing attempts. - Bind the key to target, actor and canonical input. - Return unknown until committed status can be resolved safely. Implementation constraints - Do not infer an absent commit from a connection timeout. Verification - Lose the response after commit and resolve one logical change. - Change input under the same key and return conflict. Deliverables - Cross-route command contract and timeout probe Rollout and recovery: Use the contract in the local gateway prototype; suspend retries if deduplication authority is unavailable. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-107 — Define regional fallback for unavailable authorization freshness **Task · Medium priority · Advanced** noCV practice brief v5 · AREGION-107 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify routing authority. Depends on: AREGION-101, AREGION-105, AREGION-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · System design 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 regional endpoint can read cached shipment data but cannot confirm whether the requesting account's access was revoked. Acceptance criteria - Separate data freshness from authorization freshness. - Deny protected reads when required authority is unavailable. - Keep public tracking behavior separately bounded by its policy. Implementation constraints - Model access revocation with synthetic identities. Verification - Serve a permitted public tracking response during primary loss. - Revoke a protected reader and verify the regional route does not use stale permission. Deliverables - Authorization fallback matrix and denial probe Rollout and recovery: Keep protected reads on fresh authority until the regional adapter meets the contract. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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 recovery promises Model outages and reconcile divergent observations. #### AREGION-108 — Model recovery-point and recovery-time limits for a regional outage **Task · Medium priority · Expert** noCV practice brief v5 · AREGION-108 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge recovery promises. Depends on: AREGION-102, AREGION-105, AREGION-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · System design 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 stakeholder asks for zero data loss and immediate recovery even when replication is asynchronous and the primary is unreachable. Acceptance criteria - Define what RPO and RTO mean for the chosen workload. - Calculate loss and recovery bounds from explicit lag and detection assumptions. - Identify guarantees the design cannot currently provide. Implementation constraints - Use hypothetical numbers and separate targets from measured results. Verification - Calculate the declared outage scenario with bounded lag. - Remove the lag bound and show that a finite loss guarantee is unsupported. Deliverables - Recovery objectives worksheet Rollout and recovery: Review targets before infrastructure approval; revise guarantees when provider constraints differ. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-109 — Reconcile divergent regional observations after connectivity returns **Task · Medium priority · Intermediate** noCV practice brief v5 · AREGION-109 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge recovery promises. Depends on: AREGION-104, AREGION-105, AREGION-108. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · System design 30% · Data 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. Support receives screenshots with different shipment states after an outage and needs to explain which accepted version is authoritative. Acceptance criteria - Compare accepted command versions and authority epochs. - Preserve stale observations as observations, not new writes. - Flag missing authoritative history as unresolved. Implementation constraints - Build a read-only synthetic reconciliation report. Verification - Reconcile two observed versions against the accepted command log. - Remove an authority segment and report an explicit gap. Deliverables - Regional reconciliation script Rollout and recovery: Run read-only after the local outage drill; avoid repair writes until authority is resolved. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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. #### AREGION-110 — Write the staged regional-read adoption and rollback plan **Chore · Medium priority · Foundational** noCV practice brief v5 · AREGION-110 · Design regional reads without promising impossible failover Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Challenge recovery promises. Depends on: AREGION-103, AREGION-107, AREGION-109. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Platform 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 architecture review approves a limited regional tracking view, but the rollout ticket still says switch all traffic. Acceptance criteria - Start with the approved read class and synthetic cohort. - Define freshness and denial checks before wider routing. - Rollback by restoring primary routing without rewriting accepted data. Implementation constraints - Include unresolved dependencies as explicit blockers. Verification - Walk a permitted tracking request through the proposed rollout. - Trigger stale authorization and verify protected traffic stays on the declared safe path. Deliverables - Regional adoption plan and decision checklist Rollout and recovery: Review the plan with the local simulator; retain a primary-routing override for recovery. Project prerequisites: Create a local primary/replica simulator and synthetic shipment records. Use local models; no multi-region infrastructure is provisioned. Engineer value: Practice consistency tradeoffs, failover authority and recovery assumptions. Company value: Review regional availability proposals with explicit data-loss and staleness limits. 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.