Design an action record that can explain an uncertain outcome

Imagine an operator approving a scheduled article. The publishing request times out, but the remote system might already have published it. A timeline that ends with a red “Failed” label gives the operator the wrong instruction: retrying immediately could repeat a consequential action.

A useful action record preserves what was intended, what was attempted, and what was verified. The AXON trace mockup explores that information hierarchy. This note develops a concrete record that could support it.

Begin with the operator’s next decision

The operator needs to decide whether to wait, reconcile, retry, reverse, or escalate. A list of animated messages is not enough. The record should connect an action to its input revision, authority, external acknowledgement, and observed result.

For the publishing example, “article 42” is insufficient if its content changed after approval. Record a reference to the approved revision and the scope of the requested action. Avoid storing the entire article, credentials, or private user data in every log entry when a restricted reference is enough.

Use an explicit event structure

{
  "eventId": "example-event-003",
  "operationId": "example-publish-042",
  "kind": "action_attempt_finished",
  "action": "article.publish",
  "resource": { "id": "article-42", "revision": "example-revision-b" },
  "approvalRef": "example-approval-017",
  "attempt": 1,
  "transportOutcome": "timeout",
  "effectOutcome": "unknown",
  "verification": { "state": "pending" }
}

Every identifier here is fictional. The separation between transportOutcome and effectOutcome is the important part. A timeout describes the caller’s observation, not necessarily the receiver’s state. A later reconciliation event can refer to the same operation without rewriting this earlier observation.

Use timestamps for investigation, but do not assume clocks from different systems agree perfectly. Sequence numbers or causal references can be more useful than sorting every event by an apparent millisecond timestamp.

Show the boundary that was crossed

The approval view should show the proposed operation, affected revision, expected visibility, and expiry. If someone edits the article after approval, the execution path needs to decide whether the old approval is invalid. A green icon in the browser cannot enforce that rule.

Keep a proposed action visually distinct from a completed action. A timeline can group states as “Proposed,” “Approved,” “Attempted,” and “Verified,” but it must also make rejection, expiry, and unknown outcomes visible. The approval-boundary guide covers the execution side of that contract.

Reconcile before retrying an unknown result

After a timeout, query an operation status or read the affected resource if the receiving service supports it. If a verified published revision matches the approved revision, record that evidence. If the action did not happen, retry according to the receiver’s documented semantics. If the result remains uncertain, keep that uncertainty visible.

An idempotency key can help the receiver recognize repeated attempts for one operation. It does not magically make every endpoint safe to retry. The receiver has to implement and retain the key correctly, and the client needs rules for payload changes and key expiry.

The interface should not offer “Undo” unless the system has a defined compensating action. Unpublishing an article may remove it from the site; it cannot guarantee that an email, feed reader, cache, or screenshot never saw it.

Record evidence without recording everything

A useful audit trail is not an indiscriminate transcript. Credentials, session tokens, payment details, and private content can turn logs into another sensitive database. Decide which fields may be recorded, who can read them, and how retention and deletion work.

References should be access-controlled, and sensitive fields should be redacted before they enter the event pipeline. Sanitizing only the visual log viewer leaves exports and storage exposed. Protect the logging path against oversized and malformed input as well as injection into a rendered viewer.

For agent-like systems, log the evidence used, the selected action, a suitable decision summary, tool activity, and verification. Do not promise access to private model reasoning as a substitute for an accurate action record.

Separate a trace view from an audit service

An operational trace is useful for investigating a request. An audit record may have stricter access, retention, integrity, and completeness requirements. “Append-only” in an application API does not prove that administrators, backups, or the underlying storage cannot alter the data.

The AXON page supplies a visual vocabulary and scripted trace. It does not implement the publishing record above, durable event storage, a policy engine, or tamper-evident verification. A successful animation shows that the interface renders; it cannot establish those backend properties.

Review with failures, not just the happy path

Walk through duplicate delivery, an expired approval, a changed revision, a lost response, a denied action, and an unavailable logging service. For each, ask whether the interface leaves the operator with a correct next step. Have the record explain what remains unknown instead of filling that space with an optimistic completion state.

That is the useful design outcome of this exercise: an action history that helps a person recover safely, even when the system cannot yet give a definitive answer.