Trace

What Trace is

Trace is a bounded, read-only view of an operation's lifecycle. It is a bounded flight recorder: it helps a developer or operator see which stages occurred, where uncertainty entered, and which observations supported the result. Core defines the projection contract; the host decides how an approved projection is stored and exposed.

Trace is intentionally smaller than private Runtime state. An approved projection may contain:

• preparation and candidate derivation;
• authorization;
• credential acquisition and cleanup markers;
• the dispatch boundary;
• provider observation;
• mutation observation;
• verifier read;
• finality and effect truth;
• reconciliation;
• operation, execution, and attempt identities where approved;
• dispatch, mutation, verifier-read, and redispatch counters;
• omission, truncation, overflow, or incomplete-evidence markers.

What it can show

Trace can connect lifecycle observations without turning them into a new source of authority. It can show that preparation and authorization preceded a dispatch boundary, that a provider acknowledged a request, that an independent verifier returned evidence, and that reconciliation was projected with the original result preserved. The result taxonomy remains:

• PRESENT means COMMITTED;
• ABSENT_FINAL means DISPROVED;
• INDETERMINATE means UNKNOWN.

Provider acknowledgment remains separate from effect truth. Provider and verifier are independent boundaries. Reconciliation is verifier-only with zero provider redispatch, and original results remain immutable.

What it cannot establish

Trace is not an authoritative inventory, ledger, schedule, directory, or other system of record. ACKNOWLEDGED in Trace is not COMMITTED, and a missing field is not proof that a stage did not happen. Trace does not evaluate whether an expectation passed; that belongs to Evaluator. It does not authorize customer-facing wording; effect truth and claim permission do that. It is not a replayable command.

Reading a projection can explain an outcome, but it does not authorize another action. A Trace view is not external truth, and it is not a promise that a hosted Trace product is available.

Reading counters

One dispatch, one verifier read, and zero redispatches can show how the protected lifecycle behaved. They support the conclusion that this flow followed the no-blind-redispatch rule; they do not prove exactly-once execution by the external provider. An absent cleanup marker is incomplete evidence to investigate, not proof of credential leakage or successful cleanup.

Catalog-price example

Consider a merchant administration UI calling an authenticated application backend. The backend binds an exact product and price, then uses a catalog provider adapter. An independent catalog verifier reads the authoritative commerce catalog. The host exposes only the approved bounded Trace projection.

The product is grounded and authorization passes. Dispatch crosses once, and the provider acknowledges. The authoritative catalog read is INDETERMINATE, so the normalized result is UNKNOWN; redispatch remains zero. Trace explains why the result is UNKNOWN, but Trace itself does not prove that the price changed.

Privacy and operational ownership

Core owns the bounded, read-only projection contract. The host or application owns storage, access, retention, deletion, export, and redaction. Operator Trace remains separate from customer-facing output. Conformance exports remove personal data, credentials, and raw provider payloads while preserving the bounded evidence needed for the declared run. See Security and privacy for the data path and trust-boundary responsibilities.

Current availability note

The Trace contract is documented, but the shared portal authority marks the Trace surface P3, planned, and not live. Read this page as an architectural contract and evidence boundary, not as an announcement of a public hosted Trace surface.