atlas: Commerce Integration Failure Atlas
publisher: Elogic Commerce
version: 1.1.0
generated_at: '2026-08-01'
canonical: https://elogic.co/commerce-integration-failure-atlas/
tests:
- id: CIF-001
  slug: duplicate-order-after-webhook-retry
  title: Duplicate order after webhook retry
  category: orders_and_fulfillment
  severity: critical
  evidence_class: D
  systems: Commerce → OMS/ERP
  test:
    given: one valid order-created event
    when: the identical event is delivered twice and the first response is delayed
    then: only one downstream order exists and both deliveries return the same mapped order ID.
    full: Given one valid order-created event, when the identical event is delivered twice and the first response is delayed,
      then only one downstream order exists and both deliveries return the same mapped order ID.
  visible_symptom: One customer checkout creates two downstream orders or two fulfillment requests.
  why_it_happens: The receiver creates the order before it records the event or idempotency key. The sender retries after
    a timeout, and the second delivery creates the same business action again.
  detection_signal: Search for one commerce order ID mapped to more than one downstream order ID. Alert on repeated event
    IDs and repeated idempotency keys with different results.
  preventive_control: Store the event ID or business idempotency key before the side effect. Return the original result for
    a safe repeat. Keep a unique constraint on the source order ID.
  control_tags:
  - idempotency
  - event-identity
  - bounded-retries
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-002
  slug: order-lost-after-a-partial-failure
  title: Order lost after a partial failure
  category: orders_and_fulfillment
  severity: critical
  evidence_class: D
  systems: Commerce → Queue → ERP
  test:
    given: a confirmed order
    when: the ERP call succeeds but the integration process stops before acknowledgement
    then: a retry restores the same mapping without losing or duplicating the order.
    full: Given a confirmed order, when the ERP call succeeds but the integration process stops before acknowledgement, then
      a retry restores the same mapping without losing or duplicating the order.
  visible_symptom: The customer receives an order number, but the ERP never receives the order and no visible error remains.
  why_it_happens: The integration marks the message complete before the downstream write is durable, or it writes one part
    of the order and fails before the completion state is recorded.
  detection_signal: Reconcile commerce orders against ERP orders by source order ID. Alert when a confirmed commerce order
    has no downstream mapping after the agreed time window.
  preventive_control: Use transactional outbox or equivalent durable handoff. Acknowledge the message only after the downstream
    result and mapping are stored. Add scheduled reconciliation.
  control_tags:
  - bounded-retries
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-003
  slug: cancelled-order-ships-because-of-a-race-condition
  title: Cancelled order ships because of a race condition
  category: orders_and_fulfillment
  severity: critical
  evidence_class: D
  systems: Commerce ↔ OMS/WMS
  test:
    given: order version 8 is cancelled
    when: an older version 7 allocation event arrives later
    then: the OMS rejects the stale event and no shipment is created.
    full: Given order version 8 is cancelled, when an older version 7 allocation event arrives later, then the OMS rejects
      the stale event and no shipment is created.
  visible_symptom: An order is cancelled in commerce but still reaches pick, pack, or shipment in the fulfillment system.
  why_it_happens: The create-order and cancel-order events travel on different paths or arrive out of order. The fulfillment
    system accepts the earlier state after the cancellation is already final.
  detection_signal: Find shipments created after a final cancellation timestamp. Track state transitions that move from cancelled
    back to open or allocated.
  preventive_control: Use entity versions or sequence numbers. Reject stale transitions. Define which system owns final fulfillment
    state and use a cancellation acknowledgement before promising success to the customer.
  control_tags:
  - ordering-and-version
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-004
  slug: split-shipment-overwrites-the-full-order-status
  title: Split shipment overwrites the full order status
  category: orders_and_fulfillment
  severity: high
  evidence_class: D
  systems: WMS/Carrier → OMS → Commerce
  test:
    given: an order with two lines and two shipments
    when: only the first shipment is confirmed
    then: one line is shipped, the other remains open, and both tracking records remain available.
    full: Given an order with two lines and two shipments, when only the first shipment is confirmed, then one line is shipped,
      the other remains open, and both tracking records remain available.
  visible_symptom: The first partial shipment marks the whole order as shipped, or the second shipment resets tracking from
    the first parcel.
  why_it_happens: The receiver treats a line-level or shipment-level event as an order-level replacement. It does not merge
    shipment state by shipment ID and order line.
  detection_signal: Compare shipped quantities by line with the order-level status. Alert when order status is complete while
    open quantity remains.
  preventive_control: Model shipments as separate entities. Merge by shipment ID, line ID, and quantity. Derive order status
    from all shipment states instead of copying one event status.
  control_tags:
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-005
  slug: duplicate-shipment-after-fulfillment-replay
  title: Duplicate shipment after fulfillment replay
  category: orders_and_fulfillment
  severity: critical
  evidence_class: D
  systems: OMS/WMS → Carrier
  test:
    given: a shipment already has a carrier label
    when: its create-label command is replayed
    then: the existing label is returned and no second billable label is created.
    full: Given a shipment already has a carrier label, when its create-label command is replayed, then the existing label
      is returned and no second billable label is created.
  visible_symptom: A recovery replay creates a second carrier label, tracking number, or shipment for an order that already
    shipped.
  why_it_happens: The replay tool resends a command without checking the effect ledger. The carrier endpoint accepts the repeated
    label request as a new action.
  detection_signal: Find multiple active labels for the same shipment intent. Compare replay logs with carrier label creation
    times.
  preventive_control: Use a stable shipment idempotency key. Store the carrier result. Make replay default to dry-run and
    require approval for commands that create external effects.
  control_tags:
  - idempotency
  - reconciliation
  - replay-safety
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-006
  slug: old-order-status-restored-by-an-out-of-order-event
  title: Old order status restored by an out-of-order event
  category: orders_and_fulfillment
  severity: high
  evidence_class: D
  systems: ERP/OMS → Commerce
  test:
    given: stored order version 12 is shipped
    when: version 10 with status processing arrives
    then: the event is rejected, logged as stale, and the order remains shipped.
    full: Given stored order version 12 is shipped, when version 10 with status processing arrives, then the event is rejected,
      logged as stale, and the order remains shipped.
  visible_symptom: An order moves from shipped or cancelled back to processing after delayed integration traffic.
  why_it_happens: The receiver applies events by arrival time and does not compare entity version, sequence, or allowed state
    transition.
  detection_signal: Alert on backward state transitions and events whose source version is below the stored version.
  preventive_control: Use a monotonic version or sequence per order. Validate transitions against a state machine. Quarantine
    stale or impossible events for review.
  control_tags:
  - ordering-and-version
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-007
  slug: stale-contract-price-cache
  title: Stale contract price cache
  category: pricing_and_promotions
  severity: critical
  evidence_class: D
  systems: ERP/Pricing → Commerce cache
  test:
    given: a buyer contract price changes from 100 to 92
    when: the invalidation event is delayed
    then: checkout revalidates against the pricing source and does not accept the stale price.
    full: Given a buyer contract price changes from 100 to 92, when the invalidation event is delayed, then checkout revalidates
      against the pricing source and does not accept the stale price.
  visible_symptom: A B2B buyer sees or orders at an old contract price after the ERP price has changed.
  why_it_happens: Price cache entries do not include account, contract, currency, unit, or effective date, or invalidation
    fails after a source update.
  detection_signal: Compare quoted and ordered price with the authoritative price response for the same account, SKU, unit,
    currency, and time.
  preventive_control: Use a complete cache key, short and explicit expiry, event-based invalidation, and a final server-side
    price check before order acceptance.
  control_tags:
  - system-of-record
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-008
  slug: currency-conversion-mismatch
  title: Currency conversion mismatch
  category: pricing_and_promotions
  severity: high
  evidence_class: D
  systems: ERP/Pricing ↔ Commerce ↔ Payment
  test:
    given: a three-line order in EUR settled in USD
    when: the same rate and half-up rounding are applied
    then: line totals, tax, grand total, authorization, and ERP value reconcile to the defined tolerance.
    full: Given a three-line order in EUR settled in USD, when the same rate and half-up rounding are applied, then line totals,
      tax, grand total, authorization, and ERP value reconcile to the defined tolerance.
  visible_symptom: The storefront total, authorized amount, and ERP order value differ by rounding or exchange-rate timing.
  why_it_happens: Systems use different rates, decimal precision, rounding modes, or conversion timestamps. One system converts
    line values while another converts the final total.
  detection_signal: Reconcile line, tax, discount, shipping, and grand total in both source and settlement currencies. Keep
    the rate and rounding method used.
  preventive_control: Define one conversion owner and one rounding policy. Send the source amount, target amount, rate, timestamp,
    and precision with the order.
  control_tags:
  - system-of-record
  - ordering-and-version
  - reconciliation
  - least-privilege
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-009
  slug: tax-inclusive-and-tax-exclusive-price-mix
  title: Tax-inclusive and tax-exclusive price mix
  category: pricing_and_promotions
  severity: critical
  evidence_class: D
  systems: ERP/PIM → Commerce → Tax
  test:
    given: a gross price of 120 with 20% VAT
    when: the record enters a tax-exclusive market flow
    then: the system derives 100 net and 20 tax once, not twice.
    full: Given a gross price of 120 with 20% VAT, when the record enters a tax-exclusive market flow, then the system derives
      100 net and 20 tax once, not twice.
  visible_symptom: Tax is added twice, removed twice, or displayed differently from the final charge.
  why_it_happens: A price field is sent without a tax-basis flag, or the receiving system assumes the opposite basis for the
    market or customer type.
  detection_signal: Compare the stored net, tax, and gross values against the configured market rule. Alert when gross is
    not equal to net plus tax within tolerance.
  preventive_control: Include tax basis, jurisdiction, rate source, and currency in the price contract. Keep display calculation
    separate from final tax calculation.
  control_tags:
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-010
  slug: promotion-precedence-conflict
  title: Promotion precedence conflict
  category: pricing_and_promotions
  severity: high
  evidence_class: D
  systems: Commerce ↔ Promotion engine/ERP
  test:
    given: a contract price and a non-stackable campaign coupon
    when: both conditions match
    then: the contract rule wins, the coupon is rejected with a reason, and the final price is identical in commerce and ERP.
    full: Given a contract price and a non-stackable campaign coupon, when both conditions match, then the contract rule wins,
      the coupon is rejected with a reason, and the final price is identical in commerce and ERP.
  visible_symptom: A coupon, contract price, tier price, bundle rule, and free-shipping rule combine in an unintended order.
  why_it_happens: The systems use different rule priority, exclusivity, or stacking logic. The integration sends only the
    final value without the applied-rule ledger.
  detection_signal: Store and compare the ordered list of applied rule IDs, base price, adjustments, and final price. Test
    rule pairs and boundary dates.
  preventive_control: Define precedence centrally. Send rule IDs and adjustment reasons. Make mutually exclusive rules explicit
    and reject unknown combinations.
  control_tags:
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-011
  slug: unit-of-measure-price-mismatch
  title: Unit-of-measure price mismatch
  category: pricing_and_promotions
  severity: critical
  evidence_class: D
  systems: ERP → Commerce
  test:
    given: one case contains 12 each and the case price is 120
    when: a buyer orders two cases
    then: quantity is 24 each for inventory and total price is 240, not 20 or 2,880.
    full: Given one case contains 12 each and the case price is 120, when a buyer orders two cases, then quantity is 24 each
      for inventory and total price is 240, not 20 or 2,880.
  visible_symptom: A case, pack, meter, kilogram, or each price is shown or ordered as if it used another unit.
  why_it_happens: The integration maps a numeric price but loses the sales unit, base unit, conversion factor, or minimum
    order quantity.
  detection_signal: Compare price per sales unit and price per base unit. Alert when the unit is missing or the conversion
    factor is zero, negative, or changed without review.
  preventive_control: Treat unit of measure as part of the price identity. Store conversion factors with effective dates.
    Validate quantity multiples at cart and order creation.
  control_tags:
  - ordering-and-version
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-012
  slug: oversell-caused-by-inventory-lag
  title: Oversell caused by inventory lag
  category: inventory_and_availability
  severity: critical
  evidence_class: D
  systems: ERP/WMS → Commerce
  test:
    given: one unit is available
    when: two checkouts confirm at the same time
    then: only one reservation succeeds and the second buyer receives a controlled out-of-stock result.
    full: Given one unit is available, when two checkouts confirm at the same time, then only one reservation succeeds and
      the second buyer receives a controlled out-of-stock result.
  visible_symptom: The storefront accepts more units than can be fulfilled during fast sales or concurrent orders.
  why_it_happens: Availability is copied on a schedule and no reservation or final availability check protects the gap between
    display and order acceptance.
  detection_signal: Track negative available-to-promise, cancellation for no stock, and the age of the last inventory update
    by SKU and source.
  preventive_control: Separate on-hand, reserved, safety stock, and available-to-promise. Use reservations or an authoritative
    check for scarce items. Reduce cache age during peaks.
  control_tags:
  - system-of-record
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-013
  slug: multi-source-allocation-mismatch
  title: Multi-source allocation mismatch
  category: inventory_and_availability
  severity: high
  evidence_class: D
  systems: Commerce ↔ OMS/WMS
  test:
    given: stock exists only in a warehouse that cannot serve the buyer’s region
    when: availability is requested for that address
    then: the item is not promised from that source.
    full: Given stock exists only in a warehouse that cannot serve the buyer’s region, when availability is requested for
      that address, then the item is not promised from that source.
  visible_symptom: The storefront promises stock that exists globally but cannot be allocated to the buyer’s location, service
    level, or legal entity.
  why_it_happens: Commerce aggregates inventory across sources while the OMS applies routing, region, hazmat, carrier, or
    warehouse rules that were not included in availability.
  detection_signal: Compare promised source with final allocated source. Track orders that change warehouse, split unexpectedly,
    or fail allocation after checkout.
  preventive_control: Use source-aware availability or an OMS availability service. Include location, channel, service level,
    and restrictions in the availability request.
  control_tags:
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-014
  slug: backorder-state-lost-between-systems
  title: Backorder state lost between systems
  category: inventory_and_availability
  severity: high
  evidence_class: D
  systems: ERP/OMS ↔ Commerce
  test:
    given: zero on-hand and backorder allowed for a specific account with a 14-day promise
    when: the buyer opens the product
    then: the item is orderable with the correct promise and the state persists into the order.
    full: Given zero on-hand and backorder allowed for a specific account with a 14-day promise, when the buyer opens the
      product, then the item is orderable with the correct promise and the state persists into the order.
  visible_symptom: An item allowed for backorder becomes unavailable, or an unavailable item is promised without an expected
    date.
  why_it_happens: The integration sends quantity but not backorder policy, expected receipt, promise date, channel rule, or
    customer eligibility.
  detection_signal: Compare quantity, sellable state, backorder flag, and promise date. Alert when backorder is true without
    a date or policy source.
  preventive_control: Define an availability contract with quantity, state, reason, expected date, and policy version. Treat
    backorder as a business state, not a negative number.
  control_tags:
  - ordering-and-version
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-015
  slug: reservation-not-released-after-payment-failure
  title: Reservation not released after payment failure
  category: inventory_and_availability
  severity: critical
  evidence_class: D
  systems: Commerce ↔ Inventory service ↔ Payment
  test:
    given: stock is reserved for a payment attempt
    when: the payment fails and the callback is lost
    then: expiry reconciliation releases the reservation once and returns availability.
    full: Given stock is reserved for a payment attempt, when the payment fails and the callback is lost, then expiry reconciliation
      releases the reservation once and returns availability.
  visible_symptom: Sellable stock remains blocked after payment decline, timeout, or abandoned checkout.
  why_it_happens: Reservation creation is durable, but release depends on a callback that can be lost or on a session timeout
    that is not reconciled.
  detection_signal: Find reservations past their expiry with no paid order. Compare reserved quantity with active payment
    or order state.
  preventive_control: Use explicit reservation expiry, idempotent release, and scheduled cleanup. Link reservation, cart,
    payment intent, and order with one correlation ID.
  control_tags:
  - idempotency
  - bounded-retries
  - reconciliation
  - correlation-id
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-016
  slug: inventory-unit-of-measure-mismatch
  title: Inventory unit-of-measure mismatch
  category: inventory_and_availability
  severity: critical
  evidence_class: D
  systems: ERP/WMS → Commerce
  test:
    given: inventory is 10 cases and one case is 12 each
    when: the storefront sells each units
    then: availability is 120 each and an order of 5 each leaves 115 each.
    full: Given inventory is 10 cases and one case is 12 each, when the storefront sells each units, then availability is
      120 each and an order of 5 each leaves 115 each.
  visible_symptom: The storefront shows 120 units when the warehouse has 10 cases of 12, or subtracts one case for an order
    of one each.
  why_it_happens: Quantity is transferred without base unit, sales unit, conversion factor, or packaging hierarchy.
  detection_signal: Validate quantity and unit together. Compare calculated base quantity with source on-hand and order decrements.
  preventive_control: Use a unit-aware inventory contract. Convert only through versioned master data. Reject quantity records
    with unknown units.
  control_tags:
  - ordering-and-version
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-017
  slug: duplicate-customer-identities
  title: Duplicate customer identities
  category: customer_and_b2b_accounts
  severity: high
  evidence_class: D
  systems: Commerce ↔ CRM/ERP/Identity
  test:
    given: an existing verified customer with CRM ID C-42
    when: the same person registers through another storefront
    then: the new login links to C-42 or enters review instead of creating an uncontrolled duplicate.
    full: Given an existing verified customer with CRM ID C-42, when the same person registers through another storefront,
      then the new login links to C-42 or enters review instead of creating an uncontrolled duplicate.
  visible_symptom: One buyer has multiple customer IDs, order histories, price groups, or consent records.
  why_it_happens: Each system creates a record before a shared identity or match decision exists. Email is used as a universal
    key even when accounts, regions, or legal entities differ.
  detection_signal: Find multiple active identities with the same verified contact, external ID, tax ID, or account relationship.
    Track merge and split events.
  preventive_control: Define a master identity and immutable cross-system IDs. Use deterministic match rules plus a reviewed
    exception queue. Never merge only because names look similar.
  control_tags:
  - system-of-record
  - idempotency
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-018
  slug: parent-child-account-hierarchy-drift
  title: Parent-child account hierarchy drift
  category: customer_and_b2b_accounts
  severity: critical
  evidence_class: D
  systems: ERP/CRM → Commerce
  test:
    given: branch B moves from parent A to parent C at midnight
    when: the new hierarchy activates
    then: B loses A permissions, gains C permissions, and no interval grants both.
    full: Given branch B moves from parent A to parent C at midnight, when the new hierarchy activates, then B loses A permissions,
      gains C permissions, and no interval grants both.
  visible_symptom: A buyer sees the wrong branches, contracts, invoices, addresses, or approval limits.
  why_it_happens: The hierarchy update is partial, arrives out of order, or replaces only one side of the parent-child relationship.
  detection_signal: Validate that every child has one valid parent for the effective period. Compare account tree versions
    across systems.
  preventive_control: Transfer hierarchy as versioned relationships with effective dates. Apply the full change atomically
    or use a staged graph validation before activation.
  control_tags:
  - ordering-and-version
  - reconciliation
  - least-privilege
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-019
  slug: buyer-role-permission-lag
  title: Buyer role permission lag
  category: customer_and_b2b_accounts
  severity: critical
  evidence_class: D
  systems: Identity/CRM → Commerce
  test:
    given: a buyer’s approval role is removed
    when: the existing session attempts to approve an order
    then: the server checks the new role version and denies the action.
    full: Given a buyer’s approval role is removed, when the existing session attempts to approve an order, then the server
      checks the new role version and denies the action.
  visible_symptom: A removed buyer can still place orders, view prices, approve quotes, or access another role’s data.
  why_it_happens: Role changes use a long cache or session token and no revocation event reaches the storefront.
  detection_signal: Compare token claims and session age with the current role version. Alert on privileged actions from a
    revoked or stale role.
  preventive_control: Use short-lived authorization claims for sensitive actions, a role version, revocation, and server-side
    authorization at the action boundary.
  control_tags:
  - ordering-and-version
  - bounded-retries
  - reconciliation
  - least-privilege
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-020
  slug: credit-status-lag
  title: Credit status lag
  category: customer_and_b2b_accounts
  severity: critical
  evidence_class: D
  systems: ERP/Credit service → Commerce
  test:
    given: an account moves to credit hold after cart creation
    when: the buyer submits the order
    then: the final check blocks net terms and records the current reason.
    full: Given an account moves to credit hold after cart creation, when the buyer submits the order, then the final check
      blocks net terms and records the current reason.
  visible_symptom: An account on credit hold places a net-terms order, or an approved account is blocked after the hold is
    cleared.
  why_it_happens: Credit state is cached without effective time, or the order checks only the value shown when the cart was
    created.
  detection_signal: Compare order acceptance time with the authoritative credit status and version. Track manual release of
    orders blocked or accepted incorrectly.
  preventive_control: Perform a final credit check at order submission. Include account, legal entity, currency, exposure,
    limit, status, version, and effective time.
  control_tags:
  - system-of-record
  - ordering-and-version
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-021
  slug: variant-mapping-collision
  title: Variant mapping collision
  category: catalog_and_product_data
  severity: critical
  evidence_class: D
  systems: PIM/ERP → Commerce
  test:
    given: two variants share the label “Blue” but have different source IDs
    when: both are imported
    then: they remain distinct and no product data is overwritten.
    full: Given two variants share the label “Blue” but have different source IDs, when both are imported, then they remain
      distinct and no product data is overwritten.
  visible_symptom: Two source variants map to one commerce SKU, or one variant overwrites another size, color, or configuration.
  why_it_happens: The target key is built from a non-unique field, normalized values collide, or the mapping ignores market
    and product family.
  detection_signal: Enforce uniqueness on source system plus source ID. Report any target SKU receiving more than one active
    source record.
  preventive_control: Use immutable source identifiers and a mapping table. Validate uniqueness before publish. Never derive
    identity only from display labels.
  control_tags:
  - system-of-record
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-022
  slug: missing-locale-fallback
  title: Missing locale fallback
  category: catalog_and_product_data
  severity: medium
  evidence_class: D
  systems: PIM/CMS → Commerce
  test:
    given: the French short description is missing and fallback to English is allowed
    when: the product publishes in France
    then: the approved English value appears and the missing translation is logged.
    full: Given the French short description is missing and fallback to English is allowed, when the product publishes in
      France, then the approved English value appears and the missing translation is logged.
  visible_symptom: A product page shows blank content, the wrong language, or an unpublished source value in one store view.
  why_it_happens: The integration treats a missing translation as an empty overwrite instead of applying the defined fallback
    or publication rule.
  detection_signal: Scan required attributes by locale before publish. Track empty values that replace non-empty target content.
  preventive_control: Define fallback by field and market. Distinguish missing, intentionally blank, and inherited values.
    Block publication when regulated or required content is absent.
  control_tags:
  - system-of-record
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-023
  slug: catalog-attribute-type-drift
  title: Catalog attribute type drift
  category: catalog_and_product_data
  severity: high
  evidence_class: D
  systems: PIM → Commerce/Search
  test:
    given: '`weight_kg` is numeric'
    when: the source sends “heavy”
    then: the record is rejected with a schema error and the last valid product remains active.
    full: Given `weight_kg` is numeric, when the source sends “heavy”, then the record is rejected with a schema error and
      the last valid product remains active.
  visible_symptom: A number becomes text, a multi-select becomes one value, or a date and unit can no longer be filtered or
    validated.
  why_it_happens: The source schema changes without a versioned contract, or the receiver accepts a new type and silently
    coerces it.
  detection_signal: Validate every payload against the expected schema and unit. Alert on type coercion, unknown enum, and
    precision loss.
  preventive_control: Version schemas. Use contract tests and explicit migration for type changes. Quarantine invalid records
    instead of publishing partial data.
  control_tags:
  - ordering-and-version
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-024
  slug: partial-media-synchronization
  title: Partial media synchronization
  category: catalog_and_product_data
  severity: high
  evidence_class: D
  systems: DAM/PIM → Commerce/CDN
  test:
    given: a product requires one primary image and a safety PDF
    when: the PDF upload fails
    then: the product stays staged and does not publish with incomplete required media.
    full: Given a product requires one primary image and a safety PDF, when the PDF upload fails, then the product stays staged
      and does not publish with incomplete required media.
  visible_symptom: A product publishes before its primary image, video, document, alt text, or CDN derivative is available.
  why_it_happens: The product and media pipelines commit separately, and the page becomes visible after only the product record
    succeeds.
  detection_signal: Validate required media references and HTTP availability before activation. Track orphan assets and broken
    derivatives.
  preventive_control: Use staged publication. Activate the product only after required assets and metadata pass checks, or
    keep a deliberate approved placeholder.
  control_tags:
  - system-of-record
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-025
  slug: invalid-category-graph
  title: Invalid category graph
  category: catalog_and_product_data
  severity: high
  evidence_class: D
  systems: PIM/ERP → Commerce
  test:
    given: category A contains B and an update sets A’s parent to B
    when: the new graph is validated
    then: activation is blocked and the live tree remains unchanged.
    full: Given category A contains B and an update sets A’s parent to B, when the new graph is validated, then activation
      is blocked and the live tree remains unchanged.
  visible_symptom: Navigation loops, duplicate paths, orphan categories, or products disappear because the category tree is
    invalid.
  why_it_happens: A parent reference points to a descendant, a deleted parent remains in use, or partial updates apply before
    graph validation.
  detection_signal: Run cycle detection, orphan checks, unique path checks, and maximum-depth checks before activation.
  preventive_control: Build and validate the full graph in staging. Activate a version only when the graph is acyclic and
    all required references resolve.
  control_tags:
  - ordering-and-version
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-026
  slug: payment-authorization-and-capture-mismatch
  title: Payment authorization and capture mismatch
  category: payments_tax_and_fraud
  severity: critical
  evidence_class: D
  systems: Commerce ↔ Payment gateway ↔ ERP
  test:
    given: an order has one authorization for 100
    when: capture is requested twice with the same key
    then: one capture of 100 exists and the second call returns the original result.
    full: Given an order has one authorization for 100, when capture is requested twice with the same key, then one capture
      of 100 exists and the second call returns the original result.
  visible_symptom: The order is captured twice, captured for the wrong amount, or marked paid when only authorization exists.
  why_it_happens: Authorization, capture, void, and refund are flattened into one paid flag, or retries use different business
    keys.
  detection_signal: Maintain a payment transaction ledger. Reconcile authorized, captured, voided, refunded, and disputed
    amounts by payment intent and order.
  preventive_control: Model each payment operation separately. Use gateway idempotency keys, amount checks, and allowed state
    transitions.
  control_tags:
  - idempotency
  - ordering-and-version
  - bounded-retries
  - reconciliation
  - least-privilege
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-027
  slug: unverified-or-replayed-payment-webhook
  title: Unverified or replayed payment webhook
  category: payments_tax_and_fraud
  severity: critical
  evidence_class: D
  systems: Payment gateway → Commerce
  test:
    given: a valid captured-payment payload
    when: the signature is invalid or the timestamp is outside the replay window
    then: the event is rejected and order state does not change.
    full: Given a valid captured-payment payload, when the signature is invalid or the timestamp is outside the replay window,
      then the event is rejected and order state does not change.
  visible_symptom: A forged or repeated callback marks an order paid, changes payment state, or triggers fulfillment.
  why_it_happens: The receiver does not verify the signature, timestamp, source, event ID, or current transaction state.
  detection_signal: Log signature result, event ID, source IP only as supporting data, event age, and state transition. Alert
    on invalid signatures and repeated events.
  preventive_control: Verify the provider signature against the raw body. Enforce replay window and event uniqueness. Fetch
    authoritative payment state before high-risk actions when supported.
  control_tags:
  - system-of-record
  - event-identity
  - ordering-and-version
  - replay-safety
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-028
  slug: tax-jurisdiction-mismatch
  title: Tax jurisdiction mismatch
  category: payments_tax_and_fraud
  severity: critical
  evidence_class: D
  systems: Commerce ↔ Tax service ↔ ERP
  test:
    given: an exempt B2B account with a valid certificate
    when: the final order is submitted
    then: the tax service receives the exemption and the ERP stores the same zero-tax basis.
    full: Given an exempt B2B account with a valid certificate, when the final order is submitted, then the tax service receives
      the exemption and the ERP stores the same zero-tax basis.
  visible_symptom: The tax shown or charged uses the wrong destination, product code, exemption, registration, or legal entity.
  why_it_happens: Address normalization, nexus, customer exemption, product tax code, or legal entity differs between quote
    and final order systems.
  detection_signal: 'Store the tax request and response basis: normalized address, product code, exemption ID, jurisdiction,
    rate, and calculation version.'
  preventive_control: Use one final tax calculation owner. Recalculate after address, shipping, item, or exemption changes.
    Send the tax basis with the order.
  control_tags:
  - system-of-record
  - ordering-and-version
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-029
  slug: refund-reconciliation-failure
  title: Refund reconciliation failure
  category: payments_tax_and_fraud
  severity: critical
  evidence_class: D
  systems: Commerce ↔ Payment ↔ ERP
  test:
    given: a partial refund of one line plus tax
    when: the gateway completes the refund and the ERP call times out
    then: replay creates one credit memo for the exact amount and no second gateway refund.
    full: Given a partial refund of one line plus tax, when the gateway completes the refund and the ERP call times out, then
      replay creates one credit memo for the exact amount and no second gateway refund.
  visible_symptom: The customer receives a refund, but the ERP credit memo, order balance, tax, or financial ledger does not
    match.
  why_it_happens: Each system records a different refund identifier, amount basis, currency, line allocation, or completion
    state.
  detection_signal: Reconcile refund ID, payment transaction, order, currency, line amounts, shipping, tax, and total. Alert
    on completed gateway refunds without ERP credit.
  preventive_control: Use one refund intent ID across systems. Record requested, accepted, completed, failed, and reversed
    states. Retry accounting effects safely and compensate when needed.
  control_tags:
  - bounded-retries
  - reconciliation
  - replay-safety
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-030
  slug: rma-status-divergence
  title: RMA status divergence
  category: returns_and_refunds
  severity: high
  evidence_class: D
  systems: Commerce ↔ OMS/WMS/ERP
  test:
    given: an RMA is closed at version 9
    when: a delayed version 7 “received” event arrives
    then: it is quarantined and the return remains closed.
    full: Given an RMA is closed at version 9, when a delayed version 7 “received” event arrives, then it is quarantined and
      the return remains closed.
  visible_symptom: The customer sees approved while the warehouse sees pending, or a closed return reopens after a delayed
    update.
  why_it_happens: Systems use different state names and allowed transitions, and the mapping has no version or transition
    guard.
  detection_signal: Map each source state to one canonical state. Alert on impossible transitions and status age beyond the
    service target.
  preventive_control: Use a canonical return state machine and versioned mappings. Keep source state and canonical state together
    for audit.
  control_tags:
  - ordering-and-version
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-031
  slug: refund-completed-without-inventory-adjustment
  title: Refund completed without inventory adjustment
  category: returns_and_refunds
  severity: critical
  evidence_class: D
  systems: Commerce/Payment ↔ WMS/ERP
  test:
    given: a refund is issued before goods arrive
    when: the refund completes
    then: inventory does not increase until the warehouse records a restockable receipt.
    full: Given a refund is issued before goods arrive, when the refund completes, then inventory does not increase until
      the warehouse records a restockable receipt.
  visible_symptom: Money is returned, but sellable, damaged, quarantine, or scrap inventory is not updated.
  why_it_happens: Refund and physical return are treated as one event even when goods are not received, inspected, or restockable.
  detection_signal: Compare refund completion with return receipt, disposition, and inventory movement. Flag financial completion
    without an expected physical-state record.
  preventive_control: Separate financial refund from physical return and disposition. Use explicit states for not received,
    received, restock, refurbish, quarantine, and scrap.
  control_tags:
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-032
  slug: return-line-mapped-to-the-wrong-sku-or-unit
  title: Return line mapped to the wrong SKU or unit
  category: returns_and_refunds
  severity: critical
  evidence_class: D
  systems: Commerce → WMS/ERP
  test:
    given: an order line contains two cases of SKU X with 12 each per case
    when: one case is returned
    then: the return records one case and 12 base units against the original line.
    full: Given an order line contains two cases of SKU X with 12 each per case, when one case is returned, then the return
      records one case and 12 base units against the original line.
  visible_symptom: The warehouse credits or restocks the wrong variant, pack size, or unit.
  why_it_happens: The return uses display SKU, parent SKU, or order-line position instead of the immutable order-line ID and
    sold unit.
  detection_signal: Compare return line with original order-line ID, variant ID, sold unit, lot/serial where relevant, and
    quantity.
  preventive_control: Create returns from immutable order-line references. Preserve sold unit and conversion factor. Reject
    returns that cannot resolve to the original line.
  control_tags:
  - ordering-and-version
  - reconciliation
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-033
  slug: silent-dead-letter-queue
  title: Silent dead-letter queue
  category: observability_and_recovery
  severity: critical
  evidence_class: D
  systems: Queue / integration platform
  test:
    given: a critical order message exhausts retries
    when: it enters the dead-letter queue
    then: an alert includes order ID, reason, age, owner, and a safe replay path.
    full: Given a critical order message exhausts retries, when it enters the dead-letter queue, then an alert includes order
      ID, reason, age, owner, and a safe replay path.
  visible_symptom: Messages fail and accumulate, but customers and operations notice the problem before engineering receives
    an alert.
  why_it_happens: The dead-letter queue exists but has no owner, age metric, business context, or alert threshold.
  detection_signal: Monitor count, oldest age, failure reason, entity type, and business value. Alert on both sudden spikes
    and any critical message beyond its service target.
  preventive_control: Assign an owner and runbook. Include correlation ID and safe replay data. Keep a dashboard and a scheduled
    review even when the count is zero.
  control_tags:
  - system-of-record
  - bounded-retries
  - dead-letter-handling
  - correlation-id
  - replay-safety
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-034
  slug: unbounded-retry-loop
  title: Unbounded retry loop
  category: observability_and_recovery
  severity: critical
  evidence_class: D
  systems: Any API or queue flow
  test:
    given: the ERP returns a temporary 503
    when: the call fails repeatedly
    then: retries follow the bounded schedule, stop at the limit, open the circuit, and preserve one recoverable message.
    full: Given the ERP returns a temporary 503, when the call fails repeatedly, then retries follow the bounded schedule,
      stop at the limit, open the circuit, and preserve one recoverable message.
  visible_symptom: A dependency outage creates a retry storm, duplicate traffic, rising cost, or wider platform failure.
  why_it_happens: Every error is treated as temporary. Retries have no limit, delay, jitter, circuit breaker, or idempotency
    control.
  detection_signal: Track attempts per operation, retry rate, repeated error class, downstream saturation, and time spent
    retrying.
  preventive_control: Classify errors. Use exponential backoff with jitter, attempt and time limits, circuit breaking, and
    dead-letter handling. Make side effects idempotent.
  control_tags:
  - idempotency
  - bounded-retries
  - dead-letter-handling
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-035
  slug: missing-correlation-id-across-systems
  title: Missing correlation ID across systems
  category: observability_and_recovery
  severity: high
  evidence_class: D
  systems: Commerce ↔ all downstream systems
  test:
    given: one checkout creates an order, payment, ERP order, and shipment request
    when: the flow completes
    then: all systems can be queried with the same correlation ID.
    full: Given one checkout creates an order, payment, ERP order, and shipment request, when the flow completes, then all
      systems can be queried with the same correlation ID.
  visible_symptom: Support cannot trace one order, payment, or product update across logs, queues, and vendor systems.
  why_it_happens: Each service generates its own request ID and drops the business correlation when making the next call.
  detection_signal: Sample critical flows and verify the same correlation ID appears in logs, message headers, API calls,
    error records, and support views.
  preventive_control: Create a correlation ID at the business-flow boundary. Propagate it without using personal data. Keep
    local request IDs as separate fields.
  control_tags:
  - correlation-id
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-036
  slug: unsafe-replay-repeats-side-effects
  title: Unsafe replay repeats side effects
  category: observability_and_recovery
  severity: critical
  evidence_class: D
  systems: Replay tool → external services
  test:
    given: an order event already sent an email and created an ERP order but missed analytics
    when: replay runs
    then: only the missing analytics effect is executed.
    full: Given an order event already sent an email and created an ERP order but missed analytics, when replay runs, then
      only the missing analytics effect is executed.
  visible_symptom: A support replay sends another email, refund, invoice, label, stock movement, or order.
  why_it_happens: The replay tool republishes the original message without checking which effects already completed.
  detection_signal: Compare replay records with an effect ledger. Alert when the same business key produces a new external
    effect.
  preventive_control: Record each effect and result. Make replay dry-run by default. Require idempotency keys, scoped approval,
    and compensation for non-idempotent operations.
  control_tags:
  - idempotency
  - reconciliation
  - least-privilege
  - replay-safety
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-037
  slug: overprivileged-integration-account
  title: Overprivileged integration account
  category: security_and_access
  severity: critical
  evidence_class: D
  systems: Integration user / service account
  test:
    given: the inventory integration needs read product and write inventory only
    when: it attempts to read customer data or change store configuration
    then: access is denied and logged.
    full: Given the inventory integration needs read product and write inventory only, when it attempts to read customer data
      or change store configuration, then access is denied and logged.
  visible_symptom: A credential used for one data flow can read or change unrelated customers, orders, configuration, or environments.
  why_it_happens: The account uses administrator rights because scoped permissions were not designed or tested.
  detection_signal: Review effective permissions, API scopes, object access, environment access, and unused privileges. Monitor
    actions outside the expected endpoint and entity set.
  preventive_control: Apply least privilege. Use separate accounts by environment and major integration. Rotate secrets and
    review access on a fixed schedule.
  control_tags:
  - bounded-retries
  - least-privilege
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-038
  slug: secret-exposed-in-logs-or-configuration
  title: Secret exposed in logs or configuration
  category: security_and_access
  severity: critical
  evidence_class: D
  systems: Application logs / CI/CD / support tools
  test:
    given: an API call fails with an authorization header and token in memory
    when: the error is logged
    then: the token is redacted and the structured log keeps only the safe credential identifier.
    full: Given an API call fails with an authorization header and token in memory, when the error is logged, then the token
      is redacted and the structured log keeps only the safe credential identifier.
  visible_symptom: API keys, tokens, passwords, or signed URLs appear in logs, error messages, exported config, or tickets.
  why_it_happens: The client logs full headers or payloads, exceptions include secrets, or configuration is stored in source
    control.
  detection_signal: Run secret scanning on repositories, build output, logs, and support exports. Alert on known token formats
    and high-entropy values.
  preventive_control: Use a secret manager, redaction at log boundaries, short-lived credentials where possible, and immediate
    rotation after exposure.
  control_tags:
  - least-privilege
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-039
  slug: tenant-or-storefront-boundary-error
  title: Tenant or storefront boundary error
  category: security_and_access
  severity: critical
  evidence_class: D
  systems: Multi-tenant commerce / integration layer
  test:
    given: a token belongs to tenant A
    when: it requests an order ID owned by tenant B
    then: the service returns no data, creates no side effect, and logs the denied boundary check.
    full: Given a token belongs to tenant A, when it requests an order ID owned by tenant B, then the service returns no data,
      creates no side effect, and logs the denied boundary check.
  visible_symptom: Data from one store, account, region, or legal entity is read or written into another.
  why_it_happens: Tenant context comes from an untrusted request field, is missing from a cache key, or is not enforced in
    the data query.
  detection_signal: Test cross-tenant object IDs. Review cache keys, database filters, queue routing, and audit logs for mismatched
    tenant and entity ownership.
  preventive_control: Derive tenant context from trusted authentication. Enforce it at every data boundary. Include tenant
    in keys, messages, and authorization checks.
  control_tags:
  - system-of-record
  - least-privilege
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
- id: CIF-040
  slug: unvalidated-external-callback
  title: Unvalidated external callback
  category: security_and_access
  severity: critical
  evidence_class: D
  systems: Carrier, tax, marketplace, payment, or vendor callback
  test:
    given: a callback payload is structurally valid but signed by an unknown key
    when: it reaches the endpoint
    then: it is rejected before any order, payment, or shipment state changes.
    full: Given a callback payload is structurally valid but signed by an unknown key, when it reaches the endpoint, then
      it is rejected before any order, payment, or shipment state changes.
  visible_symptom: An attacker or wrong partner system can trigger state changes through a public callback URL.
  why_it_happens: The endpoint trusts payload fields or source IP alone and does not verify signature, audience, timestamp,
    nonce, schema, or expected state.
  detection_signal: Log verification outcome, callback age, event ID, issuer, audience, and state transition. Alert on repeated
    invalid attempts.
  preventive_control: Use strong signature or mutual authentication, replay protection, strict schema validation, allowlisted
    event types, and server-side authorization of the resulting action.
  control_tags:
  - event-identity
  - ordering-and-version
  - bounded-retries
  - least-privilege
  - replay-safety
  version: 1.1.0
  last_reviewed: '2026-08-01'
  limitations: Synthetic test pattern. Official sources support control or delivery behavior where mapped; they do not prove
    a vendor defect, client incident, breach, or incident frequency.
