title: hary-frontend failures after hary-ai change (hary-platform)

description: Synthetic demo fixture. hary-ai is pointed at the shared LLM gateway with a freshly configured virtual key. Every chat completion call comes back 401 Unauthorized on both auth schemes, the circuit breaker opens, the BFF times out, and the assistant panel goes dark for users. The gateway's own logs are not available, so whether the virtual key is unprovisioned or the Basic credential is wrong stays an open question — exactly the kind the video hands to the on-call engineer.

origin_service: hary-ai

hypothesis_statuses: confirmed inferred inferred unknown unknown


description: Synthetic demo fixture. Minutes after a hary-ai rollout bumps the text analyser engine, a user pastes a block copied out of an external editor: an unpaired surrogate followed by four thousand combining marks. The input PII pass raises IndexError instead of handling it, the input-guardrail node re-raises, and from then on every turn carrying that same byte sequence returns HTTP 500 while well-formed messages sail through. That makes it a partial failure — chat success falls to 71.4%, not to zero — so volume and latency dashboards stay flat and only the affected sessions notice. The third-party analyser engine emits no telemetry of its own, so whether this is a library defect in the rewritten span merge or a missing input-validation step in hary.guardrails.pii is exactly the question the video hands to the on-call engineer.

hypothesis_statuses: confirmed inferred inferred unknown


description: Synthetic demo fixture. A reworded tool-calling prompt template ships to hary-ai and the agent node starts receiving a function-call payload it cannot decode. AgentNode._is_retryable_llm_error treats the decode failure as retryable, so AgentNode.__call__ burns all three attempts on an error that can never succeed, then falls back to _partial_answer_result and returns a text-only prefix. Users get HTTP 200 with a plausible but truncated reply. Nothing 5xxs: success rate holds at 99.6% while agent p95 goes from 2.1 s to 6.9 s, the partial-answer salvage rate goes from 0.3% to 44.8%, and thumbs-down on the assistant panel climbs. The llm-gateway and model-provider supply no telemetry of their own, so whether the malformed payload is a model-side output regression or a defect in the new template cannot be settled from this evidence.


prefix: Other-Architectures/Cache-Stampede

title: web failures after results-cache change (search-platform)

description: Synthetic demo fixture. A results-cache node restarts cold during a scheduled maintenance window and comes up with an empty keyspace. The read-through path's single-flight registry is in-process, so it comes up empty too: every miss opens its own backfill, the fan-out floods the index tier, index query admission saturates, database p95 climbs from 14 ms to 480 ms, and the search page returns 504s until the prewarm loop refills the ring. No deployment involved. No index-tier or database source is supplied, so whether the index tier could have absorbed the fan-out with more executor threads stays an open question.

origin_service: results-cache


title: frontend failures after payment-api deployment (checkout-platform)

description: Synthetic demo fixture. A payment-api deployment repoints the service at a new database secret reference; the credential resolver hands the pool a password the payment-db role rejects with 28P01, the result is memoised so retries amplify, order-api's worker pool saturates and checkout starts failing for shoppers. No database-side or secret-store audit logs are supplied, so whether the new secret was never applied to the database role or the wrong value was stored stays an open question.

origin_service: payment-api


title: member-portal failures after checkout-service change (messaging-platform)

description: Synthetic demo fixture. A producer promotes an order-event payload schema in which the 'recipient' field stops being a string and becomes a contact object. The stream consumer's decoder raises on the first such record, the worker exits and re-reads the very same offset, the dead-letter topic that should have quarantined it is not provisioned, partition backlog and consumer lag climb, notification delivery stalls and members see an empty notification history. The queue broker and the schema registry supply no telemetry of their own, so whether the producer's schema change was deliberate, reviewed or announced cannot be established from this evidence.

origin_service: stream-consumer