Patterns

Implementation patterns

Established integration shapes for governed actions in systems you own.

How should I put these pieces together?

Provider + independent verifier

Separate mutation from authoritative effect truth.

The provider mutates. A verifier independently reads authoritative state. Provider acknowledgement is an observation—not final truth.

  1. Request
  2. Provider mutation
  3. Authoritative read-back
  4. Effect truth
  5. Bounded claim

Outcome-aware claim authority

Authorize only the proposition matching authoritative truth.

InitialExecutionClaimPlan has mutually exclusive COMMITTED, DISPROVED, and UNKNOWN alternatives. Only the matching branch reaches claim evaluation; unused branches never become authority.

  1. Effect truth
  2. Matching plan branch
  3. Claim evaluation
  4. Permitted proposition

Live UNKNOWN reconciliation

Resolve same-process uncertainty without repeating provider mutation.

Use the exact owned UNKNOWN result in the same Runtime for a single verifier-only read, with no provider redispatch. LiveReconciliationClaimPlan limits any resulting claim to the related historical observation.

  1. Exact UNKNOWN
  2. Same Runtime
  3. Verifier-only read
  4. Related result

Durable UNKNOWN recovery

Continue verification after process loss without repeating the original effect.

Retain recovery material, require accepted authority, register the verifier, and use CAS/fencing with RecoveryClaimPlan. Recovery is verifier-only with zero redispatch; the host must schedule and operate it.

  1. Retained record
  2. Accepted authority
  3. Verifier-only recovery
  4. CAS acceptance

Host-owned control boundary

Keep application policy and customer behavior under application control.

The host owns identity, policy, provider credentials, verifier implementation and authority, persistence, operations, and customer-facing behavior. AnswerUp governs the consequential-action lifecycle inside that boundary.

  1. Host context
  2. AnswerUp lifecycle
  3. Host systems
  4. Approved delivery
Local runnable example

Generic HTTP

Connect AnswerUp to your existing HTTP workflow. Your application sends the request, and a separate verifier checks the system of record.

HTTP reference preview.4 shows how to handle a lost response and check the original operation without sending it again. It runs the current package set with synthetic local state.

Reference status and compatibility history

The older private HTTP reference is separate from the runnable preview.4 archive. Source evidence at commit 839489149ee8ed9843f80133ae1838f492bf98b4 pins it to @answerup/core@1.0.0-rc.1, @answerup/runtime@0.2.0-preview.3, @answerup/actions@0.2.0-preview.4. It is not a distributed package or hosted service. That historical Core rc.1 / Runtime preview.3 / Actions preview.4 reference has no established compatibility with Actions preview.8. This does not describe the current HTTP preview.4 archive.

Works with your existing safeguards

How AnswerUp fits with familiar patterns

Idempotency keys help a provider recognize repeats. Sagas coordinate multi-step work. Outboxes preserve outbound messages. Custom reconciliation checks a business system, and ordinary logs retain observations. These remain useful host-owned approaches.

AnswerUp links the requested action, execution evidence, independent verification, reconciliation and returned permission for a bounded customer-facing claim. Your application still owns identity, policy, provider integration, independent reads, durable admission and recovery, and final delivery.