MissionFlow

The objective stays. The path adapts.

A MissionFlow is an outcome with boundaries. Excapia plans a route to it, follows that route deterministically where it can, adapts inside your rules when it must, and declares success only when the outcome is verified.

MissionFlow Theater

The objective stays. The path adapts.

Give Excapia an outcome, define the boundaries, and follow execution from the first action to verified completion.

Interactive product demonstration · Illustrative demo data · Runs locally in your browser and contacts no system

Scenario A: checkout after deployment. This walk-through runs in your browser with JavaScript. Without it, here is what happens:

  1. The objective is defined with three success conditions: the order exists, payment is confirmed, the confirmation is delivered.
  2. A browser worker follows the recorded checkout path in a fictional staging store.
  3. A storefront release renamed the checkout button, so the step fails. Deterministic retries are exhausted.
  4. An agent examines the screenshot and proposes a replacement selector, which is validated inside the configured scope and approved.
  5. Execution continues on the alternate route.
  6. Order, payment and delivery evidence are checked. The mission is Verified only because all three assertions pass.

Three scenarios, three kinds of change

Each scenario is deterministic: the same settings and choices always produce the same events. Change the settings to see different, truthful outcomes.

A · Checkout after deployment

A storefront release renames the checkout button. Retries are exhausted, so an agent proposes a replacement selector, which is validated inside scope before execution continues.

TrySet the recovery policy to Deterministic retries only: the order assertion fails and the mission ends Failed, never Verified.

B · Deployment verification

A service check fails after a release. Excapia proposes an allowlisted rollback and stops at an approval boundary. You decide.

TryDecline the rollback: the mission ends Blocked with the reason, and nothing is changed.

C · Distributed continuity

A branch worker loses its central link. Read-only checks continue under an authority lease; a change waits for fresh approval; reconciliation comes before new work.

TryChoose the 5 min lease: it expires during the outage and the worker stops.

Objective vs route

How a MissionFlow differs from a fixed workflow

A fixed workflow is a route. When the route breaks, the workflow fails, even if the business outcome was still reachable another way. When the route completes, the workflow succeeds, even if the outcome was never achieved.

A MissionFlow is anchored to the objective. Its success criteria are checked independently of the steps that ran. Its strategies are alternatives toward the same objective. Its boundaries limit what any route may do.

Fixed workflow

  • Success = last step exited cleanly
  • Failure = any step failed
  • Change = edit the workflow and redeploy

MissionFlow

  • Success = every required assertion passed
  • Failure = assertions cannot pass within the rules
  • Change = another permitted route to the same objective

Approval boundaries

Where execution stops and a person decides

Every action is evaluated against the administrative policy and the mission’s contract. Deny beats approval, and approval beats allow. Actions that need approval put the mission into Waiting for approval, with the proposal, the evidence and the risk shown to the approver.

Approval of a diagnosis does not grant permission to execute. Declining is recorded, and the mission reports Blocked rather than Verified.

  • Allow

    Read-only checks in staging; validated selector repairs in scope.

    runs
  • Needs approval

    Rollbacks, writes to shared systems, anything privileged.

    waits
  • Deny

    Actions outside the allowlist, forbidden resources, production writes.

    blocked

Evidence

What confirms success

Each success criterion names what is checked and where: a record in the order store, a status from a payment API, a message in a mailbox, a checksum at a partner. The result is stored with the observed value, the time, and the artifacts that support it.

A strategy that reports success is treated as a claim. Excapia verifies the claim independently and rejects it if the criteria do not hold, as in the settlement-file mission on the right.

Mission Control showing three completion assertions passed and the decision to switch from SFTP to the partner API after SFTP claims were rejected.
Synthetic demo data: two SFTP claims were rejected by the verifier before the partner-API fallback was verified.

Three separate kinds of state

The theater shows them separately because they mean different things. A repaired step does not make a mission verified; a lost link does not fail a mission.

Mission

Ready Running Waiting for approval Blocked Verified Failed

Whether the outcome has been achieved and proven.

Step

Pending Running Passed Failed Skipped

What happened to one action on one route.

Connectivity

Connected Disconnected Reconnecting

Whether a worker can reach central authority, and so which state is confirmed or stale.

Model your own mission with us.

Bring a journey you need to be sure of. We will show it as a MissionFlow with real evidence.

Request a Demo