# Observe a call without confusing it with approval

Use traces and outcomes to diagnose execution, and keep durable evidence requirements explicit.

Source context: Source-guided
Source: https://github.com/lssm-tech/contractspec/blob/d58fa5b7de53a947811e5cc68346be028ce18528/packages/foundation/contracts-runtime-kernel/src/operations/invoke.ts

## Carry context through the call

A useful operation trace lets you connect a request, its selected contract version, the handler outcome and the interface that invoked it. The registry's canonical result can carry trace and source context supplied by the host.

Use those identifiers to follow a failure across layers. Keep diagnostic details bounded and avoid collecting raw inputs merely because they are available to the handler.

## Understand the telemetry path

The inspected invocation path can emit configured success and failure telemetry through a host-supplied telemetry context. It checks the operation's data-handling configuration and can redact declared transient fields before computing telemetry properties.

Telemetry errors are handled as best effort so they do not automatically fail the business handler. That is useful for operations monitoring, but it means a telemetry event is not automatically a durable record of every effect.

At this snapshot, success telemetry is emitted after the handler returns but before output validation. Use the final canonical operation result when counting completed successes; a handler event alone does not establish that the returned value passed the contract boundary.

| Evidence | Useful for | Do not treat it as |
| --- | --- | --- |
| Trace/source identifier | Following one invocation | An authorization grant |
| Telemetry event | Behavior and failure monitoring | Guaranteed durable audit persistence |
| Approval receipt | Evidence checked at an execution boundary | A general-purpose reusable permission |
| Durable host record | Accountability and recovery according to host design | Something created merely by declaring an audit intent |

## Make denials visible

Record the meaningful failure category and operation identity for denied requests. For an approval demo, show the missing-receipt reason alongside the handler invocation count. That makes the boundary understandable without inventing a successful effect.

When a request is denied before handler entry, distinguish it from a business failure after execution began. The recovery action is different: fix context or satisfy an authorized approval path in the first case, investigate the implementation or provider in the second.

## Review the operational path you depend on

If the product requires durable audit or cost evidence, choose and test the host persistence path explicitly. Include a failure or retry case and verify how the record relates to the business mutation.

Use the smallest evidence needed to support the claim. A source declaration, a fixture trace and a live environment qualification each answer different questions; label them accordingly in examples and runbooks.

## Related examples

- [Review an agent's migration proposal](https://lssm.co/examples/release-steward/): Follow a deterministic release migration through scoped subagents, digest-bound approval, and a draft PR receipt.