Provider and verifier responsibilities

The provider attempts the change. The verifier independently checks the system that owns the resulting fact. They remain separate because the system attempting an action cannot prove its own success. The Core package classifies the evidence; it does not perform the external provider or verifier I/O.

Architecture

Inputs can come from an application UI, API, workflow, copilot, agent, webhook, messaging interface, or optional voice interface. A typical integration looks like this:

application backend
→ AnswerUp protected lifecycle
→ provider adapter attempts the change
→ authoritative business system
→ separate verifier reads the resulting state
→ Core classifies the result

The host supplies the architecture: it knows which business system is authoritative and registers the provider and verifier capabilities. The details below keep those capabilities from silently becoming one authority.

The protected lifecycle

The passive, callback-free manifest declares bounded identities and versions. It contains no executable callbacks. Separate executable host registrations own orchestration, provider I/O, verifier I/O, and credentials. The frozen public Actions result projection exposes only the approved result shape.

Preparation is side-effect-free. The host checks authorization, derives the expected candidate binding from admitted facts, and freezes that binding into a process-local HostExecutionRecord before dispatch. The host owns this expected binding. The verifier independently observes the authoritative system, then Core compares the exact UTF-8 candidate and stable reference without normalization or provider substitution. These constraints make the later classification about the approved operation rather than about a provider’s preferred representation.

Provider responsibility

The provider boundary owns provider-specific request construction, credential use, dispatch mechanics, response capture, timeout behavior, and provider-side idempotency where applicable. It classifies its own observation as ACKNOWLEDGED, REJECTED, PRECONDITION_FAILED, or UNCERTAIN.

That observation is not effect truth. The provider cannot rewrite Core’s expected binding, verify itself, place credentials in results, or turn an acknowledgment into an authoritative claim.

Verifier responsibility

The verifier reads the system that owns the effect and compares the exact candidate and stable reference. Its read includes the applicable scope and any bound quantity, value, revision, or other fact. It applies the correct finality rule and reports stale, contradictory, unavailable, malformed, or indeterminate reads honestly.

Finality means that the read is strong enough for the conclusion being made. That may be a terminal record establishing completion or final absence, a revision or version rule establishing that the read is current enough, or append-only/event evidence establishing what was authoritatively recorded. The frozen families are authoritative terminal lookup, authoritative version/revision comparison, and authoritative append-only/event evidence.

The verifier observations PRESENT, ABSENT_FINAL, and INDETERMINATE map to COMMITTED, DISPROVED, and UNKNOWN. A timeout, empty read, cache, provider statement, or local mutation flag cannot independently establish final absence.

Dispatch and isolation

The explicit dispatch boundary determines when the provider may have been invoked. Before it, provider invocation has not occurred. After it, the provider may have acted even if no response arrives. Dispatch, mutation, acknowledgment, verifier-read, and redispatch counters can explain lifecycle behavior, but they do not prove authoritative state.

Provider and verifier identities, callbacks, credentials, and state stay separate. The HostExecutionRecord is private process-local expected binding; it is not provider state, a public result, or a serialized reconciliation handle. Runtime instances cannot cross-read one another’s authority. The host owns credential cleanup and private retention.

Example: updating a delivery address

An order-management UI sends an authenticated backend an exact order identity and proposed delivery address. The backend authorizes that binding and passes it through the protected lifecycle. A fulfillment provider adapter attempts the change, while a separate order verifier reads the authoritative order-management record. AnswerUp does not own that fulfillment system.

“Update accepted” is only a provider observation. If the authoritative order record contains the exact new address under the expected order and scope, the verifier can support PRESENT and Core can classify COMMITTED. Supported final evidence that the requested address change is absent can support ABSENT_FINAL and DISPROVED. An unavailable, stale, contradictory, or non-final read remains UNKNOWN.

Current preview note

The accepted Runtime preview.5 / Actions preview.8 contract maps a post-dispatch PROJECTION_FAILED to UNKNOWN, preserves internal truth, and keeps zero redispatch; it is not a pre-dispatch INTEGRATION_FAILURE. This closes the former mapping gap but does not certify a provider, host, or deployment. No provider retry repairs a projection failure.

The current HTTP reference preview.4 example runs the current package set locally with local test-provider and verifier state. The older private HTTP reference used Core rc.1, Runtime preview.3 and Actions preview.4; compatibility with newer packages has not been established for that historical source. Neither is hosted execution or live-provider validation. The release candidate does not imply hosted execution, automatic retry, automatic durable recovery, exactly-once behavior, conformance service availability, or certification.