# Task 12 canonical drill research artifact

This tracked research artifact is the machine-readable source for the 30 drill
contracts and seven rubric axes. Reader-facing Markdown contains only prompt
and reference-answer cards; the Task 12 validator compares those cards with
these rows. Premise-route rationales follow the canonical rows.

TASK12_SC_BEGIN
SC|SC01|Domain fan-out versus owned work|An accepted order fact feeds risk analytics notification and one executor|Ask peak rate burst payload fan-out latency ownership duplicate tolerance retention replay authority and on-call cost|If independent bounded contexts each need the fact use EventBridge routing; if exactly one worker owns buffered work use SQS; SNS plus per-subscriber SQS is valid when push fan-out and subscription/resource-policy controls dominate|I separate fact distribution from work ownership; EventBridge fits content-routed domain facts, while SQS fits competing ownership and buffering, with stable IDs and idempotent effects in either branch|Rules isolate consumers but do not establish completion; queues expose backlog and leases but do not create domain authority; choose only after failure ownership and replay source are named|Producer acknowledgement, target delivery, consumer commit, and business effect remain separate; no cross-service atomic write|Outbox intent prevents accepted-without-publication; inspect per-entry results; quarantine and reconcile rather than blind replay|Requests times fan-out, payload, retry, queue age, DLQ/replay storage, engineering and on-call|Outbox age, target failures including failed DLQ sends, oldest work, duplicate effects; least-privilege bus and queue policies|SNS to SQS for simple push subscriptions; Kinesis when retained independently positioned replay is required|If content routing is unused or backlog ownership and per-message pacing dominate, migrate to queues; if independent retained replay becomes mandatory, use a log|Why not direct dual write; who owns redrive; how is one customer effect proved|Naming a favorite service; calling bus acceptance completion; retry or DLQ without authority and reconciliation|C42 C60 C05 C08 C38 FSR02 SLO01
SC|SC02|SQS Standard versus FIFO|Payment-adjustment work has duplicates and some accounts require serial mutation|Ask ordering unit, group cardinality, throughput skew, retry identity, five-minute dedup boundary, consumer transaction and deadline|Use Standard when commutative idempotent work and throughput dominate; FIFO when strict order within a well-distributed MessageGroupId is required; redesign a single hot group rather than claim global order|FIFO orders only within a group and broker dedup is time-bounded; both consumers still need an atomic inbox or effect receipt and reconciliation|Standard may reorder and redeliver; FIFO can head-of-line block and dedup does not cover database or provider effects; choose group from the invariant and measure skew|No global order and no one-time business effect; visibility is a lease and delete is acknowledgement|Poison work blocks a FIFO lane; quarantine only with an explicit gap policy, then repair source order and validate account totals|Batched request count, group distribution, hot lane, retention, retry work and idle consumers|Oldest age by group, receive count, dedup conflicts, poison identity; isolate tenants and encrypt/classify payload|Kinesis for retained per-key replay; Standard plus version guards for commutative updates|If hottest group breaches deadline or ordering is unnecessary, repartition or move; if retained multi-consumer replay appears, use a log|Can dedup outlive five minutes; what happens after consumer commit but before delete|Saying FIFO is exactly once; one queue means global order; optimistic locking is idempotency|C02 C03 C04 C40 C41 C43 C63 FSR05
SC|SC03|EventBridge routing versus SNS fan-out|Several teams subscribe to execution facts across accounts|Ask filtering needs subscriber types push versus queues cross-account policy retry age DLQ ownership archive replay rate and payload|Choose EventBridge for rule-based integration routing and bus boundaries; choose SNS for topic push fan-out, often to SQS; either is valid only with explicit resource policies and retry/DLQ ownership|EventBridge expresses content routes; SNS expresses topic subscriptions. Neither proves target effects. Validate destination policies, inspect producer results, retain source identity, and reconcile|EventBridge target retry differs from Lambda runtime; a configured DLQ ARN is unusable without queue permission. SNS delivery and subscriber queue behavior are separate boundaries|PutEvents acknowledgement ends before matching and targets; target DLQ ends before repair; SNS publication ends before endpoint effect|Contain failed route or subscriber, retain manifest, repair policy/config, replay original IDs at bounded rate, reconcile every intended consumer|Published events times matched targets, delivery attempts, archives, queue requests and cross-account operations|FailedEntryCount, unmatched intents, target failures, failed DLQ sends, subscriber backlog; SourceArn and SourceAccount conditions|SNS FIFO to SQS FIFO when its documented subscriber/order conditions fit; outbox relay direct to owned queues for command work|If rules become trivial and subscription push dominates, SNS may simplify; if per-subscriber backlog ownership dominates, attach queues|What does HTTP 200 prove; why can DLQ depth be zero during loss|Calling archive a ledger; assuming resource policy; checking CloudWatch generically|C60 C64 C05 C08 C57 FSR02 FSR03 SEC03
SC|SC04|Kinesis versus MSK|A retained ordered market/execution stream needs multiple replaying consumers|Ask rate bytes key skew retention ecosystem Kafka API/connectors event time operations team regional recovery and total cost|Kinesis fits AWS-native managed partitioned logs with shard/on-demand choices; MSK fits a deliberate Kafka protocol, ecosystem, transactions within Kafka, or portability need; either can be wrong for one hot key|Both require partition-key design, idempotent external effects, capacity and replay drills. MSK adds broker/ecosystem control; Kinesis reduces broker operations but has its own shard and consumer modes|Order is partition-scoped; Kafka transactions stop before arbitrary external systems; neither is financial authority|A poison or stalled partition blocks its ordered scope; restore checkpoints and reconcile rather than skip silently|Retain original records, detect lag and poison lanes, recover checkpoints, pace replay, suppress external side effects and reconcile|Peak bytes and records, partitions, retention, consumers/EFO, broker fleet/storage/transfer, staffing and DR|Per-partition lag, throttles, ISR/broker health where relevant, poison identity, access and encryption boundaries|SQS for destructively owned work; Data Firehose for buffered landing; Flink for stateful event-time computation on a source|Kafka ecosystem or existing expertise can select MSK; lower operational appetite and AWS-native integration can select Kinesis; measured hot-key infeasibility can force domain repartition|Where do transactions stop; how is reshard/repartition ordering handled|Kinesis is serverless Kafka; MSK gives external exactly once; aggregate throughput proves feasibility|C10 C29 C75 kinesis_capacity FSR04
SC|SC05|DynamoDB Streams versus semantic outbox or Kinesis|Order state changes must publish stable domain facts and rebuild projections|Ask whether raw item images carry business meaning, transaction boundary, retention, replay horizon, fan-out, sequence and schema ownership|Use a semantic outbox item in the same transaction as authority when publication contract matters; Streams can relay that item or expose acceptable CDC; add Kinesis when longer retained independent replay and throughput shape justify it|Raw CDC says an item changed, not why. An outbox fixes identity, type, causation and payload at commit. Kinesis extends replay but does not close the original database-message gap|Streams order per item and retain briefly; outbox closes only local atomic intent; relay and consumers remain retryable|Relay crash or retention expiry can strand or duplicate publication; repair leases and source history before bounded replay|Repair outbox leases, never regenerate IDs, recover from authority or archive when retention expires, rebuild side-effect-free and reconcile|Transactional rounded writes, outbox/GSI amplification, stream consumers, retention/archive and rebuild capacity|Outbox oldest age, lease state, stream age, sequence gaps, duplicate effects; minimize sensitive payload and scope stream readers|Relational outbox/CDC when authority is Aurora; direct dual write only as explicitly repaired transitional debt|If item images are sufficient and no semantic publication exists, raw Streams may fit; if retention/replay exceeds Streams, add a durable log/archive|Can a Stream be an event store; what happens after relay publish timeout|Calling CDC event sourcing; claiming outbox gives one business effect|C23 C38 CS01 AP16 FSR02
SC|SC06|Step Functions Standard versus Express versus local orchestration|Withdrawal needs callbacks timeouts provider calls and possibly human approval|Ask duration callback/human wait invocation mode volume state size external ambiguity audit deadline compensation and cost|Standard fits long-lived visible durable state and callbacks; Express fits high-volume short workflows only under its invocation semantics; local orchestration fits one bounded service transaction with no durable cross-boundary wait|Workflow history coordinates steps but is not the ledger. Persist provider idempotency keys and receipts, model UNKNOWN states and deadlines, post balanced ledger entries under ledger authority, and reconcile provider statements|Standard workflow execution semantics stop at task/provider effects; Express mode changes retry boundary; compensation is forward action, not rollback|Provider timeout after effect is ambiguous; workflow retry can duplicate an irreversible transfer without receipt lookup|Timeout after provider call is ambiguous; contain account scope, lookup receipt before retry, escalate irreversible uncertainty, reconcile and record human action|State transitions or duration/memory, callbacks, logs/history retention, provider calls, operator work and break loss|Execution age, callback deadline, provider receipt gaps, ledger imbalance, privileged approval audit, secret rotation|A database-backed process manager when custom state/query/control is needed; choreography for few simple reversible reactions|If all work is short stateless and volume makes Standard expensive, Express may fit; if workflow state must join rich domain queries, local process manager may win|What is execution authority; how do you recover a lost callback|Step Functions makes payment exactly once; compensation deletes history; Express is cheaper without workload|C65 C39 RSP08 FSR07 INV06
SC|SC07|Data Firehose versus a Kinesis consumer|Compliance events need buffered S3 landing and a transformation team proposes custom code|Ask destination latency buffering transform complexity failure ownership source replay record size partitioning and need for per-record decisions|Use Data Firehose for managed buffered delivery to supported destinations; use a Kinesis consumer when the team owns stateful validation routing low-latency actions or checkpoints|Firehose reduces delivery operations but destination semantics and duplicate warning vary; a consumer gives control and replay position but adds capacity, code, quarantine and on-call work|Firehose is not a work queue or general replay log; successful landing is not ledger completeness|Destination failure can delay or duplicate delivery; keep source and backup evidence and validate landed manifests|Retain source manifest, monitor delivery errors/backups, repair destination/config, reprocess stable identities, validate object and authority control totals|Ingest and converted bytes, buffering, transforms, destination writes, backup storage versus consumer compute/checkpoints/operations|Delivery freshness/errors, backup prefix, object manifests, encryption/key access and data classification|Direct S3 batch/export for scheduled snapshots; Flink for stateful event-time transforms|If custom state or per-record deadline appears, own a consumer; if processing becomes simple buffered landing, Firehose removes toil|Which destinations change duplicate warning; where is replay source|Calling Firehose Kinesis; assuming S3 objects prove financial completeness|C28 C66 C119 EVD03
SC|SC08|Lambda consumer versus Flink MSK or another stateful processor|A stream computes event-time windows and must replay late data|Ask event-time state size timers lateness checkpoint/source/sink compatibility throughput latency tail replay side effects and team expertise|Lambda fits stateless or bounded per-record/batch transforms; Flink fits managed event-time state and checkpoints; MSK plus stream framework fits Kafka ecosystem; long-lived custom workers fit specialized state/control|Select from measured state lifetime, watermark behavior, recovery and sink semantics. Lambda partial batch responses reduce work but do not supply durable event-time state or atomic external effects|Checkpoint guarantees stop at compatible source, state and sink; Lambda checkpointing stops before business effect|Poison data, late events or checkpoint restore can repeat outputs; isolate state and suppress external effects during replay|Quarantine poison data with order policy, restore checkpoint/savepoint, replay isolated state, suppress notifications/provider calls and reconcile output|State bytes and checkpoint storage, compute duty, shuffle, source reads, sink amplification, replay and operator expertise|Watermark lag, checkpoint duration/failure, iterator age, late records, output control totals, scoped roles and state encryption|KCL/ECS worker for custom per-shard state; database projection with source versions for simpler aggregates|If state fits one idempotent transaction and windows disappear, Lambda may simplify; if checkpoints miss SLO or ecosystem burden is excessive, custom workers may win|Can Flink make an external API exactly once; how are late corrections represented|Defaulting to Lambda because events are present; replaying side effects|C11 C12 C53 C67 REL06
SC|SC09|Lambda versus ECS Fargate or EC2|Sustained compute includes a latency-critical matching candidate|Ask measured service time duty peak-to-average tail target cold behavior state connections deterministic sequencing hardware failure recovery deployment and FTE cost|Lambda fits bursty stateless edges when measured warm and cold tails pass; ECS/Fargate fits sustained long-lived processes; EC2 fits maximum runtime/hardware/control. A deterministic low-tail matcher defaults to evidenced long-lived compute, not a label|Compute price parity is separate from capacity and operating parity. Model peak headroom, scaling lag, queue growth, HA, state recovery and release fencing before cost|No runtime supplies financial correctness; matcher journal, one writer epoch and deterministic replay establish its scoped boundary|Cold starts, scaling lag, host loss or a second writer can breach tail and sequence invariants; fence and recover from journal|Fence writers, preserve journal, fail over one epoch, replay with publication suppressed, compare decision digests, reconcile executions and ledger|Invocations/GB-s versus task/instance hours, minimum HA fleet, utilization, transfer, observability, deployment and on-call|p50/p99/cold tail, queue age, writer epoch conflict, journal flush, decision digest, least-privilege release role|Managed Batch for offline jobs; specialized hardware only with measured need|If cold tail or sustained fleet economics/SLO fail, leave Lambda; if long-lived fleet idle and complexity dominates while Lambda measurements pass, move edges back|Why not Lambda matcher; what does the reviewed no-price-crossing example prove|Serverless is cheaper; containers are faster; ignoring utilization and failure recovery|C53 C115 CS12 ARCC REL07
SC|SC10|Authority and read-store choices|Orders balances portfolios search and low-latency reads have different access patterns|Ask every access pattern key/range consistency read-your-writes authority invariant volume item size relationships freshness rebuild and operations|Start with APs and physical lanes. DynamoDB can own keyed transactional aggregates; Aurora can own relational constraints; cache and search are derived accelerators; choose each path from the invariant, never brand preference|Keep reservation ledger and legal order transition on command authority. Serve portfolio/search/cache projections with version/freshness and overlay durable receipts for read-your-writes|GSI/cache/search freshness never transfers authority; transaction boundary is store-specific and cross-service publication needs outbox|Projection lag, eviction or index gap can serve stale data; fall back or label freshness and rebuild vNext|On projection gap serve stale-with-label or authority fallback, rebuild vNext from durable source, catch up, cut over conditionally and reconcile|Rounded item/read units, GSIs, replicas, cache hit/eviction, search indexing, storage/rebuild and staff|Hot physical lanes, throttles, freshness/gaps, cache miss, exact totals; tenant key isolation and evidence access|Aurora for cross-row relational workloads; DynamoDB for bounded key access; no cache when source meets SLO economically|Measured access-pattern or invariant change falsifies the store; migrate with single authority plus CDC/outbox and reversible reads|Can a strong read of portfolio authorize withdrawal; single versus multi-table|Schema-first table design; scans as APIs; cache as source of truth|AP01 AP07 AP12 C46 C21 C92 REL04
TASK12_SC_END

TASK12_FA_BEGIN
FA|FA01|Accepted order missing publication|Order write and cached 201 precede PutEvents at order-handler lines 155-208 and retry cache return at 229-241|Write succeeds then publish throws times out or is dropped by configuration|Ask command identity timeline exact responses bus/rule version pending age customer retry and outbox evidence|Order row is apparent operational authority; no as-built ledger; publication intent should be durable outbox|Unknown acceptance to customer and stranded order or duplicate from a new key|High financial correctness and support severity; Critical if invariant or customer loss exposure is active|Freeze duplicate creation, query canonical key, preserve order and request fingerprint, inspect durable intent, then repair publication with original identity and reconcile|Prevent with atomic order idempotency result and outbox; detect accepted-without-outbox/receipt; contain account; repair from authority; validate downstream receipt and state|Retry cannot create missing durable intent safely; same key can falsely return 201 and a new key changes identity|Reject new-key workaround, pause affected relay lane and expose PENDING status|Create or repair outbox conditionally from order after investigation, relay original event ID through idempotent consumers|Every accepted order maps to outbox, legal transition, execution or cancellation and ledger/reconciliation disposition|Order API and messaging owners; RBK01/RBK02|Pending age, outbox oldest, publish entries, duplicate keys, downstream receipt, SLO01|Ambiguous producer timeout and configuration drift remain; no repair proves an external effect without receipt/reconciliation|If a proven transactional publication boundary already exists, use it; otherwise escalate when missing-intent count or deadline breaches|Would reversing write order help; how do you expose client status|Retry; delete cache; trust 201; call EventBridge the authority|CS01 CS02 FSR02 RBK01 RBK02 SLO01
FA|FA02|Partial PutEvents and ambiguous outcome|Three handlers discard PutEvents results at exact repository routes in CS03|HTTP 200 has failed entries or client times out after submission|Ask original entry identity and per-entry response bus ARN rule deployment retry owner and downstream receipts|Authoritative order/trade plus durable outbox manifest; EventId is not business authority|Some intents absent or duplicated; stale portfolio/notification and destructive redrive risk|High; Critical if financial postings or customer decisions depend on missing fact|Stop whole-batch retry and message deletion; preserve manifest; classify explicit failure versus unknown|Prevent stable IDs and inspected results; detect control-total gaps; contain bad publisher/config; repair explicit failures and reconcile unknowns; validate each intended effect|Retry explicit failed entries only; ambiguous entries may have been accepted, so idempotent consumers and receipt lookup are required|Disable destructive replayer, validate named bus/rules and isolate publisher lane|Republish original identity only after classification or accept duplicate into atomic inbox; never regenerate fact|Attempted equals explicit result plus owned unknown; each intent maps to downstream receipt or reconciled authority|Messaging owner plus domain owner; RBK02|FailedEntryCount, per-code count, outbox age, rule canary, receipt gaps, SLO01|Nominal zero failures can coexist with nonexistent-bus drop; configuration validation is independent|If producer offers a durable idempotent receipt lookup, use it; breach after deadline opens incident|What does EventId prove; how can zero DLQ depth mislead|Retry whole batch; delete after HTTP 200; check CloudWatch only|CS03 C08 FSR03 RBK02 C57 SLO01
FA|FA03|Duplicate fill and partial posting|Trade insert order update publication are separate at 83-145; portfolio has no inbox and uses floating point|Crash after trade write or duplicate TradeExecuted during partial ledger posting|Ask stable execution ID order version partial-fill semantics posting transaction currency scale provider receipt and replay source|Execution authority owns fill; ledger owns balanced postings/reservations; portfolio is derived|Duplicate holdings or one-sided cash/securities postings, incorrect availability and customer harm|Critical financial integrity|Fence affected account/order, stop projector/replay and withdrawals, preserve event and posting evidence|Prevent deterministic execution ID, conditional order transition, balanced posting transaction and inbox; detect duplicates/imbalance; contain scope; repair append correction; validate reconciliation|Retry is safe only when same execution identity returns the prior effect receipt; it cannot blindly repeat external or posting effects|Freeze projection publication and financially sensitive actions for affected scope|Recover missing side from authority or append reviewed reversal/correction; rebuild projection vNext|Exact minor-unit debits equal credits; one execution identity maps to one posting set; order CumQty and ledger reconcile|Execution ledger and reconciliation owners; RBK07|Duplicate IDs, posting imbalance, version gaps, negative positions, SLO05|External venue ambiguity and prior customer action on stale view remain|If the ledger transaction already atomically covers both sides, focus on duplicate receipt; otherwise incident stays open|Why optimistic locking fails; partial fills and corrections|Replay fixes it; overwrite balance; portfolio proves ownership|CS04 CS05 CS06 CS10 C47 INV06 FSR04 RBK07 SLO05
FA|FA04|Poison record blocks ordered lane|One malformed execution repeatedly fails before checkpoint|A schema-incompatible record reaches the lowest uncommitted sequence and every retry fails deterministically|Ask ordering scope failed sequence batch settings retention age later-record policy schema owner and side effects already made|Retained source plus authoritative execution/ledger; checkpoint is processing position only|Freshness breach for one key and possible downstream deadline while other lanes look healthy|High by affected financial deadline and scope|Stop unbounded retry, preserve raw bytes and identity, cap concurrency impact, do not skip silently|Prevent schema compatibility tests; detect iterator age and poison identity; contain lane; repair decoder/data or explicit compensating sequence; validate gap closure|Retry does not fix deterministic poison and consumes retention/headroom; DLQ/quarantine is holding, not terminal repair|Quarantine only with explicit ordered-gap policy and park later versions|Deploy compatible decoder canary, reinsert or replay original sequence at bounded rate, rebuild if needed|Contiguous expected versions, source-to-applied manifest and exact totals reconcile before release|Stream consumer and domain owner; RBK04|Per-shard age, failed sequence, retry count, retention margin, gap age, SLO03|Skipping may violate order; source may expire before fix|If event is provably irrelevant and invariant-safe, governed skip can close; otherwise rebuild from longer source|Bisect versus partial response; why not keep retrying|Send to DLQ; replay blindly; aggregate lag only|FSR05 RBK04 C11 C12 C43 SLO03
FA|FA05|Lagging or gapped projection rebuild|Portfolio lacks source sequence and daily snapshot is incomplete|Gap alarm or discrepancy appears while live updates continue|Ask authority source completeness retention watermark version side-effect suppression capacity cutover and rollback compatibility|Execution/ledger remains authority; portfolio vCurrent and vNext are projections|Stale holdings and unsafe decisions if projection is trusted; rebuild can duplicate notifications|High; Critical only if stale view authorizes money/securities|Remove projection from authorization, label freshness, preserve old view and isolate rebuild destination|Prevent inbox/version checks; detect gaps and exact discrepancies; contain reads; repair vNext from durable source; validate before conditional alias cutover|Retrying later events cannot fill unknown missing versions; replay without idempotency and side-effect suppression can worsen harm|Park future versions, cap rebuild below live SLO and disable external outputs|Snapshot/manifest then deterministic backfill, catch-up to watermark, compare counts/amounts/versions, canary reads, atomic alias switch|No gaps, exact totals and watermark match authority before/after cutover; rollback only while old view compatible|Projection owner plus finance reconciliation; RBK05|Freshness, gap age, rebuild ETA, source retention, control totals, SLO03|Incomplete source or changed semantics may require forward repair rather than rollback|If source retention cannot finish catch-up, restore archive or rebuild window; abort when live SLO burns|Why not rebuild in place; read-your-writes during cutover|Replay as repair; strong-read projection; switch on row count alone|FSR09 RBK05 REL05 CS06 CS07 CS09 SLO03
FA|FA06|Region/dependency failure with reconciliation discrepancy|Business probes fail, recovery-point age rises, writer epoch conflicts, provider statement differs|Regional outage or dependency ambiguity during failover|Ask RTO RPO authority replication mode provider availability client DNS/keepalive fencing evidence and discrepancy window|One fenced command/ledger writer; provider and ledger have separate authorities joined by reconciliation|Unavailable orders or split brain, lost/duplicate external actions and financial break|Critical when second writer or unresolved imbalance exists|Stop writes, fence old Region, block stale endpoints, preserve manifests and protect evidence|Prevent tested topology and keys; detect business probes/epoch/RPO; contain one writer; repair authority first then outbox/projections; validate provider and ledger totals|Failover does not repair ambiguous external calls or propagated corruption; retry only after receipt lookup|Route no commands until one epoch and dependency/KMS readiness are proved|Promote one writer, replay missing intent under capacity caps, rebuild derived views, reconcile half-open UTC window, fail back separately|Measured RTO/RPO, one epoch, stale-client rejection, exact ledger/provider control totals and closed breaks|Incident commander, ledger, platform, external ops and compliance; RBK08|Business SLOs, epoch conflict, recovery-point age, dependency probes, break aging|DNS caches, long connections, provider ambiguity and corruption survive topology move|If corruption is replicated use clean restore rather than failover; if RPO evidence fails stay read-only|RTO versus RPO; how to fence old clients|Fail over and retry; multi-Region equals zero loss; encryption proves compliance|FSR12 FSR07 RBK08 DR01 DR02 DR03 DR04 REL08 SLO05
TASK12_FA_END

TASK12_QE_BEGIN
QE|QE01|peak=8000 records/s;payload=700 B/record;shard_bytes=1000000 B/s/shard;shard_records=1000 records/s/shard;skew=1.25 ratio;util=0.80 ratio;top_share=0.15 ratio;commit=9000 records/s;live=5000 records/s;safety=1000 records/s;backlog=4500000 records|Size shards by bytes and records; test the top key; compute spare and drain|shards=ceil(max(peak*payload/shard_bytes,peak/shard_records)*skew/util); spare=commit-live-safety; drain=backlog/spare|shards=13 shards;hot_key=1200 records/s;spare=3000 records/s;drain=1500 s|Thirteen aggregate shards fit, but a 1200-record/s single key exceeds the 1000-record/s lane; 4.5M drains in 25 minutes only with protected spare|Half payload still record-bound; top_share above 0.125 stays infeasible; commit<=live+safety gives NO_SAFE_DRAIN|Using MB for records, omitting skew/headroom, dividing by total capacity, or hiding Infinity|kinesis_capacity kinesis_recovery kinesis_planned_shards kinesis_drain_seconds C113 C114
QE|QE02|order=1.2 KiB/item;idem=0.7 KiB/item;outbox=1.6 KiB/item;sentinel=0.2 KiB/item;account_gsi=0.45 KiB/entry;status_gsi=0.35 KiB/entry;ready_gsi=0.45 KiB/entry;txn_multiplier=2 WRU/ordinary-WRU;peak_orders=120 orders/s;order_share=0.50 ratio|Round every item; derive base, indexes, aggregate, and hottest physical order lane|base=txn_multiplier*sum(ceil(each base KiB)); gsi=sum(ceil(each index KiB)); aggregate=(base+gsi)*peak_orders; hot=peak_orders*share*txn_multiplier*ceil(order)|base=12 WRU/order;gsi=3 WRU/order;total_per_order=15 WRU/order;aggregate=1800 WRU/s;hot_order_lane=240 WRU/s|Billing work is 1800 WRU/s but lanes are separate; aggregate can fit while a physical lane fails, so compare every table/index key lane to its target|At order_share 1.0 the lane is 480 WRU/s; a 200-WRU/s lane target is an explicit planning assumption and fails despite aggregate provision; adding a replica changes operation/pricing topology|Rounding after summing, forgetting transaction doubling, charging GSI transaction multiplier, or treating aggregate as one partition|dynamodb_amplification AP06 AP16 ddb_wru_per_order C113
QE|QE03|rate=5000 records/s;seconds=2592000 s/month;batch=100 records/invocation;consumers=3 consumers;retry=0.02 retries/original;replay=0.05 replay-records/original;memory=1 GB;duration=0.08 s/invocation;request_price=0.0000002000 USD/invocation;gb_second_price=0.0000166667 USD/GB-s;shared_engineering=12000 USD/month;shared_oncall=6000 USD/month;shared_compliance=4000 USD/month|Using reviewed Task 10 Lambda prices for eu-west-1 retrieved 2026-08-22 and excluding free tier symmetrically, compute replay-inclusive billed invocations for the same three consumers, consumer work, request and duration cost, then marginal and allocated cost|source=rate*seconds; processed=source*(1+retry+replay); invocations=processed/batch*consumers; work=processed*consumers; request_cost=invocations*request_price; gb_seconds=memory*duration; duration_cost=invocations*gb_seconds*gb_second_price; marginal=request_cost+duration_cost; allocated=marginal+shared_engineering+shared_oncall+shared_compliance|source_records=12960000000 records/month;invocations=416016000 invocations/month;consumer_work=41601600000 consumer-records/month;request_cost=83.203200 USD/month;gb_seconds=0.080000 GB-s/invocation;duration_cost=554.689109 USD/month;marginal=637.892309 USD/month;allocated=22637.892309 USD/month|Replay is explicitly processed through the same three Lambda consumers, so it appears in both billed invocations and work; marginal is this Lambda path while allocated adds the stated shared engineering/on-call/compliance burden|Batch 10 multiplies every replay-inclusive invocation and compute charge by ten; double consumers doubles work and marginal cost; poison coupling can reach the whole batch without durable partial checkpoints|Counting source records as consumer work, omitting replay from billed invocations, applying one invocation to all consumers, hiding regional price inputs, or calling allocated cost marginal|batching fanout lambda_request_usd lambda_gb_second_usd engineering_usd oncall_usd compliance_usd C49 C113 A123
QE|QE04|variable_transport=94.392164 USD/month;variable_projection=173.5992 USD/month;fixed_cache=150 USD/month;variable_rebuild=8.67996 USD/month;variable_reconciliation=2.679914 USD/month;fixed_engineering=900 USD/month;fixed_oncall=300 USD/month;fixed_other=1000 USD/month;writes=61560000 writes/month;avoided_read_value=0.000000566 USD/read|Using reviewed Task 10 eu-west-1 inputs retrieved 2026-08-22, sum separately labeled fixed and variable burden; derive base, half-volume and double-volume break-even; decide whether ratio alone justifies CQRS|variable=sum(variable components); fixed=sum(fixed components); total=fixed+variable; base=total/(writes*avoided_read_value); half=(fixed+0.5*variable)/(0.5*writes*avoided_read_value); double=(fixed+2*variable)/(2*writes*avoided_read_value)|variable=279.351238 USD/month;fixed=2350.000000 USD/month;total=2629.351238 USD/month;base=75.462912 reads/write;half=142.908388 reads/write;double=41.740175 reads/write|The reviewed alternative needs about 75.46 reads/write for base cost parity; authority, 2-second freshness, recovery and operations can still reject it|Half volume keeps fixed burden at 2350.000000 and halves variable burden to 139.675619, giving 142.908388 reads/write; double volume keeps fixed burden and doubles variable burden to 558.702476, giving 41.740175 reads/write; zero avoided benefit gives NO_ECONOMIC_WIN before division|Omitting fixed work, scaling fixed inputs with traffic, using read/write ratio without price units, treating cache hit as invariant proof, or dividing by zero benefit|cqrs_components cqrs_break_even cqrs_break_even_reads_per_write C35 C49 C102
TASK12_QE_END

TASK12_SD_BEGIN
SD|SD01|Design a read-heavy brokerage experience|Ask rates/peaks, read paths, p99, freshness/read-your-writes, authority, order unit, replay/retention, RTO/RPO, tenants, cost and team|Assume 100 order/s average, 0.25 active duty, 95 percent accepted, 61,560,000 accepted-source writes/month, 50 reads/write, 2-second portfolio freshness, eu-west-1 planning baseline, Task 10 fixed burden 2350.000000 USD/month and variable burden 279.351238 USD/month, avoided read value 0.000000566 USD/read, no projection authorization|Order status, portfolio/search, acceptance receipt and audit; explicit freshness and customer status|No venue matcher, clearing implementation or universal multi-Region guarantee|Order/risk/reservation and ledger are authority; projections are rebuildable; exact money and balanced postings|Per-account order/version; transactional command plus outbox; inbox and expected projection version; receipt overlay for read-your-writes|API to command transaction/outbox; relay and routed facts; independent portfolio/search/cache projections; ledger reconciliation and S3 evidence|Read amplification can justify denormalized AP07/cache/search, but write amplification, freshness and rebuild remain priced|Ambiguous acceptance uses receipt lookup; gaps park and rebuild vNext; replay suppresses side effects; reconciliation closes exact totals|Task 10 gives 61,560,000 accepted-source writes/month from 100*2,592,000*0.25*0.95; break-even=(2350.000000+279.351238)/(61560000*0.000000566)=75.462912 reads/write, so compare the assumed 50 reads/write rather than assume CQRS pays|SLO01/SLO03, outbox age, gaps, exact totals, tenant IAM, PII redaction, canary contracts, REL05 rebuild, tested RTO/RPO|I keep command and ledger authority small, publish durable intent, and buy read models only for named APs with version/freshness and reversible rebuilds|Explain AP inventory, physical lanes, overlay receipts, projection manifests, SLOs, security boundary and cost denominator|Why cache not authority; how cut over vNext; what if top account is hot; restore after retention; tenant leak response|Two databases equals CQRS; eventual consistency everywhere; cache authorizes withdrawals; no reconciliation|Aurora authority if relational invariants dominate; same-table CQRS-lite if projections do not pay|If freshness, rebuild, or complete-cost evidence fails, serve authority/fewer views; sustained access-pattern change triggers migration|Score authority/AP routes, conditional read-store choice, exact failure proof and quantified falsifier|ARCA AP07 C35 AP12 REL05 SLO01 SLO03 SEC02 cqrs_break_even
SD|SD02|Design write-heavy market and execution ingestion|Ask peak records/bytes, burst/skew, key/order, retention/replay, consumer fan-out, event time, tail, source authority, sink capacity, RTO/RPO and ops|Assume 8000 peak records/s, 700 B, 15 percent hot key, three consumers, 24-hour stream retention and longer S3 archive|Durable ingestion, per-symbol/order sequence, independent risk/compliance/projection consumers and paced replay|No cross-symbol total order, retail query UI or claim that broker log is ledger|Venue/matcher owns execution sequence; ledger owns postings; stream is retained transport|Partition order only; stable event ID; consumers use inbox/version; external effects outside checkpoint|Fenced ingress writers to Kinesis or MSK, raw archive, Lambda/KCL consumers for simple paths, Flink only for event-time state, outbox into ledger boundaries|Minimize synchronous indexes/fan-out; buffer and batch, but top key 1200/s is infeasible against a 1000/s lane until domain repartition|Partial producer results classified; poison lane contained; retained or restored replay at protected spare; exact execution/ledger reconciliation|Thirteen aggregate shards by reviewed model, yet hot key is first bottleneck; drain 4.5M in 1500s at 3000/s spare|Iterator age per shard, throttles, gaps, duplicate fills, exact totals, source/sink permissions, immutable release artifacts and DR drills|I size bytes and records with skew, then reject aggregate feasibility when one business key breaches its lane|Discuss sequence assignment, repartition migration, producer manifests, checkpoint/external boundary, replay source/sink and cost|How preserve order during reshard; what if archive expired; EFO or shared reads; late event correction; no-spare branch|Aggregate throughput proves fit; stream is event store/ledger; replay sends notifications again|MSK for Kafka ecosystem/transactions inside Kafka; custom journal for matcher decisions|If one key cannot partition without breaking invariant, isolate/dedicated writer; if Kafka ecosystem value exceeds ops burden, migrate|Score dimensional capacity, hot-lane recognition, guarantee boundary, replay validation and credible alternative|ARCB C10 C29 kinesis_capacity kinesis_recovery FSR04 RBK04
SD|SD03|Design a mixed exchange with deterministic matching core and serverless edges|Ask matching p99/jitter, order books, writer scope, peak burst, journal durability, risk/ledger boundary, client deadline, DR fencing, release and staff|Planning assumptions: 8000 commands/s aggregate peak, hottest book 2000 commands/s, measured service time 0.0002 s/command, 1.5 capacity headroom, symbol-partitioned books, durable acceptance, long-lived single writer per book, matcher fleet 9000 cost-units/month and serverless-edge baseline 3000 cost-units/month|Acceptance, pre-trade reservation, deterministic match/execution, postings, projections, notifications and audit|No Lambda default for matcher, no global order, no instant active-active ledger|Command/risk, matcher journal/execution and balanced ledger are distinct authorities; views remain projections|One fenced epoch per book, monotonic order/execution versions, stable IDs, outbox/inbox between authorities|Serverless API/validation and durable command intent; long-lived matcher fleet/journal; transactional posting service; event log/bus to serverless projections and workflow edges|Write-heavy core minimizes synchronous work; read-heavy edges denormalize; hot book and journal flush dominate before monthly average|Unknown acceptance lookup; matcher crash replays journal with publication suppressed; duplicate fill returns receipt; reconcile executions to postings; fenced regional recovery|A writer provides 1/0.0002=5000 commands/s; aggregate plan is ceil(8000*1.5/5000)=3 book workers at 0.533333 aggregate utilization, hottest-book utilization is 2000/5000=0.400000, and matcher-fleet/edge cost ratio is 9000/3000=3.000000 under these explicit planning inputs|Epoch conflicts, decision digest, journal depth, duplicate fills, imbalance, SLOs, tenant/security evidence, REL07 shadow release and DR01/DR02/DR03 fenced recovery|I put deterministic sequencing on an evidenced long-lived single-writer substrate and keep elastic APIs, workflows and projections around it|Expand reservations, cancel/replace/partial fill, outbox boundaries, exact money, canary symbol rollout, recovery proof and unit economics|Why not Lambda; failure after match before publish; hot symbol; standby promotion; rollback after new journal format; recompute workers and utilization at 12000 commands/s or 0.0004 s/command|Serverless everywhere; EventBridge sequences fills; portfolio is balance; active-active without fencing|Managed low-latency specialized substrate or Kafka-based core only if measurements and deterministic recovery contract fit|If measured Lambda tail/state and recovery pass it can serve a bounded low-rate case; if single writer saturates partition by invariant or hardware|Score domain authorities, matcher substrate evidence, deterministic recovery, financial reconciliation and migration trigger|ARCC CS12 REL07 C53 C115 INV01 INV06 DR01 DR02 DR03
SD|SD04|Design long-lived settlement or withdrawal with external ambiguity|Ask amount/currency, approval policy, provider idempotency/receipt, callbacks/timeouts, deadlines, compensation limits, ledger/settlement authority, reconciliation, humans, RTO/RPO and security|Planning assumptions: 20 withdrawals/s peak, 0.25 monthly peak-duty ratio, 2592000 s/month, 2 s provider service time, 1.5 concurrency headroom, 90 concurrent-call maximum, 10000 obligations due within 600 s, 0.01 breaks/obligation reconciliation share, 12 workflow transitions/withdrawal, 1200-break recovery backlog due within 1800 s, 0.5 breaks/s operator-reconciliation capacity, 0.1 breaks/s live arrival and 0.1 breaks/s protected safety; provider can time out after effect, callback may duplicate, two-person high-value approval, daily statements|Durable request/approval, execution intent, provider interaction, settlement state, balanced postings, exceptions and evidence|No assumption provider supports cancellation, no workflow-as-ledger, no automatic compensation of irreversible transfer|Execution request authority, approval authority, provider/settlement receipt and financial ledger are separate; reconciliation joins them|Stable withdrawal and provider keys; legal state transitions; exact postings; callback inbox; UNKNOWN state blocks blind retry|API command transaction/outbox; Step Functions Standard callback/task token or durable process manager; provider adapter receipt lookup; ledger posting commands; exception queue and reconciliation batches|Long waits favor durable orchestration; provider calls, transitions, evidence retention, operator hours and expected break loss drive cost|Timeout becomes UNKNOWN; contain account, lookup receipt, do not duplicate; callback dedup/version; append correction not overwrite; reconcile statement window and human sign-off|provider_desired=ceil(20*2*1.5)=60 concurrent calls;provider_assigned=min(60,90)=60 concurrent calls;provider_protected=60/(2*1.5)=20.000000 withdrawals/s;deadline_required=10000/600=16.666667 obligations/s;deadline_reconciliation=16.666667*0.01=0.166667 breaks/s;operator_protected=0.5-0.1-0.1=0.300000 breaks/s;deadline_state=SAFE;recovery_required=1200/1800=0.666667 breaks/s;recovery_state=NO_SAFE_DEADLINE;transitions=20*0.25*2592000*12=155520000 transitions/month;drain=1200/0.3=4000 s=66.666667 minutes|SLO05/SLO06, receipt gaps, callback duplicates, ledger balance, privileged approvals, secrets/KMS, release compatibility, DR fencing|I model the provider timeout as ambiguous, keep workflow state separate from ledger authority, and require receipt lookup plus reconciliation before retry or closure|Walk every state and owner, irreversible boundary, compensation limits, callback security, exact postings, break lifecycle and failover; with the stated 90-call maximum, doubled provider time lowers protected throughput to 15.000000 withdrawals/s versus 16.666667 obligations/s, so the sensitivity is NO_SAFE_DEADLINE|Lost callback; provider says sent but ledger absent; human override; secret compromise; Region loss; failback; doubled_service=2*2=4 s;doubled_desired=ceil(20*4*1.5)=120 concurrent calls;doubled_assigned=min(120,90)=90 concurrent calls;doubled_provider_protected=90/(4*1.5)=15.000000 withdrawals/s;deadline_required=10000/600=16.666667 obligations/s;sensitivity_state=NO_SAFE_DEADLINE|Retry provider; workflow succeeded so money moved; compensation is rollback; CloudTrail alone is audit completeness|Database process manager for richer domain queries; choreography only for few simple reversible reactions|If callbacks are reliable and flow short Express/local may fit; if Standard history/query limits or cost breach, migrate state while preserving IDs|Score execution/approval/settlement/ledger separation, ambiguity handling, exact reconciliation, security evidence and falsifier|C65 C39 RSP08 RSP09 INV06 FSR07 FSR12 SLO05 SLO06 SEC05
TASK12_SD_END

TASK12_RW_BEGIN
RW|RW01|Order write plus PutEvents gap|code/lambdas/order-handler/handler.ts:155-165,167-181,183-208; code/lambdas/order-handler/handler.ts:193-205; code/lambdas/trade-executor/handler.ts:134-145; code/lambdas/dlq-replayer/handler.ts:114-133|High stranded-order and false-success risk|Order persists, cache persists, publication fails or partially fails, retry returns cached success|Ask exact request identity authority and response timeline bus/rule version and downstream receipts|The database/event dual write is non-atomic and HTTP acknowledgement is narrower than routing; atomically store order/result/outbox, relay original ID and reconcile|Name CS01 and CS03, distinguish explicit failed entry from timeout unknown, keep order authority separate from EventBridge|Inspect every result immediately and add pending-publication repair without changing logical identity|Transactional order plus request fingerprint and semantic outbox; idempotent relay/consumer and reconciliation|Expand schema first, dual-read status, backfill missing intents under manifest, canary relay, then remove direct publication|Rollback reads/relay while old authority valid; roll forward once new facts use new contract|Every accepted order maps to one durable intent and downstream receipt or owned break|Why reversing calls fails; how to migrate without duplicates|Retry PutEvents; trust EventId; delete cached row|If a true atomic broker transaction is introduced, outbox choice changes; bus config drift still needs proof|CS01 CS03 FSR02 REL04
RW|RW02|Cached idempotency and retry ambiguity|code/lambdas/order-handler/handler.ts:167-180,229-241|High duplicate-order or false-success risk|Original returns failure after cached 201; same key skips publish; new key creates new order|Ask canonical command identity payload fingerprint retention response state lease and repair owner|Replace response cache with durable IN_PROGRESS/COMPLETED command receipt atomically tied to order/outbox; same-key mismatch conflicts|TTL is cleanup, fail-open lookup is unsafe, and retry after ambiguous external effect needs receipt/reconciliation|Stop recommending new keys; preserve fingerprint and return pending lookup token|Backfill receipt state from orders/outbox, add lease/takeover and effect receipt, reconcile unknowns|Deploy compatible reads, write new receipt transaction, repair old rows, then enforce mismatch and retire cache path|Rollback response presentation only; never delete committed order or regenerate identity|One fingerprint maps to one order/version/result; late retry returns compatible outcome|TTL expiry; concurrent retries; provider effect boundary|Cache equals idempotency; new key solves retry; TTL is deadline|If product accepts best-effort duplicate creation explicitly severity changes, but financial order semantics usually reject it|CS02 C40 AP08 FSR01
RW|RW03|Trade write publication duplicate and missing paths|code/lambdas/trade-executor/handler.ts:83-118,120-145; code/lambdas/trade-executor/handler.ts:79-104,120-145|Critical if execution/posting correctness is affected|Trade commits, order changes, publish fails; retry stops at duplicate insert before publication|Ask deterministic execution identity authority and partial fills legal predecessor outbox state and ledger postings|Make fill, conditional order transition and semantic outbox one compatible transaction; duplicate returns prior effect receipt and resumes relay|A random new trade ID and one-trade-per-order key cannot model partial fills; external matcher boundary still needs idempotent ingestion|Persist repairable publication state and inspect PutEvents entries|Migrate deterministic fills, backfill outbox from stored trade, canary relay, reconcile portfolio and ledger|Add new schema/index first, dual-read old fills, single authoritative writer, backfill, cut over consumers|Roll back reads before semantic switch; after new executions append corrections and roll forward|Every execution ID has legal order version, one posting set, outbox and reconciled projections|Failure between trade and order; missing event recovery; partial fill|Conditional put makes workflow idempotent; ordinary retry finishes it|If execution authority is external, local transaction begins at ingestion receipt rather than match decision|CS04 CS05 C38 FSR04 AP04
RW|RW04|Portfolio identity version and money correctness|code/lambdas/portfolio-updater/handler.ts:145-186; code/shared/types/dynamodb.ts:63-79; code/shared/types/events.ts:36-47; code/lambdas/portfolio-updater/handler.ts:145-178; infra/environments/production/main.tf:565-605; code/shared/validation/schemas.ts:21-27; code/lambdas/trade-executor/handler.ts:55-63; code/lambdas/portfolio-updater/handler.ts:64-84,121-135; code/lambdas/portfolio-snapshot/handler.ts:50-61|Critical if used for availability; otherwise high projection correctness|Duplicate or late fill applies through version lock; floating arithmetic drifts totals|Ask source sequence event identity currency scale rounding authority and rebuild source|Treat portfolio as projection; atomically inbox tradeId plus expected version and exact-minor-unit update; park gaps and rebuild|Optimistic locking controls concurrent overwrite, not novelty/order. A strong read cannot upgrade provenance. Exact money must cross envelope/storage boundaries|Remove projection from authorization, detect duplicates/gaps and validate serialization|Versioned vNext rebuild from authoritative executions/ledger, catch up, compare exact totals and cut over|Introduce exact fields and decoder, shadow calculate, backfill vNext, canary reads, then retire float view|Retain old projection alias only if compatible; never roll back authoritative postings|One event identity once, contiguous source versions, exact quantities/currency totals equal authority|How handle old float history; gap after retention; read-your-writes|Version lock deduplicates; timestamp orders events; portfolio is balance|If operations are mathematically commutative ordering need may narrow, but identity and exact money remain|CS06 CS07 CS10 AP07 AP13 REL05
RW|RW05|Scans indexes access patterns and capacity|code/lambdas/portfolio-snapshot/handler.ts:64-107|Medium scalability, high audit risk if called complete|Dataset exceeds one page/memory or hot symbol GSI lane saturates while aggregate looks healthy|Ask AP, result bound, pagination/snapshot semantics, point-in-time requirement, hot share, export deadline and control totals|Replace request-path scans with AP-specific Query/indexes; use PITR export plus manifest for scalable snapshots and reconcile completeness|Alex DeBrie access-pattern-first design requires keys and physical lanes before indexes. LastEvaluatedKey is continuation, not snapshot isolation|Paginate immediately and stop labeling current JSONL complete|Create export/reconciliation pipeline, versioned output, checksums/counts/exact totals and bounded catch-up|Add cursor-compatible API, run parallel export, compare manifests, switch consumers, retire scan after evidence|Roll back reader to old path only within known bounds; export failures resume from manifest|All source segments represented once, exact totals and watermark recorded; hot lanes stay within target|Sparse GSI lifecycle; hot symbol; point-in-time versus pagination|DynamoDB scan scales; add GSI first; aggregate WCU proves fit|If access pattern is rare offline, export may beat an index; if low bounded table, pagination may suffice|CS09 AP06 C21 C24 C81 C96 C114
RW|RW06|Missing ledger reconciliation IAM observability deployment and safe sequence|infra/modules/eventbridge/main.tf:29-38,73-95; infra/environments/production/main.tf:575-605; infra/modules/lambda/main.tf:12-70; bounded absence check below; code/shared/types/dynamodb.ts:16-93; infra/modules/dynamodb/main.tf:1-60; repository-wide absence check below; code/lambdas/trade-executor/handler.ts:55-81; infra/modules/lambda/main.tf:12-31|Critical architecture gap for production financial authority|A fill occurs, projection changes, DLQ send fails, deployment changes semantics and no control total closes the break|Ask regulated scope ledger owner postings reservation policy IAM principals evidence population SLO release compatibility and RTO/RPO|Do not infer posture from absence beyond inspected routes; add explicit balanced ledger/reconciliation, fix rule-scoped queue policies, business SLOs and compatible canaries in dependency order|Smallest hardening is policy plus failed-DLQ-send alarm and publication manifests; production repair adds ledger/reservation authority, reconciliation and replay-safe releases while matcher substrate follows measurement|Grant EventBridge only scoped SendMessage, alarm failed sends, block portfolio authorization and preserve release artifacts|Introduce ledger schema/posting service and reconciliation batches; backfill under manifest; canary views; fence writers; test restore|Expand controls and authorities, shadow/control-total compare, single-writer cutover, then contract old paths; never dual-authority casually|Rollback traffic/config while formats compatible; roll forward corrections after financial facts or schemas change|Balanced exact postings, one writer, complete manifests, least-privilege negative tests, SLO and DR evidence|Why CloudTrail/Object Lock is insufficient; safe order of changes; matcher migration|No IAM means insecure; encryption means compliant; deploy everything together|If an external governed ledger exists, integrate and prove its routes rather than duplicate it; repository alone does not show one|CS08 CS11 CS12 SEC03 REL04 REL07 SLO05
TASK12_RW_END

TASK12_RUBRIC_BEGIN
RUBRIC|requirement discovery|Chooses immediately|Asks one generic question|Covers rate or latency but misses business ambiguity|Elicits workload, deadlines, authority and recovery constraints|Prioritizes quantified constraints, exposes conflicting assumptions, cites evidence and states a falsifier
RUBRIC|authority and invariant clarity|Calls transport or projection authority|Names data without invariant|Separates some stores|Names command, execution, ledger and projection roles with exact money|Proves invariants at transaction/reconciliation boundaries with evidence and states a falsifier
RUBRIC|guarantee-boundary precision|Claims system-wide guarantee|Repeats service label|Names one boundary|Separates producer, transport, consumer and effect with order/idempotency scope|Traces every stopping boundary and ambiguous window to evidence, proof and falsifier
RUBRIC|failure/recovery/reconciliation|Says retry, DLQ, replay or fail over|Lists controls without repair|Explains detection and repair partially|Separates prevention, detection, containment, repair and validation|Supplies owner, bounded runbook, exact reconciliation evidence, residual ambiguity and falsifier
RUBRIC|quantitative/cost reasoning|No units or arithmetic|Uses averages only|Computes one dimension|Carries units through peak, skew, fan-out, drain and complete cost|Independently checks branches/sensitivities, capacity feasibility, evidence quality and falsifier
RUBRIC|observability/security/operations|Says check CloudWatch or encrypt|Lists tools|Names signals or IAM broadly|Ties business SLOs, scoped access, release and DR to owners|Defines evidence populations, negative/security tests, recovery proof, cost and falsifier
RUBRIC|communication and trade-off clarity|Unstructured answer|Service trivia|Structured but universal choice|Concise conditional opening plus deeper alternative and migration trigger|Makes assumptions explicit, compares credible alternatives, cites evidence and ends with falsifier
TASK12_RUBRIC_END

# Premise route audit

# Columns: ROUTE_MAP | drill ID | ordered route@owner pairs | load-bearing rationale
TASK12_ROUTE_MAP_BEGIN
ROUTE_MAP|SC01|C42@research/claim-register.md C60@research/claim-register.md C05@research/claim-register.md C08@research/claim-register.md C38@research/claim-register.md FSR02@deliverable/07-reliability-and-correctness.md SLO01@deliverable/10-observability-security-and-operations.md|Queue/log ownership, routing roles, acknowledgement and DLQ boundaries, atomic publication repair, producer failure handling, and customer acceptance are all load-bearing.
ROUTE_MAP|SC02|C02@research/claim-register.md C03@research/claim-register.md C04@research/claim-register.md C40@research/claim-register.md C41@research/claim-register.md C43@research/claim-register.md C63@research/claim-register.md FSR05@deliverable/07-reliability-and-correctness.md|SQS delivery, ordering, bounded deduplication, business-idempotency transactions, visibility/delete leases, poison-lane recovery, and durable receipts jointly define the choice.
ROUTE_MAP|SC03|C60@research/claim-register.md C64@research/claim-register.md C05@research/claim-register.md C08@research/claim-register.md C57@research/claim-register.md FSR02@deliverable/07-reliability-and-correctness.md FSR03@deliverable/07-reliability-and-correctness.md SEC03@deliverable/10-observability-security-and-operations.md|EventBridge/SNS roles, SNS mode behavior, producer/target/DLQ boundaries, failed-entry repair, and cross-account least privilege are each used.
ROUTE_MAP|SC04|C10@research/claim-register.md C29@research/claim-register.md C75@research/claim-register.md kinesis_capacity@research/cost-model.md FSR04@deliverable/07-reliability-and-correctness.md|Partition-scoped ordering, Kafka transaction limits, hot-key reshard limits, capacity arithmetic, and ordered-lane recovery are the comparison's load-bearing constraints.
ROUTE_MAP|SC05|C23@research/claim-register.md C38@research/claim-register.md CS01@research/repository-evidence.md AP16@deliverable/05-dynamodb-deep-dive.md FSR02@deliverable/07-reliability-and-correctness.md|Streams retention/ordering, atomic outbox intent, the repository dual-write gap, transactional item layout, and ambiguous publication repair support the choice.
ROUTE_MAP|SC06|C65@research/claim-register.md C39@research/claim-register.md RSP08@deliverable/08-fintech-trading-architecture.md FSR07@deliverable/07-reliability-and-correctness.md INV06@deliverable/08-fintech-trading-architecture.md|Workflow-mode semantics, saga compensation limits, settlement finality, ambiguous provider recovery, and exact posting invariants define the orchestration boundary.
ROUTE_MAP|SC07|C28@research/claim-register.md C66@research/claim-register.md C119@research/claim-register.md EVD03@deliverable/10-observability-security-and-operations.md|Firehose duplicate exceptions and buffered-delivery scope, destination-scoped freshness/error metrics, and reconciliation manifests jointly define landing, monitoring, and proof.
ROUTE_MAP|SC08|C11@research/claim-register.md C12@research/claim-register.md C53@research/claim-register.md C67@research/claim-register.md REL06@deliverable/10-observability-security-and-operations.md|Lambda batch/checkpoint limits, long-lived compute alternatives, Flink event-time state boundaries, and compatible state migration support the processor choice.
ROUTE_MAP|SC09|C53@research/claim-register.md C115@research/claim-register.md CS12@research/repository-evidence.md ARCC@deliverable/08-fintech-trading-architecture.md REL07@deliverable/10-observability-security-and-operations.md|Measured compute fit, price-versus-capacity separation, repository matcher evidence, deterministic writer authority, and safe release controls are load-bearing.
ROUTE_MAP|SC10|AP01@deliverable/05-dynamodb-deep-dive.md AP07@deliverable/05-dynamodb-deep-dive.md AP12@deliverable/05-dynamodb-deep-dive.md C46@research/claim-register.md C21@research/claim-register.md C92@research/claim-register.md REL04@deliverable/10-observability-security-and-operations.md|Concrete order/portfolio/balance access paths, financial authority, DynamoDB transaction scope, store-specific capabilities, and projection cutover define the choices.
ROUTE_MAP|FA01|CS01@research/repository-evidence.md CS02@research/repository-evidence.md FSR02@deliverable/07-reliability-and-correctness.md RBK01@deliverable/07-reliability-and-correctness.md RBK02@deliverable/07-reliability-and-correctness.md SLO01@deliverable/10-observability-security-and-operations.md|The observed dual-write and cached-response paths, ambiguous publication failure, command and producer runbooks, and customer acceptance outcome close the diagnosis.
ROUTE_MAP|FA02|CS03@research/repository-evidence.md C08@research/claim-register.md FSR03@deliverable/07-reliability-and-correctness.md RBK02@deliverable/07-reliability-and-correctness.md C57@research/claim-register.md SLO01@deliverable/10-observability-security-and-operations.md|Repository partial-result handling, EventBridge delivery limits, producer/target recovery, configuration caveats, and durable-acceptance SLO evidence jointly define diagnosis and closure.
ROUTE_MAP|FA03|CS04@research/repository-evidence.md CS05@research/repository-evidence.md CS06@research/repository-evidence.md CS10@research/repository-evidence.md C47@research/claim-register.md INV06@deliverable/08-fintech-trading-architecture.md FSR04@deliverable/07-reliability-and-correctness.md RBK07@deliverable/07-reliability-and-correctness.md SLO05@deliverable/10-observability-security-and-operations.md|Execution/projection evidence, schema and exact-money constraints, balanced-posting invariants, duplicate recovery, ledger-break runbook, and reconciliation SLO support every repair step.
ROUTE_MAP|FA04|FSR05@deliverable/07-reliability-and-correctness.md RBK04@deliverable/07-reliability-and-correctness.md C11@research/claim-register.md C12@research/claim-register.md C43@research/claim-register.md SLO03@deliverable/10-observability-security-and-operations.md|Poison-lane failure and runbook behavior, Lambda batch/checkpoint semantics, FIFO lane scope, and projection-freshness SLO define containment, replay, and release.
ROUTE_MAP|FA05|FSR09@deliverable/07-reliability-and-correctness.md RBK05@deliverable/07-reliability-and-correctness.md REL05@deliverable/10-observability-security-and-operations.md CS06@research/repository-evidence.md CS07@research/repository-evidence.md CS09@research/repository-evidence.md SLO03@deliverable/10-observability-security-and-operations.md|Projection gap/rebuild controls, release compatibility, repository identity/version/scan evidence, and the portfolio freshness SLO establish safe vNext recovery.
ROUTE_MAP|FA06|FSR12@deliverable/07-reliability-and-correctness.md FSR07@deliverable/07-reliability-and-correctness.md RBK08@deliverable/07-reliability-and-correctness.md DR01@deliverable/07-reliability-and-correctness.md DR02@deliverable/07-reliability-and-correctness.md DR03@deliverable/07-reliability-and-correctness.md DR04@deliverable/07-reliability-and-correctness.md REL08@deliverable/10-observability-security-and-operations.md SLO05@deliverable/10-observability-security-and-operations.md|Region/provider ambiguity, fenced failover, command/ledger/outbox/projection recovery tiers, failback control, and clean reconciliation closure define authority-first recovery.
ROUTE_MAP|QE01|kinesis_capacity@research/cost-model.md kinesis_recovery@research/cost-model.md kinesis_planned_shards@research/cost-model.md kinesis_drain_seconds@research/cost-model.md C113@research/claim-register.md C114@research/claim-register.md|The exact capacity and recovery formulas/results plus controlled unit-economics and hot-lane rules make every calculation traceable.
ROUTE_MAP|QE02|dynamodb_amplification@research/cost-model.md AP06@deliverable/05-dynamodb-deep-dive.md AP16@deliverable/05-dynamodb-deep-dive.md ddb_wru_per_order@research/cost-model.md C113@research/claim-register.md|The write-amplification formula/result, physical access lanes, transaction bundle, and denominator discipline support the rounded calculation.
ROUTE_MAP|QE03|batching@research/cost-model.md fanout@research/cost-model.md lambda_request_usd@research/cost-model.md lambda_gb_second_usd@research/cost-model.md engineering_usd@research/cost-model.md oncall_usd@research/cost-model.md compliance_usd@research/cost-model.md C49@research/claim-register.md C113@research/claim-register.md A123@research/source-ledger.md|Batch/fan-out formulas, both Lambda prices, all three allocation inputs, cost-model discipline, unit economics, and dated source lineage are independently load-bearing.
ROUTE_MAP|QE04|cqrs_components@research/cost-model.md cqrs_break_even@research/cost-model.md cqrs_break_even_reads_per_write@research/cost-model.md C35@research/claim-register.md C49@research/claim-register.md C102@research/claim-register.md|The full component formula, break-even equation/result, CQRS spectrum, model discipline, and sensitivity rule support the conclusion.
ROUTE_MAP|SD01|ARCA@deliverable/08-fintech-trading-architecture.md AP07@deliverable/05-dynamodb-deep-dive.md C35@research/claim-register.md AP12@deliverable/05-dynamodb-deep-dive.md REL05@deliverable/10-observability-security-and-operations.md SLO01@deliverable/10-observability-security-and-operations.md SLO03@deliverable/10-observability-security-and-operations.md SEC02@deliverable/10-observability-security-and-operations.md cqrs_break_even@research/cost-model.md|The read-heavy architecture and access paths, authority/CQRS boundary, migration, durable acceptance and projection freshness SLOs, data protection, and economics form one closed design.
ROUTE_MAP|SD02|ARCB@deliverable/08-fintech-trading-architecture.md C10@research/claim-register.md C29@research/claim-register.md kinesis_capacity@research/cost-model.md kinesis_recovery@research/cost-model.md FSR04@deliverable/07-reliability-and-correctness.md RBK04@deliverable/07-reliability-and-correctness.md|The ingestion architecture, partition ordering, external transaction boundary, capacity/recovery math, and ordered-lane runbook cover design and failure recovery.
ROUTE_MAP|SD03|ARCC@deliverable/08-fintech-trading-architecture.md CS12@research/repository-evidence.md REL07@deliverable/10-observability-security-and-operations.md C53@research/claim-register.md C115@research/claim-register.md INV01@deliverable/08-fintech-trading-architecture.md INV06@deliverable/08-fintech-trading-architecture.md DR01@deliverable/07-reliability-and-correctness.md DR02@deliverable/07-reliability-and-correctness.md DR03@deliverable/07-reliability-and-correctness.md|The exchange architecture, matcher evidence, release rules, compute fit, deterministic identity/postings, and command, ledger, and durable-log DR contracts support fenced regional recovery.
ROUTE_MAP|SD04|C65@research/claim-register.md C39@research/claim-register.md RSP08@deliverable/08-fintech-trading-architecture.md RSP09@deliverable/08-fintech-trading-architecture.md INV06@deliverable/08-fintech-trading-architecture.md FSR07@deliverable/07-reliability-and-correctness.md FSR12@deliverable/07-reliability-and-correctness.md SLO05@deliverable/10-observability-security-and-operations.md SLO06@deliverable/10-observability-security-and-operations.md SEC05@deliverable/10-observability-security-and-operations.md|Workflow semantics, compensation limits, settlement and ledger authorities, exact postings, provider/Region ambiguity, reconciliation closure, audit retrieval, and privileged approval are all required.
ROUTE_MAP|RW01|CS01@research/repository-evidence.md CS03@research/repository-evidence.md FSR02@deliverable/07-reliability-and-correctness.md REL04@deliverable/10-observability-security-and-operations.md|The exact order and producer paths, ambiguous publication handling, and compatible outbox release control support diagnosis and migration.
ROUTE_MAP|RW02|CS02@research/repository-evidence.md C40@research/claim-register.md AP08@deliverable/05-dynamodb-deep-dive.md FSR01@deliverable/07-reliability-and-correctness.md|The cached response path, idempotency identity rule, command-record access path, and unknown-response recovery define the repair.
ROUTE_MAP|RW03|CS04@research/repository-evidence.md CS05@research/repository-evidence.md C38@research/claim-register.md FSR04@deliverable/07-reliability-and-correctness.md AP04@deliverable/05-dynamodb-deep-dive.md|The exact execution write/publish paths, atomic outbox rule, duplicate/order recovery, and execution access path close both missing and duplicate cases.
ROUTE_MAP|RW04|CS06@research/repository-evidence.md CS07@research/repository-evidence.md CS10@research/repository-evidence.md AP07@deliverable/05-dynamodb-deep-dive.md AP13@deliverable/05-dynamodb-deep-dive.md REL05@deliverable/10-observability-security-and-operations.md|Repository projection/schema evidence, portfolio and rebuild access paths, and compatibility-aware cutover support exact-version migration.
ROUTE_MAP|RW05|CS09@research/repository-evidence.md AP06@deliverable/05-dynamodb-deep-dive.md C21@research/claim-register.md C24@research/claim-register.md C81@research/claim-register.md C96@research/claim-register.md C114@research/claim-register.md|The scan evidence, snapshot AP, pagination and capacity semantics, AP-first modeling, rebuild completeness, and hot-lane economics define the correction.
ROUTE_MAP|RW06|CS08@research/repository-evidence.md CS11@research/repository-evidence.md CS12@research/repository-evidence.md SEC03@deliverable/10-observability-security-and-operations.md REL04@deliverable/10-observability-security-and-operations.md REL07@deliverable/10-observability-security-and-operations.md SLO05@deliverable/10-observability-security-and-operations.md|Repository infrastructure/ledger/matcher gaps, least privilege, compatible migration/release, and zero-tolerance reconciliation closure establish the safe sequence.
TASK12_ROUTE_MAP_END