SYSE.43:5.2 - Reorganize still-valid timeout episodes

An agent’s small exact store contains three episodes under a common “timeout” keyword. In E1 the interface establishes rejection before acceptance. In E2 the request was accepted, its reply was lost, and querying the original attempt later confirmed an effect. In E3 acceptance is known but the supported query still leaves the effect unknown. The original traces remain valid.

A proposed summary “retry after timeout” fits neither E2 nor E3. The engineer extracts acceptance and effect status and builds two conditional index entries: established rejection before effect permits reconsidering a new call under the current preconditions; accepted or uncertain execution requires same-attempt outcome recovery before any replay. Both entries link to the original traces and their interface edition. E2 remains a useful contrary case even if most examples are E1.

The current interrupted attempt A19 was accepted. Retrieval by that known status now returns the recovery branch and E2/E3 evidence rather than the most common retry narrative. The controller requests A19’s outcome and uses that actual return through SYSE.42; a past successful lookup does not establish A19’s present effect. If the return remains unknown, so does this task. Dropping E3 to make the summary shorter would remove that stop and is rejected.

For three episodes, a two-entry conditional index can suffice. A larger corpus with differently worded recovery questions may justify candidate links and revised note descriptions, tested against the same queries and contrary episodes. Compare total maintenance and retrieval effort before adopting it. This changes the organization of valid experience, unlike correction of a false current-state summary below.