{
  "uid": "cogitave.learn.observability-and-reliability.instrument-for-observability",
  "kind": "moduleUnit",
  "href": "/modules/observability-and-reliability/instrument-for-observability/",
  "title": "Instrument for observability",
  "summary": "",
  "type": null,
  "products": [],
  "roles": [],
  "levels": [],
  "subjects": [],
  "headings": [
    "1. Three signals, one correlation",
    "2. SLIs measured on the real system",
    "3. AI and agent observability",
    "4. Propagation: bound to the Core model"
  ],
  "source": "Observability is the layer that **measures** the platform's performance claims;\nit is also where SOC 2 CC7 monitoring comes from. The\n[observability standard](../../../../standards/docs/standards/observability.md)\nis short and directive - this unit walks its four parts.\n\n## 1. Three signals, one correlation\n\nCogitave's telemetry is **OpenTelemetry-spec**: the collector and SDK conform to\nthe OpenTelemetry specification rather than importing a vendor agent. There are\nthree signals, correlated under one model:\n\n- **Traces** - the path of a request across services, span by span.\n- **Metrics** - numeric time series (latency, error counts, throughput).\n- **Logs** - structured, queryable event records.\n\nThe point of one correlation is that a single latency spike, its error log, and\nthe trace that produced it are the **same** record read three ways. The standard\nstates this as structured, queryable evidence: **every change, access, and\ninference is a traceable record**. When you instrument a service, you are not\nadding debug output - you are producing audit evidence.\n\n## 2. SLIs measured on the real system\n\nA **Service Level Indicator (SLI)** is a measured signal of health. The standard\ndefines the menu each service draws from:\n\n- **Latency** - p50 and p99 of the operation.\n- **Error rate** - the fraction of requests that fail.\n- **Availability** - the fraction of time the service is serving.\n\nThe measured targets are realistic, not aspirational: **single- to\nlow-double-digit millisecond p99** at the edge for a knowledge/MCP query, and\nns-class only for in-process operations. The standard's own rule is that\nns-class claims are in-process and **measured, never asserted**. When the error\nbudget behind an SLO is exhausted, that is the **release-freeze trigger** - the\nmechanism the next unit engineers into a policy.\n\n## 3. AI and agent observability\n\nBecause Cogitave is AI-native, telemetry covers a surface most observability\nstacks ignore. On top of the three signals, the standard requires:\n\n- **The agent trace** - each step and tool call an agent makes, so an agent run\n  is as inspectable as an HTTP request.\n- **Token and cost** per inference.\n- **Eval drift** and **hallucination / guardrail-violation** monitoring.\n\nCrucially, **inference records are kept as responsible-AI evidence** for\nISO/IEC 42001. An agent's behavior is not ephemeral; it is retained the way a\nfinancial transaction is. This is the same \"assume non-repudiation\" posture the\n[AGENTS floor](../../../../../AGENTS.md) sets for every action.\n\n## 4. Propagation: bound to the Core model\n\nThe last part is what makes the whole thing queryable. **All signals are bound to\nthe Cogitave Core model**, so telemetry is reachable from **MCP** - a human and\nan agent ask the same question of the same model and get the same answer. The\nstandard calls this **dogfooding observability**: the platform observes itself\nthrough the same interface it exposes to everyone else.\n\n> [!TIP]\n> When you instrument a new service, the checklist is short: emit all three\n> signals under one correlation, define at least the latency/error/availability\n> SLIs, add the agent trace and token/cost if it calls a model, and confirm the\n> signals land on the Core model so they answer from MCP. The standard is the\n> source of truth for each of these - link to it, do not reinvent it.\n",
  "partOf": "cogitave.learn.observability-and-reliability",
  "durationInMinutes": 7,
  "quiz": null
}