feat: regenerate docs and table

Author: bachgarash

docs/registry/attributes/service.md

@@ -54,8 +54,8 @@ port.
 
 `service.criticality` has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.
 
-| Value  | Description | Stability |
-|---|---|---|
+| Value | Description | Stability |
+| --- | --- | --- |
 | `critical` | Service is business-critical; downtime directly impacts revenue, user experience, or core functionality. [5] | ![Development](https://img.shields.io/badge/-development-blue) |
 | `high` | Service is important but has degradation tolerance or fallback mechanisms. [6] | ![Development](https://img.shields.io/badge/-development-blue) |
 | `low` | Service is non-essential to core operations; used for background tasks or internal tools. [7] | ![Development](https://img.shields.io/badge/-development-blue) |

docs/registry/entities/service.md

@@ -56,4 +56,23 @@ port.
 
 **[4] `service.criticality`:** This attribute enables classification of services based on their operational importance, allowing observability platforms to implement criticality-aware tracing, monitoring, and sampling strategies. By standardizing service criticality, organizations can implement adaptive sampling rates (e.g., 100% for critical, 10% for low-priority services), optimize telemetry costs by reducing data from non-critical services, improve incident response by surfacing critical service traces first, and enable better capacity planning and resource allocation.
 
+---
+
+`service.criticality` has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.
+
+| Value | Description | Stability |
+| --- | --- | --- |
+| `critical` | Service is business-critical; downtime directly impacts revenue, user experience, or core functionality. [5] | ![Development](https://img.shields.io/badge/-development-blue) |
+| `high` | Service is important but has degradation tolerance or fallback mechanisms. [6] | ![Development](https://img.shields.io/badge/-development-blue) |
+| `low` | Service is non-essential to core operations; used for background tasks or internal tools. [7] | ![Development](https://img.shields.io/badge/-development-blue) |
+| `medium` | Service provides supplementary functionality; degradation has limited user impact. [8] | ![Development](https://img.shields.io/badge/-development-blue) |
+
+**[5]:** Examples include payment processing, authentication, and primary user-facing APIs.
+
+**[6]:** Examples include shopping cart, search, and recommendation engines.
+
+**[7]:** Examples include batch processors, cleanup jobs, and internal dashboards.
+
+**[8]:** Examples include analytics, reporting, and non-essential integrations.
+
 <!-- markdownlint-restore -->

docs/resource/README.md

@@ -122,6 +122,25 @@ port.
 **[3] `service.namespace`:** A string value having a meaning that helps to distinguish a group of services, for example the team name that owns a group of services. `service.name` is expected to be unique within the same namespace. If `service.namespace` is not specified in the Resource then `service.name` is expected to be unique for all services that have no explicit namespace defined (so the empty/unspecified namespace is simply one more valid namespace). Zero-length namespace string is assumed equal to unspecified namespace.
 
 **[4] `service.criticality`:** This attribute enables classification of services based on their operational importance, allowing observability platforms to implement criticality-aware tracing, monitoring, and sampling strategies. By standardizing service criticality, organizations can implement adaptive sampling rates (e.g., 100% for critical, 10% for low-priority services), optimize telemetry costs by reducing data from non-critical services, improve incident response by surfacing critical service traces first, and enable better capacity planning and resource allocation.
+
+---
+
+`service.criticality` has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.
+
+| Value | Description | Stability |
+| --- | --- | --- |
+| `critical` | Service is business-critical; downtime directly impacts revenue, user experience, or core functionality. [5] | ![Development](https://img.shields.io/badge/-development-blue) |
+| `high` | Service is important but has degradation tolerance or fallback mechanisms. [6] | ![Development](https://img.shields.io/badge/-development-blue) |
+| `low` | Service is non-essential to core operations; used for background tasks or internal tools. [7] | ![Development](https://img.shields.io/badge/-development-blue) |
+| `medium` | Service provides supplementary functionality; degradation has limited user impact. [8] | ![Development](https://img.shields.io/badge/-development-blue) |
+
+**[5]:** Examples include payment processing, authentication, and primary user-facing APIs.
+
+**[6]:** Examples include shopping cart, search, and recommendation engines.
+
+**[7]:** Examples include batch processors, cleanup jobs, and internal dashboards.
+
+**[8]:** Examples include analytics, reporting, and non-essential integrations.
 <!-- markdownlint-restore -->
 <!-- prettier-ignore-end -->
 <!-- END AUTOGENERATED TEXT -->