---
id: "question-semantic-debugging"
type: "open-question"
source_timestamps: ["§6.2"]
tags: ["future-direction", "debugging"]
related: ["concept-observability-side-effect", "concept-edit-source-principle"]
sources: ["paper"]
sourceVaultSlug: "icm-paper-folder-architecture-2026Jun02"
originDay: 2
---
# Can ICM provide traceability, not just observability?

## The question

ICM today offers **observability** (read any output) but **not traceability**: if a stage-3 phrase sounds wrong, there is **no direct way to trace it to its cause** (which reference file? which contract? which upstream output?). The practitioner does it manually.

## Resolution path

Build **source maps** connecting an output phrase back to:

- the specific instruction in a stage `CONTEXT.md`,
- the reference file (Layer 3) that produced it,
- the prior-stage artifact (Layer 4) it transformed.

In other words: **semantic debugging** — breakpoints, stack-traces, and source-map equivalents for *content* pipelines, paralleling compiler debug builds.

## Why it matters

This is the **machinery the [[concept-edit-source-principle]] needs** to be practical: editing source instead of output requires knowing which source. Closes ICM's biggest "glass-box" gap by strict governance definitions — see [[concept-observability-side-effect]] and [[contrarian-observability-free]].

Named in the paper as future work; would also strengthen any cross-model results from [[question-cross-model]].


## Related across days
- [[concept-edit-source-principle]]
- [[concept-observability-side-effect]]
- [[quote-edit-source]]
- [[open-arc-what-remains]]