diff --git a/README.md b/README.md
index 1581353..efd4009 100644
--- a/README.md
+++ b/README.md
@@ -14,7 +14,7 @@ mdbook serve --open
 
 To submit new guidelines, file a PR. They should be
 
-- beneficial for { safety, COGs, maintenance },
+- beneficial for { safety, efficiency, maintenance },
 - agreeable to a majority of experienced (3+ years) Rust developers,
 - comprehensible to Rust novices (4+ weeks),
 - practically applicable in real world scenarios.
diff --git a/src/guidelines/README.md b/src/guidelines/README.md
index 763538c..05fa236 100644
--- a/src/guidelines/README.md
+++ b/src/guidelines/README.md
@@ -9,7 +9,7 @@ A collection of pragmatic design guidelines helping application and library deve
 We build on existing high-quality guidelines, most notably the [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/checklist.html),
 addressing topics often encountered by Rust developers. For a guideline to make it into this book, we expect it to meet the following criteria:
 
-- [ ] It positively affects { safety, COGs, maintenance }; i.e., it must where applicable
+- [ ] It positively affects { safety, efficiency, maintenance }; i.e., it must where applicable
   - [ ] promote **safety best-practices** and prevent sources of risk
   - [ ] lead to **high throughput**, **low latency**, and **low memory usage**
   - [ ] make code **readable and understandable**
@@ -41,7 +41,7 @@ spirit.
 
 ## Submitting New Guidelines
 
-Do you have a practical guideline that leads to better safety, COGS or maintainability? We'd love to hear from you!
+Do you have a practical guideline that leads to better safety, efficiency or maintainability? We'd love to hear from you!
 Here is the process you should follow:
 
 - Check if your guideline follows the [meta design principles](#meta-design-principles) above.
diff --git a/src/guidelines/performance/M-HOTPATH.md b/src/guidelines/performance/M-HOTPATH.md
index e6b3550..8ea42c2 100644
--- a/src/guidelines/performance/M-HOTPATH.md
+++ b/src/guidelines/performance/M-HOTPATH.md
@@ -5,7 +5,7 @@
 <why>To end up with high performance code.</why>
 <version>0.1</version>
 
-You should, early in the development process, identify if your crate is performance or COGS relevant. If it is:
+You should, early in the development process, identify if your crate is performance or efficiency relevant. If it is:
 
 - identify hot paths and create benchmarks around them,
 - regularly run a profiler collecting CPU and allocation insights,
diff --git a/src/guidelines/performance/M-THROUGHPUT.md b/src/guidelines/performance/M-THROUGHPUT.md
index 4d224c7..8a255d3 100644
--- a/src/guidelines/performance/M-THROUGHPUT.md
+++ b/src/guidelines/performance/M-THROUGHPUT.md
@@ -2,7 +2,7 @@
 
 ## Optimize for Throughput, Avoid Empty Cycles (M-THROUGHPUT) { #M-THROUGHPUT }
 
-<why>To ensure COGS savings at scale.</why>
+<why>To ensure efficiency at scale.</why>
 <version>0.1</version>
 
 You should optimize your library for throughput, and one of your key metrics should be _items per CPU cycle_.