1. Capture runtime state

The goal is to handle capture runtime state as a traceable containerd activity. The solution must contain evidence and clearly separate host, containerd, CRI, OCI and Kubernetes.

Task

1. Read the matching reference file in docs/.
2. Pick a matching example from examples/.
3. Run only safe local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Write a short risk and cleanup note.

Acceptance Criteria

• Commands or model artifacts are reproducible.
• No production endpoints, credentials or nodes are used.
• Namespace, snapshotter, runtime or CRI context is explicit.
• Failures and boundaries are documented.

Submission

submission/
  evidence/
  notes.md
  cleanup.md

2. Read configuration

The goal is to handle read configuration as a traceable containerd activity. The solution must contain evidence and clearly separate host, containerd, CRI, OCI and Kubernetes.

Task

1. Read the matching reference file in docs/.
2. Pick a matching example from examples/.
3. Run only safe local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Write a short risk and cleanup note.

Acceptance Criteria

• Commands or model artifacts are reproducible.
• No production endpoints, credentials or nodes are used.
• Namespace, snapshotter, runtime or CRI context is explicit.
• Failures and boundaries are documented.

Submission

submission/
  evidence/
  notes.md
  cleanup.md

3. Explain namespace confusion

The goal is to handle explain namespace confusion as a traceable containerd activity. The solution must contain evidence and clearly separate host, containerd, CRI, OCI and Kubernetes.

Task

1. Read the matching reference file in docs/.
2. Pick a matching example from examples/.
3. Run only safe local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Write a short risk and cleanup note.

Acceptance Criteria

• Commands or model artifacts are reproducible.
• No production endpoints, credentials or nodes are used.
• Namespace, snapshotter, runtime or CRI context is explicit.
• Failures and boundaries are documented.

Submission

submission/
  evidence/
  notes.md
  cleanup.md

4. Check image and content model

The goal is to handle check image and content model as a traceable containerd activity. The solution must contain evidence and clearly separate host, containerd, CRI, OCI and Kubernetes.

Task

1. Read the matching reference file in docs/.
2. Pick a matching example from examples/.
3. Run only safe local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Write a short risk and cleanup note.

Acceptance Criteria

• Commands or model artifacts are reproducible.
• No production endpoints, credentials or nodes are used.
• Namespace, snapshotter, runtime or CRI context is explicit.
• Failures and boundaries are documented.

Submission

submission/
  evidence/
  notes.md
  cleanup.md

5. Evaluate snapshotter risk

The goal is to handle evaluate snapshotter risk as a traceable containerd activity. The solution must contain evidence and clearly separate host, containerd, CRI, OCI and Kubernetes.

Task

1. Read the matching reference file in docs/.
2. Pick a matching example from examples/.
3. Run only safe local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Write a short risk and cleanup note.

Acceptance Criteria

• Commands or model artifacts are reproducible.
• No production endpoints, credentials or nodes are used.
• Namespace, snapshotter, runtime or CRI context is explicit.
• Failures and boundaries are documented.

Submission

submission/
  evidence/
  notes.md
  cleanup.md

6. Analyze CRI failure mode

The goal is to handle analyze cri failure mode as a traceable containerd activity. The solution must contain evidence and clearly separate host, containerd, CRI, OCI and Kubernetes.

Task

1. Read the matching reference file in docs/.
2. Pick a matching example from examples/.
3. Run only safe local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Write a short risk and cleanup note.

Acceptance Criteria

• Commands or model artifacts are reproducible.
• No production endpoints, credentials or nodes are used.
• Namespace, snapshotter, runtime or CRI context is explicit.
• Failures and boundaries are documented.

Submission

submission/
  evidence/
  notes.md
  cleanup.md

7. Review registry hosts.toml

The goal is to handle review registry hosts.toml as a traceable containerd activity. The solution must contain evidence and clearly separate host, containerd, CRI, OCI and Kubernetes.

Task

1. Read the matching reference file in docs/.
2. Pick a matching example from examples/.
3. Run only safe local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Write a short risk and cleanup note.

Acceptance Criteria

• Commands or model artifacts are reproducible.
• No production endpoints, credentials or nodes are used.
• Namespace, snapshotter, runtime or CRI context is explicit.
• Failures and boundaries are documented.

Submission

submission/
  evidence/
  notes.md
  cleanup.md

8. Document security decision

The goal is to handle document security decision as a traceable containerd activity. The solution must contain evidence and clearly separate host, containerd, CRI, OCI and Kubernetes.

Task

1. Read the matching reference file in docs/.
2. Pick a matching example from examples/.
3. Run only safe local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Write a short risk and cleanup note.

Acceptance Criteria

• Commands or model artifacts are reproducible.
• No production endpoints, credentials or nodes are used.
• Namespace, snapshotter, runtime or CRI context is explicit.
• Failures and boundaries are documented.

Submission

submission/
  evidence/
  notes.md
  cleanup.md

9. Create evidence package

The goal is to handle create evidence package as a traceable containerd activity. The solution must contain evidence and clearly separate host, containerd, CRI, OCI and Kubernetes.

Task

1. Read the matching reference file in docs/.
2. Pick a matching example from examples/.
3. Run only safe local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Write a short risk and cleanup note.

Acceptance Criteria

• Commands or model artifacts are reproducible.
• No production endpoints, credentials or nodes are used.
• Namespace, snapshotter, runtime or CRI context is explicit.
• Failures and boundaries are documented.

Submission

submission/
  evidence/
  notes.md
  cleanup.md

10. Describe cleanup

The goal is to handle describe cleanup as a traceable containerd activity. The solution must contain evidence and clearly separate host, containerd, CRI, OCI and Kubernetes.

Task

1. Read the matching reference file in docs/.
2. Pick a matching example from examples/.
3. Run only safe local or model-based steps.
4. Collect evidence below submission/evidence/.
5. Write a short risk and cleanup note.

Acceptance Criteria

• Commands or model artifacts are reproducible.
• No production endpoints, credentials or nodes are used.
• Namespace, snapshotter, runtime or CRI context is explicit.
• Failures and boundaries are documented.

Submission

submission/
  evidence/
  notes.md
  cleanup.md

Official Sources and Boundary

• containerd documentation, getting started and configuration: https://containerd.io/docs/2.3/getting-started/
• containerd registry hosts.toml: https://github.com/containerd/containerd/blob/main/docs/hosts.md
• containerd runtime v2 and shim model: https://github.com/containerd/containerd/blob/main/docs/runtime-v2.md
• Kubernetes container runtimes: https://kubernetes.io/docs/setup/production-environment/container-runtimes/
• Kubernetes Container Runtime Interface: https://kubernetes.io/docs/concepts/containers/cri/
• OCI Image Specification: https://github.com/opencontainers/image-spec
• OCI Runtime Specification: https://github.com/opencontainers/runtime-spec
• Open Container Initiative: https://opencontainers.org/

This workshop does not introduce a containerd API. It maps official concepts into labs, review questions and operational workflows. When a file describes a model, it is explicitly framed as a model or lab artifact.

Practice Appendix: containerd Evidence for this exercise

This appendix connects the file with repeatable runtime evidence. It is deliberately practical: every statement should map to a concrete layer, artifact, impact and operational decision.

A.1 Layer Model

containerd must be understood as runtime layer: host, systemd, containerd daemon, plugins, content store, snapshotter, runtime v2, shim, runc, CRI, CNI and Kubernetes all have different responsibilities.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.2 Daemon and Socket

The containerd daemon exposes a gRPC API through a Unix socket. Changes to the socket, permissions or service determine which tools and orchestrators can talk to the runtime.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.3 Plugin System

containerd loads functionality through plugins. CRI, snapshotters, diff service, content service, runtime task service and image verification must be evaluated through the active plugins.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.4 Content Store

The content store keeps OCI content by digest. Tags are names; digests are content addresses. This separation is central for reproducibility and supply-chain review.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.5 Snapshotter

Snapshotters create usable root filesystems from image layers. OverlayFS is the common default, while remote snapshotters such as Stargz or Nydus change startup time, IO behavior and failure modes.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.6 Container and Task

A container is a metadata object; a task is the running execution. Many debugging mistakes come from mixing these two layers.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.7 Runtime v2 and Shim

containerd starts containers through runtime-v2 shims. The shim preserves IO, exit status and process relationship and partially decouples running tasks from the containerd daemon.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.8 OCI Runtime

runc or alternative runtimes implement the OCI Runtime Specification. They start the isolated process with namespaces, mounts, cgroups and security profiles.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.9 CRI

Kubernetes does not talk directly to ctr; it talks CRI. crictl is often better for node diagnosis, while ctr works deeper inside containerd.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.10 CNI

containerd is not the full Kubernetes network. During pod startup the CRI layer calls CNI plugins that configure network namespace, IPAM, routes and port mapping.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.11 Registry and Resolver

Registry behavior is controlled through resolver, host namespace and hosts.toml. Mirror, TLS, authentication and capabilities must be reviewed separately.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.12 Cgroups and Systemd

On systemd hosts, kubelet and runtime should use a consistent systemd cgroup model. Mixed cgroup drivers lead to hard-to-debug node problems.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.13 Namespaces

containerd namespaces are metadata namespaces, not Linux namespaces. Kubernetes typically uses k8s.io; direct ctr experiments should use dedicated namespaces.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.14 Rootless

Rootless containerd reduces some host risks, but has clear limits around networking, cgroups, storage and Kubernetes integration. Rootless is an operating model, not a blanket security promise.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.15 Image Trust

Signatures, verification, SBOM and vulnerability scanning are supply-chain controls. They must be integrated before pull, before start or through admission and policy mechanisms.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.16 Security Profiles

Seccomp, AppArmor, SELinux, capabilities and RuntimeClass limit container behavior. These controls complement each other, but do not replace safe images or host hardening.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.17 Garbage Collection

Garbage collection must not only look at free disk space. Content, snapshots, images, containers, tasks and leases must be evaluated together to avoid damaging active workloads.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.18 Observability

Good runtime diagnosis collects versions, service status, logs, events, plugins, namespaces, registry failures, snapshotter state and CRI output as one evidence package.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.19 Upgrade and Rollback

Runtime upgrades affect running workloads and Kubernetes nodes. A safe path includes backup, drain, version test, service restart, smoke test, rollback and post-change review.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.20 Incident Response

Registry outage, TLS errors, pull rate limits, damaged snapshots or runtime failures need separate runbooks. An incident ends only when cause, workaround, fix and prevention are documented.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.21 Model and Reality

Many examples are safe models. Transfer to real nodes needs additional review: distribution, containerd version, Kubernetes version, CNI, registry, security policy and change process.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.22 Evidence

Evidence contains command output, configuration, logs, hashes, versions and review notes. It does not contain production secrets, tokens, client certificates or pull credentials.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.23 Performance

Performance depends on snapshotter, registry latency, layer structure, deduplication, filesystem, IO, CPU, cgroups and remote snapshotters. Every optimization needs a measurement goal.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.24 Production Transfer

Production transfer is not copying lab files. It needs ownership, change ticket, rollback, monitoring, security approval, maintenance window and documented acceptance criteria.

This perspective must become concrete in review. A generic sentence such as "check runtime" is not enough; expected evidence names the tool, file, risk and decision.

Concrete review questions:

• Which runtime layer is affected?
• Which file or output supports the statement?
• Is the behavior containerd directly, CRI, OCI, CNI or Kubernetes?
• Which change would be risky on a production node?
• Which rollback option exists?
• Which evidence must not contain secrets?
• Which versions must be named?
• Which acceptance check proves success?

Typical evidence:

evidence/
  tooling.txt
  runtime-layer.md
  config-or-model.txt
  risk-note.md
  rollback.md

A.25 Minimal Completion Evidence

• containerd, ctr and runc versions are documented where installed.
• Scope is clearly described as model, local host or Kubernetes node.
• TOML, YAML, JSON and shell artifacts are syntactically validated.
• Registry, runtime, snapshotter or CRI changes have a rollback note.
• Evidence contains no production credentials.
• Official sources are referenced and not replaced by invented assumptions.