> ## 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.

# Your first request

> Follow a simple text request and see why the record, the answer and the business result are separate.

Imagine an application asking for a short summary of material it is allowed to use. It wants one complete text answer rather than a live stream.

This is an **illustrative walkthrough of the selected design**. It is not a trace from a production service, and the summary request is not an executable API example.

<Steps>
  <Step title="Establish whose request this is">
    The trusted entry point authenticates the caller and the operation it may perform. The request describes the needed answer and its constraints; it cannot grant itself a different tenant or broader permission.

    A durable caller records the original invocation before sending. An ordinary authenticated client does not need to create a Guild professional or a work commitment simply to request text.
  </Step>

  <Step title="Choose an offering that can meet the request">
    Gateway checks approved supply, policy and the requested capabilities. It resolves the required parameters into a compatible execution plan.

    If a mandatory fact is unknown or no offering satisfies the restrictions, the request stops here. Gateway does not silently change the requirement or select an unapproved destination.
  </Step>

  <Step title="Preserve the original call">
    The scoped request key and canonical request fingerprint identify the original logical call. The fingerprint checks the request's meaning; it is not a stored copy of the prompt.

    A duplicate request with the same key and matching fingerprint resolves that original call. The same key with different request content is a conflict, not permission to run a replacement.
  </Step>

  <Step title="Record a permitted attempt before sending">
    Gateway establishes the required attempt record and native-capacity reservation in one admitted database transaction. Only confirmed persistence lets the original live owner dispatch that attempt.

    A lost commit confirmation stops progression until the original operation is resolved. The database transaction is not held open while the provider performs model work.
  </Step>

  <Step title="Observe the provider result">
    The adapter sends the planned request and reports response content, terminal outcome and available usage evidence. It must not make hidden retries outside the shared attempt budget.

    A lost connection does not necessarily mean that the provider did no work. Missing usage fields stay unknown rather than becoming zero.
  </Step>

  <Step title="Confirm the final record, then release the answer">
    For this buffered mode, Gateway withholds successful answer delivery until the required final record and notification obligation are confirmed. A provider success with unresolved final persistence is not yet a successful caller response.

    Live streaming has a different release boundary, explained in the next journey.
  </Step>

  <Step title="Let the application own the result">
    The application receives the answer and decides what to do with it. When it needs exact answer replay after restart, it saves that answer under the original invocation.

    Gateway's execution record remains content-free. Financial settlement, where applicable, is a separate process owned by the relevant financial components.
  </Step>
</Steps>

## What “one request” means

The logical call remains the same through a permitted recovery. Each physical provider dispatch has its own attempt identity and consumes the original limits. A skipped candidate is not a provider attempt, and a client's equal-key replay is not a new inference.

## Where this journey can stop

Before dispatch, unsuitable supply or missing permission can prevent provider work. After dispatch, a failure can leave an uncertain provider outcome or incomplete usage. After provider completion, a storage or delivery problem can prevent the application from receiving a usable answer.

Those endings are deliberately different. The purpose of the design is not to make every path look successful; it is to leave an accurate account and a safe next action.

Read [Following a live stream](/public/gateway/journeys/live-stream) for incremental delivery, or [When a confirmation is lost](/public/gateway/journeys/lost-confirmation) for the point where a simple retry becomes unsafe.


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