Catalog runtime evidence

You authored a prompt three weeks ago. Is anything still calling it? Open it in Catalog and the Observability section shows exactly which runs referenced it, joined by real runtime identity instead of name matching, so the count you see is one you can trust.

See the runs behind a definition

1. Run crux dev and open the definition in Catalog.
2. Scroll to its Observability section: latest run status, timestamp, and delivery-health badge.
3. Click View N runs to open Runs pre-filtered to that definition.

Zero activity is a real state, not a broken link: View N runs appears only when the server rollup reports at least one run, and a definition that has never been referenced says so plainly (No runs have referenced this definition yet.).

What you'll see

The section adapts to what Crux can truthfully prove for the definition's kind:

• Direct activity: the runtime recorded this definition's exact authored id on runs. You get status, timing, delivery health, and View N runs.
• Contributor: the definition (a knowledge base, tool policy, or structural child) contributed to runs it does not own. Catalog shows Referenced by N runs, or reports the indexed parent's activity while stating the child was not independently observed.
• Runtime-observed, unjoined: the kind's primitives appear in Runs (deferred work, media operations, ingest sources), but normal runtime records cannot observe the authored local identity. Catalog names the relevant primitives and withholds per-definition counts rather than guessing.
• Eval-primary: scorers correlate through the Eval join; a live scoring.judge span still surfaces when an authored judge({ id }) ran.
• No runtime: static or declarative definitions show no fabricated counts and no dead links.

Run Detail links back

Run Detail lists every definition reference on the run or span. When the run's exact (projectId, manifestId) artifact is available, ids resolve against that historical Catalog even if the current source was renamed or deleted. A missing manifest or missing definition remains explicitly unresolved; Crux never substitutes the current checkout. Current-Catalog comparison is shown separately, and historical ids still filter the Runs list.

Run Detail also has a separate Current project health card. At read time, Crux Local correlates the run's recorded DefinitionRef values with active and suppressed lint findings in the currently materialized Project Index. This is current authored context, not historical run evidence: it does not claim that a suppression happened during execution, does not create a suppression span, and cannot change the run's success or failure status.

The card preserves matched definition roles and relationships and keeps active and suppressed totals separate. A definition links back to Catalog only when it resolves in the current Catalog and has a supported Catalog kind; unresolved or unsupported definitions remain plain, non-navigable evidence. Suppressed rows remain visibly tagged and show the finding source separately from the directive location, scope, and optional reason. A reasonless directive still renders as no reason recorded. If no Project Index is available, the context is absent rather than treated as a run error.

Bounded media Runs follow the same exact-identity rule. If the runtime genuinely holds and records one media.operation DefinitionRef, Run Detail can navigate to that Catalog source. Most direct streamImage()/streamSpeech() call sites do not expose their compiler-local identity at runtime, so the link honestly says unavailable. Conflicting exact refs are ambiguous. Operation name, provider, model, span name, and source coordinates are never fuzzy join keys.

Catalog Health uses the same active-versus-suppressed distinction. Its badges, severity, rule, affected-definition, and default verdict counts are active-only, while suppressed rows remain available for audit. See Index Lint.

Authored and observed execution evidence

Catalog gives a statically valid evidence.record() call its own definition, source location, diagnostics, role/kind coverage, and proven subject relation. It deliberately omits payloads, conclusions, and idempotency values. The definition means “this source can author a claim,” not “the claim was recorded” or “the claim is true.”

When Local has observed evidence for a related canonical subject, Catalog can navigate to the filtered Runs view. Run Detail then uses the durable evidence read model to show conclusions, conflicts, explicit supersession/history, payload availability, and retained producer/source navigation. Historical DefinitionRefs stay historical; a separate Catalog action may attempt to open the current definition with the same stable ID.

Honest gaps

Crux only joins when the runtime already holds a real compiled definition handle; it never invents an id from a stack trace, so a few kinds stay truthfully uncounted:

• Anonymous or non-literal definitions simply omit the ref.
• Injectables and storage ports have no canonical runtime identity, so Catalog never selects an arbitrary owner for them.
• File-loaded skills without a registry composite id do not invent a join key; registry-loaded skills do join.
• Compositions (parallel / pipeline / swarm / consensus) need an authored id so runtime and index share the same identity.

The join envelope (DefinitionRef), the coverage manifest, runtimeIdentity treatments, and the plane-ownership model live in the Observability reference.

For status vocabulary and delivery health on those runs, see Runs and delivery health.

Related

• Devtools: dashboard surfaces
• Execution evidence
• Runs and delivery health
• Privacy: DefinitionRef.source sanitization
• Troubleshooting: "why doesn't my definition show runs?"