instrumentation

Using this skill: announce "Using instrumentation", make a todo per numbered step in ## Steps, and do not skip the gates. This skill's worth is its process, not a hand-reproduced outcome. If you were told to "run instrumentation", run it, do not improvise its result. (Suite standard: https://github.com/horizon-foundry/foundry/blob/main/reference/skill-authoring.md)

Overview

This is a ship gate, and its weight follows the project's declared release policy. The foundry skill owns what required, optional, and waived each do to a release; this skill produces the record they are scored against.

You cannot improve what you do not measure. Most instrumentation is added after the fact, as scattered capture() calls that never answer a real question. The discipline: decide what you need to learn first, instrument the whole path to it on one identity, make the capture reliable. Analytics that silently drops events or splits a user across two identities is worse than none: it produces confident, wrong funnels.

When NOT to use

System observability (errors, latency, saturation, alerting): a different question with its own discipline, assessed by production-audit's operability dimension; never folded into the event plan (see "Product analytics is not observability").
Choosing the product's success measure: the frame declares it; this skill derives activation from it and instruments the path.
Building or reviewing the surface that DISPLAYS the numbers (a dashboard, a report, an experiment read-out): readout. This skill ends when reliable events exist; whether a reader can act on them without being misled is a separate discipline with its own failure mode.
Scoring the instrumentation gate or issuing a ship verdict: foundry check cites the records; production-audit judges.