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

# Core Concepts

> The controlled concepts behind AtlaSent: verified identity, organizational authority, execution-time authorization, permits, gates, execution, effect, and proof.

AtlaSent provides **authorization for consequential computational actions**.
Its core mechanism is **execution-time authorization**: determining whether an
exact consequential action is organizationally authorized under current
conditions before the governed effect occurs.

The distinction to keep in mind throughout these docs is:

> **Verified identity tells AtlaSent who or what is acting. It does not tell AtlaSent what the organization authorizes that Actor to do.**

<CardGroup cols={2}>
  <Card title="Verified Actor Identity" icon="fingerprint" href="/concepts/verified-actor-identity">
    How AtlaSent establishes the Actor from an authoritative identity source without treating identity as authority.
  </Card>

  <Card title="Execution-time authorization" icon="shield-check" href="/concepts/execution-time-authorization">
    The fresh per-request authorization determination made at the execution boundary.
  </Card>

  <Card title="Organizational authority" icon="building-shield" href="/concepts/organizational-authority">
    The standing, scoped organizational right to cause or approve a class of change.
  </Card>

  <Card title="Consequential computational actions" icon="bolt" href="/concepts/consequential-computational-actions">
    The actions whose effects may require explicit authority, policy, evidence, or enforcement.
  </Card>

  <Card title="Identity, authority, authorization, approval, and access" icon="scale-balanced" href="/concepts/authority-vs-authorization">
    Why these concepts — plus Permit, Execution, Effect, and Proof — must not be collapsed.
  </Card>
</CardGroup>

## The controlled lifecycle

```text theme={null}
Verified Actor Identity
        ↓
Organizational Authority
        +
Policy + Assertions + required Approval + current Context
        ↓
Evaluation → Authorization Decision
        ↓ allow only, when Permit required
Permit Issued
        ↓
Permit Verification at Gate
        ↓
Native Execution
        ↓
Observed Effect
        ↓
Evidence
        ↓
Verified Proof (only where verification establishes it)
```

This is a semantic ladder, not a claim that every integration exercises every rung. Each stage must remain explicit: `allow` is not a Permit; a Permit is not Verification; Verification is not Execution; Execution is not Effect; Evidence is not automatically Verified Proof.

## Product/runtime nouns

<CardGroup cols={2}>
  <Card title="Action class" icon="list-tree" href="/concepts/action-class">
    The organization-specific runtime governance/configuration object for an Action Type.
  </Card>

  <Card title="Policy" icon="scroll" href="/concepts/policy">
    Versioned rules defining conditions under which Authority may permit an Action.
  </Card>

  <Card title="Permit" icon="ticket" href="/concepts/permit">
    The bounded runtime artifact carrying a positive Authorization to an execution boundary.
  </Card>

  <Card title="Runtime flow" icon="route" href="/concepts/runtime-flow">
    How Evaluation, Permit verification, execution, observed effect, and evidence connect end to end.
  </Card>

  <Card title="Proof verification" icon="file-shield" href="/concepts/proof-verification">
    How Evidence becomes independently verifiable Proof for the properties actually checked.
  </Card>

  <Card title="Approval" icon="user-check" href="/concepts/approval">
    Verified approver input that may satisfy a required condition; not itself final Authorization.
  </Card>
</CardGroup>

## Distinctions that must remain intact

* **Identity ≠ Authority**
* **Authority ≠ Authorization**
* **Authority ≠ Approval**
* **Approval ≠ Decision**
* **Decision ≠ Permit**
* **Permit ≠ Verification**
* **Verification ≠ Execution**
* **Execution ≠ Effect**
* **Evidence ≠ Verified Proof**
* **`allow` ≠ Execution**
* **Action Type ≠ Action Class**
* **Action Class ≠ Protected Class**
* **Gate ≠ Policy**
* **Proof ≠ generic log**

For the complete controlled vocabulary, see the [Glossary](/concepts/glossary).

## Where to go next

* **Understand identity:** [Verified Actor Identity](/concepts/verified-actor-identity).
* **Understand the category:** [Execution-time authorization](/concepts/execution-time-authorization) → [Organizational authority](/concepts/organizational-authority).
* **Understand the governed object:** [Consequential computational actions](/concepts/consequential-computational-actions).
* **Understand the distinctions:** [Identity vs. authority vs. authorization vs. approval vs. access](/concepts/authority-vs-authorization).
* **Build:** [Quickstart — your first protected action](/quickstart/first-evaluation).
* **Trace the runtime:** [Runtime flow](/concepts/runtime-flow) → [Permit](/concepts/permit) → [Proof verification](/concepts/proof-verification).


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