Durable action records and logging

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. It is not automatically a durable hosted store, an authoritative business database, or claim permission by itself. Interactive Trace remains a future P3 surface.

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 that durable reconciliation is currently provided by Core.

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.

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.

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; a durable record may preserve its history, but it does not supply the live authority needed to perform that follow-up.

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.