[Observability] Audit cross-signal fields, error semantics and compatibility boundaries

[Tsukikage7]

Parent and scope

Parent roadmap: #3562, Workstream 1.

Extract the current-state audit from the ownership scope recorded in #3562 into an independently deliverable documentation task.

The 2026-09-05 weekly report still tracks observability as an umbrella activity. As of 2026-09-07, no separate public claim or open PR was found for this specific audit deliverable. This issue is initially unassigned; existing implementation ownership remains in place.

Deliverables

• Add a source-backed inventory of the current Metrics, Trace, Log and Metadata representations of service, method, protocol, side and error information. Record the actual key names and value sources; explicitly mark fields that are absent or not applicable.
• For each mapping, include the implementation location, signal-specific meaning, and relevant existing tests. Pin the audited revision and distinguish merged behavior from open PR proposals.
• Document low-cardinality metric dimensions versus high-cardinality diagnostic data, including trace/span IDs and free-form error text. Identify inconsistencies without changing exported behavior.
• List compatibility constraints for existing metric names/labels, trace attributes, configuration and logger behavior.
• Produce a compact follow-up matrix: observed gap, affected files, related issue/PR, existing owner where publicly recorded, and a concrete validation scenario.

Acceptance criteria

The documentation must be reviewable against a named repository revision. Every statement about existing behavior must have a code or test reference. Proposed semantics must be clearly separated from observed behavior; unresolved mappings remain explicit questions.

Use the current target branch at implementation time. The triage baseline is develop@5f54b6a8cc9702abb320aa324784176689878ed0 (2026-09-06). A reviewer should be able to select a field/error scenario and trace its current representation across the applicable signals.

Boundaries

Documentation only. Do not rename metrics, change label cardinality, implement a shared error-classification package, alter span lifecycle/propagation, or build dashboards.

Metrics implementation remains under #3337; tracing under #3338 / #3551; metadata under #3356 / #3499; default filter wiring and related protocol integration under #3568. Record overlaps for coordination rather than taking over those changes.

[AsperforMias]

ask for assign

[Tsukikage7]

@AsperforMias Thanks for volunteering! Please start with the field inventory and compatibility audit described in this issue. I’m happy to review your PR. Any implementation changes to rpc.service should be coordinated with #3551.