diff --git a/.vitepress/theme/components/UnderConstruction.vue b/.vitepress/theme/components/UnderConstruction.vue
index a8afef78e..f197a936d 100644
--- a/.vitepress/theme/components/UnderConstruction.vue
+++ b/.vitepress/theme/components/UnderConstruction.vue
@@ -1,6 +1,6 @@
 <template>
   <Badge
-    type="warning"
+    type="info"
     text="Under Construction"
     title="This section is under construction and may not be complete. Check back later for updates..."
   />
diff --git a/about/bad-practices.md b/about/bad-practices.md
index 4755171fc..48aa9f892 100644
--- a/about/bad-practices.md
+++ b/about/bad-practices.md
@@ -8,25 +8,17 @@
 
 
 
-## Questionable Prior Arts
+## Questionable Prior Arts <UnderConstruction/>
 
-<UnderConstruction/>
-
-### DAOs, DTOs, Active Records
-
-<UnderConstruction/>
+### DAOs, DTOs, Active Records <UnderConstruction/>
 
 - → see [Best Practices / Passive Data](best-practices#data)
 
-### Object-Relational Mappers
-
-<UnderConstruction/>
+### Object-Relational Mappers <UnderConstruction/>
 
 - → see [Best Practices / Querying](best-practices#querying)
 
-### BO-centric Frameworks
-
-<UnderConstruction/>
+### BO-centric Frameworks <UnderConstruction/>
 
 ... which bypass or are in conflict with CAP's [key design principles](bad-practices.md), for example:
 
@@ -35,9 +27,7 @@
 
 These would be in conflict with CAP's focus on stateless services processing passive data, as well as with the querying-based approach to read and write data.
 
-### Determinations & Validations
-
-<UnderConstruction/>
+### Determinations & Validations <UnderConstruction/>
 
 - This might be a special thing if you come from a background where these terms were prominently positioned, accompanied by corresponding frameworks
 - Quite likely that is an SAP background, as we didn't find the term "determination" used outside of these SAP circles in that context
@@ -46,9 +36,7 @@ These would be in conflict with CAP's focus on stateless services processing pas
 - CAP does provide declarative element-level validations though → these are advisable, as we can optimize the implementations behind the scenes, which is just not possible in the imperative call-level frameworks.
 -
 
-### Sticking to DIY (or NIH)
-
-<UnderConstruction/>
+### Sticking to DIY (or NIH) <UnderConstruction/>
 
 Such as...
 
@@ -60,25 +48,19 @@ Such as...
 Doing so would spoil the party, for example regarding rapid local development at minimized costs, fast test pipelines, late-cut µ services.
 It would also expose your projects to risks of disruptions by changes in those rather volatile technologies.
 
-### Always done it this way
-
-<UnderConstruction/>
+### Always done it this way <UnderConstruction/>
 
 - and CAP is different... for a reason, or more... ;-)
 
 
 
-## Abstracting from CAP
-
-<UnderConstruction/>
+## Abstracting from CAP <UnderConstruction/>
 
 - CAP already provides abstractions from the underlying database, the protocols, the deployment target, the client technology, and more.
 - CAP is also an implementation of Hexagonal Architecture, which is an abstraction of the same kind.
 - So, abstracting from CAP would be abstracting from an abstraction, which is a bad idea in general, and certainly will ensure that you won't benefit from the full power of CAP, any longer.
 
-### Squared Hexagons
-
-<UnderConstruction/>
+### Squared Hexagons <UnderConstruction/>
 
 - As documented in the best practices guide, CAP is not only very much in line with Hexagonal Architecture, it actually *is an implementation* of it.
 - So there's little need to invest into the outer hexagon → focus on the inner one
diff --git a/about/index.md b/about/index.md
index 0ce9c2442..802eed59a 100644
--- a/about/index.md
+++ b/about/index.md
@@ -2,7 +2,7 @@
 status: released
 ---
 
-# About CAP
+# Introduction to CAP
 
 Value Propositions {.subtitle}
 
@@ -14,7 +14,7 @@ Value Propositions {.subtitle}
 
 The _Cloud Application Programming Model_ (CAP) is a framework of languages, libraries, and tools for building *enterprise-grade* cloud applications. It guides developers along a *golden path* of **proven best practices**, which are **served out of the box** by generic providers cloud-natively, thereby relieving application developers from tedious recurring tasks.
 
-In effect, CAP-based projects benefit from a primary **focus on domain**, with close collaboration of developers and domain experts, **rapid development** at **minimized costs**, as well as **avoiding technical depts** by eliminating exposure to, and lock-ins to volatile low-level technologies.
+In effect, CAP-based projects benefit from a primary **focus on domain**, with close collaboration of developers and domain experts, **rapid development** at **minimized costs**, as well as **avoiding technical debts** by eliminating exposure to, and lock-ins to volatile low-level technologies.
 
 
 
@@ -44,7 +44,7 @@ cds watch
 
 ### Growing as You Go...
 
-Add things only when you need them or when you know more. Avoid any premature descisions or upfront overhead. For example, typical CAP projects adopt an *iterative* and *evolutionary* workflow like that:
+Add things only when you need them or when you know more. Avoid any premature decisions or upfront overhead. For example, typical CAP projects adopt an *iterative* and *evolutionary* workflow like that:
 
 1. **jumpstart a project** → no premature decisions made at that stage, just the name.
 2. **rapidly create** fully functional first prototypes or proof-of-concept versions.
@@ -94,7 +94,7 @@ CAP provides mocked variants for several platform services out-of-the-box, which
 
 CAP's thorough [agnostic design](best-practices#agnostic-by-design) not only allows to swap local mock variants as stand-ins for productive platform services, it also allows to do the same for your application services.
 
-Assumed you plan for a microservices arctitecure, the team developing microservice `A` would always have a dependency to the availability of microservice `B`, which they need to connect to, at least in a hybrid setup, worst case even ending up in the need to always have both deployed to the cloud.
+Assumed you plan for a microservices architecture, the team developing microservice `A` would always have a dependency to the availability of microservice `B`, which they need to connect to, at least in a hybrid setup, worst case even ending up in the need to always have both deployed to the cloud.
 
 With CAP you can (and should) instead just run both services in the same local process at development, basically by using `B` as a plain old library in `A`, and only deploy them to separate microservices in production, **without having to touch your models or code** (given `A` uses `B` through public APIs, which should always be the case anyways).
 
@@ -239,7 +239,7 @@ That initiative happened to be quite successful, and gave a boost to a steadily
 
 SaaS customers, verticalization partners, or your teams can...
 
-- Add/overide annotations, translations, initial data
+- Add/override annotations, translations, initial data
 - Add extension fields, entities, relationships
 - Add custom logic → in-app + side-by-side
 - Bundle and share that as reuse extension packages
@@ -300,11 +300,11 @@ That might sound like a contradiction, but it isn't: While CAP certainly gives *
 
 > [!tip]
 >
-> And maybe most important: As CAP itself is designed as an open framework, everything what's not covered by CAP today can be solved in application projects, in specific custom code, or by [generic handlers](best-practices.md#extensible-framework) ... or by [plugins](../plugins/index.md) that you could build and contribute. <br/>⇒  **Contributions *are* welcome!**
+> And most important: As CAP itself is designed as an open framework, everything what's not covered by CAP today can be solved in application projects, in specific custom code, or by [generic handlers](best-practices.md#extensible-framework) ... or by [plugins](../plugins/index.md) that you could build and contribute. <br/>⇒  **Contributions *are* welcome!**
 
 
 
-## Focus on Domain
+## Focus on Domain 
 
 CAP places **primary focus on domain**, by capturing _domain knowledge_ and _intent_ instead of imperative coding — that means, _What, not How_ — which promotes the following:
 
@@ -312,21 +312,13 @@ CAP places **primary focus on domain**, by capturing _domain knowledge_ and _int
 - _Out-of-the-box_ implementations for _best practices_ and recurring tasks.
 - _Platform-agnostic_ approach to _avoid lock-ins_, hence _protecting investments_.
 
-### Conceptual Modeling by CDS
+### Conceptual Modeling by CDS <UnderConstruction/>
 
-<UnderConstruction/>
-
-### Domain-Driven Design
-
-<UnderConstruction/>
-
-### Rapid Development
-
-<UnderConstruction/>
+### Domain-Driven Design <UnderConstruction/>
 
-### Minimal Distraction
+### Rapid Development <UnderConstruction/>
 
-<UnderConstruction/>
+### Minimal Distraction <UnderConstruction/>
 
 
 
@@ -338,17 +330,11 @@ There's a nice definition of technical debt found at this [glossary by ProductPl
 
 So, how could CAP help to avoid — or reduce the risks of — piling up technical debt?
 
-### Less Code → Less Mistakes
-
-<UnderConstruction/>
+### Less Code → Less Mistakes <UnderConstruction/>
 
-### Single Points to Fix
+### Single Points to Fix <UnderConstruction/>
 
-<UnderConstruction/>
-
-### Minimized Lock-Ins
-
-<UnderConstruction/>
+### Minimized Lock-Ins <UnderConstruction/>
 
 ### Evolution w/o Disruption
 {#evolution-wo-disruption}