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 or durable recovery. Live reconciliation uses the exact UNKNOWN result and authority in the same runtime/process context. After process loss, Runtime durable recovery provides a distinct host-operated path only when the host retained a closed DurableRecoveryRecordV2, accepted recovery authority, and a stable registered verifier binding. Both paths are verifier-only and perform zero provider redispatch; neither changes the original historical result.

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.

Initial execution claim authority

Default initial claim behavior remains success-oriented and proposition-specific. DISPROVED does not automatically authorize any negative natural-language claim, and initial UNKNOWN does not automatically grant ordinary safe-claim authority. Legacy claims.build remains a one-proposition compatibility path whose callback is captured at registration; its returned proposition is snapshotted, validated, and frozen before provider dispatch so later caller mutation cannot change what Core evaluates.

An action may opt in at registration with a data-only, bounded InitialExecutionClaimPlan. It provides COMMITTED, DISPROVED, and UNKNOWN as mutually exclusive alternatives, not three simultaneous permissions. Initial authoritative verification runs first; Runtime selects only the matching proposition for Core evaluation, and unused branches never become authority. A permitted initial UNKNOWN branch appears only in observationClaims as RELATED_INITIAL_VERIFICATION_OBSERVATION_ONLY, describing that exact historical observation—not current unresolved state, success, failure, retry, redispatch, compensation, reconciliation, recovery, or future truth.

Two verifier-only continuation paths

Live reconciliation and durable recovery are deliberately separate mechanisms. Live reconciliation is process-local: the host passes the exact Actions-owned UNKNOWN object back to the same ProtectedActionRuntime, subject to its existing one-shot authority. It cannot be reconstructed from a clone, serialized value, or log.

Runtime durable recovery is a process-loss path. It requires a host-retained closed DurableRecoveryRecordV2, accepted recovery authority, stable verifier registration, and the documented lease, fencing, source-record digest, and CAS controls. The host owns storage, scheduling, and invocation; recovery is not automatic restart behavior. It performs authoritative verifier read-back with zero provider redispatch and creates a related result or next recovery record. It does not restore the live association or mutate the original UNKNOWN into a different historical outcome.

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. The @answerup/core package 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.