Durable action records and logging

What should my application retain?

Your application should retain a host-owned record of each consequential action for the operational lifetime approved for that application. “Durable” means the record survives the host process lifecycle under the host’s storage design. It does not mean immutable forever, legally compliant by default, or sufficient to reconstruct Core’s process-local live reconciliation authority.

Four different records

Trace is a bounded, read-only lifecycle projection useful for understanding what Core observed. Actions 0.2.0-preview.8 returns an empty privacy-safe Trace envelope by design, so applications must retain bounded host-owned lifecycle evidence and counters. Trace is not automatically a durable hosted store, an authoritative business database, or claim permission by itself. Trace is REFERENCE ONLY: the Portal documents the contract and host evidence guidance but supplies no Trace viewer, populated export surface, or separately consumable tool. This does not imply lifecycle evidence or events do not exist.

A durable action record is application-owned. It correlates operation, effect, execution, and attempt identities across the request, effect, execution, provider attempt, and later verification. It retains immutable original outcomes alongside later reconciled results, with bounded grounding, authorization, dispatch-boundary observation, provider observation, verifier observation, effect truth, and claim information where approved. It is detailed enough for support, reconciliation, investigation, and owner review. It must not contain live process-local reconciliation authority, pretend to be authoritative business state, or imply automatic persistence, store integration, or recovery scheduling.

Application or operational logs are host-owned diagnostic and monitoring events. They can support health, performance, alerts, failures, and operations, and may be sent to a logging, monitoring, or SIEM system. They are not effect truth, a replay command, or a substitute for the durable action record or authoritative system.

Authoritative business state is the inventory, ledger, schedule, directory, CRM, order, logistics, or other system that owns the external fact. The independent verifier reads it. Under the defined finality policy, it is the applicable source for authoritative effect evidence.

Keep the identities straight

Identity	What it identifies	What the host keeps stable
Host request or delivery key	The customer's request at the application boundary; it is not a Core identity.	Use the same tenant-scoped key and input fingerprint to detect an exact replay before another `runtime.run()`. Reject the same key with changed input.
Operation identity	One protected action proposal and its lifecycle, within its original action and tenant scope.	Keep its association with the original request and later related results. A new proposed action needs its own operation.
Effect identity	The particular external effect the independent verifier must read.	Use the original effect identity for authoritative lookup, live reconciliation, and accepted durable recovery.
Execution identity	The protected execution associated with that operation and effect.	Preserve the original execution binding in host evidence and check it when joining results or claims.
Provider attempt identity	The original dispatch attempt, supplied to `provider.dispatch`.	Save it with the dispatch binding before provider I/O. It is not the verifier callback's `attemptIdentity`, which Actions preview.8 supplies as the separate literal `"verification"` marker.

The package supplies the protected lifecycle identities; the host retains their exact relationship to its trusted request and business record. The verifier's marker describes a read, not the provider attempt that produced the effect. Compare an authoritative effect record with the saved original dispatch binding, including the provider attempt identity if the authoritative record carries it. Do not compare that record with the verifier callback marker. The selected HTTP reference preview.3 stores this binding before its synthetic provider POST; the lost-response example shows the read-back rule.

Recommended field inventory

At minimum, design for operation identity; effect identity; execution identity; attempt identity; tenant or account scope where applicable; grounded referent (the exact target) or bounded reference; evidence or snapshot reference; authorization decision reference; dispatch-boundary observation; provider observation category; verifier observation; finality decision (the rule that makes an observation decisive); normalized effect truth; safe-claim permission or public-result category; relation to an original UNKNOWN result and later reconciliation result; timestamps; omission or truncation markers; schema/version identifier; and retention and access-control metadata.

For example, a software product changing a customer’s billing contact can link the original request, authorization, provider attempt, verifier result, and later reconciliation in one durable action record. The authoritative customer-account system remains the owner of the actual billing contact. The record explains the operation; it does not become that business state.

For replay protection, persist a tenant-scoped request key, exact input fingerprint, admission state, and eventual immutable result before returning a duplicate response. An exact replay returns the retained response or bounded pending state without invoking the provider again; a changed-input replay conflicts. If a dispatch may already have happened, missing local response data is not permission to call runtime.run() again. The selected HTTP example demonstrates this with local single-writer storage; an integrating application must supply its own production storage, atomic admission, ownership and crash handling.

Keep sensitive and live state out

Do not store raw credentials, provider secrets, live reconciliation handles, unrestricted prompts or transcripts, raw provider payloads by default, another tenant’s identifiers, or private Runtime state. Do not treat diagnostic logs as business truth. Store bounded references and approved observations, with access controls and omission markers where detail is intentionally withheld.

Retention should follow the application’s approved operational, contractual, privacy, deletion, and legal policies. Do not promise “permanent” retention. Reconciliation is verifier-only follow-up for an unresolved effect. The same-process Actions path requires the exact returned UNKNOWN object; the post-process-loss path instead requires the closed v2 durable recovery record, accepted authority/source digest, and stable verifier binding. Durable data cannot reconstruct the live association or authorize redispatch.

Different operating responsibilities

For a Builder, one application database and focused structured logs may be enough. Stable identities, immutable result history, access control, and a defined retention policy still matter; enterprise tooling is not mandatory.

For Business, records may feed centralized operations, audit, security monitoring, case management, or SIEM. Use role-based access, tenant or business-unit scope, controlled exports, and formal retention/deletion policies. Trace and operational logs may have different audiences.

For a Product Maker, records must be tenant-isolated. Product support and customer-visible history are separate projections. Retention, deletion, regional storage, schema migration, access controls, and scale are product responsibilities. Customer history must not expose private Trace or provider payloads, and product telemetry must remain separate from authoritative effect truth.

The application is the software using AnswerUp. The host is the trusted runtime/backend environment operating the integration. The integration owner is the person or organization responsible for supplying and governing that integration. They may be the same organization, but the responsibilities should be named rather than assumed.

ProtectedActionStore and Runtime recovery

ProtectedActionStore is a design-level host contract. It is not automatically wired to Runtime durable recovery and does not provide persistence, recovery scheduling, authority acquisition, or CAS integration by itself.

Host-owned item	Required relationship
Lifecycle record	Retains the action and identity references plus immutable result history.
Original `UNKNOWN`	Remains an immutable entry; it is never overwritten by later evidence.
`DurableRecoveryRecordV2`	Stored as the closed verifier-only continuation record; it is not an Actions live result.
Accepted authority/source digest	Independently retrieved by `acquire` and compared with the exact source record.
CAS commit	Atomically accepts a terminal patch or replaces a continuing `UNKNOWN` with its next record and digest.
Related reconciliation result	Appended and linked to the original `UNKNOWN`, without changing the original or redispatching.

No raw provider payload, credential, callback, exception, private Runtime state, or live reconciliation handle belongs in these records.