diff --git a/ipa/general/0126.mdx b/ipa/general/0126.mdx
index 18aab9d..78a8901 100644
--- a/ipa/general/0126.mdx
+++ b/ipa/general/0126.mdx
@@ -11,21 +11,467 @@ recognizable to facilitate seamless navigation of API documentation.
## Guidance
-- API names **must** use ‘Title Case’
-- API names **must** be written as nouns
- - **For example:** 'Alert Configurations' not 'Configure Alerts'
-- API names **should** be precise and self-explanatory to convey the function of
- the APIs
-- API names **should not** include platform-specific branding or terms
-- APIs for platform services **should not** include the platform name
- - **For example,** 'Atlas Search' **should** be displayed as 'Search'
-- Discoverability through search **should** be considered to facilitate fast
- identification
-- API names **should** avoid using acronyms unless widely recognized
+
+
+
+
+API names **must** use 'Title Case'.
+
+
+
+
+
+```yaml
+tags:
+ - name: Alert Configurations
+ - name: Billing and Invoices
+```
+
+
+ Each significant word is capitalized, and the grammatical word "and" stays
+ lowercase, which is the conventional Title Case form.
+
+
+
+
+
+
+```yaml
+tags:
+ - name: alert configurations
+ - name: Billing And Invoices
+```
+
+
+ The first tag is all lowercase, and the second capitalizes the grammatical
+ word "And", so neither follows Title Case.
+
+
+
+
+
+
+
+
+
+
+API names **must** be written as nouns. For example, 'Alert Configurations' not
+'Configure Alerts'.
+
+
+
+
+
+```yaml
+tags:
+ - name: User Invitations
+ - name: Project Members
+```
+
+
+ Each name labels the thing the API manages rather than an action taken on it,
+ so the name reads as a service area.
+
+
+
+
+
+
+```yaml
+tags:
+ - name: Invite Users
+ - name: Manage Project Members
+```
+
+
+ Each name leads with a verb, describing an action instead of naming the
+ functional area, which reads as an operation rather than a top-level service.
+
+
+
+
+
+
+ Collect every entry under `tags` and read each `name`.
+
+
+ For each name, identify the leading word and decide whether it is a verb or
+ an action phrase ("Configure", "Manage", "Create", "Invite").
+
+
+ Confirm the name reads as a noun phrase naming a functional area rather than
+ an action.
+
+
+ Report any tag name that is phrased as a verb or action.
+
+
+
+
+
+
+
+
+
+API names **should** be precise and self-explanatory to convey the function of
+the APIs.
+
+
+
+
+
+```yaml
+tags:
+ - name: Payment Methods
+ - name: Scheduled Reports
+```
+
+
+ Each name states the functional area plainly, so a reader knows what the API
+ covers without consulting other documentation.
+
+
+
+
+
+
+```yaml
+tags:
+ - name: Misc
+ - name: Core Service
+```
+
+
+ "Misc" and "Core Service" are vague and convey nothing about the function the
+ API serves, leaving a reader to guess what the group contains.
+
+
+
+
+
+
+ Collect every entry under `tags` and read each `name`.
+
+
+ For each name, decide whether it names a specific function or is generic
+ filler ("Misc", "Other", "General", "Core").
+
+
+ Cross-check the operations grouped under the tag and confirm the name
+ accurately and specifically describes them.
+
+
+ Report any tag name that is vague or does not describe the operations it
+ groups.
+
+
+
+
+
+
+
+
+
+API names **should not** include platform-specific branding or terms.
+
+
+
+
+
+```yaml
+tags:
+ - name: Search
+ - name: Data Federation
+```
+
+
+ Each name describes the function alone, so it stays meaningful regardless of
+ the product or surface that hosts the API.
+
+
+
+
+
+
+```yaml
+tags:
+ - name: Acme Search
+ - name: Acme Cloud Data Federation
+```
+
+
+ The branded prefix adds no information about the function and ties the name to
+ a product surface, which clutters the documentation index.
+
+
+
+
+
+
+ Collect every entry under `tags` and read each `name`.
+
+
+ For each name, check whether it contains a product, brand, or trademark term
+ rather than a plain functional descriptor.
+
+
+ Report any tag name carrying branding or platform-specific terminology.
+
+
+
+
+
+
+
+
+
+APIs for platform services **should not** include the platform name. For
+example, 'Atlas Search' **should** be displayed as 'Search'.
+
+
+
+
+
+```yaml
+tags:
+ - name: Search
+ - name: Backups
+```
+
+
+ Within a platform's own API, the platform name is implied, so each function is
+ named on its own.
+
+
+
+
+
+
+```yaml
+tags:
+ - name: Platform Search
+ - name: Platform Backups
+```
+
+
+ Repeating the platform name on every tag is redundant inside that platform's
+ API and pads each name without adding meaning.
+
+
+
+
+
+
+ Identify the platform or service that owns the specification.
+
+
+ Collect every entry under `tags` and read each `name`.
+
+
+ For each name, check whether it begins with or contains the owning
+ platform's name.
+
+
+ Report any tag name that prefixes the function with the platform name.
+
+
+
+
+
+
+
+
+
+Discoverability through search **should** be considered to facilitate fast
+identification.
+
+
+
+
+
+API names **should** avoid using acronyms unless widely recognized.
+
+
+
+
+
+```yaml
+tags:
+ - name: Access Control
+ - name: API Keys
+```
+
+
+ "Access Control" is spelled out, and "API" is a widely recognized acronym, so
+ both names stay clear to a general reader.
+
+
+
+
+
+
+```yaml
+tags:
+ - name: RBAC
+ - name: SLA Templates
+```
+
+
+ "RBAC" and "SLA" are domain acronyms that a reader unfamiliar with the area
+ cannot decode, which hurts navigation.
+
+
+
+
+
+
+ Collect every entry under `tags` and read each `name`.
+
+
+ For each name, find any token that is an acronym or initialism.
+
+
+ Decide whether the acronym is widely recognized by a general audience or is
+ domain-specific jargon.
+
+
+ Report any tag name relying on an acronym that is not widely recognized.
+
+
+
+
+
+
+
+
## OpenAPI Consideration
-- When defining `tags` in OpenAPI Specification, these naming principles
- **should** be applied
-- Each tag **should** represent a logical grouping of APIs, aligning with
- top-level service areas to enhance discoverability and navigation
+
+
+
+
+When defining `tags` in an OpenAPI specification, these naming principles
+**should** be applied.
+
+
+
+
+
+```yaml
+tags:
+ - name: Payment Methods
+ - name: Scheduled Reports
+```
+
+
+ The tag names are nouns in Title Case that name a function plainly, so the
+ same naming principles that govern API names govern the tags.
+
+
+
+
+
+
+```yaml
+tags:
+ - name: configure payments
+ - name: RBAC
+```
+
+
+ One tag is a lowercase verb phrase and the other an obscure acronym, so the
+ tag names ignore the naming principles applied to API names.
+
+
+
+
+
+
+ Collect every entry under `tags` and read each `name`.
+
+
+ For each name, apply the API-name checks: Title Case, noun phrasing, precise
+ wording, no branding, no platform name, no obscure acronyms.
+
+
+ Report any tag name that violates one of those naming principles.
+
+
+
+
+
+
+
+
+
+Each tag **should** represent a logical grouping of APIs, aligning with
+top-level service areas to enhance discoverability and navigation.
+
+
+
+
+
+```yaml
+tags:
+ - name: Billing
+paths:
+ /invoices:
+ get:
+ tags: [Billing]
+ /payment-methods:
+ get:
+ tags: [Billing]
+```
+
+
+ Both operations belong to the same service area and share one tag, so the tag
+ represents a coherent top-level grouping.
+
+
+
+
+
+
+```yaml
+tags:
+ - name: Endpoints
+paths:
+ /invoices:
+ get:
+ tags: [Endpoints]
+ /users:
+ get:
+ tags: [Endpoints]
+```
+
+
+ Unrelated operations are lumped under a single catch-all tag, so the grouping
+ reflects no service area and gives a reader no way to navigate.
+
+
+
+
+
+
+ Collect every entry under `tags` and the set of operations referencing each
+ tag.
+
+
+ For each tag, inspect the grouped operations and decide whether they form
+ one coherent service area.
+
+
+ Check for catch-all tags that group unrelated operations and for tags that
+ fragment one service area across several names.
+
+
+ Report any tag that does not align with a single top-level service area.
+
+
+
+
+
+
+
+