diff --git a/contributors/design-proposals/architecture/architecture.md b/contributors/design-proposals/architecture/architecture.md
index 367d7e20b..182d1d1c5 100644
--- a/contributors/design-proposals/architecture/architecture.md
+++ b/contributors/design-proposals/architecture/architecture.md
@@ -214,7 +214,7 @@ agent.
 Each node runs a container runtime, which is responsible for downloading images and running containers.
 
 Kubelet does not link in the base container runtime. Instead, we're defining a
-[Container Runtime Interface](container-runtime-interface-v1.md) to control the
+[Container Runtime Interface](/contributors/devel/container-runtime-interface.md) to control the
 underlying runtime and facilitate pluggability of that layer.
 This decoupling is needed in order to maintain clear component boundaries, facilitate testing, and facilitate pluggability.
 Runtimes supported today, either upstream or by forks, include at least docker (for Linux and Windows), 
diff --git a/contributors/design-proposals/auth/apparmor.md b/contributors/design-proposals/auth/apparmor.md
index 34ecf978e..a88154bb1 100644
--- a/contributors/design-proposals/auth/apparmor.md
+++ b/contributors/design-proposals/auth/apparmor.md
@@ -268,7 +268,7 @@ already underway for Docker, called
 ## Container Runtime Interface
 
 Other container runtimes will likely add AppArmor support eventually, so the
-[Container Runtime Interface](container-runtime-interface-v1.md) (CRI) needs to be made compatible
+[Container Runtime Interface](/contributors/devel/container-runtime-interface.md) (CRI) needs to be made compatible
 with this design. The two important pieces are a way to report whether AppArmor is supported by the
 runtime, and a way to specify the profile to load (likely through the `LinuxContainerConfig`).