What actually happens when ATPX runs a mission

1. You state a goal

Every mission starts with a title and a goal in plain language — "reduce API latency," "cut redundant data transfer." ATPX records this as the mission's starting context.

2. ATPX moves through an 11-stage pipeline

These are the real stage names from the mission engine — observe → understand → validate → connect → predict → simulate → decide → approve → execute → measure → learn. No stage is skipped, and the sequence is enforced server-side, not just in the UI.

3. Nothing executes without approval

Reaching the execute stage is gated: the mission engine will not advance past approve without a decided, permission-checked approval from a user allowed to approve it. This is enforced in the same function that performs the transition — not a separate check that a bug could bypass.

4. Execution is a real, queued job

Once approved, ATPX enqueues a real execution job through its durable job queue — the same queue used for every other background operation, with retries and dead-letter handling, not a fire-and-forget request.

5. Evidence, not a claim

The Evidence Engine compares a real measured baseline against the real measured result: latency, success rate, data transferred. Confidence is shown honestly — if there isn't enough data to compute it, the product says so instead of inventing a number.

6. You can roll back

A mission that reached execution can be rolled back to the approval stage, clearing its approval so a fresh decision is required before it can execute again. That's a real reversion of the mission's own state, provable in its own audit log — stated honestly, it does not undo an external system's side effects, since no generic mechanism for that exists yet.