oc-signal-forge

Topics in the source

• Signal Forge
• /oc-signal — Command Reference
• Operating model — Designer → Builder → Evaluator
• Phase 0 — Frame (/oc-signal frame)
• Phase 1 — Designer (/oc-signal design)
• Phase 2 — Builder (/oc-signal build, /oc-signal harvest)
• Phase 3 — Evaluator (/oc-signal verify) — the signature gate
• Phase 4 — Wire (/oc-signal wire)

On first invocation, read references/orchestrator.md and follow its welcome protocol. Owns the backend of analytics: instrumentation design, the harvester / ingestion layer, the transform / middleware, the store, and — the part most analytics tooling skips — validation that the signal answers the question correctly, before it's ever exposed. The dashboarding front end already exists (oc-dash-forge); this is the skill that feeds it a number you can trust. The hard part of analytics is not laying pipe. It's proving the number is right. A pipeline that runs is not a pipeline that's correct, and a metric that's correct can still answer the wrong question — "active users" computed from raw page-loads is a perfectly accurate count of the wrong thing. Signal Forge exists because that silent failure mode is the default outcome of every dashboard built without an adversarial check between the data and the chart. So this is a -forge tri-agent harness. A Designer defines the metric and its instrumentation spec from the question it serves, a Builder implements the instrumentation + harvester + transform + store, and an Evaluator is skeptical about correctness — it tries to disprove the number

This is an excerpt. Refer to the complete source and its current requirements.