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.

Fictional O-92 separates a complete operation record from its unresolved external result. No action or lookup was executed.

Start with the operation the business intended

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.

Use a blank register with explicit unknowns

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.

Keep the attempt history attached to one operation

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.