KCAE.ENCOUNTER:4.3 - Provide actual invocation, deduplication and receipt

For a software observer, identify the event subscription, its delivery semantics, a receiver and failure behavior. Validate the event’s source and permitted scope before running retrieval. Use a stable event identity together with the intended operation/version when suppressing repeated processing. Choosing only a case ID can wrongly suppress a later changed condition; choosing the receipt timestamp can fail to recognize a retry of the same event.

Under at-least-once delivery, distinguish a claim to perform the inquiry from a completed result. In a store with suitable conditional writes, create one processing record for the logical event/operation key, with the relevant input identity, an in-progress state, an attempt/owner token and a bounded completion or lease deadline. A duplicate with the same key but a different relevant payload is an identity conflict to resolve, not a cached answer. The first worker’s successful claim authorizes that attempt under the stated permission; it does not assert that the inquiry happened.

On a repeated invocation, read the state using the consistency needed by that store’s conditional-update contract:

• Completed, with a durably stored result: return that result and its original source/case basis, if access and retention still permit it. Do not rerun the inquiry or create another outgoing notice just to answer the duplicate. Missing result data is an integrity/recovery problem, not a successful completed state. KCAE.ENCOUNTER:4.4 separately checks whether an old result can support reliance now.
• In progress, with a valid claim: return a pending disposition or arrange a bounded later retry according to the event interface. Do not start a competing inquiry merely because the caller has not received a result. Do not permanently acknowledge unfinished work unless a durable continuation or recovery mechanism has taken responsibility for it.
• Abandoned or expired, without a completed result: establish the permitted recovery. A runtime may confirm that the earlier invocation terminated; another environment may only show an expired lease. Conditionally replace the stale claim with a new attempt token so two recovery workers cannot both acquire it. Then resume from a valid checkpoint or rerun only the work whose repetition is safe under the known effect state. If recovery cannot exclude conflicting commits or harmful repeated effects, return a recoverable unresolved state and obtain reconciliation rather than silently treating the event as processed.

Provide the mechanism that revisits an unfinished claim: actual queue redelivery, a recovery scheduler, or a resumable workflow with its documented behavior. A stored deadline does not invoke any of them. Choose bounded retries and account for repeated computation and model charges. Retain completed keys/results for the intended duplicate window, or define how older deliveries are rejected or reconciled when retention expires. An expired cache entry must not silently turn an old consequential operation into a new one.

Lease expiry does not kill a worker. If an old worker can resume after another attempt takes over, guard completion with an atomic comparison of the current owner token and in-progress state; a stale owner must be unable to commit its result or outgoing intent. In this construction, keep the inquiry replayable and defer externally visible effects until that guarded commit. Any effect path outside the guarded store needs its own idempotency or fencing support. Merely checking a lease and later making an unguarded external call leaves a race. If the chosen runtime cannot exclude that race for the proposed action, confirm termination before taking over, or preserve the unresolved effect state for an authorized person.

Persist the accepted result and completed state together. If another service must receive a suggestion, a transactional outbox can also commit the outgoing intent in that same supported local transaction, guarded by the current attempt token. Give the outgoing logical operation a stable identity across attempts. A sender can retry that intent; the recipient must deduplicate or otherwise reconcile repeated effects at its own boundary. The local outbox does not make arbitrary remote effects exactly once.

If an earlier attempt may already have posted a note, sent a message or launched an action before recording completion, inspect the external effect using that stable identity where possible. Recover an observed result, retry through a receiver that enforces the required idempotency window, or perform an explicitly authorized compensating operation when appropriate. Where the effect is unknown and repetition could be harmful, do not automatically replay it. An explicit “inquiry/effect unresolved” return is safer and more truthful than either a fabricated result or indefinite silent suppression.

Separate “event received,” “inquiry performed,” “suggestion sent,” “suggestion displayed” and “person understood or used it.” An acknowledgement lost after display creates an unknown receipt state, not proof of non-delivery. Do not repeatedly interrupt the user merely to make an internal receipt counter definite. Obtain a receiver query or use the agreed duplicate policy. Deletion and permission withdrawal apply to stored event payloads as well as search data.