Safe claims

Authoritative verification establishes effect truth. Core derives a bounded claim permission for the exact operation and identity scope. The application chooses wording within that permission. The formal claim types are EFFECT_COMMITTED, EFFECT_DISPROVED, and EFFECT_UNKNOWN.

From evidence to wording

The sequence is:

authoritative verification
→ normalized effect truth
→ bounded claim permission
→ application-selected wording

The public projection is the protected boundary that exposes the permitted category without exposing private evidence. A provider acknowledgment, local flag, or status label cannot authorize a success claim.

Result-to-language guide

Claim permission	Established	The application may say	It must not infer
`EFFECT_COMMITTED`	The authoritative read found the exact effect for the approved operation.	“The requested change was recorded.”	That another operation, record, account, or later state has the same result.
`EFFECT_DISPROVED`	Applicable final evidence supports the absence of the exact requested effect.	“The requested change was not recorded.”	That no attempt occurred, or that a new attempt is authorized.
`EFFECT_UNKNOWN`	Available evidence cannot determine whether the exact effect exists.	“We couldn’t confirm whether the change took effect. Please don’t submit it again while we check.”	Success, final absence, or permission to retry.

Example: updating a customer phone number

An account UI sends an authenticated backend an approved phone-number update. An independent CRM verifier reads the authoritative customer record after the CRM update provider attempts the change. The application receives only the bounded claim permission, not a license to repeat the provider’s payload in public copy.

For EFFECT_COMMITTED, the application may say, “The phone number on this account was updated.” For EFFECT_DISPROVED, it may say, “The requested phone-number change was not recorded.” For EFFECT_UNKNOWN, it may say, “We couldn’t confirm whether the phone number changed. Please don’t submit it again while we check.” The application should not echo the phone number unless the approved privacy and identity scope expressly permits it.

Scope and privacy

A claim applies only to the exact operation, record or referent, account or tenant, quantity or value where applicable, identity and privacy scope, authoritative read, and relevant time. One verified operation cannot be broadened into a statement about other records, accounts, history, or later state.

Public claims should omit raw evidence, prompts or transcripts, credentials, provider payloads, private Trace, internal counters, unrelated customer identifiers, stack traces, and tenant details. Detailed operational information belongs only in bounded access-controlled views.

Core and application responsibilities

Core derives the permitted effect-claim category, protects the bounded projection and claim boundary, and prevents unsupported success language from being authorized by its result. It does not write or send the final message.

The application owns final copy, localization, audience, timing, notifications, UX, privacy policy, and appropriate freshness or timestamp language. It also owns the decision about how a claim is displayed or communicated to a particular person.

Freshness

Verified truth supports a statement about the exact operation and authoritative read. It does not guarantee that the state can never change later. Durable displays may need timestamp or freshness context. Later reconciliation may produce a new related claim, but a previous COMMITTED result cannot authorize a claim about another operation.