Observability

Type: types/tag-readme.md

Making otherwise hidden execution paths, system state, failures, and quality drift visible. Assign this tag when an artifact explains what evidence exposes such a condition, why available evidence cannot expose it, or how that evidence becomes inspectable. Describing a failure without addressing its visibility is insufficient. Evaluation asks what a check establishes; observability asks what can be seen or reconstructed. KB maintenance covers the actions taken to keep the KB healthy. Work on signals used by those actions may carry both tags.

Runtime visibility

• computational-model — inspectable orchestration is a precondition for seeing how a run actually progressed rather than inferring from the final artifact
• Designing a Memory System for LLM-Based Agents — bridges observability to memory: hidden fallback paths and degraded execution become extraction targets for maintenance and repair
• Final task success does not establish intended-path health — identical terminal outcomes cannot distinguish a healthy prescribed path from successful fallback without independent execution evidence
• Silent disambiguation is the semantic analogue of tool fallback — extends the same observability problem to underspecified specs: a useful artifact can hide that the contract did not determine the path and the runtime repaired it locally

Detection & Signals

• Quality signals for KB evaluation — catalog of weak signals that can make hidden quality changes visible enough to drive maintenance or learning loops
• Notes need quality scores to scale curation — compresses many weak signals into ranked note quality so curation effort goes where it matters
• Link graph plus timestamps enables make-like staleness detection — dependency-aware staleness detection turns silent drift into an explicit review queue
• Semantic review catches content errors that structural validation cannot — adversarial reading supplies visibility into content failures that deterministic validation never surfaces

Inspectable Artifact

• Inspectable artifact, not supervision, defeats the blackbox problem — representational form determines whether failures and drift can be inspected, diffed, tested, and verified at all

Related Tags

• KB maintenance — maintenance consumes the signals observability exposes
• Computational model — runtime architecture determines which state transitions are inspectable
• Learning theory — soft signals, oracle strength, and inspectable artifacts explain what observability can reliably support
• LLM reliability — error correction and verification theory explain how visible signals can become actionable

Other tagged notes

• Collection-as-artifact freshness - Proposal: register collection-maintenance targets with collection-text inputs for casebook-wide staleness without per-file dependency edges
• Factored dependency pairs for review freshness - Proposal: keep review dependencies factored as two-input pairs where that shape fits; type and collection pairs and cohort ack are shipped while a review target with more than two inputs remains
• Single-artifact review bundles still cut Claude costs substantially after cache-aware weighting - April 2-4, 2026 review telemetry reweighted with Anthropic Opus 4.6 prompt-caching prices still shows a substantial cost drop from the single-artifact bundle refactor
• Trace-learning techniques in related systems - Trace-learning systems compared on ingestion pattern, representational form, behavioral authority, artifact structure, and evidence tier across repo reviews and lightweight coverage