diff --git a/docs/src/SUMMARY.md b/docs/src/SUMMARY.md
index 9d1bdee78c..820786dcf5 100644
--- a/docs/src/SUMMARY.md
+++ b/docs/src/SUMMARY.md
@@ -19,4 +19,5 @@
 - [Doxygen](./doxygen.md)
 
 # Specifications
-- [Runtime Stitching](./specs/runtime-stitching.md)
+- [Template](./specs/specs.md)
+  - [Runtime Stitching](./specs/runtime-stitching.md)
diff --git a/docs/src/specs/runtime-stitching.md b/docs/src/specs/runtime-stitching.md
index dbefac6adf..390fa5bc39 100644
--- a/docs/src/specs/runtime-stitching.md
+++ b/docs/src/specs/runtime-stitching.md
@@ -1,11 +1,17 @@
 # Runtime Stitching
 
+Runtime stitching adds the ability for the runtime to stitch together multiple,
+indepently compiled programs together at runtime, ie. without compiler knowledge of
+how the binary programs will be composed.
+
+## Motivation
+
 In order to flexibly support arbitrary training schedules / composing multiple
 models together we want to have the ability for the runtime to stitch
 graphs together.  To achieve this we need to define an ABI kind of interface
 between the compiler and the runtime.
 
-## Simple Example
+### Simple Example
 ```
 mod_a = pybuda.compile(PyTorch_module_a)
 mod_b = pybuda.compile(PyTorch_module_b)
@@ -58,6 +64,11 @@ Compiler will decide where the tensors should live, host, device dram, device l1
 - Runtime will need to invoke `toLayout` on all input tensors before invoking
   the program.
 
+## Test Plan
+
+- Add a new test to the runtime gtest suite that verifies the runtime can
+  correctly stitch together 2 independently compiled programs.
+
 ## Concerns
 
 - Tensors pass through device memory spaces (dram, L1) will have a dynamic
diff --git a/docs/src/specs/specs.md b/docs/src/specs/specs.md
new file mode 100644
index 0000000000..93568262b2
--- /dev/null
+++ b/docs/src/specs/specs.md
@@ -0,0 +1,42 @@
+# Specifications
+
+Specifications are documents that define the requirements for features or
+concepts that are particularly cross-cutting, complex, or require a high degree
+of coordination and planning. They are intended to be a living document that
+evolves as the feature is developed and should be maintained as the goto
+reference documentation for the feature or concept.
+
+Specifications are written in markdown and are stored in the `docs/src/specs`
+directory of the repository. Below is a template that should be used when
+creating a new specification.
+
+## Specification Template
+
+```markdown
+# [Title]
+
+A brief description of the feature or concept that this specification is
+defining.
+
+## Motivation
+
+A description of why this feature or concept is needed and what problem it is
+solving. This section is best written by providing concrete examples and use
+cases.
+
+## Proposed Changes
+
+A list of the components that will be impacted by this spec and a detailed
+description of the changes that will be made to each respective component.
+
+It should also call out any interactions between components and how they might
+share an interface or communicate with each other.
+
+## Test Plan
+
+A brief description of how the feature or concept will be tested.
+
+## Concerns
+
+A list of concerns that have been identified during the design of this feature.
+```