Minimum incident telemetry should identify who or what initiated an operation, which version handled it, what state and dependency boundaries it crossed, what effect occurred, and how the operator verified recovery.
Identify the execution without storing the whole payload
Every event needs an event time, received time, environment, service and version, operation name, severity, trace and span identifiers, request or run identifier, and a pseudonymous tenant or account reference where the approved investigation requires one. Keep the original event source and schema version. Those fields let an operator join the path and detect clock or deployment changes without copying private prompts, documents, access tokens, or full customer records into the telemetry system.
For model operations, record the provider, model identifier, request attempt, latency, token counts when available, completion class, and provider request identifier. For tool operations, add the tool and schema version, authorization decision, target resource class, idempotency key, attempt, downstream response identifier, effect class, and result status. Sensitive arguments should be excluded, redacted, or replaced by approved categorical fields before durable storage.
Record state, retries, errors, and operator decisions
A workflow event should identify the prior state, new state, checkpoint, transition reason, and actor. Retry records need the error class, attempt number, backoff, next attempt time, maximum attempts, and terminal disposition. Errors need a stable grouping key plus the direct exception and affected operation. Preserve the successful work around the error so a partial-effect incident can be distinguished from a request that changed nothing.
Operator actions belong in the same incident path. Record who acknowledged the alert, which runbook version they used, which command or approved action they executed, what state existed beforehand, and how the result was verified. Google's incident-management guidance emphasizes a live incident document and retained state changes because coordination and later analysis both depend on a record that survives individual memory.
Apply retention and access to fields, not vague log classes
Map each field to its purpose, viewers, storage system, retention period, redaction rule, export, and deletion path. A trace identifier may remain useful longer than raw content. An error fingerprint may support recurrence analysis without keeping the original customer input. Test access and deletion against indexes and exports, then record dependencies whose retention the application cannot control.
Incident Recovery Record is installed by Reality Contact, LLC. The buyer decides lawful collection, retention, access, redaction, and deletion and may exclude fields even when they improve debugging. The implementation verifies the approved record in six scenarios; it does not replace privacy, security, legal, or regulatory review.
Where the service stops
Reality Contact, LLC installs bounded telemetry and recovery controls but does not provide forensic determinations, certify security or compliance, decide lawful retention, approve production access, or supply continuing incident response. The buyer approves the telemetry fields, redaction and retention rules, alert owners, recovery authority, scenarios, production credentials, and final deployment. This is technical implementation and incident-record preparation; it does not replace the buyer's legal, privacy, security, compliance, or forensic review. We do not promise complete telemetry, a single root cause, error-free recovery, continuous availability, or visibility into systems that do not expose records.
Sources: OpenTelemetry trace data and span semantics; Google SRE incident-management guidance.