diff --git a/docs/reference-architectures/cisco-ucs-llm-serving/README.md b/docs/reference-architectures/cisco-ucs-llm-serving/README.md
index 5319a031e..a01394fba 100644
--- a/docs/reference-architectures/cisco-ucs-llm-serving/README.md
+++ b/docs/reference-architectures/cisco-ucs-llm-serving/README.md
@@ -237,3 +237,5 @@ enough that dedicated GPU compute would sit largely idle between bursts, the CPU
 deployable option rather than a fallback of last resort. The GPU wins clearly on
 latency and throughput at scale; AMX makes the CPU competitive enough that the choice is
 meaningful rather than obvious.
+
+Both serving instances were provisioned through Spinifex's EC2-compatible endpoint as standard EC2 instance types — `m8i.2xlarge` for the CPU path, `g6.2xlarge` for the GPU path — with standard `aws ec2` CLI calls. Teams already operating AWS infrastructure can point their existing tooling at a Spinifex node with a single profile swap.
diff --git a/docs/reference-architectures/cisco-ucs-platform-benchmark/README.md b/docs/reference-architectures/cisco-ucs-platform-benchmark/README.md
index efac517b0..e370f5e53 100644
--- a/docs/reference-architectures/cisco-ucs-platform-benchmark/README.md
+++ b/docs/reference-architectures/cisco-ucs-platform-benchmark/README.md
@@ -235,3 +235,5 @@ for CPU-bound concurrent work is 2 worker processes per 8-vCPU instance before l
 degrades — confirmed as compute contention rather than a storage or network ceiling —
 while the GPU instance shows no strain through the full sweep, consistent with the L4
 sitting at 22–35% utilisation under a single worker.
+
+All benchmark instances were provisioned through Spinifex's EC2-compatible endpoint using standard `aws ec2` CLI calls — the same instance types, placement groups, and security groups that work on AWS work here unchanged. Teams already operating AWS infrastructure can point their existing tooling at a Spinifex node with a single profile swap.
diff --git a/docs/reference-architectures/cisco-ucs-vision-pipeline/README.md b/docs/reference-architectures/cisco-ucs-vision-pipeline/README.md
index 95969d445..dc3f6b983 100644
--- a/docs/reference-architectures/cisco-ucs-vision-pipeline/README.md
+++ b/docs/reference-architectures/cisco-ucs-vision-pipeline/README.md
@@ -233,12 +233,15 @@ model artefacts worth keeping should be copied to Predastore before running this
 
 ### 6. Conclusion
 
-This pipeline demonstrates a genuinely mixed CPU/GPU edge-AI workload — Intel
+This pipeline demonstrates a mixed CPU/GPU edge-AI workload — Intel
 AMX-accelerated detection and NVIDIA L4-accelerated captioning, running as independent
 EC2-compatible instances against a shared S3-compatible object store, on Cisco Unified Edge
 hardware managed entirely through standard AWS tooling. AMX delivers a real,
 accuracy-neutral 2.4–3x throughput gain on this hardware; the L4 leaves significant
 headroom at this workload's current scale; and streaming from a central bucket rather
-than a private local volume costs 59–62% throughput, precisely because each frame is a
-small, latency- rather than bandwidth-bound request — a concrete, measured answer to
-what "the edge-AI pipeline is S3-backed" actually costs, not just a claim that it works.
+than a private local volume costs 59–62% throughput, because each frame is a
+small, latency- rather than bandwidth-bound request. Teams already operating
+AWS infrastructure can point their existing tooling at a Spinifex node with a
+single profile swap — EC2 instances, Viperblock EBS volumes, Predastore S3
+buckets, and OVN VPC networking all provisioned from the same Terraform
+resources that work on AWS.