Core lifecycle

Each stage answers a different question: validation, trusted context, grounding, authorization, provider execution, verification, effect truth, and safe continuation.

In plain language, the lifecycle moves from “what might we do?” to “what are we allowed to do?” and finally “what actually happened?” A proposal may originate from an autonomous or assisted agent, workflow or automation, API, application or UI, structured event, chat, or voice. A proposal is the intended action; evidence supports its details; authorization is permission; verification checks the authoritative system after an attempt; effect truth is the normalized answer to whether the intended change is supported.

The lifecycle in order

A provider acknowledgment is an observation at dispatch, not effect truth. ACKNOWLEDGED is therefore intermediate; COMMITTED requires supported effect truth. The nine stages are:

1. Proposal. An agent, workflow, API, application, event, chat, or voice channel describes a possible operation. A proposal is intent, not permission or proof.
2. Admission and trusted context. The host validates bounded input and supplies server-owned identity, scope, policy, and snapshots. User or model assertions cannot create trusted context.
3. Grounding. Core binds the supplied proposal fields and supporting evidence to bounded candidates and an exact referent. Ambiguous or missing candidates stop before dispatch.
4. Authorization. A trusted policy authority decides whether the identified requester may perform the identified operation. Permission is not completion.
5. Protected execution. The host assigns operation, effect, execution, and attempt identities and prepares the provider boundary. Credentials remain host-owned.
6. Dispatch and acknowledgment. The provider may be called once. Its acknowledgment is an observation, not effect truth.
7. Independent verification. The verifier reads the authoritative system using the expected candidate and stable reference. Core does not let the provider verify itself.
8. Effect truth and projection. PRESENT maps to COMMITTED, ABSENT_FINAL maps to DISPROVED, and INDETERMINATE maps to UNKNOWN. UNKNOWN is unresolved truth, not ordinary failure or success.
9. Reconciliation. Only an exact live in-process authority may perform verifier-only follow-up in this preview. Reconciliation never redispatches.

import { createProtectedActionRuntime } from '@answerup/actions';
const runtime = createProtectedActionRuntime();

The example uses package-root ESM and synthetic data. It does not execute an action by itself.

Why the separation matters

Grounding identifies the exact target, authorization establishes permission, and verification establishes supported effect truth. Keeping them separate gives application code a safe continuation point: clarify a proposal, refresh context, obtain permission, inspect a verifier result, or reconcile an unresolved effect. Missing, stale, malformed, or contradictory inputs stop preparation or leave effect truth unresolved.

Identity and counters

The host should distinguish operation, effect, execution, and attempt identities. An operation groups the business request; an effect identifies the intended state change; an execution identifies the protected run; an attempt identifies a provider dispatch. These identities let Trace and conformance answer whether reconciliation performed zero redispatches. They do not prove exactly-once execution or authoritative state by themselves.

Example: an access revocation

An approved administrative workflow or identity-management agent submits a request to revoke a former employee’s access. Trusted host context supplies the tenant and administrator identity. Grounding binds the account and systems to exact referents, authorization checks policy, and the provider attempts revocation. The verifier reads the identity authority. PRESENT supports committed revocation; an unavailable read produces UNKNOWN, even if the provider says “done.”

Developer checklist

The integrator must provide bounded inputs, trusted context, policy authority, provider registration, verifier registration, identity scope, and credential ownership. AnswerUp Core owns lifecycle classification, closed result projection, and the no-blind-redispatch boundary. The downstream claim policy must use supported effect truth, not timing, a missing field, a cache, or a provider acknowledgment.