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

# Core concepts

> The objects and lifecycle behind every Atlas signing flow.

A handful of concepts describe everything Atlas does. They are the same whether
you drive Atlas from the REST API, the MCP server, or the dashboard.

## Objects

<AccordionGroup>
  <Accordion title="Envelope" icon="envelope">
    The unit of work: one document (or set of documents) routed to a set of participants for
    signature. An envelope moves through a defined [lifecycle](/guides/envelope-lifecycle) and
    carries its own policy — delivery mode, expiration, branding, legal framework, and metadata.
  </Accordion>

  <Accordion title="Participant" icon="user">
    A person involved in an envelope (typically a signer, optionally a viewer or approver), with a
    signing order. Each participant gets a single-purpose, tokenized link — never an account.
  </Accordion>

  <Accordion title="Field" icon="pen">
    A fillable thing on the document: signature, initials, date, text, checkbox. Detection proposes
    fields and assigns each to a participant; the sender is the final authority and can edit
    everything at review.
  </Accordion>

  <Accordion title="Template" icon="copy">
    A frequently used document with a confirmed field layout and named signer roles. Repeat sends
    supply only recipients and [prefill values](/guides/prefill) — no detection, no review friction.
  </Accordion>

  <Accordion title="Events & certificate" icon="shield-check">
    An append-only, hash-chained history of everything that happened to an envelope. On completion
    it backs the audit certificate — the evidentiary record companion to the signed PDF.
  </Accordion>

  <Accordion title="Webhook" icon="bell">
    A registered endpoint that receives signed, retried notifications for lifecycle events and
    extraction results. See [Webhooks](/guides/webhooks).
  </Accordion>

  <Accordion title="Credits" icon="coins">
    Sending consumes a credit. Balance and ledger live in the dashboard; out-of-credit senders are
    blocked only at the send moment.
  </Accordion>
</AccordionGroup>

## The shape of a send

Whether a developer, an agent, or a human initiates it, a send follows the same
arc:

<Steps>
  <Step title="Create">
    Submit the document (by URL, inline content, or upload) and the participant list. Atlas stores
    the document, starts detection asynchronously, and returns the envelope immediately with a
    review URL. The caller never waits on analysis.
  </Step>

  <Step title="Review">
    Detection assigns fields to participants and the envelope reaches `review`. A human inspects
    placement and clicks Send — the default contract. (Template sends and explicit auto-send opt-ins
    skip the gate.)
  </Step>

  <Step title="Send">
    A credit is consumed, the first participant is emailed their signing link, and the envelope is
    `in_progress`.
  </Step>

  <Step title="Sign">
    Each participant fills only their own fields and submits. Atlas advances to the next participant
    or completes the envelope.
  </Step>

  <Step title="Complete">
    Atlas stamps the final PDF, generates the certificate, notifies everyone, and fires webhooks.
    Structured extraction is available on request.
  </Step>
</Steps>

<Note>
  Review-first is the default everywhere: **agents prepare, humans approve.** This is a product
  guarantee, not a configuration default you have to remember.
</Note>