Pillar — Observability

Prefix: OBS- Catalog: v1.1 deltas (additive to v1.0 Observability). What it measures: whether an agent can see a product portfolio as one system — joinable logs, traces that cross application boundaries, honest health probes, and error budgets per slice — without leaking secrets into the signal.

v1.0 already covers structured logging, error aggregation, distributed tracing, a health endpoint, metrics export, and SLOs. These v1.1 criteria close the gaps that appear once an agent is debugging a user journey that hops between applications in the same product. All checks are vendor-neutral: they describe capabilities, never a commercial observability product.

Criteria in this pillar

OBS-100 — Shared telemetry field schema

Level: 3 · Scope: portfolio · Check: deterministic
The portfolio publishes one schema for required log and span attributes (at minimum timestamp, severity, message, request or trace identifier, and application identifier). Every application emits those fields from its structured logger (OBS-010).
Rationale: agents correlating a failure across applications cannot join logs that use requestId in one slice and req_id in another. A shared schema is the join key.
Evidence expected: a committed schema (document or JSON Schema / OpenTelemetry semantic-convention subset); each application's logger config includes the required fields; a sample log line per application parses against the schema.

OBS-110 — Trace context propagates across applications

Level: 4 · Scope: portfolio · Check: deterministic
Requests that cross application boundaries carry a W3C traceparent (or equivalent OpenTelemetry context). Downstream applications continue the trace rather than starting an unrelated one. Logs emitted under the request include the same trace identifier (OBS-030).
Rationale: a portfolio is one product. Without propagated context, an agent debugging a slow user journey sees N disconnected traces and guesses at causality.
Evidence expected: inbound and outbound HTTP (or RPC) instrumentation injects and extracts trace context; a sample cross-application trace shows one trace identifier; log records on both sides include that identifier.

OBS-120 — Liveness and readiness are distinct

Level: 3 · Scope: application · Check: deterministic
The application exposes separate liveness and readiness (or equivalent) signals. Liveness answers "restart me"; readiness answers "do not send traffic yet". A single HTTP 200 on /api/health (OBS-040) does not satisfy this criterion.
Rationale: deploy gates and load balancers that share one health URL either kill a booting process or send traffic to a process that cannot serve. Agents wiring canaries need both answers.
Evidence expected: two routes or probe configs; readiness fails when a required dependency is down; liveness does not fail solely because a dependency is down; CI or deploy config uses both.

OBS-130 — Error budget visible per application

Level: 4 · Scope: portfolio · Check: manual
Service-level objectives (OBS-060) are measured per application. A portfolio view shows remaining error budget as k/n applications inside budget. A blended portfolio SLO that hides a burning slice does not satisfy this criterion.
Rationale: portfolio scoring (CSPC-31) is the unit. An agent deciding whether it is safe to ship needs the slice's budget, not an average that a healthy neighbour inflates.
Evidence expected: SLO document or dashboard with per-application budget; k/n view; alert or review cadence when a slice burns.

OBS-140 — Telemetry excludes secrets and raw personal data

Level: 4 · Scope: application · Check: deterministic
Logs, traces, and error reports MUST NOT emit secrets, session tokens, or raw personal data (email addresses, account numbers, health identifiers) in attributes or bodies. Redaction is configured at the SDK or a documented logging wrapper, not left to reviewers.
Rationale: observability that leaks credentials or personal data is an incident, not a signal. Agents copy whatever the logger already prints.
Evidence expected: redaction config or wrapper; a lint or test that fails known secret or personal-data field names; sample production-like log lines with those fields absent or hashed.

v1.0 Observability — the published OBS-010 through OBS-060 criteria.
v1.1 pillars — draft catalog, including these deltas and the six new pillar stubs.
v1.0 specification — the published standard.

Criteria in this pillar

Level: 3 · Scope: portfolio · Check: deterministic

The portfolio publishes one schema for required log and span attributes (at minimum timestamp, severity, message, request or trace identifier, and application identifier). Every application emits those fields from its structured logger (OBS-010).

Rationale: agents correlating a failure across applications cannot join logs that use requestId in one slice and req_id in another. A shared schema is the join key.

Evidence expected: a committed schema (document or JSON Schema / OpenTelemetry semantic-convention subset); each application's logger config includes the required fields; a sample log line per application parses against the schema.

Level: 4 · Scope: portfolio · Check: deterministic

Requests that cross application boundaries carry a W3C traceparent (or equivalent OpenTelemetry context). Downstream applications continue the trace rather than starting an unrelated one. Logs emitted under the request include the same trace identifier (OBS-030).

Rationale: a portfolio is one product. Without propagated context, an agent debugging a slow user journey sees N disconnected traces and guesses at causality.

Evidence expected: inbound and outbound HTTP (or RPC) instrumentation injects and extracts trace context; a sample cross-application trace shows one trace identifier; log records on both sides include that identifier.

Level: 3 · Scope: application · Check: deterministic

The application exposes separate liveness and readiness (or equivalent) signals. Liveness answers "restart me"; readiness answers "do not send traffic yet". A single HTTP 200 on /api/health (OBS-040) does not satisfy this criterion.

Rationale: deploy gates and load balancers that share one health URL either kill a booting process or send traffic to a process that cannot serve. Agents wiring canaries need both answers.

Evidence expected: two routes or probe configs; readiness fails when a required dependency is down; liveness does not fail solely because a dependency is down; CI or deploy config uses both.

Level: 4 · Scope: portfolio · Check: manual

Service-level objectives (OBS-060) are measured per application. A portfolio view shows remaining error budget as k/n applications inside budget. A blended portfolio SLO that hides a burning slice does not satisfy this criterion.

Rationale: portfolio scoring (CSPC-31) is the unit. An agent deciding whether it is safe to ship needs the slice's budget, not an average that a healthy neighbour inflates.

Evidence expected: SLO document or dashboard with per-application budget; k/n view; alert or review cadence when a slice burns.

Level: 4 · Scope: application · Check: deterministic

Logs, traces, and error reports MUST NOT emit secrets, session tokens, or raw personal data (email addresses, account numbers, health identifiers) in attributes or bodies. Redaction is configured at the SDK or a documented logging wrapper, not left to reviewers.

Rationale: observability that leaks credentials or personal data is an incident, not a signal. Agents copy whatever the logger already prints.

Evidence expected: redaction config or wrapper; a lint or test that fails known secret or personal-data field names; sample production-like log lines with those fields absent or hashed.