Handling every result

Treat the result taxonomy as closed: NOT_DISPATCHED, COMMITTED, DISPROVED, and UNKNOWN are the only public outcomes. Application code must handle every permitted value explicitly and reject missing or unfamiliar values instead of treating them as success.

NOT_DISPATCHED means the protected provider boundary was not crossed. COMMITTED means authoritative evidence supports the intended effect. DISPROVED means authoritative evidence supports final absence or contradiction of that effect. UNKNOWN means the available evidence cannot determine the effect. PRESENT maps to COMMITTED; ABSENT_FINAL maps to DISPROVED; INDETERMINATE maps to UNKNOWN.

Provider observations are not final results

ACKNOWLEDGED is an intermediate provider observation, never a success claim. REJECTED and PRECONDITION_FAILED map to NOT_DISPATCHED only when dispatch did not cross the protected boundary; after dispatch, insufficient evidence can leave the result UNKNOWN. UNCERTAIN means provider knowledge is incomplete.

Provider-specific states remain private observations until an independent authoritative verifier supports a normalized result. The provider must not verify itself. Omitted, malformed, or contradictory information must not become an optimistic guess. A verifier read that finds the intended effect maps PRESENT to COMMITTED; final authoritative absence maps ABSENT_FINAL to DISPROVED; an unavailable or contradictory read maps INDETERMINATE to UNKNOWN.

Recovery belongs to the application

Your application decides what happens next. Before dispatch, it may correct the request, refresh trusted context, ask for clarification, or obtain authorization. After dispatch, an unresolved result may permit verifier-only reconciliation using the exact live process-local authority available in this preview. AnswerUp Core classifies the bounded lifecycle outcome, preserves the dispatch distinction, projects a safe claim, and prevents blind redispatch through the protected reconciliation path. It does not automatically retry or choose the recovery workflow.

Never add an automatic blind retry: an unresolved effect must be investigated or reconciled before any genuinely new attempt.

The application or integrator is responsible for presenting clarification, obtaining new input or authorization, refreshing context, deciding whether to create a genuinely new proposal, choosing user-facing wording from the permitted result, and invoking allowed verifier-only reconciliation. Core supplies the bounded lifecycle classification and safe claim projection. The original result remains immutable during reconciliation, which performs zero provider redispatch.

Example: canceling a software subscription

A customer-support application proposes canceling subscription sub-381. Its authenticated backend supplies the subscription record and the policy service checks the support agent’s permission. If the identifier is missing or ambiguous, or the agent lacks permission, the result is NOT_DISPATCHED; the billing provider was not crossed. If the billing system’s authoritative record confirms cancellation, the result is COMMITTED.

If a final authoritative read confirms that the subscription remains active and the intended cancellation is absent, the result is DISPROVED. If the provider accepted the request but the independent billing-system read-back is unavailable or contradictory, the result is UNKNOWN. Provider acknowledgment alone does not establish billing-system truth, and the application must not automatically repeat the cancellation.

A practical handling table

If public projection fails after an effect may have occurred, preserve internal truth, expose only bounded uncertainty, and do not redispatch. Detailed preview-specific projection and certification limitations remain documented in the relevant limitations and conformance material; this page states the safe handling rule without claiming that the current mismatch is corrected.