Five-minute lumber walkthrough

This is a synthetic documentation walkthrough, not an executable quickstart. It lets a reader follow every boundary around one consequential action without package access, credentials, a provider connection, or a live inventory system.

Step 1: the proposed operation

A procurement application, inventory workflow, or business agent submits a bounded request to reserve 20 boards of an 8-foot cedar product. The proposal may have originated in an agent, workflow, API, application UI, chat, or voice channel—for example, a human request might have been “Reserve 20 boards for my project.” The proposal records intent; it does not establish the exact product, authorization, or inventory change.

Step 2: the incoming proposal

The submitting system supplies a proposal such as { operation: "reserve", productText: "8-foot cedar", quantity: 20 }. It is a candidate action, not a command that has already happened. The host validates the fields and supporting evidence; if quantity, product, or an inventory identifier changes unexpectedly, it rejects or clarifies the proposal.

Step 3: trusted host context

The host supplies server-owned context: requester identity, account scope, the inventory authority name, a bounded catalog snapshot, policy revision, and context version. The host—not the model or customer—decides which context is trusted. The snapshot may be stale, malformed, incomplete, or from the wrong tenant. Any of those conditions must stop preparation or remain visible as uncertainty; Core does not repair the context.

Step 4: candidate resolution and grounding

Grounding binds the supplied proposal fields and supporting evidence to bounded candidates and an exact referent. The synthetic catalog may contain cedar-8ft-gradeA and cedar-10ft-gradeA. The host resolves the supplied product details to cedar-8ft-gradeA, records evidence and source snapshot, and freezes the selected referent. If two records remain plausible, the result is clarification or invalid proposal and no provider dispatch occurs. A candidate is not permission and a referent is not an effect.

Step 5: authorization

The trusted policy authority evaluates requester customer-42, operation reserve, referent cedar-8ft-gradeA, quantity 20, and account scope. An allowed decision means preparation may continue. It does not mean inventory was reserved. A denial, stale policy snapshot, unavailable policy service, or malformed decision fails closed as a pre-dispatch result.

Step 6: operation, effect, execution, and attempt identities

The host creates a stable operation identity for this reservation request, an effect identity for the intended inventory change, an execution identity for this protected run, and an attempt identity for the provider call. These identities let later observations be correlated without confusing one run with another. They are not proof that inventory changed and do not establish exactly-once execution.

Step 7: provider dispatch and acknowledgment

The host invokes its provider boundary with the frozen binding. AnswerUp Core performs no provider I/O. The provider may return ACKNOWLEDGED, REJECTED, PRECONDITION_FAILED, or UNCERTAIN. ACKNOWLEDGED means only that the provider observed or accepted the request at dispatch. It is not an authoritative reservation and must not authorize “your boards are reserved.”

Step 8: independent verifier read

The host invokes a separate verifier against the authoritative inventory system. The verifier checks the exact product, quantity, account scope, execution/effect reference, and applicable finality rule. It returns one of three normalized observations:

• PRESENT: authoritative state supports the reservation.
• ABSENT_FINAL: authoritative state supports that the reservation is finally absent.
• INDETERMINATE: the read is unavailable, stale, contradictory, incomplete, or cannot establish finality.

The provider does not verify itself. A cache, empty read without a finality rule, local mutation flag, provider message, or timeout cannot establish ABSENT_FINAL.

Step 9: effect truth and bounded downstream result

Core maps PRESENT to COMMITTED, ABSENT_FINAL to DISPROVED, and INDETERMINATE to UNKNOWN. COMMITTED permits a bounded claim such as “The synthetic reservation was confirmed.” DISPROVED permits language that the reservation was not confirmed. UNKNOWN permits only language such as “We could not confirm whether the reservation took effect.” Raw provider payloads, credentials, private Trace, and unsupported details stay out of the public projection.

Step 10: the lost-response variant

Suppose dispatch crosses the provider/API boundary, the provider may mutate inventory, and the response is lost before the host receives acknowledgment. The effect is not known to be absent or present. Core returns UNKNOWN, a truthful effect result—not a generic exception and not success. The host must preserve the immutable original snapshot, attempt identity, and bounded lifecycle observations. It must not turn the lost response into a new reservation request.

If the same Runtime instance still owns an exact live reconciliation authority, the application may perform a verifier-only reconciliation. The result can later become COMMITTED, DISPROVED, or remain UNKNOWN; provider dispatch during reconciliation must remain zero. After process loss, this preview cannot reconstruct the live authority. A copied, serialized, cloned, stale, reconstructed, or foreign handle is insufficient.

Evidence to retain

An integrator should retain approved bounded operation, effect, execution, and attempt identities; grounding evidence references; policy decision reference; provider observation category; verifier observation; result state; and privacy-safe lifecycle counters. Retention and access controls should be defined separately so the record supports safe continuation without exposing credentials or unnecessary personal data.

What establishes effect truth

An applicable independent verifier observation against the authoritative inventory system establishes supported effect truth. Proposal details, grounding, authorization, provider observations, local records, caches, timeouts, and copied handles provide context for the lifecycle but do not replace that observation.

Example outcome

If the verifier returns PRESENT, the walkthrough ends COMMITTED. If it returns ABSENT_FINAL after the provider’s acknowledgment, it ends DISPROVED, because the provider was not the final authority. If the verifier returns INDETERMINATE, the result is UNKNOWN. The application may state that confirmation is pending or unavailable, but it must not claim that the boards were reserved. Any permitted follow-up is verifier-only reconciliation; it never redispatches the provider.