> ## Documentation Index
> Fetch the complete documentation index at: https://docs.accelmars.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Investigating a request

> Follow the original operation and ask each record only for the fact it can establish.

“The request failed” is a useful symptom, but it is not yet a diagnosis. The provider might have failed, the database confirmation might be missing or the application might have lost an answer that was already produced.

The diagnostic task is to separate those facts and identify a responsible next action—not to retry until the system produces something that looks successful.

## Start with the original identity

Find the original invocation, logical call and relevant attempt. Keep the request fingerprint, pinned plan and source generation associated with that work.

A new identifier hides the relationship you are trying to investigate. Equal-key replay must not become another provider send just because a user-facing response was lost.

## Ask the questions in order

<Steps>
  <Step title="Was the request admitted?">
    Check the authenticated scope and whether approved supply could satisfy the mandatory requirements. A refusal before provider dispatch is different from a failed remote execution.
  </Step>

  <Step title="Was an attempt registered, and what is known about sending?">
    Use the original protected execution and native records together with attributable transport evidence. A registration by itself does not prove the provider received the request.
  </Step>

  <Step title="Could output have been exposed?">
    Check the applicable output or final-release boundary. Possible exposure closes hidden answer substitution, even when receipt cannot be proved.
  </Step>

  <Step title="Did the final record commit?">
    Resolve the complete original operation through the qualified confirmation path. A missing replica row or pending commit is not rollback evidence.
  </Step>

  <Step title="Did the caller retain the answer?">
    Ask the caller-owned result store. Gateway's content-free execution record cannot reconstruct missing answer bytes.
  </Step>

  <Step title="Is a financial effect still unresolved?">
    Ask the actual financial owner about the original operation. An outbox backlog or missing Gateway receipt does not prove that no money moved.
  </Step>
</Steps>

## Use telemetry as a guide, not a substitute

Traces, counters and logs help locate the operation. They do not replace authoritative execution, caller-content or financial records.

Useful measurements include evidence-commit latency, first activity and first meaningful output, blocked delivery time, cancellation latency, unknown usage, outbox age, integrity refusals and readiness failures. Names and thresholds must come from the current deployment rather than be invented by this guide.

Do not place prompts, credentials or private response bodies in metric labels or diagnostic strings.

## Provider observations have a separate reporting path

The reporting design covers rate limiting, terminal failure, quarantine, recovery and provider-declared deprecation or sunset. Those observations can inform review; they do not independently certify an approved capability.

Before durable journaling, reporting can be best effort. Durable unacknowledged observations are delivered at least once, with receiving deduplication. A slow sink should not block the inference path, but reporting drops and backlog must remain visible.

## End with a truthful disposition

Matching authoritative evidence may permit the original next step. Conflict stops conflicting progression. Insufficient evidence remains unresolved with an owner.

None of those states is repaired by writing zero usage, assuming no debit or launching another inference without authorization. Continue with [Lost confirmations](/public/gateway/journeys/lost-confirmation) or [Usage and payment](/public/gateway/records/usage-cost-and-payment).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.