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

# Gateway, explained

> Understand how AccelMars plans AI requests, tracks execution and handles uncertainty.

Gateway gives applications a shared, controlled way to use AI models. It checks which model offerings can meet a request, manages the permitted execution attempts and keeps a reliable record of what happened.

The application still decides what the answer means for its work. **A model producing an answer is not the same as a task being accepted, a user receiving it or a payment being settled.**

This guide explains that separation, starting with familiar situations and then following the architecture behind them. You do not need to know AccelMars's internal project names to begin.

<CardGroup cols={2}>
  <Card title="Why Gateway exists" icon="lightbulb" href="/public/gateway/start/why-gateway">
    See the problems that appear when every application manages AI calls differently.
  </Card>

  <Card title="Follow one request" icon="route" href="/public/gateway/journeys/first-call">
    Walk from an application's question to an answer, including the points where execution must stop.
  </Card>

  <Card title="Explore the architecture" icon="diagram-project" href="/public/gateway/architecture/how-it-works">
    Meet the planner, execution core, provider adapters and evidence store.
  </Card>

  <Card title="Understand the evidence" icon="clipboard-check" href="/public/gateway/design/implementation-status">
    Separate the selected design from dated local tests and unverified deployment claims.
  </Card>
</CardGroup>

## Three questions to keep separate

**May this request run?** The request needs an authorized caller, suitable approved model capabilities and permission to send the relevant data to the selected destination.

**What happened when it ran?** Gateway tracks the original request and each physical provider attempt. It distinguishes a confirmed result from an outcome that cannot yet be established.

**Did the surrounding work succeed?** The application owns its result storage and business decisions. Other components own financial effects. Gateway's execution records inform those decisions; they do not replace them.

```mermaid theme={null}
%%{init: {"flowchart": {"nodeSpacing": 20, "rankSpacing": 30, "padding": 12}}}%%
flowchart TB
    A[Application asks for an AI result] --> B[Gateway checks and plans]
    B --> C[Gateway records a permitted attempt]
    C --> D[Provider performs model work]
    D --> E[Gateway records the outcome]
    E --> F[Application uses or stores the result]
```

This is a simplified view of responsibilities, not a claim that every box is a separate server. The request journeys explain the additional checks for streaming, failure and lost confirmations.

## A guide, not a new design contract

You are reading **Reader Edition 1.1**, based on Gateway's Final Design 1.0. The implementation evidence used here is dated **12 October 2026**. A newer publication date does not turn that evidence into a live service check.

The engineering collection remains the authority for exact contracts. This guide adds explanation and clearly identified examples without changing those contracts. Start with the [reading paths](/public/gateway/start/reading-paths), or consult [About this edition](/public/gateway/reference/about-this-edition) for the scope and update policy.


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