High-risk claim register

Reference appendixDownload original Markdown ↗

Last verified: 2026-08-22 (Asia/Dubai)

This register controls semantic language used by Tasks 2–14. Approved wording may be paraphrased only if the boundary remains equally narrow. A chapter author must re-check any mutable claim against its direct source and update the retrieval date. Inference means a design conclusion, not a documented AWS guarantee.

Evidence statuses:

• verified: the cited source directly supports the documented portion of the approved wording.
• route only: the source is the mandatory verification route; the mutable statement or value must be checked and dated before use.

The separate Inference handling column is authoritative. none means no additional inference label is required. Any other value requires the chapter to label that portion Inference: rather than presenting it as vendor-guaranteed.

Delivery, retry, ordering, and failure boundaries

ID	Approved wording	Boundary / forbidden shorthand	Source IDs	Freshness	Evidence status	Inference handling
C01	“Exactly once” is meaningful only after naming the operation, scope, identity key, time window, and externally visible side effects.	Never write “the system is exactly once.”	F01	stable	verified	none
C02	SQS Standard is an at-least-once queue: a message can be delivered more than once, and best-effort ordering can differ from send order. A Lambda SQS consumer can also receive a batch again after processing or acknowledgement failures.	Not “single delivery,” FIFO, or exactly-once processing.	A02, A09	mutable	verified	none
C03	An SQS FIFO queue preserves strict order within a MessageGroupId; independent groups can be processed independently.	Not global order across all groups.	A10	mutable	verified	none
C04	SQS FIFO deduplication suppresses duplicate sends with the same deduplication ID within the documented five-minute interval. It does not deduplicate a consumer's database writes, API calls, or other business effects.	AWS uses “exactly-once delivery” for this broker boundary. Do not expand it to “exactly-once processing.”	A10, F11	mutable	verified	label the external-effect boundary Inference:
C05	EventBridge retries a retriable target-delivery failure for up to the target's configured event age and retry attempts; the documented default is up to 24 hours and 185 attempts with exponential backoff and jitter. After exhaustion, a configured target DLQ can retain the undelivered event only when EventBridge has permission to send to that queue; without a usable DLQ, EventBridge drops it.	This is delivery from EventBridge to a target, not function-runtime retry or business rollback. A DLQ ARN in target configuration does not prove the queue is writable.	A05, A81	mutable	verified	none
C06	EventBridge target delivery, Lambda asynchronous invocation, and Lambda event-source mapping are three different failure boundaries with different owners, retry controls, and terminal destinations.	Do not use “the Lambda DLQ” without naming the invocation path.	A01, A04, A05	mutable	verified	label the cross-source synthesis Inference:
C07	A Lambda event-source mapping polls or otherwise reads from its source and invokes the function synchronously. The source or mapping retains/checkpoints work according to that integration; Lambda's asynchronous invocation queue and retry policy do not govern it.	Not equivalent to invoking Lambda asynchronously.	A01, A03, A04	mutable	verified	none
C08	PutEvents returns HTTP 200 with per-entry results and FailedEntryCount; producers must inspect and recover failed entries. Even HTTP 200, FailedEntryCount: 0, and an EventId are only producer-API acknowledgement under the named request: AWS documents that a nonexistent event bus can return those signals while event matching finds no rule and drops the event.	No PutEvents response proves valid bus configuration, matching/routing, target delivery, consumer durability, handler effects, or business completion. Independently validate the bus/configuration and reconcile downstream effects.	A06, A82	mutable	verified	none
C09	The package makes no ordering claim for an EventBridge event bus. If a design requires order, it introduces and cites an ordering mechanism, sequence/version check, or ordered transport.	This is a conservative architecture rule, not an assertion that observed delivery is random.	A07, F01	mutable	route only	label the entire design rule Inference:
C10	Kinesis Data Streams orders records within a shard; a partition key maps records to shards, so designs discuss ordering for a stated key and account for resharding.	Not global order across shards or an automatic business sequence.	A14	mutable	verified	none
C11	For Kinesis event-source mappings, Lambda checkpoints a batch only after complete success by default; a failed batch can be retried, so handlers must be idempotent.	Do not infer one invocation or one business effect per record.	A03	mutable	verified	none
C12	With ReportBatchItemFailures, Lambda uses the lowest failed sequence number as the checkpoint and retries from that record; successful records can still be retried.	Partial batch response reduces repeated work; it does not provide exactly-once processing.	A03	mutable	verified	none
C13	BisectBatchOnFunctionError splits a failed Kinesis batch for retry. When combined with partial failure reporting, Lambda bisects at the returned sequence number.	Bisection isolates failures; it is not a DLQ or a transaction.	A03	mutable	verified	none
C14	Kinesis Data Streams retains records for 24 hours by default and can be configured up to 8,760 hours (365 days); longer-than-default retention incurs additional charges.	A retention window is a replay opportunity, not proof consumers can recover within it.	A15	mutable	verified	none
C15	Provisioned Kinesis capacity is constrained per shard by documented record and byte rates. Retrieve the current quota page before using the present values in a calculation.	No timeless “Kinesis handles N events/s” claim. Payload size and key skew matter.	A16	mutable	route only	none
C16	A PutRecords call can partially succeed. Producers must inspect every entry's result and retry failed records without blindly duplicating successful records.	A successful request is not proof every record succeeded.	A17	mutable	verified	none
C17	Enhanced fan-out gives each registered Kinesis consumer dedicated read throughput per shard over SubscribeToShard; retrieve the current byte rate and consumer quotas before quantitative use.	It does not remove partition-key skew, downstream limits, retries, or idempotency needs.	A16, A18	mutable	verified	label downstream consequences Inference:
C18	SQS message retention is configurable within the current documented bounds, presently one minute through fourteen days.	Retention is not a durable archive or replay log.	A11	mutable	verified	none
C19	SQS FIFO throughput depends on region, batching, high-throughput mode, and message-group distribution. Query the current quota for the deployment instead of reusing “300/3,000 TPS per group.”	Reject fixed universal FIFO throughput.	A11	mutable	route only	none
C20	SNS FIFO topics preserve ordering and deduplicate within their documented FIFO delivery boundary; consumers must still make side effects idempotent. Verify supported subscriber types and throughput quotas at design time.	Not end-to-end exactly-once business processing.	A12, F11	mutable	verified	label the external-effect boundary Inference:

Storage, workflow, replay, and transaction boundaries

ID	Approved wording	Boundary / forbidden shorthand	Source IDs	Freshness	Evidence status	Inference handling
C21	DynamoDB can serve eventually consistent reads; tables and LSIs also support strongly consistent reads when requested. GSIs and DynamoDB Streams support eventually consistent reads only.	“DynamoDB is strongly consistent” or “eventually consistent” without naming the operation is incomplete.	A19	mutable	verified	none
C22	DynamoDB transactions provide ACID semantics for the documented DynamoDB items in one AWS account and Region. They do not atomically include EventBridge, SQS, an HTTP call, or another external system.	Not a distributed transaction across AWS services.	A20	mutable	verified	label the external-service boundary Inference:
C23	DynamoDB Streams captures item-level modifications in time order per item and retains stream records for 24 hours. A stream consumer can be retried and must be idempotent.	Do not claim table-wide global order or indefinite replay.	A01, A21	mutable	verified	none
C24	DynamoDB item size and service quotas are current-documentation facts. Retrieve them before capacity math and state whether secondary-index keys/attributes count toward the modeled write and storage.	No undated quota or “unlimited scale” shorthand.	A22	mutable	route only	none
C25	Step Functions Standard follows exactly-once workflow execution: tasks and states are not run more than once unless Retry behavior is specified in ASL. Asynchronous Express follows at-least-once workflow execution; Synchronous Express follows at-most-once workflow execution. These workflow-execution labels do not make provider completion or external effects atomic with workflow history.	Always name workflow type, invocation mode, Retry/Catch policy, and the task/provider stopping boundary.	A25, A26	mutable	verified	label external-effect design conclusions Inference:
C26	Amazon S3 provides strong read-after-write consistency for object PUT/DELETE and subsequent GET/LIST behavior described by the S3 consistency model.	This does not make a multi-object workflow transactional.	A27	mutable	verified	label multi-object boundary Inference:
C27	S3 event notifications are designed for at-least-once delivery and are not guaranteed to arrive in event order. Use object key, version ID, or sequencer information and idempotent processing where order matters.	Not a lossless, ordered transaction log.	A28	mutable	verified	none
C28	Amazon Data Firehose uses at-least-once delivery. If delivery times out, a retry might introduce duplicates when the original request eventually succeeds; AWS states that this duplicate warning applies to every supported destination except Amazon S3, Apache Iceberg Tables, and Snowflake.	State the destination before discussing retry-created duplicates. The three exceptions narrow this warning; they do not authorize an end-to-end exactly-once business-processing claim.	A29	mutable	verified	none
C29	Kafka transactions can make consume-transform-produce and offset commits atomic within Kafka's supported boundary. An external database or API side effect still needs an atomic connector/transactional integration or idempotency. Amazon MSK does not expand Kafka's transaction boundary.	Not “Kafka/MSK makes payment processing exactly once.”	A30, F28	mutable	verified	label the external-system and MSK boundary Inference:
C30	Use current service names: Amazon Managed Service for Apache Flink and Amazon Data Firehose. AWS X-Ray SDKs and daemon are on a published end-of-support path, so new tracing guidance routes through OpenTelemetry.	Do not use “Kinesis Data Analytics,” “Kinesis Data Firehose,” or recommend new X-Ray SDK instrumentation without dated context.	A29, A31, A37, F27	mutable	verified	none
C31	Data Firehose is a managed delivery service with buffering and destination-specific retry behavior; it is not a general replayable stream or work queue.	Not “Kinesis” shorthand; distinguish Data Streams from Data Firehose.	A29	mutable	verified	label the product-comparison conclusion Inference:
C32	DynamoDB TTL deletion is asynchronous and can occur within a period measured in days after expiry; TTL must not enforce a precise deadline or correctness invariant.	Reject “TTL deletes within 48 hours” as a guaranteed deadline.	A23	mutable	verified	label correctness consequence Inference:
C33	Service quotas are regional, mode-dependent, and mutable where the service page says so. Quote a number only with region, retrieval date, adjustable/non-adjustable status, and the controlling dimension.	No fixed quota copied from local notes.	A08, A11, A16, A22, A52	mutable	route only	none
C34	Ordering and concurrency trade off against the serialization scope: a single writer or partition can create order for that scope, while more partitions increase parallelism and require cross-partition coordination where invariants span keys.	“Global ordering is impossible” is too broad; it is possible only by accepting a common serialization bottleneck or equivalent coordination.	F01, F09, F24	stable	verified	none

Pattern, business-correctness, operations, and cost controls

ID	Approved wording	Boundary / forbidden shorthand	Source IDs	Freshness	Evidence status	Inference handling
C35	CQRS separates command and query models; it is a spectrum and neither requires two databases nor implies event sourcing. Start from access patterns and add projections only when their value justifies staleness, write amplification, recovery, and operational cost.	Never define CQRS as “two databases” or “event sourcing.”	F06, F21–F23	stable	verified	none
C36	Event sourcing stores state changes as an authoritative event sequence and reconstructs state by replay. It is independent of CQRS and much broader than publishing integration events after ordinary CRUD.	PutEvents or a DynamoDB Stream does not by itself make a service event sourced.	A06, F07	stable/mutable	verified	label the product-example boundary Inference:
C37	A message is the transport envelope; a command requests an action, an event records a past fact, and a notification may merely signal that something changed. CloudEvents and AsyncAPI standardize envelopes/contracts, not business semantics or processing guarantees.	Do not call every broker record an event.	F25, F26	stable	verified	none
C38	A transactional outbox atomically commits business state and an outbox record in one local database transaction; a relay/CDC process can publish later. Publication and consumption remain retryable, so consumers still need idempotency.	It solves the database-to-message dual-write gap, not end-to-end exactly once.	A20, A21, F04	stable/mutable	verified	none
C39	A saga coordinates a sequence of local transactions with compensating actions, but does not provide ACID isolation across the whole business process. State the chosen choreography/orchestration model, compensation limits, and reconciliation path.	Compensation is not rollback when an external action is irreversible.	F05, F10	stable	verified	none
C40	Business idempotency means repeated delivery of the same logical request produces one intended state transition/effect. Where possible, commit the idempotency record and protected state change in the same authoritative transaction.	A broker message ID, HTTP idempotency key, or time-limited cache alone is not proof of idempotent business effects.	F02, F04, F11	stable	verified	none
C41	Ordering does not remove duplicate delivery, and deduplication does not establish causal or version order. Ordered consumers still require idempotency; state transitions that reject stale versions require a sequence/version rule.	Never substitute FIFO for state-machine validation.	A02, A10, A12, A28, F01	stable/mutable	verified	label the cross-source synthesis Inference:
C42	A queue primarily assigns work among competing consumers and removes acknowledged work; a log retains an ordered sequence for independently tracked consumers and replay within retention. Actual products can combine traits, so state the concrete semantics.	Do not decide from the product category alone.	A14, F01, F02	stable/mutable	verified	none
C43	A DLQ is a holding area, not a recovery strategy. A complete design defines alarm ownership, retained context, diagnosis, correction, safe redrive, idempotency, replay order, and reconciliation.	“Send to DLQ” is not a terminal answer.	A13, A36, A43, F02, F03, F13	stable/mutable	verified	none
C44	Backpressure is a control decision: bound concurrency/backlog, shed or defer work, protect downstream capacity, and monitor age/lag against a recovery budget. Autoscaling alone can amplify overload or hit a downstream limit.	Reject “the managed service scales automatically” as an overload strategy.	A43, F03, F13, F14	stable/mutable	verified	none
C45	Retries require a deadline, bounded attempts, exponential backoff, jitter, and idempotent operations. Retry at one owned layer when possible to avoid multiplicative load.	Not “retry three times” without timing, error class, and ownership.	A26, A43, F03, F11, F12	stable/mutable	verified	none
C46	Authoritative financial state enforces monetary invariants and is the reconciliation source. Caches, search indexes, notifications, portfolio/P&L views, and analytics projections are derived and may be stale. Matching/execution, clearing/settlement, and ledgering are distinct boundaries.	Never approve a trade, reservation, or available balance solely from a convenience projection.	A24, A32–A35, F09, F17, F18 (retrieved 2026-08-24)	stable/mutable	verified	none
C47	A financial ledger is append-oriented, preserves audit history, and supports balancing/reconciliation. Use exact decimal or scaled-integer monetary representation with an explicit currency/scale; do not use binary floating point for authoritative amounts.	An event bus/archive or mutable balance row is not automatically an accounting ledger.	A41, F08, F17	stable/mutable	verified	none
C48	An SLO defines a measurable reliability target over a window; its error budget is the permitted shortfall. Service health metrics must be supplemented with business-correctness signals such as duplicate fills, ledger imbalance, projection lag, and reconciliation breaks.	Availability alone is not financial correctness.	A43, F14–F16	stable/mutable	verified	none
C49	Every numeric price is sourced and dated. Cost claims use eu-west-1 inputs and workload variables, then report units such as cost per accepted order, fill, projection update, or retained audit year. A break-even conclusion includes requests, bytes, fan-out, batching, duration/memory, indexes, retention, logs/traces, transfer, KMS, replay, and engineering/on-call cost.	Never write “serverless is cheaper” as a universal claim.	A44–A51, A63–A80, A99, F19, F20	mutable	route only	none
C50	Observability and security recommendations use current first-party guidance: OpenTelemetry-compatible signals and business correlation IDs; least-privilege temporary credentials; managed secret rotation; encryption/key policies; immutable or integrity-validated audit evidence; and explicit WAF/IAM boundaries.	A tool's presence is not proof of observability, least privilege, or audit integrity.	A36–A42, F27	mutable	route only	none
C51	API Gateway is the managed client-facing API boundary; API type, integration, authorization, timeout, payload, throttling, and quota semantics must be verified for the selected REST, HTTP, or WebSocket API before design claims or calculations.	API acceptance does not prove downstream business completion, and a quota for one API type is not portable to another.	A52, A53	mutable	route only	label downstream implications Inference:
C52	AWS Glue supplies managed data-integration/catalog capabilities and Athena queries data in place using SQL. Treat both as asynchronous analytics/projection paths and verify current quotas, supported formats, latency, and scan-based price inputs before use.	Neither service is an authoritative transaction processor or low-latency matching path.	A56, A57	mutable	route only	label workload-fit conclusions Inference:
C53	ECS, AWS Fargate, and EC2 are compute alternatives when sustained utilization, process lifetime, runtime control, specialized networking/hardware, or latency requirements make Lambda a poor fit. Verify the selected launch type/instance semantics and capacity model.	Do not claim containers or EC2 are always cheaper/faster; compare the stated workload and operational cost.	A58–A60	mutable	route only	label workload-fit conclusions Inference:
C54	API Gateway WebSocket APIs and AWS AppSync subscriptions are live-client delivery options with distinct connection, authorization, fan-out, and quota behavior. Client delivery remains a derived notification path, not authoritative financial state.	Never infer ordered, lossless, or exactly-once client receipt without a separately documented protocol.	A54, A55	mutable	route only	label delivery and authority conclusions Inference:
C55	Amazon MQ is a managed ActiveMQ/RabbitMQ compatibility option for legacy broker protocols and migration constraints. Verify engine/version/topology/durability semantics for the chosen broker.	Do not choose Amazon MQ merely because the system “needs a queue”; compare protocol compatibility and operational constraints with native AWS messaging.	A61	mutable	route only	label selection guidance Inference:
C56	Aurora read replicas and Aurora Serverless v2 have distinct scaling, endpoint, lag, capacity, and cost behavior. Verify current engine/version/Region support and keep monetary write invariants on an explicitly authoritative transaction path.	“Serverless” does not mean instantaneous scaling, zero idle cost, or strongly current replicas.	A35, A62	mutable	route only	label invariant and workload-fit conclusions Inference:
C57	For an EventBridge target DLQ configured programmatically, the SQS queue needs a resource-based policy granting events.amazonaws.com sqs:SendMessage, normally constrained by the rule source ARN. EventBridge publishes InvocationsFailedToBeSentToDLQ when it cannot place an event in the configured target DLQ.	Creating an SQS queue and setting dead_letter_config.arn does not grant this permission. A zero-depth queue is not evidence that no delivery failures occurred.	A81	mutable	verified	none
C58	Event notification announces a past fact without prescribing a recipient's reaction; event-carried state transfer includes enough state for a consumer to maintain a local copy; event collaboration is an interaction style in which components react to published facts; event sourcing makes an event sequence authoritative for rebuilding state. A design may combine these dimensions, but they are not synonyms.	Notification does not mean lossy, event-carried state is not event sourcing, and publishing integration events after CRUD does not make the producer event sourced.	F07, F29, F30	stable	verified	none
C59	Schema compatibility is a relationship between writer and reader versions, not a property of a format alone. An event contract includes syntax and business meaning: additive optional fields with defined defaults can support mixed versions, while changed identity, units, meaning, or required fields need an explicit compatible or versioned transition. CloudEvents and AsyncAPI can standardize envelopes and interface descriptions but do not prove semantic compatibility or processing guarantees.	“It is JSON,” a schema-registry check, or a new version field alone does not make a change safe for deployed consumers or retained-event replay.	F01, F25, F26	stable	verified	none
C60	EventBridge event buses evaluate events against rules and send matches to configured targets; SNS topics send published messages to subscribed endpoints. These are bounded routing/fan-out roles. Delivery, retention/replay, ordering, consumer commits, and business effects still follow the selected service mode, endpoint, and application design.	Do not define publish-subscribe from a product name or infer end-to-end processing guarantees from successful routing configuration.	A07, A83	mutable	verified	none
C61	Fairness is an explicit scheduling and isolation property: one tenant, key, priority class, or poison item must not monopolize shared capacity beyond the stated policy. Measure wait/lag by class and use bounded queues, quotas, lanes, weights, reserved capacity, load shedding, or admission control as the workload requires.	Aggregate throughput can look healthy while a quiet tenant starves. FIFO order is not a fairness policy, and autoscaling is not admission control.	F03, F13, F14	stable	verified	none
C62	EventBridge event-bus rules perform content-based matching and route matching events to targets. An optional archive retains selected bus events and can replay them to the source bus, but replay does not preserve original arrival order.	An event bus/archive is not a partitioned log, work queue, ledger, or proof of target/business completion.	A84	mutable	verified	none
C63	Receiving an SQS message makes it temporarily invisible; successful consumers delete it, while an unacknowledged message can become visible again. Lambda polls SQS and can deliver a record more than once, so partial-batch responses reduce unnecessary retries but do not remove the need for idempotent effects.	SQS FIFO plus Lambda is not end-to-end exactly once. Visibility is a lease, not a transaction over the handler's side effects.	A02, A85	mutable	verified	none
C64	SNS Standard subscribers can receive messages out of order or more than once. SNS applies filter policies per subscription, retries delivery according to the endpoint protocol, and can place exhausted deliveries in a subscription-level SQS DLQ. SNS FIFO ordering/deduplication remains scoped to its documented topic/subscription boundary.	Topic publication is not subscriber completion; Standard and FIFO modes and each endpoint's failure policy must be named.	A12, A13, A83, A86, A91	mutable	verified	none
C65	Step Functions Standard follows exactly-once workflow execution: tasks and states are not run more than once unless ASL Retry is configured. Asynchronous Express is at-least-once workflow execution and Synchronous Express is at-most-once workflow execution. Standard supports job-run and callback patterns; Express does not. Task invocation, provider completion, and external effects can remain ambiguous or non-atomic relative to workflow history.	Standard's positive guarantee stops at workflow execution; it is not exactly-once payment, ledger, provider, or API effect. Use stable identity, effect receipts, status lookup, idempotency, compensation, and reconciliation.	A25, A26, A87, F05, F10	stable/mutable	verified	label external-effect and compensation conclusions Inference:
C66	Data Firehose is a managed, buffered delivery path to supported destinations with destination-specific retry/duplicate behavior. Buffering controls are hints.	It is not a general event bus, competing-consumer queue, or replayable multi-consumer log.	A29, A88	mutable	verified	label workload-fit conclusion Inference:
C67	Managed Service for Apache Flink runs Apache Flink applications for stateful stream processing, including event-time logic. Checkpoints restore application state after failures; any exactly-once wording is bounded by the replayable source, checkpointed operator state, connector/sink behavior, and external effects.	Flink checkpoint recovery does not by itself make an arbitrary database or API side effect exactly once.	A31, A89, F31	stable/mutable	verified	label connector/external-effect boundary Inference:
C68	Operate each service at its owned boundary: delivery failures and failed DLQ writes for routers/topics; queue age, visibility/redelivery, and DLQ depth for work queues; iterator or consumer lag and throttling for logs; execution failures/timeouts for workflows; and checkpoint duration/failure, backpressure, and restart/downtime for stateful processors. Pair transport signals with business reconciliation.	A green service dashboard is not evidence of complete or correct financial state. Metric availability and names are service/version dependent and must be checked in current documentation.	A03, A36, A81, A85, A86, A89, A90	mutable	verified	label business-correctness conclusion Inference:
C69	An SNS FIFO topic can deliver to SQS Standard or FIFO queues. The SNS FIFO to SQS FIFO path is the path documented for strict order/deduplication; an SQS Standard subscriber has best-effort order and at-least-once delivery. AWS documents its FIFO exactly-once delivery/processing label only while all listed conditions hold, including no subscription filtering; with filtering enabled, AWS labels delivery at-most-once because messages can be filtered out. FIFO topic owners can enable a built-in archive, and subscribers can replay a selected time window to their endpoint.	These are SNS-to-SQS delivery/archive boundaries, not one-time consumer database or external effects. Replay can repeat effects and requires idempotency/reconciliation.	A92, A93, A94	mutable	verified	label the consumer/external-effect and replay conclusions Inference:
C70	Kinesis Data Streams currently offers Provisioned, On-demand Standard, and account-level On-demand Advantage. A new on-demand stream starts with documented baseline capacity; on-demand can throttle for roughly 15 minutes after traffic exceeds twice the prior peak, and one hot partition key remains bounded by one shard. Advantage adds warm throughput, a different price shape, and a 25 MiB/s ingest plus 25 MiB/s retrieval account-level regional commitment.	“On demand” is not instant unlimited capacity or hot-key isolation. Verify Region support, account settings, prior peak, commitment, and current quotas before selection.	A16, A95	mutable	verified	none
C71	A Kinesis stream defaults to a 1 MiB maximum record size and can be configured up to 10 MiB in supported Regions for intermittent large records. The sustained per-shard 1 MB/s write and 2 MB/s read baselines remain unchanged; large-record burst support is not intended for sustained high-volume large records.	Do not write simply “the maximum record is 10 MiB,” and do not convert intermittent burst support into sustained capacity. Downstream component limits can be lower.	A16, A95	mutable	verified	none
C72	PutRecord supports SequenceNumberForOrdering only for puts from the same client to the same partition key: submit serially and set record n to record n-1's successfully returned sequence number. An ambiguous result breaks that chain. PutRecords can partially succeed, processes later entries after an individual failure, and therefore does not guarantee request order; correlate every response entry and retry only failures.	Neither API deduplicates business effects. Retrying after an ambiguous result can duplicate a stored record; stable event identity, authoritative domain versions, and idempotent consumers remain required.	A17, A96	mutable	verified	label the ambiguous-result and external-effect consequences Inference:
C73	KPL collection batches Kinesis records into PutRecords; aggregation packs multiple user records into one Kinesis record. Buffering trades latency for packing efficiency, and consumers must deaggregate compatibly. Lambda parallelization plus aggregation has documented partition-key conditions; with enhanced fan-out, inner events whose partition keys do not correspond can be dropped without processing or a failure destination.	“Batching” and “aggregation” are not synonyms. Never enable aggregation without testing every consumer/deaggregator and partition-key/order path.	A03, A96, A98	mutable	verified	label consumer-compatibility design conclusions Inference:
C74	KCL balances shards across workers, checkpoints processed positions, provides at-least-once delivery, adapts to splits/merges, and processes/checkpoints parent shards before child shards to preserve per-partition-key order across resharding.	A checkpoint is consumer progress, not a transaction over an arbitrary database/API effect. A custom consumer must explicitly implement equivalent lease, parent/child, checkpoint, and retry behavior.	A97	mutable	verified	label external-effect and custom-consumer conclusions Inference:
C75	Provisioned resharding changes future hash-range routing while retained records remain in parent shards. On-demand manages shard count but can still throttle during rapid growth or skew; provisioned permits selective shard splits for hot hash ranges.	Adding shards cannot split a single partition key across shards without changing the key and its ordering scope. Capacity recovery must distinguish aggregate shortage from one irreducible hot key.	A95, A97	mutable	verified	label the single-key design consequence Inference:
C76	For Kinesis event-source mappings, Lambda treats errors before and during invocation differently. Pre-invocation throttling/system inability is retried until source expiry or MaximumRecordAgeInSeconds; MaximumRetryAttempts does not bound it. An invoked function error is retried until source expiry, maximum age, or the retry quota. Age is -1 or 60–604,800 seconds; retry attempts are -1–10,000. Bisection applies to function errors and splits do not consume retry quota. Partial failures restart at the lowest failed sequence. S3 retains the complete invocation record while SQS/SNS destinations retain failure metadata.	These controls reduce blocking/repeated work but do not create exactly-once processing. Operations must separate inability-to-invoke from handler poison/failed effects and destination delivery, then choose retained payload, replay, idempotency, and reconciliation.	A03, A98	mutable	verified	label external-effect and recovery-policy conclusions Inference:
C77	Kinesis publishes producer/read success, byte/record, throttling, iterator-age, and enhanced-fan-out metrics; optional shard-level metrics help locate skew. Lambda publishes function metrics and opt-in event-count metrics including failed invokes, drops, and successful on-failure delivery. Exact names/dimensions and enablement are mutable.	A stream-level average can hide one hot shard, and a delivered failure record does not prove a repaired business effect. Pair service metrics with producer identities, consumer checkpoints, version gaps, and reconciliation.	A98, A99	mutable	verified	label business-correctness conclusions Inference:
C78	Kinesis price calculations use the current eu-west-1 AWS Price List and pricing-page billing semantics. On-demand Data-In rounds each record to 1 KiB; provisioned PUT payload units use 25 KiB chunks. Keep raw payload bytes, billed ingestion units, read bytes, shard/consumer hours, retention, and downstream costs separate.	Do not reuse US-East examples, mix raw bytes with billed units, or report invoice-level precision from a workload estimate.	A46, A99	mutable	verified	none
C79	ExplicitHashKey overrides normal partition-key hashing. If its mapping changes, records with one logical partition key can be routed to different shards and lose the normal same-key ordering assumption.	Use one authoritative stable mapping plus an ordered, version-checked cutover, or reject explicit hashing where logical-key order is load-bearing.	A96	mutable	verified	label the ordering and cutover consequence Inference:
C80	Large-record support is an end-to-end compatibility decision: KCL 2.x and KPL 1.0.5+ support it; Lambda's base64-plus-metadata envelope remains limiting and oversized records use the configured failure path; Firehose dynamic partitioning and HTTP/Snowflake/Redshift destinations do not support it; the Flink Kinesis source supports up to 10 MiB while its sink must not be used above 1 MiB.	Do not increase a stream maximum until every producer, consumer, transformer, destination, failure path, and replay tool is proven compatible.	A95	mutable	verified	none
C81	DynamoDB modeling starts with a complete access-pattern inventory, then chooses item collections and indexes that answer those patterns. Key conditions select data; filter expressions run after selection and do not reduce the read work already performed. Single-table design can return heterogeneous related items in one request, but new access patterns, analytics, ownership, and cognitive/deployment coupling can justify other table boundaries.	Never start from a generic entity diagram, add an index without an owned AP, or present one mega-table as doctrine.	A111, F21, F22, F33–F35	stable/mutable	verified	label workload/table-boundary conclusions Inference:
C82	DynamoDB tables and LSIs support eventual or strong reads; GSIs and Streams support eventual reads only. Standard reads round evaluated data in 4 KiB units (strong 1 unit, eventual 0.5), transactional reads double the strong-read units; standard writes round each written item in 1 KiB units and transactional writes double them. Query rounds the evaluated result before filtering, while BatchGet rounds each item separately.	Do not apply one aggregate rounding rule to every API or request strong consistency from a GSI.	A19, A100	mutable	verified	none
C83	TransactWriteItems and TransactGetItems currently support up to 100 distinct items and 4 MB across one or more tables in the same AWS account and Region; a write transaction cannot target the same item twice. Transactional changes reach GSIs, Streams, and backups gradually, and a ClientRequestToken deduplicates identical TransactWriteItems calls for only ten minutes.	Transactions may cross tables inside the documented boundary, but request-token idempotency is not durable business idempotency and a stream batch is not a transaction envelope.	A20, A101	mutable	verified	none
C84	DynamoDB Streams retains change records for 24 hours, preserves modification order for each individual item primary key, and offers key-only, new-image, old-image, or old-and-new-image views. Lambda consumption is at least once and can repeat a record. Transaction changes can interleave or appear at different times, so a same-transaction outbox item is required when consumers need one semantic business-event envelope.	A Stream is short-lived CDC, not a long-retention event store, ledger, global item-collection order, or exactly-once business effect.	A21, A102	mutable	verified	label semantic-envelope and external-effect conclusions Inference:
C85	DynamoDB TTL deletes expired items asynchronously, typically within a few days. Pending expired items remain readable/billable until deletion; TTL deletes appear in the originating Region's Stream as service deletes, and MREC replicated deletes consume replicated write capacity.	TTL is cleanup only, not lease, authorization, financial expiry, or retention-deadline enforcement. MRSC global tables do not support TTL.	A23, A103, A107	mutable	verified	label correctness/expiry conclusions Inference:
C86	An LSI shares the base partition key, is created with the table, contributes to the 10 GB item-collection limit, and can support strong reads. A GSI uses independent keys, is maintained asynchronously, supports eventual reads only, and its capacity/skew can throttle base-table writes. Sparse indexes contain only items with the index keys; changing an indexed key can create an old-entry delete plus new-entry put.	Item collections, adjacency lists, sparse GSIs, and overloaded indexes are tools only when their AP mapping and amplification are explicit.	A104, F21, F35	stable/mutable	verified	label workload-fit conclusions Inference:
C87	Current on-demand warm throughput for a new table is 12,000 read units/s and 4,000 write units/s, while an individual physical partition remains bounded at 3,000 read units/s and 1,000 write units/s. Provisioned capacity, autoscaling, warm throughput, burst capacity, and adaptive capacity have distinct response boundaries; none makes one hot key unlimited.	High-cardinality distribution and measured skew remain design inputs. Write sharding trades a hotter key for fan-out reads plus ordering/merge work.	A22, A105, F24, F32, F33	stable/mutable	verified	label sharding and overload consequences Inference:
C88	DynamoDB PITR supports a configurable 1–35-day window at per-second granularity and restores to a new table. Export to S3 uses the PITR data plane asynchronously without consuming RCUs or affecting table performance; full and incremental exports are available, and incremental exports are compacted final-state views that can split one transaction across export windows.	Restore/export is not in-place rollback, an atomic business snapshot, a ledger, or automatic projection reconstruction.	A106	mutable	verified	label recovery/projection conclusions Inference:
C89	Global Tables default to multi-Region eventual consistency (MREC); multi-Region strong consistency (MRSC) was introduced in 2025. MRSC uses exactly three Regions as three replicas or two replicas plus a witness, synchronously replicates for cross-Region strong reads and zero RPO at higher latency, cannot use TTL, LSIs, or transactions, and the consistency mode cannot be changed after creation. MREC remains asynchronous, has no replication-latency SLA, and its transactions are atomic only in the source Region; its recovery point equals observed replication delay, usually seconds but requiring measurement.	Multi-Region replication does not supply conflict-free financial semantics or make external effects globally atomic. Monitor replication/conflict signals and reconcile.	A24, A107	mutable	verified	label business-conflict and external-effect conclusions Inference:
C90	Durable idempotency stores a canonical request fingerprint and state such as IN_PROGRESS with an owner/lease, then COMPLETED with the durable response and protected business effect committed atomically where possible. Concurrent duplicates read the same result or receive a retryable in-progress response; mismatched fingerprints are rejected, and expired/failed attempts use an explicit repair path. Event consumers use a durable inbox keyed by stable business event identity.	TTL is cleanup, a client request token is ten-minute API deduplication, and a cached HTTP response alone does not prove one business effect.	A20, A101, F11	stable/mutable	verified	label the record/state-machine design Inference:
C91	DynamoDB can atomically store exact monetary state and immutable posting items, but accounting semantics come from the application contract: fixed minor units or exact decimal discipline, currency/scale and rounding policy, balanced postings, authoritative balances/reservations, version checks, projection separation, and reconciliation.	DynamoDB, Streams, an order row, or a mutable balance row is not by itself a ledger.	F08, F17, F21	stable	verified	label the concrete ledger design Inference:
C92	DAX, ElastiCache, Aurora, and OpenSearch solve different APs. DAX caches eventually consistent item reads and passes strong/transactional reads through; cached Query/Scan results are not invalidated by item writes. ElastiCache requires an explicit cache-aside/read-through invalidation and source-of-truth policy. Aurora PostgreSQL is PostgreSQL-compatible and ACID-compliant and exposes SQL transactions with documented isolation boundaries; OpenSearch suits search/relevance/aggregations as a derived index.	No cache or search index should authorize balances, reservations, executions, or ledger postings. Engine, endpoint, replica, and isolation choices must be explicit.	A32–A35, A108, A109, A112	mutable	verified	label selection and source-of-truth conclusions Inference:
C93	DynamoDB condition expressions can enforce create-if-absent and compare-and-set transitions; optimistic version attributes reject stale writers but do not deduplicate distinct events. A uniqueness sentinel item and the protected entity can be conditioned/written in one transaction where the uniqueness scope fits the transaction boundary.	A version check is not event identity, and checking before writing is not uniqueness under concurrency.	A101, A110	mutable	verified	label sentinel and concurrency design Inference:
C94	A table per bounded context is often a useful default for this case because it aligns ownership, IAM, stream, backup/restore, scaling, and deployment boundaries while retaining single-table item collections inside a context and cross-table transactions where documented.	This is a governed case-specific choice, not a universal DynamoDB rule; a mega-table or multiple entity tables can be better under different AP and ownership constraints.	F21, F22	stable	verified	label every use Inference:
C95	DynamoDB write amplification is the sum of rounded base-item and affected index-entry work. For TransactWriteItems, each transaction-targeted base-item write consumes two underlying writes; indexes are not transaction targets, and each asynchronously affected GSI entry is added at ordinary index write cost after the transaction completes. For a sub-1-KiB GSI entry, defining indexed attributes requires one index put, removing them requires one index delete, and changing an indexed key requires the old delete plus the new put. Index projection size, sparse membership, key moves, and entry count change capacity and storage; GSI propagation is gradual and index throttling can affect base writes.	Never apply the transaction multiplier to GSI entries, count only the insertion side of a sparse-index lifecycle, or omit a sentinel/index from a named logical route. “One API write equals one write unit” and “indexes are free reads” are false models.	A100, A101, A104	mutable	verified	label workload consequence Inference:
C96	Query must paginate using LastEvaluatedKey; Scan also paginates and reads broad table/index data. Projection rebuilds need a versioned full source, repeatable checkpoint/cutover protocol, and gap detection because Streams retention is only 24 hours and exports are not transaction snapshots.	A one-page Scan, one export object, or a live Stream alone is not a complete rebuild.	A102, A106, A111	mutable	verified	label rebuild/cutover design Inference:
C97	CQRS separates command and query responsibilities along a spectrum: separate code paths, same-store models, authoritative state plus projections, specialized read stores, or an event-sourced command model. A separate database and event sourcing are optional decisions justified by measured access patterns, consistency/freshness SLOs, and operating cost.	Never define CQRS as two databases, require eventual consistency for code-only CQRS, or make event sourcing the final mandatory maturity stage.	A113, F06, F36	stable/mutable	verified	label workload-fit and adoption conclusions Inference:
C98	An event-sourced aggregate reconstructs state from an authoritative per-aggregate event sequence and appends against an expected version. Production design includes snapshot version/invalidation, immutable event schema or upcasters, temporal replay, isolated backfill, external-effect suppression, and event-store backup/restore/reconciliation. A transport log is an event store only if the complete authority, retention, concurrency, schema, recovery, and query contract is deliberately satisfied.	Kinesis retention or DynamoDB Streams alone is not automatically an event store. A snapshot is an optimization, not authority, and replay must not resend historical payments or notifications.	A114, F01, F07, F36	stable/mutable	verified	label AWS-product/event-store fit and replay-effect conclusions Inference:
C99	A semantic outbox item committed with authoritative state closes the local state-versus-publication-intent atomicity gap. Raw CDC closes no semantic transaction-envelope gap by itself; a relational outbox closes the same local gap through one database transaction and polling/log-tail CDC; direct database/broker dual write closes neither crash window. Every relay/consumer path still admits retries or ambiguous outcomes and requires stable identity, idempotency, replay controls, and reconciliation.	Outbox/CDC is not end-to-end exactly once. DynamoDB transaction item changes can interleave in Streams, so consumers needing one business envelope consume the semantic outbox item rather than infer a transaction from raw rows.	A20, A21, A101, A102, A115, F04, F11	stable/mutable	verified	label variant-selection and semantic-envelope conclusions Inference:
C100	An idempotent projection applies a stable event identity and authoritative aggregate version in one conditional target mutation/inbox boundary, rejects stale/duplicates, parks gaps, checkpoints only committed progress, and reconciles against authority. Rebuild uses a versioned isolated target, controlled backfill plus catch-up, side-effect suppression, control totals, and blue/green cutover/rollback.	Deduplication alone does not establish order; a checkpoint does not prove the target effect; rebuilding in place can corrupt the serving projection.	A102, A106, F01, F02, F11	stable/mutable	verified	label the concrete rebuild/cutover procedure Inference:
C101	Saga choreography distributes process progress across participant events; orchestration keeps explicit durable process state in a coordinator. Both require idempotent tasks, timeouts, semantic locks, compensation limits, effect receipts, and reconciliation. A pivot/irreversible step changes later recovery toward forward completion or manual resolution. Step Functions Standard supports durable history and callback waits, but workflow execution semantics do not make arbitrary downstream effects exactly once.	Compensation is a forward business action, not ACID rollback. Do not use a saga to hide an invariant that should be enforced in one aggregate/transaction.	A25, A26, A87, A116, F05, F10	stable/mutable	verified	label service/external-effect, pivot, and workload-fit conclusions Inference:
C102	A CQRS break-even model compares read work avoided with per-write transport, projection/index writes, storage, replay/rebuild, reconciliation, and fixed engineering/on-call burden. With all terms in one declared cost unit, the read/write threshold is (variable projection cost per write + fixed operational cost / writes) / avoided cost per read; sensitivity must vary volume, read benefit, and fan-out.	A read/write ratio alone cannot justify CQRS, and modeled cost units are not an AWS bill. Task 10 may substitute dated eu-west-1 prices without changing the dimensional equation.	F19, F20	stable	verified	label workload conclusions Inference:
C103	SQS DLQ redrive is a bounded message-move operation, not message transformation or repair. Operators can set a custom maximum redrive velocity and should begin slowly; redrive needs explicit IAM/KMS permissions, source/DLQ retention awareness, idempotent consumers, an abort threshold, and post-redrive validation. Standard-queue expiry continues from original enqueue time, while FIFO enqueue time resets on DLQ transfer.	A DLQ, redrive task, or empty queue does not prove repaired business state. SQS does not filter or modify messages during managed redrive.	A118	mutable	verified	label the workload-specific rate, repair, and validation policy Inference:
C104	Lambda reserved concurrency bounds and reserves function-level concurrency. SQS event-source maximum concurrency is a separate mapping-level cap; the sum of mapping caps should fit the function reservation or throttling can result. These controls isolate capacity but do not admit clients, repair effects, or prove downstream capacity.	Autoscaling is not admission control or backpressure. A circuit breaker and concurrency cap contain load but do not establish correctness.	A117, F03, F13	stable/mutable	verified	label capacity allocation and overload-policy conclusions Inference:
C105	RTO and RPO are organization-defined recovery objectives. AWS Well-Architected requires selecting and testing a recovery strategy against them; multi-Region replication/failover does not replace backups, corruption recovery, single-writer fencing, external-effect reconciliation, or game days.	Illustrative RTO/RPO values are business assumptions, not AWS service promises. Multi-Region is not globally atomic financial processing.	A119, F14, F15	stable/mutable	verified	label concrete tier objectives and failover decisions Inference:
C106	Region failover must use a pre-provisioned recovery data plane such as Route 53 health checks or ARC routing controls rather than depending on a centralized control plane during the incident. DNS TTL governs resolver cache freshness, while existing connections and endpoint caches can continue reaching the old Region until clients reconnect or re-resolve; keepalive and client retry identity must fit the RTO.	A routing-control change does not instantly move every client, fence the old writer, prove data recovery, or make a retried command safe. Test failover and failback through cached DNS and long-lived-connection paths.	A120, A121	mutable	verified	label concrete routing, TTL, connection, and retry-policy conclusions Inference:
C107	FIX separates the client order identity (ClOrdID), current order state (OrdStatus), specific report purpose (ExecType), execution identity (ExecID), correction/cancel reference (ExecRefID), ordered quantity (OrderQty), cumulative filled quantity (CumQty), and open quantity (LeavesQty). For an active order, FIX defines LeavesQty = OrderQty - CumQty; terminal states can report zero leaves.	A lifecycle implementation must choose and version its own transition/correction policy. FIX vocabulary does not make a message authoritative, cancel an accepted fill, or prove one-time processing.	F37	stable	verified	label concrete authority and transition design Inference:
C108	Execution, clearing obligation, and settlement completion/failure are distinct states. PFMI requires an applicable financial-market infrastructure's rules to define when settlement becomes final; the intended value date, revocability/finality point, calendar, and legal effect belong to the governing market/product policy.	Never infer settlement from execution or present one jurisdiction/product calendar as universal law. External statements and independently owned reconciliation remain required.	F17, F38	stable	verified	label concrete obligation/state machine and policy choice Inference:
C109	CloudTrail log-file integrity validation and S3 Object Lock can protect or validate named evidence artifacts within their documented scopes. Object Lock applies retention/legal hold to object versions and has distinct governance/compliance modes.	CloudTrail, Object Lock, KMS, encryption, or an immutable archive alone does not prove record completeness, semantic correctness, access governance, retention-policy suitability, or regulatory compliance.	A41, A122	mutable	verified	label evidence architecture and compliance conclusion Inference:
C110	Business/effective, event, ingestion, processing, and recorded times answer different questions. FIX TransactTime identifies when the represented business transaction occurred; causality and serialization still require stable identity, source sequence/version, writer epoch, and dependency relationships.	A wall-clock timestamp, even UTC and high precision, is not a causal or total-order proof. Policy time zones/cutoffs must map deterministically to UTC [startInclusive,endExclusive) reporting windows.	F01, F37	stable	verified	label the cross-source time/causality synthesis Inference:
C111	The LMAX article is a concrete example of sequential in-memory business logic fed by a durable journal, deterministic replay, snapshots, and replicated processors. It demonstrates that a single writer can simplify one serialization scope; it is not a universal exchange topology, AWS guarantee, or measured capacity promise for another workload.	Do not copy LMAX's historical throughput figure, whole-platform single thread, or failover design as a default. Partition books and choose runtime only from measured latency, throughput, recovery, and operating evidence.	F09	stable	verified	label every concrete match-core design and workload conclusion Inference:
C112	Task 9 architecture envelopes are illustrative assumptions expressed as workload ratios, rates, bytes, service time, utilization, capacity allocation, and modeled engineering burden. They make selection falsifiable but are not AWS prices, service promises, or production measurements.	Do not turn a ratio threshold into an automatic architecture decision or duplicate Task 10's complete regional price analysis. Measure distributions, skew, tail latency, downstream commit rate, rebuild time, correctness loss, and ownership before selection.	F19, F20	stable	verified	label every workload selection conclusion Inference:
C113	Fintech unit economics uses a business denominator and three explicit numerators: marginal AWS cost, allocated platform cost, and risk-adjusted fully loaded cost. Every mutable price input is bound to the exact eu-west-1 AWS Price List SKU, usage/operation, unit, tier boundary, publication, currency, and retrieval date; workload and people costs remain labeled planning assumptions.	A unit ratio is not an invoice or permission to game the denominator. Rejected orders, partial fills, inactive-account burden, duplicate/retry work, replay, and retention growth remain in the numerator or an explicit reconciliation.	A99, A123–A126, F19, F20	stable/mutable	verified	label allocation and economic recommendations Inference:
C114	Capacity economics must recompute the reviewed Kinesis and DynamoDB formulas with billed-unit rounding, skew/hot-key feasibility, headroom, fan-out, live+safety+replay allocation, and no-safe-drain branches. A cheap monthly average cannot establish a per-key/per-partition feasibility or recovery claim.	Never replace Task 5/6 capacity units, infer hot-key feasibility from aggregate cost, or call replay alone repair.	A99, A100, A105	mutable	verified	label workload, distribution, and migration conclusions Inference:
C115	Lambda memory selection is a measured experiment across memory, architecture, duration, tail latency, and workload shape. Lambda versus sustained compute compares price-only break-even separately from availability/headroom, idle capacity, scaling lag, connection/state reuse, patching/failover, and engineering/on-call burden.	More memory does not universally reduce cost or latency; price parity is not decision parity; serverless is not universally cheaper.	A51, A123, A124	mutable	verified	label workload-fit and measured-tuning conclusions Inference:
C116	Adding a DynamoDB global-table replica converts the existing table into a replica table: on-demand base-table writes consume replicated write request units (rWRUs) in every Region containing a replica, while GSI updates consume ordinary write request units (WRUs) in every such Region.	For n added replica Regions, bill base rWRUs and GSI WRUs in all n+1 Regions; single-Region and global-table operations are distinct even when current public unit prices happen to be equal.	A127	mutable	verified	label topology, restore/storage exclusions, and price conclusions Inference:
C117	An SLO is a user-outcome objective over explicitly defined good and eligible events. Error-budget and multi-window burn-rate alerts can combine fast and slow detection; concrete targets, windows, and paging thresholds remain workload policy, and safety invariants remain outside an availability budget.	A burn-rate policy is not an AWS guarantee and cannot legalize lost commands, duplicate effects, unexplained balances, or other correctness breaks.	F14–F16, F39	stable	verified	label every target, exclusion, and threshold Inference:
C118	W3C Trace Context standardizes trace propagation, while baggage carries application-defined properties and has explicit privacy/security risks. Trace/span identity is diagnostic and sampling-sensitive; durable command, event, order, execution, account, and source-version identities must be persisted independently.	A trace ID is not a business idempotency key, durable lineage proof, audit record, authorization context, or completeness proof. Never place secrets or raw sensitive identifiers in baggage.	F27, F40, F41	stable	verified	label sampling, redaction, and correlation policy Inference:
C119	AWS service metrics have service-specific namespaces, dimensions, statistics, publication behavior, and gaps: API Gateway distinguishes Latency from IntegrationLatency; DynamoDB throttles/errors require valid dimension pairs; Step Functions count metrics can be at-least-once or best-effort; Firehose delivery/freshness metrics are destination-scoped and one-minute aggregation can hide short bursts; Lambda, EventBridge, SQS, and SNS metrics have their own documented statistics, delivery limits, and dimensions.	These metrics diagnose components; they do not prove an accepted financial command completed, a projection is correct, a customer received a notice, or audit evidence is complete.	A128–A131, A139–A142	mutable	verified	retrieved 2026-08-23; label alarm windows and business-signal synthesis Inference:
C120	Least privilege requires scoped policy reasoning and validation, including identity- and resource-based policy interaction and service-specific confused-deputy conditions. In pooled SaaS, runtime tenant context and tenant-scoped credentials/authorization are explicit controls; dedicated accounts or resources change blast radius but do not alone prove tenant isolation.	Wildcard-free text is not sufficient proof of least privilege. Multi-account topology, JWT presence, or a private network does not substitute for resource-level authorization and cross-tenant negative tests.	A38, A132, A136, A138, A143	mutable	verified	A38 retrieved 2026-08-22; A132 A136 A138 A143 retrieved 2026-08-23; label the concrete tenant and account boundary Inference:
C121	Every KMS key has a key policy; IAM permissions govern a KMS key only when its key policy enables that path. Encryption context can constrain symmetric-key use and is logged in plaintext, so it must not contain secrets. Secrets Manager rotation coordinates secret and target-service credential versions and can fail or retry.	Encryption is not authorization or availability. Rotation is not complete until consumers use and validate the new credential, old access is revoked as policy permits, and dependent effects reconcile.	A39, A40, A133, A134	mutable	verified	retrieved 2026-08-23; label key, revocation, and rotation policy Inference:
C122	CloudTrail records named management, data, network-activity, and Insights event scopes; by default trails/event data stores include management events but not data or Insights events. Integrity validation and immutable storage protect named artifacts only. SaaS silo/pool/bridge choices change isolation and operational trade-offs but do not establish application authorization. AWS WAF protection applies only through a supported, explicitly associated web ACL scope and does not authenticate a caller.	CloudTrail is not an application financial audit or proof of event completeness, and account/VPC/WAF boundaries do not prove tenant isolation or authorization. Record event selectors, regions/accounts, trails/stores, retention, validation, application evidence, and WAF association scope separately.	A41, A42, A122, A135, A136, A144	mutable	verified	A41 A42 A122 retrieved 2026-08-22; A135 A136 A144 retrieved 2026-08-23; label audit coverage and topology conclusions Inference:
C123	A Lambda weighted alias can route between at most two published versions subject to documented compatibility constraints; CodeDeploy deployment configurations can stage Lambda traffic and integrate alarms/rollback. Event and data evolution still requires explicit backward/forward compatibility, retained rollback targets, replay safety, and correctness reconciliation.	A canary metric or code rollback cannot erase events, postings, provider calls, schema changes, or other facts already emitted. Dual writes are not atomic without an authority/evidence contract that closes divergence.	A137, F01, F25, F26	stable/mutable	verified	retrieved 2026-08-23; label rollout fractions, stop conditions, and migration decisions Inference:

Interview-dangerous local corrections

These findings do not edit the read-only repositories. Later chapters must quote the approved replacement, not the local shorthand.

ID	Evidence IDs and exact local locator	Problem	Controlled replacement
X01	R01, R05 — SSE tier-1-core/message-queues/basic.md:60; application docs/use-cases/kinesis-use-cases.md:214,218-219	Deduplication at send/delivery is expanded into consumer processing and external effects.	Use C03–C04. Say “FIFO deduplicates repeated sends with the same deduplication ID during the documented interval and orders within a message group; consumers remain idempotent.”
X02	R01, R05 — SSE tier-1-core/message-queues/basic.md:62; application docs/sqs.md:18 and docs/use-cases/kinesis-use-cases.md:210,219	Frozen quota and ambiguous unit/group/region/high-throughput mode.	Use C19. Query A11 for the target Region and mode, date the value, and model active message groups plus batching.
X03	R02 — application docs/use-cases/eventbridge-use-cases.md:29-40 describes target retries/DLQs; code/lambdas/order-handler/handler.ts:195-208 and code/lambdas/trade-executor/handler.ts:135-148 publish without checking entry results.	Risks treating EventBridge's target handoff as Lambda runtime retry, treating PutEvents acknowledgement as routing/durability, and treating a configured DLQ ARN as a writable recovery path.	Use C05–C08 and C57. Draw separate boxes for producer API acknowledgement, bus/configuration validation, EventBridge delivery, DLQ permission/write, Lambda invocation type, and business processing/recovery.
X04	R03 — application docs/use-cases/kinesis-use-cases.md:210,508,853-882 contains fixed shard rates, reshard-operation limits, consumer thresholds, and dollar cutovers.	Mutable limits/prices are presented as timeless architecture rules.	Use C14–C17, C33, and C49. Recalculate from current pages, dated eu-west-1 inputs, payload distribution, key skew, and consumer topology.
X05	R03 — application docs/kinesis.md:151 and docs/use-cases/kinesis-use-cases.md:529,549 use “Kinesis Data Firehose.”	Product names are stale.	Use C30: “Amazon Managed Service for Apache Flink” and “Amazon Data Firehose”; mention former names only for search/history context.
X06	R03, R06 — SSE tier-1-core/kafka/basic.md:21,47-57 and tier-1-core/kafka/theory.md:36-51,125,201-223,253; application docs/use-cases/kinesis-use-cases.md:853-888.	Compact “exactly one consumer,” ordering, and Kafka/MSK “exactly once” labels omit partition/group membership, retries/rebalances, transaction boundary, and external effects.	Use C10–C13, C29, C34, and C41. State the partition/shard and consumer-group boundary, then add idempotency and version checks.
X07	R04 — application code/lambdas/order-handler/handler.ts:12-21,136-208, code/lambdas/trade-executor/handler.ts:76-148, and code/lambdas/portfolio-updater/handler.ts:44-119.	Code/comments expose non-atomic state/publication sequences, best-effort idempotency, and projection retries; local implementation intent is not proof of end-to-end guarantees.	Use C06, C08, C38, C40, C41, and C46. Task 2 must evidence each path and label repository inference separately from documented service behavior.

Repository case-study finding register

These twelve IDs are the canonical routes for the running case study. The repository locator controls the observed portion. The claim/source IDs control documented semantics. The “required conclusion” is explicitly an Inference unless it merely repeats code or controlled wording. Later chapters and drills cite these IDs instead of inventing a broader guarantee.

ID	Exact repository evidence	Controlled semantics	Required bounded conclusion
CS01	code/lambdas/order-handler/handler.ts:155-165,167-181,183-208	C22, C38 / A20, A21, F04	Inference: the order/idempotency writes and EventBridge publication are separate commits, so an outbox/repair state plus idempotent consumption is required.
CS02	code/lambdas/order-handler/handler.ts:167-180,229-241	C08, C32, C40 / A06, A23, A82, F11	Inference: a cached 201 can be returned without reliable evidence of valid bus routing or downstream progress; transact the key, request identity, protected state, and outbox, validate configuration separately, and define late-retry behavior.
CS03	code/lambdas/order-handler/handler.ts:193-205; code/lambdas/trade-executor/handler.ts:134-145; code/lambdas/dlq-replayer/handler.ts:114-133	C08 / A06, A82	Documented + observed: all three callers discard per-entry results. Even zero failed entries plus EventId is only producer-API acknowledgement and can accompany a nonexistent-bus drop. Inspect entries, independently validate the bus/configuration, retain durable replay identity, and reconcile downstream effects.
CS04	code/lambdas/trade-executor/handler.ts:83-118,120-145	C22, C38 / A20, A21, F04	Inference: trade creation, order transition, and outgoing event can diverge. Transact compatible DynamoDB state plus outbox with a conditional state transition.
CS05	code/lambdas/trade-executor/handler.ts:79-104,120-145	C08, C40 / A06, A82, F11	Inference: after a late publication failure, ordinary retry encounters the conditional duplicate trade write before publication. Publication intent must be independently retryable under the original event identity.
CS06	code/shared/types/events.ts:36-47; code/lambdas/portfolio-updater/handler.ts:145-186	C40-C41 / F11	Inference: optimistic item-version locking does not deduplicate tradeId; atomically store a projector inbox identity with the protected projection mutation.
CS07	code/shared/types/events.ts:36-47; code/lambdas/portfolio-updater/handler.ts:145-178; infra/environments/production/main.tf:565-605	C09, C34, C41 / A07, F01, F09, F24	Inference: the portfolio applies arrival order without a source sequence. Add an authoritative per-scope version, stale/duplicate rejection, gap handling, and reconciliation.
CS08	infra/modules/eventbridge/main.tf:29-38,73-95; infra/environments/production/main.tf:575-605; infra/modules/lambda/main.tf:12-70; repository-wide absence assertion for aws_sqs_queue_policy and sqs:SendMessage	C05-C07, C57 / A01, A03-A05, A81	Documented + observed: target DLQ and Lambda runtime failures are separate, and neither declared SQS DLQ has the resource policy required for EventBridge to send. Add rule-scoped queue policies, alarm InvocationsFailedToBeSentToDLQ, retain an independent recovery source, and operate each boundary separately.
CS09	code/lambdas/portfolio-snapshot/handler.ts:64-107	C21, C24 / A19, A22; direct bounded route: DynamoDB export to S3, retrieved 2026-08-22	Inference: one filtered, unpaginated Scan assembled into one in-memory object is not a scalable or proven complete point-in-time export. Use bounded pagination or PITR-backed DynamoDB export, manifests, and reconciliation controls; export completion remains asynchronous.
CS10	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	C47 / A41, F08, F17	Observed + controlled: authoritative monetary amounts must not use binary floating point. Carry exact value, currency, scale, and governed rounding.
CS11	code/shared/types/dynamodb.ts:16-93; infra/modules/dynamodb/main.tf:1-60; repository-wide absence search recorded in repository-evidence.md	C46-C48 / A32-A35, A41, F08, F17, F18	Inference: no append-only ledger, reservation, clearing/settlement, or reconciliation implementation is apparent in scope. Define authorities and balanced postings; keep portfolios derived.
CS12	code/lambdas/trade-executor/handler.ts:55-81; infra/modules/lambda/main.tf:12-31	C49, C53 / A44-A51, A58-A60, F09, F19, F20	Inference: the random Lambda execution simulation does not justify Lambda for a latency-critical matching loop. Select long-lived or serverless compute only from stated workload, latency, sequencing, recovery, cost, and operations evidence.

Mandatory author checklist

Before a later task introduces or changes a high-risk statement:

1. Select an existing claim ID or add a new row with equally precise wording.
2. Open the direct source, not a search result or local note.
3. Confirm owner/author, scope, prerequisites, exceptions, and retrieval date.
4. For a number, record Region, unit, adjustable status, and date.
5. For a guarantee, name producer, transport, consumer, state store, and external side-effect boundary.
6. Label derived conclusions Inference: and cite the premises.
7. Reject the sentence if the source supports only a narrower claim.