docs: route PyTorch compiler and checkpoint knowledge by scope

docs/reference-matrix.md

@@ -94,6 +94,16 @@ in (evidence/claim discipline, benchmark hygiene, RunSpec) — not an external
 mining source. The local sibling clone at `codex/skill-eval-bootstrap`
 (82218b4) is a **different fork lineage**; see §2.
 
+### PyTorch compiler and asynchronous-save responsibilities
+
+The [compiler/checkpoint scope map](../src/inferrsi/data/skill_library/README.md#pytorch-compiler-and-checkpoint-scope-routing)
+links the `f15b476814ebc5eade36fb40512e379ebf79dd60` technical-document dependency
+card with the separately inspected `7d239835e773c91689eb298692097f4a3340491f`
+DCP implementation readset and its independently retrieved live recipe.
+It preserves document versus implementation evidence, source/recipe dates and
+attribution, and different mutation, completion and measurement boundaries.
+The two sources do not establish a tested combined runtime stack.
+
 ### Reviewed systems-paper mechanisms
 
 `mined` below means pack-mediated extraction into the linked candidate artifacts.

docs/searchspace-matrix.md

@@ -313,6 +313,16 @@ English procedures. They do not qualify every backend listed by their upstream
 projects. Main-only contribution, dependency and peer material remains at its
 original owners rather than duplicated under local skills.
 
+## PyTorch compiler and checkpoint scope selection
+
+Use the [existing-owner scope map](../src/inferrsi/data/skill_library/README.md#pytorch-compiler-and-checkpoint-scope-routing)
+to distinguish CUDA compiler guards/capture/output lifetime from the DCP
+Accelerator staging-pause, RAM/Host snapshot and SSD/Storage save entries.
+The shared diagnostic questions are actual mutation/liveness and named timing
+boundaries; graph replay is not staging/upload completion, and DCP completion
+does not establish replay eligibility. Existing source-derived maturity and
+resource coverage remain unchanged; no combined protocol is introduced.
+
 ## Issue #27: Drama3 NPU readiness (guidance only, no new coverage)
 
 The [Drama3 NPU readiness supplement](drama3-npu-readiness.md) is a scoped task

src/inferrsi/data/knowledge_packs/README.md

@@ -15,6 +15,12 @@ Cache-DiT, for example, can also be a direct dependency of vLLM-Omni. Its entry
 is classified as a peer technique for this initial extraction; reclassify an
 entry when the learning use case changes instead of duplicating its claims.
 
+For `pytorch/pytorch`, the [compiler/checkpoint scope map](../skill_library/README.md#pytorch-compiler-and-checkpoint-scope-routing)
+relates the [compiler dependency card](dependency/pytorch/cuda/compiler/cudagraph-shapes-and-lifetimes.json)
+to the existing [DCP async-save owner](../skill_library/frameworks/pytorch/dcp-async-save-performance/SKILL.md),
+keeping its fixed implementation and live recipe separate from compiler
+documentation, with each owner's completion and version boundaries intact.
+
 ## Storage and compatibility
 
 ```text

src/inferrsi/data/skill_library/README.md

@@ -65,6 +65,30 @@ and server task/slot cancellation. Its pinned source contracts are untested nati
 existing owners. The [scope and source map](repositories/llama-cpp/audit-llama-runtime-state/SKILL.md#choose-the-scope)
 links all three responsibilities and their separate source snapshots.
 
+## PyTorch compiler and checkpoint scope routing
+
+Choose by the affected responsibility within `pytorch/pytorch`. The compiler
+dependency card and DCP procedure retain different source snapshots and
+completion contracts; their shared repository name does not make a tested stack.
+
+| Need | Existing entry | Retained evidence | Completion / applicability boundary |
+| --- | --- | --- | --- |
+| Inductor guards, capture shapes, replay addresses or live outputs | [Compiler dependency card](../knowledge_packs/dependency/pytorch/cuda/compiler/cudagraph-shapes-and-lifetimes.json) | Technical documents at `f15b476814ebc5eade36fb40512e379ebf79dd60`, accessed 2026-10-15; upstream-reported, imported/unverified | Compile/recompile guards, graph recording/replay and output lifetime are independent constraints; this is CUDA/compiler guidance |
+| Training-visible save pauses, snapshot buffers and cleanup | [DCP async-save procedure](frameworks/pytorch/dcp-async-save-performance/SKILL.md) and [source ledger](frameworks/pytorch/dcp-async-save-performance/references/sources.md) | Implementation at `7d239835e773c91689eb298692097f4a3340491f`, inspected 2026-10-15; candidate / empirical validation `not_run` | Preserve caller capture, staging, upload, cached-buffer reuse and caller-owned cleanup boundaries; writer completion is separate from backend durability and distributed recovery |
+| Tutorial examples and API/version differences | [DCP documentation/implementation reconciliation](frameworks/pytorch/dcp-async-save-performance/references/sources.md#documentation-matched-against-implementation) | Live async recipe retrieved 2026-10-15, with its own retained HTML hash and page metadata | The recipe's 2.4+ / 2.9+ labels do not identify the inspected main commit or establish a matching wheel; source notices and recipe attribution remain in the ledger |
+
+Known mutation and storage lifetimes are a shared diagnostic prerequisite,
+with different checks: the compiler card calls for retaining outputs across
+later calls and exercising input mutation; DCP locates the next mutation of checkpointed state
+and follows its [completion/lifetime contract](frameworks/pytorch/dcp-async-save-performance/SKILL.md#completion-and-lifetime-contract).
+Neither owner's completion event establishes the other's safe reuse or eligibility.
+
+Keep timing boundaries separate too: compiler checks distinguish cold cost,
+recompilation, capture and steady-state replay; DCP measures
+[caller, staging, upload and step time](frameworks/pytorch/dcp-async-save-performance/SKILL.md#evidence-to-request-in-a-separately-authorized-measurement),
+including first-use versus reused buffers. These are owner-specific checks,
+not a combined compiler/checkpoint calling protocol or compatibility result.
+
 ## Engine knowledge
 
 Five repository entry skills, 15 focused sub-skills and one research router