> ## 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. # Runtime flow > How AtlaSent moves from a proposed consequential action through organizational authority, authorization, Permit verification, execution, and evidence. AtlaSent provides **authorization for consequential computational actions**. The runtime model connects three independent questions: *did a qualified organizational source authorize this exact consequence; can the consequence currently be withheld across every reachable same-effect path; and what native effect was independently established?* **Evidence boundary:** the first question is implemented by the current authorization/Permit runtime. Whole-topology protection continuity, atomic execution admission, and independent native-effect establishment are architecture requirements with bounded preview work; they must not be described as universally available until the corresponding acceptance evidence is current and complete. The core lifecycle is: `Intent → Authority → Policy → Evaluation → Permit → Verification → Execution → Evidence` The important rule is that these stages are **not interchangeable**. An Approval is not final Authorization. An `allow` Decision is not Execution. A Permit is not Evidence. ## End-to-end flow ```text theme={null} Caller / proposed Action ↓ identity resolution → Actor / Execution Principal ↓ Action Type + Resource/Target + Environment + Context ↓ trusted Assertions / required Approval ↓ current organizational Authority ↓ reachable same-effect topology / practical control ↓ Policy / active Policy Bundle ↓ POST /v1/evaluate ↓ Decision: allow | deny | hold | escalate ↓ allow only Permit (`permit_token` on the current evaluate response) ↓ Gate at the actual execution boundary ↓ POST /v1-verify-permit ↓ Verification + single-use/replay enforcement ↓ Execution admission / execution ↓ Native Effect ↓ Evidence / Proof ``` The diagram is the **target end-to-end invariant**, not a claim that every connected path currently implements every stage. A specific accepted path may only be described as topology-complete, atomically admitted, or independently effect-terminalized when that exact path has acceptance evidence proving it. ## 1. Resolve the action and actor The request identifies the Action being attempted and the Resource/Target it may affect. The runtime must distinguish the boundary **Caller** from the resolved **Actor**, and where relevant from the **Execution Principal** that will actually attempt the native effect. The Action Type identifies what kind of action is being attempted. The organization-specific Action Class configures governance for that Action Type. Those are related but different concepts. ## 2. Establish current organizational context The Authorization determination can consume trusted inputs such as: * organizational Authority and delegation; * current Policy / Policy Bundle; * required Approval; * separation-of-duties or quorum results; * verified Assertions; * Resource/Target state; * environment and transaction context; * timing and other current conditions. A technically capable Caller cannot manufacture organizational Authority by sending favorable context. Nor can an upstream IAM/PAM allow, policy-engine result, approval artifact, risk score, or scoped credential become positive Authority unless its source is independently qualified for the exact organizational proposition. ## 3. Evaluate The public decision operation is: ```http theme={null} POST /v1/evaluate ``` Evaluation returns a Decision: | Decision | Runtime meaning | | - | - | | `allow` | The request satisfies the evaluated Authorization conditions; a Permit may be issued. | | `deny` | The request is not authorized under the evaluated conditions. | | `hold` | A required condition or evidence item remains outstanding. | | `escalate` | Additional authority, review, or evidence is required. | Only a positive Authorization can produce the Permit needed for a permit-gated execution path. The current wire response exposes the Permit on the flat response surface (for example `permit_token`) rather than the old nested Permit shape shown in some historical documentation. ## 4. Verify at the Gate A **Gate** is an enforcement point with practical ability to withhold or constrain the native effect on a particular route. Gateway placement is not proof of whole-effect control. The architecture requires protection status to account for the reachable same-effect topology, including alternate actuators, bypass, break-glass, stale, and unknown routes. **Current topology coverage is path-specific and evidence-bounded; do not infer whole-effect control from a single governed route.** The public verification operation is: ```http theme={null} POST /v1-verify-permit ``` Verification checks the Permit for the actual execution attempt, including the applicable validity, binding, expiry, revocation, and replay requirements. The current permit-gated path enforces single-use consumption semantics as part of this boundary. > **Do not execute merely because an earlier Evaluation or an external gateway returned allow. Gate the native effect on successful Permit Verification and whatever practical-control evidence the specific accepted path requires.** The verification binding should be derived from the original request/execution context required by the current contract; do not expect the evaluate response to invent or echo every binding field. ## 5. Execute The **target invariant** is that successful Verification and execution admission/consumption form an atomic, replay-safe boundary before the native system attempts the Action. Do not describe the current runtime generally as providing atomic admission unless the exact execution path has acceptance evidence showing the verify/consume-to-operation handoff is atomic for that path. AtlaSent does not become the underlying deployment system, financial system, clinical system, database, or agent framework. It governs the authorization boundary; the native system performs the effect. Execution is a distinct state. It is possible for an Action to be authorized and never execute, or for a native system to return a failure after Authorization. A provider, workflow, connector, gateway, or PEP reporting success does not alone establish the native effect. Independent terminal effect establishment is a target architecture requirement and is only a current capability claim for paths with current profile-qualified evidence; otherwise ambiguity remains explicit. ## 6. Preserve Evidence / Proof The evidence model should correlate: * the proposed Action and normalized context; * Actor / Execution Principal identity context; * applicable Authority and Policy; * required Assertions and Approval evidence; * Evaluation and Decision; * Permit issuance; * Verification / replay outcome; * reachable same-effect routes and their current governed/bypassable/stale/unknown state **where topology evidence exists**; * exact admission/consumption identity **where the path implements the atomic-admission invariant**; * native execution reference and provider result; * versioned, profile-qualified Native Effect evidence **where an effect-establishment profile is implemented and accepted**; * unresolved or indeterminate outcome state when evidence is insufficient; * conformance between the authorized and executed action; and * invalidation caused by Authority or topology drift. Use **tamper-evident** for hash-linked evidence history unless a stronger storage property is independently supported. **Proof** means cryptographically verifiable Evidence, not an arbitrary log entry. ## Enforcement posture Not every AtlaSent-connected path should be described as production-blocking. AtlaSent can be introduced through modes such as shadow/advisory evaluation and later moved into bounded enforcement after the customer and execution topology are ready. Where a specific path is configured and tested as **fail-closed and permit-gated**: > **No valid Permit means no execution through that governed path.** Do not apply that claim to non-enforcing, shadow, historical, or merely observed paths. Topology incompleteness still prevents a whole-topology claim, but it does not negate the tested behavior of a specific governed route. ## Why this is different from workflow A workflow can collect a request and an Approval. It may sequence steps before or after the action. That does not by itself establish that the exact action is organizationally authorized at the execution boundary. AtlaSent's model keeps the workflow input and the runtime determination separate: ```text theme={null} workflow / IAM / system-of-record facts ↓ trusted inputs organizational Authority + Policy ↓ per-request Authorization ↓ Permit ↓ Gate / Verification ↓ Execution ``` ## Why this is different from a policy engine A policy engine can evaluate expressions. AtlaSent's current accepted runtime contract connects evaluation to a bounded Permit and Verification/Evidence for governed paths. The broader architecture extends that linkage toward whole-topology protection continuity, atomic execution admission, and independently established native-effect truth; those later capabilities remain evidence-bounded until their acceptance records support a current capability claim. ## Controlled distinctions * **Caller ≠ Actor ≠ automatically the Execution Principal** * **Action Type ≠ Action Class** * **Authority ≠ Authorization** * **Authority ≠ Approval** * **Approval ≠ Decision** * **Decision ≠ Permit** * **Permit ≠ Evidence** * **`allow` ≠ Execution** * **Gate ≠ Policy** * **External allow ≠ organizational Authority** * **Gateway placement ≠ whole-effect control** * **Provider/PEP success ≠ terminal Native Effect** * **Proof ≠ generic log** The mechanism at the execution boundary. The standing organizational right evaluated as part of Authorization. The bounded runtime artifact used at the Gate. How the evidence chain can be independently verified. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.