← Back to catalogue
Published

Telemetry / Operational Signal

vr.wm-sft-017 · wm-sft-017-telemetry-operational-signal

Describe a typed operational signal record with source attribution, interpretation, collection qualifications and governed evidence use.

World Models Information and virtual systems INF.SFT.TEL
Bundle → Layer → Finding → QuestionsClassifiersWhat it isWhy it existsDistinguishing featuresWhat robots and AI may and may not doMoral aspectsOwnersLinks to other meta-modelsIdentity and identifiersDirect propertiesRecognitionCapabilities and actionsHazards and failure modesStandards and interfacesContext of useSources

Bundle → Layer → Finding → Questions Filled

3 bundles · 3 layers · 5 findings · 10 questions

Signal and source What signal is emitted and by which runtime.

Signal definition

Metric, log or trace type with its meaning.

Signal type and semantics

The name, type, unit and meaning of a signal.

  1. Is the signal a metric, log, trace or profile, and what does it measure or describe?
  2. Which unit and aggregation does a metric use?

Resource attribution

The service, deployment and runtime the signal belongs to.

  1. Which service, version and deployment emitted the signal?
  2. On which host, container or region did it run?
Collection pipeline How signals travel and are reduced.

Collection and sampling

Agents, collectors, sampling and retention.

Sampling and loss

How much of the signal is kept.

  1. Which sampling rate or rule applies to traces and logs?
  2. Were signals dropped or delayed in the pipeline?
Use in operations How signals drive alerts and objectives.

Alerting and objectives

Rules and objectives that consume the signals.

Alert rule

A condition on signals that triggers notification or action.

  1. Which alert rules use this signal, and what thresholds do they set?
  2. Which service level objective is measured from this signal?

Sensitive content

Personal or secret data inside signals.

  1. Do attributes or log lines carry personal data or secrets?
  2. Is such content redacted before the signal leaves the runtime?

Classifiers Filled

Family
World Models
Category
Information and virtual systems
Entry kind
entity
Navigation path
NAV.INF.SFT.TEL
Domain
INF.SFT.TEL
Industry
Cross-industry
Tags
telemetryoperationalsignalinf.sft.tel

What it is Filled

Telemetry is the stream of operational signals, mainly metrics, logs and traces, that running software emits about its own behaviour, tied to the runtime, service and deployment that produced it. It serves observing and operating systems in near real time; the long-term evidential record and the physical sensor readings of devices are separate subjects.

In scope

  • Record identity and typed metric/log/span interpretation
  • Source resource and time evidence, sampling and delivery qualifications
  • Local derivation, consumer references, access and disposition evidence

Out of scope

  • Runtime, deployment, network endpoint, service commitment and incident master lifecycles
  • Production collection, sampling configuration, export, alert routing, objective evaluation and response execution
  • Physical sensor/device master models and legally evidential archive systems
  • Full profiling payloads, continuous trace aggregates, universal telemetry ontology and executable protocol conformance

Why it exists Filled

Describe a typed operational signal record with source attribution, interpretation, collection qualifications and governed evidence use.

Distinguishing features Filled

  • It is emitted by running software about itself and is tied to a runtime and deployment.
  • It serves near-real-time operation; evidential retention belongs to the operational log record.
  • It combines metrics, logs and traces correlated by shared resource and trace identifiers.
  • Distinct from measurements of the physical world, which come from sensors and observation records.

What robots and AI may and may not do Filled

Must not

  • Change sampling, retention or alerting in production without authorisation.
  • Silence or acknowledge alerts to hide an ongoing incident.
  • Export telemetry containing personal data outside the permitted environment.
  • Emit or store credentials in signal attributes.

Only with a human decision

  • Changing alert routing or paging rules for production services.
  • Approving telemetry export to third parties.

May

  • Query metrics, logs and traces within granted scope to diagnose problems.
  • Correlate signals across services by trace and resource identifiers.
  • Propose alert thresholds and dashboards from observed baselines.
  • Flag signals that carry personal data or secrets.

Moral aspects Filled

  • Telemetry can reveal user behaviour and must be minimised and protected.
  • Missing or misleading signals delay detection of outages that affect many people.
  • Collecting everything has real cost and energy use; sampling choices are trade-offs.

Who is affected

  • End users of the observed services
  • Operators and on-call engineers
  • Service owners
  • Security teams

Owners Filled

Steward

The service owner, supported by the platform or site reliability team, answers for the signals and their use.

Roles

Service steward
Approve meaning, purpose and runtime bindings.
Telemetry custodian
Maintain local records and execute separately authorized retention workflows.
Evidence analyst
Interpret qualified views without treating missing signals as normal operation.
Privacy and access reviewer
Review sensitivity, recipient scopes and exceptional disclosure.
Profile maintainer
Version schemas and test conversions; no automatic production change authority.

Master systems

  • Observability platforms
  • Metrics stores
  • Tracing backends

Links to other meta-models Filled

aligned

  • WM-MAT-008 - Candidate registry parent: generic observation concepts align, but typed signal payload and operational occurrence identity remain local.
  • OpenTelemetry signal data models and OTLP - Selected conceptual and protocol mappings require pinned schemas and tested adapters before conformance claims.
  • W3C Trace Context and PROV-O - Use correlation and provenance concepts without claiming authentication, truth or executable ontology conformance.
  • RFC 5424 and RFC 3339 - Preserve protocol-specific source semantics and timestamp representation; no universal transport guarantee.

references

  • WM-SFT-010 - Runtime identity is externally mastered; keep a time-qualified binding, including unresolved state.
  • WM-SFT-009 - Deployment identity and lifecycle remain external; no deployment execution belongs here.
  • WM-SFT-018 - Optional backlink to a consumer of traffic evidence. Preserve the ledger direction WM-SFT-018 REFERENCE WM-SFT-017; no required reverse containment or exposure authority.
  • WM-SFT-016 - Reliability commitment and evaluator remain external; record only qualified evidence bindings.
  • WM-ACT-042 - Incident response may consume signal evidence; triage, paging and response execution stay external.

neighbor

  • WM-MAT-008 Observation / Measurement Record - Registry parent is reconciled as a candidate alignment. This root is an information entity with typed software operational evidence, not a physical measurement process.
  • WM-SFT-018 Network / Endpoint - The ledger has an inbound consumer reference to telemetry. Traffic and reachability evidence do not transfer endpoint lifecycle, exposure policy or authentication ownership here.
  • Runtime, deployment and reliability commitment - Bind external masters with observation-time evidence. No local operation changes runtime or evaluates objective compliance.
  • Operational log and evidential archive - A log occurrence is a supported signal class. Evidential preservation may reference it separately; near-real-time use does not impose a universal short retention period.
  • Profiles and physical sensors - The registry purpose bounds this draft to metrics, logs and traces. Profiles are deferred. Physical observations may be referenced but device mastery and physical measurement procedures remain external.

parent

  • WM-MAT-008

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • A signal is identified by its name and resource attributes such as service name, version and instance.
  • Traces and spans carry trace and span identifiers as defined by W3C Trace Context.

Direct properties not applicable Not applicable

Not applicable

Telemetry is information emitted by software; any physical units belong to the values it reports, not to the signal itself.

Recognition optional Filled

  • A telemetry signal is a time-stamped metric, log or span attributed to a running service.
  • Often confused with audit logs kept as evidence or with device sensor readings.

Capabilities and actions required Filled

  • Signals can be sampled, aggregated, correlated, alerted on and expired.
  • Signals can be enriched with deployment and resource attributes on collection.

Hazards and failure modes required Filled

  • Leakage of personal data or secrets through attributes and log lines.
  • Alert fatigue that hides important signals.
  • Blind spots when sampling or pipeline loss drop the relevant data.

Standards and interfaces required Filled

  • OpenTelemetry protocol and semantic conventions.
  • W3C Trace Context.
  • Prometheus exposition format for metrics.

Context of use required Filled

  • Used in software operations, incident response and service level management.
  • Where signals contain personal data, data protection law applies.

Sources Filled

  1. Metrics Data Model - OpenTelemetry project
  2. Logs Data Model - OpenTelemetry project
  3. Trace Context - World Wide Web Consortium
  4. The Syslog Protocol - Internet Engineering Task Force
  5. Tracing API - OpenTelemetry project
  6. OTLP Specification - OpenTelemetry project
  7. Resource SDK - OpenTelemetry project
  8. PROV-O: The PROV Ontology - World Wide Web Consortium
  9. Date and Time on the Internet: Timestamps - Internet Engineering Task Force
  10. Handling sensitive data - OpenTelemetry project
  11. OpenTelemetry Specification (Cloud Native Computing Foundation)

Open questions

  • Pin immutable technical source revisions and current errata, complete external HTTP checks and restore independent provider review before any canonical promotion.
  • Define conditional nested schemas and test fixtures for missing source time, reset counters, incompatible distributions, untrusted trace context, partial export, duplicate receipts, redaction and expiry.
  • Resolve adopter-specific master bindings, retention and privacy policies and test adapters against the chosen protocol versions.
  • Evaluate whether profiling or whole-stream/trace models need separately bounded extensions rather than expanding this record root.
  • Executable nested metric/log/span schemas, profile fixtures and tested adapters are not supplied.
  • Immutable source snapshots, errata and revision pins need coordinator verification.
  • Continuous profiling, complete trace graphs, workload-specific selection bias and statistical error estimators remain deferred.
  • Storage residency, lawful bases, retention periods and security controls require adopting-profile review.
  • No production runtime, collector or remote publication was tested.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-sft-017-telemetry-operational-signal/spec.yaml, ver-cy/world-models/card-supplements/wm-sft-017-telemetry-operational-signal.json