A tool timeout tells the operator that a caller stopped waiting. It does not, by itself, identify the business operation or establish whether an external action happened. Save the operation identity before a consequential tool call, then keep the timeout observation attached to that identity. The next receiving person needs a record they can inspect without reconstructing the task from a model conversation.
The register below is a proposed documentation aid for AI integrations. It separates the intended operation, individual attempts, observed evidence and authority for the next step. Pharos Production's AI development and integration services describe bounded tool access, state tracking and human exception handling. Ask which durable operation records an engagement will actually deliver; the service description does not establish that this register is implemented in a particular system.
Keep the working copy blank until an authorized operator records a real operation. The separately completed O-92 example is fictional. Its fields are filled, but its external result remains UNRESOLVED. No connector call, provider lookup, retry or customer-system investigation was executed for this article. Copying a table creates a document, not a functioning execution journal or an authorization control.

An operation identity belongs to a specific business intent within a defined system boundary. A maintenance request might need a routing label changed after an authorized decision. Record which request, which intended change and which target environment the identifier represents. A conversation identifier can help locate the surrounding discussion, but it does not necessarily distinguish two actions proposed during that discussion.
Choose the identity boundary before recording attempt history. One operation can have several attempts under an approved recovery policy. One attempt can also contain observations from several technical components. If every log entry becomes a new business operation, the receiving reviewer loses the relationship the register is supposed to preserve. Document that relationship in ordinary language beside the identifier convention.
Keep the operation reference stable in the receiving packet. This is a documentation rule, not a claim that every provider accepts the same identifier. An internal operation reference, an external provider reference and a provider's idempotency mechanism can serve different purposes. Record the mappings that actually exist. Leave an unavailable provider reference unavailable rather than constructing a plausible value from another identifier.
Define the scope of uniqueness the system promises. The same visible identifier in another environment or account may refer to unrelated work. Include enough target context for an authorized reviewer to find the right record. A short display label is useful only when its controlled lookup resolves to an unambiguous operation within the intended boundary.
The following field map defines one reusable record. In a working copy, replace the instruction with a value or an explicit missing-value state. Do not retain an example identifier as a default for real work. Where a field contains a controlled reference, the receiving role must know how to retrieve the underlying object through approved access.
| Field | What the working copy must record |
|---|---|
| Operation identity | Stable business-operation reference and its uniqueness boundary |
| Business intent | Source request reference and intended effect |
| Target context | Environment, account boundary and target record reference |
| Request representation | Controlled payload or fingerprint reference, with revision context |
| Connector context | Tool definition and connector configuration references |
| Authority reference | Approved action boundary and the applicable decision reference |
| Attempt history | Attempt identifiers and their relationship to the operation |
| Dispatch observation | What was actually recorded about sending the request |
| Caller observation | Timeout or other locally observed event and its time reference |
| Provider reference | External operation identifier, or an explicit unavailable state |
| Evidence reference | Result lookup or other evidence, observation scope and retrieval status |
| Outcome state | Resolved conclusion within scope, or UNRESOLVED with a reason |
| Receiving owner | Accountable role accepting the open item |
| Next permitted step | Bounded action, approving authority and evidence needed for review |
A blank cell is ambiguous. It can mean not applicable, not collected, unavailable or accidentally omitted. Agree the missing-value vocabulary for the working register and retain its meaning with exported records. A record that says lookup unavailable should also state whether the access path is missing or the provider returned an unavailable result.
These fields do not establish a required universal database schema. A team may already retain equivalent evidence in several controlled systems. In that case, build an index that preserves their relationships instead of copying sensitive material into a second store. The index must still make the operation, uncertainty and receiving owner legible to the next reviewer.
A manually edited page is not the durable execution journal that an automated workflow may require. Agree how the implementation retains the operation reference and its intended request before dispatch, and how an authorized operator retrieves that retained state after interruption. The documentation register can point to those records, but filling its cells afterward does not prove they existed before the call. If the system cannot supply the required pre-dispatch evidence, record that implementation gap separately from the quality of the incident notes. A polished page must not become evidence of a storage guarantee, concurrency control or exactly-once effect that nobody demonstrated. These are acceptance questions for the actual design, not properties conferred by using this table.
Give an attempt its own reference while retaining the parent operation identity. The attempt record should identify the prepared request version, its permitted target and the observations actually captured. A failed local preparation and a dispatched request with no received acknowledgment describe different conditions. The register should not collapse both into a single failed label.
Preserve uncertainty about dispatch when the available evidence cannot resolve it. A local log statement that preparation began does not prove a network request was sent. A caller timeout does not reveal every event at the remote system. Record the observed boundary precisely and identify the missing evidence, rather than promoting a likely sequence into an established one.
When an authorized process permits another attempt, attach the new attempt to the same relevant operation record and retain the earlier observations. A new attempt identifier does not erase the possibility of an earlier effect. The approved recovery procedure must determine which request identity and provider protections apply. This article supplies a record structure, not a replacement for that procedure.
If an operator discovers that an attempt was attached to the wrong operation, retain a correction reference. Identify the earlier relationship, the reason for changing it and the role that approved the correction. Reassigning a row without history can make a later reviewer believe the original dispatch had a different business intent.