@keelcore/standards 0.9.7 → 0.10.0

package/governance/coding.md

@@ -2,9 +2,7 @@
 
 These rules govern all code edits in this project. They are non-negotiable.
 
-**Maturity:** Required
-**Version:** 1.0.0
-**Last Reviewed:** 2026-03-09
+**Maturity:** Required **Version:** 1.0.0 **Last Reviewed:** 2026-03-09
 
 ## Core Preservation
 
@@ -16,141 +14,154 @@ These rules govern all code edits in this project. They are non-negotiable.
 
 ## Commenting Rules
 
-6. Comments explain enduring intent, invariants, contracts, architecture — not patch notes.
-7. No "added this", "fixed this", "temporary workaround" style narration.
-8. Comments are file-local; no broader project lore unless strictly necessary.
-9. Prefer code over commentary for the obvious.
-10. When updating code, update any nearby comment that would become misleading.
+1. Comments explain enduring intent, invariants, contracts, architecture — not patch notes.
+2. No "added this", "fixed this", "temporary workaround" style narration.
+3. Comments are file-local; no broader project lore unless strictly necessary.
+4. Prefer code over commentary for the obvious.
+5. When updating code, update any nearby comment that would become misleading.
 
 ## Scope Control
 
-11. All edits to existing files must be surgical — minimum necessary lines/regions/symbols.
-12. No opportunistic widening — no drive-by refactors, renames, formatting sweeps, dead-code cleanup.
-13. Do not introduce dead code — no unreachable branches, unused variables/imports, orphaned helpers.
-14. Do not reflow stable text gratuitously.
-15. Preserve surrounding code shape.
-16. Minimize diff surface area; correctness wins over minimalism when they conflict.
+1. All edits to existing files must be surgical — minimum necessary lines/regions/symbols.
+2. No opportunistic widening — no drive-by refactors, renames, formatting sweeps, dead-code cleanup.
+3. Do not introduce dead code — no unreachable branches, unused variables/imports, orphaned helpers.
+4. Do not reflow stable text gratuitously.
+5. Preserve surrounding code shape.
+6. Minimize diff surface area; correctness wins over minimalism when they conflict.
 
 ## Consistency and Reviewability
 
-17. Human reviewability outranks aesthetic optimization.
-18. Match local conventions: repo/module > file-local > language style guide.
-19. Avoid sweeping rewrites.
-20. Maintain interface stability — no silent signature/flag/config-key changes.
-21. When practical, preserve backward compatibility; do not silently drop old forms.
-22. Preserve blame usefulness — keep unchanged lines untouched.
+1. Human reviewability outranks aesthetic optimization.
+2. Match local conventions: repo/module > file-local > language style guide.
+3. Avoid sweeping rewrites.
+4. Maintain interface stability — no silent signature/flag/config-key changes.
+5. When practical, preserve backward compatibility; do not silently drop old forms.
+6. Preserve blame usefulness — keep unchanged lines untouched.
 
 ## Refactoring Rules
 
-23. Refactoring is opt-in, not ambient.
-24. Required refactors must be local.
-25. Do not bundle unrelated improvements.
-26. Prefer extension over churn.
+1. Refactoring is opt-in, not ambient.
+2. Required refactors must be local.
+3. Do not bundle unrelated improvements.
+4. Prefer extension over churn.
 
 ## File Editing Discipline
 
-27. Preserve untouched regions exactly.
-28. Do not reorder imports, declarations, functions, keys, or fields unless required.
-29. Do not rename symbols for taste.
-30. Do not change comments/docstrings/whitespace outside the affected area.
-31. Never leave a file in a partially migrated state.
+1. Preserve untouched regions exactly.
+2. Do not reorder imports, declarations, functions, keys, or fields unless required.
+3. Do not rename symbols for taste.
+4. Do not change comments/docstrings/whitespace outside the affected area.
+5. Never leave a file in a partially migrated state.
 
 ## New File Discipline
 
-32. Follow naming, package structure, header conventions of adjacent files.
-33. Creating a new file requires explicit justification; prefer extending existing files.
-34. Test files may use longer functions, explicit repetition, table-driven patterns — do not compress.
+1. Follow naming, package structure, header conventions of adjacent files.
+2. Creating a new file requires explicit justification; prefer extending existing files.
+3. Test files may use longer functions, explicit repetition, table-driven patterns — do not compress.
 
 ## Style
 
-35. Prefer boring, conventional, long-lived patterns over novelty.
-36. Follow language style guide unless local style clearly overrides.
-37. Conservative house style: readability, portability, diff minimization, explicitness, reviewer clarity.
-38. Style must be consistent within the file and stable across future edits.
+1. Prefer boring, conventional, long-lived patterns over novelty.
+2. Follow language style guide unless local style clearly overrides.
+3. Conservative house style: readability, portability, diff minimization, explicitness, reviewer clarity.
+4. Style must be consistent within the file and stable across future edits.
 
 ## Security
 
-39. No hardcoded credentials, tokens, private keys, disabled TLS verification, open CORS, permissive file modes.
-    Note existing violations and raise them rather than propagating them.
+1. No hardcoded credentials, tokens, private keys, disabled TLS verification, open CORS, permissive file modes. Note
+   existing violations and raise them rather than propagating them.
 
 ## Documentation
 
-40. When observable behavior/flags/config/API/errors change, note that external docs may need updating.
+1. When observable behavior/flags/config/API/errors change, note that external docs may need updating.
 
 ## Formatting and Linting Automation
 
-41. Format and lint via project scripts, not ad-hoc commands.
-42. Propose `scripts/format.sh` and `scripts/lint.sh` if they do not exist.
-43. Do not embed formatter/linter invocations in YAML or Makefiles when a script can be the entry point.
+1. Format and lint via project scripts, not ad-hoc commands.
+2. Propose `scripts/format.sh` and `scripts/lint.sh` if they do not exist.
+3. Do not embed formatter/linter invocations in YAML or Makefiles when a script can be the entry point.
 
 ## Git Hook Integration
 
-44. Pre-commit hook calls a single stable entry point: `scripts/git_precommit.sh`.
-45. `scripts/git_precommit.sh` invokes format + lint scripts; no logic duplicated in the hook itself.
+1. Pre-commit hook calls a single stable entry point: `scripts/git_precommit.sh`.
+2. `scripts/git_precommit.sh` invokes format + lint scripts; no logic duplicated in the hook itself.
 
 ## Change Justification
 
-46. Every non-trivial change must be justifiable as necessary.
-47. No speculative fixes.
-48. No silent cleanup of unconventional-but-correct code.
-49. Preserve intent over stylistic purity.
+1. Every non-trivial change must be justifiable as necessary.
+2. No speculative fixes.
+3. No silent cleanup of unconventional-but-correct code.
+4. Preserve intent over stylistic purity.
 
 ## Completeness and Consistency
 
-50. Do not leave referenced functions/variables/imports/code paths broken.
-51. No partial renames, partial signature migrations, inconsistent call-site updates.
-52. Changed code must remain internally consistent with the rest of the file.
-53. Prefer a complete narrow fix over an ambitious broad rewrite.
+1. Do not leave referenced functions/variables/imports/code paths broken.
+2. No partial renames, partial signature migrations, inconsistent call-site updates.
+3. Changed code must remain internally consistent with the rest of the file.
+4. Prefer a complete narrow fix over an ambitious broad rewrite.
 
 ## Default Operating Principle
 
-54. Treat every edit as a constrained maintenance operation, not a redesign opportunity.
-55. Ideal change: minimal, correct, legible, locally consistent, unsurprising.
+1. Treat every edit as a constrained maintenance operation, not a redesign opportunity.
+2. Ideal change: minimal, correct, legible, locally consistent, unsurprising.
 
 ## Concurrency and Shared-State Safety
 
-56. Do not remove synchronization primitives or introduce unprotected shared state.
-57. Do not introduce goroutines/threads/async into previously synchronous code paths.
-58. Do not move code across concurrency boundaries without preserving ordering and safety.
+1. Do not remove synchronization primitives or introduce unprotected shared state.
+2. Do not introduce goroutines/threads/async into previously synchronous code paths.
+3. Do not move code across concurrency boundaries without preserving ordering and safety.
 
 ## Type and Contract Safety
 
-59. Do not widen specific types to any/interface{}/generic containers.
-60. No unsafe casts, reflection-driven access, or dynamic fallbacks where typed alternatives exist.
-61. Do not remove type checks, assertions, validation, or boundary contracts without equal replacement.
+1. Do not widen specific types to any/interface{}/generic containers.
+2. No unsafe casts, reflection-driven access, or dynamic fallbacks where typed alternatives exist.
+3. Do not remove type checks, assertions, validation, or boundary contracts without equal replacement.
 
 ## Ambiguity Control
 
-62. When ambiguous, prefer the narrowest conservative interpretation consistent with literal text and intent.
-63. Seek clarification only when conservative interpretation produces broken, incomplete, or unsafe output.
+1. When ambiguous, prefer the narrowest conservative interpretation consistent with literal text and intent.
+2. Seek clarification only when conservative interpretation produces broken, incomplete, or unsafe output.
 
 ## Complexity Preservation
 
-64. Do not introduce worse asymptotic complexity where a better one existed.
-65. Do not replace indexed/cached/streaming/incremental behavior with full scans or redundant allocation.
+1. Do not introduce worse asymptotic complexity where a better one existed.
+2. Do not replace indexed/cached/streaming/incremental behavior with full scans or redundant allocation.
+
+## Locale and Reproducibility
+
+1. Builds, tests, and tooling MUST be reproducible independent of the developer's or CI runner's
+   locale. Never depend on an inherited `LANG`/`LC_*` for program behavior.
+2. Any locale-sensitive operation — collation/sort order, numeric or date formatting, case-folding —
+   MUST pin an explicit, deterministic locale (`LC_ALL=C`, or an equivalent language-native
+   invariant) rather than rely on the ambient default.
+3. Pin at the outermost boundary that covers all subprocesses (e.g. the build entrypoint exports
+   `LC_ALL=C`) so that tools you do not own inherit the deterministic locale too.
+4. Where a locale dependency is load-bearing, add a test that runs the path under a hostile `LC_*`
+   and asserts the invariant holds. Language-specific mechanics live in the per-language standards
+   (e.g. bash.md, "Locale Determinism").
 
 ## Source File Trailing Newlines
 
-66. Every text source file (`.go`, `.sh`, `.md`, `.yml`, `.yaml`, `.toml`, `.json`,
-    `.gitignore`, `.gitattributes`) MUST end with a single trailing newline character.
-67. Verify and fix trailing newlines before handing off any file edits.
-68. Adding a new text-format type to the repo requires updating `scripts/lint/newlines.sh`
-    and the pre-commit hook in the same commit.
+1. Every text source file (`.go`, `.sh`, `.md`, `.yml`, `.yaml`, `.toml`, `.json`, `.gitignore`, `.gitattributes`) MUST
+   end with a single trailing newline character.
+2. Verify and fix trailing newlines before handing off any file edits.
+3. Adding a new text-format type to the repo requires updating `scripts/lint/newlines.sh` and the pre-commit hook in the
+   same commit.
 
 ## Go Module Version Format
 
-69. The `go` directive in `go.mod` MUST use the two-component form: `go 1.25` — never `go 1.25.0`.
-70. After every `go mod tidy` or `go get`, verify the `go` directive and strip any trailing `.0`.
+1. The `go` directive in `go.mod` MUST use the two-component form: `go 1.25` — never `go 1.25.0`.
+2. After every `go mod tidy` or `go get`, verify the `go` directive and strip any trailing `.0`.
 
 ## Static Analysis Suppression
 
-71. The standalone `staticcheck` binary does NOT respect `//nolint:staticcheck` directives.
-    Use `//lint:ignore SA1019 <reason>` instead.
-72. Place the `//lint:ignore` directive on its own line immediately above the flagged statement —
-    inline (end-of-line) placement may be silently ignored.
+1. The standalone `staticcheck` binary does NOT respect `//nolint:staticcheck` directives. Use
+   `//lint:ignore SA1019 <reason>` instead.
+2. Place the `//lint:ignore` directive on its own line immediately above the flagged statement — inline (end-of-line)
+   placement may be silently ignored.
 
 ## Program Entry Points
 
-73. `main` (and any program entry point) must be KISS: orchestration and wiring only.
-74. No default behaviors, business logic, or configuration in `main` — those belong in the library.
-75. A correct `main` is ~15 lines: parse flags, call library, handle exit.
+1. `main` (and any program entry point) must be KISS: orchestration and wiring only.
+2. No default behaviors, business logic, or configuration in `main` — those belong in the library.
+3. A correct `main` is ~15 lines: parse flags, call library, handle exit.

package/governance/observability.md

@@ -2,148 +2,139 @@
 
 These rules govern metrics, logging, tracing, and alerting across all services. They are non-negotiable.
 
-**Maturity:** Required
-**Version:** 1.0.0
-**Last Reviewed:** 2026-03-09
+**Maturity:** Required **Version:** 1.0.0 **Last Reviewed:** 2026-03-09
 
 ## Metrics
 
 ### Vendors and Retention
 
-1. The approved metrics vendor(s) are documented in the internal vendor registry. No additional metrics
-   backends are introduced without ARB approval.
-2. Metrics retention: real-time resolution (≤60s) for 15 days; 5-minute rollup for 90 days;
-   1-hour rollup for 13 months.
+1. The approved metrics vendor(s) are documented in the internal vendor registry. No additional metrics backends are
+   introduced without ARB approval.
+2. Metrics retention: real-time resolution (≤60s) for 15 days; 5-minute rollup for 90 days; 1-hour rollup for 13 months.
 3. Long-term retention beyond 13 months requires explicit data classification and archival approval.
 
 ### Taxonomy and Namespace Schema
 
-4. All metric names follow the schema: `{org}_{service}_{noun}_{unit}` (e.g., `keelcore_auth_requests_total`).
-5. Metric namespaces are registered centrally; unregistered namespaces are rejected at the ingestion layer.
-6. Label keys are lowercase snake_case. Label values must not contain high-cardinality free-text (e.g.,
-   user IDs, trace IDs, URLs). Cardinality limit per metric: 10,000 distinct label value combinations.
+1. All metric names follow the schema: `{org}_{service}_{noun}_{unit}` (e.g., `keelcore_auth_requests_total`).
+2. Metric namespaces are registered centrally; unregistered namespaces are rejected at the ingestion layer.
+3. Label keys are lowercase snake_case. Label values must not contain high-cardinality free-text (e.g., user IDs, trace
+   IDs, URLs). Cardinality limit per metric: 10,000 distinct label value combinations.
 
 ### Required Metric Ontologies
 
-7. Every service exposes RED metrics: **R**ate (requests per second), **E**rrors (error rate),
-   **D**uration (latency distribution — p50, p95, p99).
-8. Every resource-bound component (database, cache, message queue, worker pool) exposes USE metrics:
-   **U**tilization, **S**aturation, **E**rrors.
-9. RED and USE dashboards are provisioned automatically from the service's metric registration.
+1. Every service exposes RED metrics: **R**ate (requests per second), **E**rrors (error rate), **D**uration (latency
+   distribution — p50, p95, p99).
+2. Every resource-bound component (database, cache, message queue, worker pool) exposes USE metrics: **U**tilization,
+   **S**aturation, **E**rrors.
+3. RED and USE dashboards are provisioned automatically from the service's metric registration.
 
 ### SLOs and SLAs
 
-10. Every public-facing service defines at least one SLO expressed as an error budget (e.g., 99.9%
-    availability over a 30-day rolling window).
-11. SLO burn-rate alerts fire at 2× and 10× burn rates and are routed to the on-call rotation.
-12. SLAs, where contractually defined, are backed by SLOs with sufficient headroom. SLA breach
-    thresholds are stricter than internal SLO thresholds.
-13. Service dashboards are published to the central dashboard registry and linked from the service runbook.
+1. Every public-facing service defines at least one SLO expressed as an error budget (e.g., 99.9% availability over a
+   30-day rolling window).
+2. SLO burn-rate alerts fire at 2× and 10× burn rates and are routed to the on-call rotation.
+3. SLAs, where contractually defined, are backed by SLOs with sufficient headroom. SLA breach thresholds are stricter
+   than internal SLO thresholds.
+4. Service dashboards are published to the central dashboard registry and linked from the service runbook.
 
 ## Logging
 
 ### Format
 
-14. All log output is structured JSON. Human-readable plain text logs are prohibited in staging and
-    production. Development environments may use formatted output via a local flag.
-15. Log lines are single-line JSON objects terminated by `\n`. Multi-line log entries are prohibited;
-    stack traces are serialized into a single string field.
+1. All log output is structured JSON. Human-readable plain text logs are prohibited in staging and production.
+   Development environments may use formatted output via a local flag.
+2. Log lines are single-line JSON objects terminated by `\n`. Multi-line log entries are prohibited; stack traces are
+   serialized into a single string field.
 
 ### Required Fields
 
-16. Every log entry must include:
-    - `timestamp` — RFC 3339 with nanosecond precision (e.g., `2026-03-09T12:00:00.000000000Z`)
-    - `level` — one of: `debug`, `info`, `warn`, `error`, `fatal`
-    - `service` — the service identifier (matches the metric namespace prefix)
-    - `version` — the deployed artifact version (SemVer)
-    - `trace_id` — W3C TraceContext trace ID (zero value if no active trace)
-    - `span_id` — W3C TraceContext span ID (zero value if no active trace)
-    - `message` — human-readable description of the event
-17. Additional fields are encouraged but must not collide with the reserved field list above.
+1. Every log entry must include:
+   - `timestamp` — RFC 3339 with nanosecond precision (e.g., `2026-03-09T12:00:00.000000000Z`)
+   - `level` — one of: `debug`, `info`, `warn`, `error`, `fatal`
+   - `service` — the service identifier (matches the metric namespace prefix)
+   - `version` — the deployed artifact version (SemVer)
+   - `trace_id` — W3C TraceContext trace ID (zero value if no active trace)
+   - `span_id` — W3C TraceContext span ID (zero value if no active trace)
+   - `message` — human-readable description of the event
+2. Additional fields are encouraged but must not collide with the reserved field list above.
 
 ### SDK-Level Enforcement
 
-18. Services must use the organization-approved logging SDK. Calls to raw `fmt.Println`,
-    `console.log`, `print()`, or equivalent bypass the structured logger and are prohibited.
-19. The logging SDK enforces required fields at construction time. A log entry missing a required
-    field must fail at build time or panic at startup, not silently emit a malformed log.
+1. Services must use the organization-approved logging SDK. Calls to raw `fmt.Println`, `console.log`, `print()`, or
+   equivalent bypass the structured logger and are prohibited.
+2. The logging SDK enforces required fields at construction time. A log entry missing a required field must fail at
+   build time or panic at startup, not silently emit a malformed log.
 
 ### Aggregation and Retention
 
-20. All logs from all environments (staging, production) are shipped to the central log aggregation
-    platform. Local-only logging is prohibited in staging and production.
-21. Log retention: 90 days at full fidelity; 13 months for `warn` and above; 7 years for `audit`
-    classified logs.
-22. Log access is role-gated. Read access to production logs requires an approved role. Queries
-    on `audit`-classified logs are themselves logged.
+1. All logs from all environments (staging, production) are shipped to the central log aggregation platform. Local-only
+   logging is prohibited in staging and production.
+2. Log retention: 90 days at full fidelity; 13 months for `warn` and above; 7 years for `audit` classified logs.
+3. Log access is role-gated. Read access to production logs requires an approved role. Queries on `audit`-classified
+   logs are themselves logged.
 
 ### Redaction and Privacy
 
-23. Personally identifiable information (PII) must not appear in log fields except `audit`-classified
-    logs with explicit data handling approval.
-24. Secrets, tokens, passwords, and private keys must never be logged, even at `debug` level.
-25. The logging SDK must provide a redaction hook that masks known-sensitive field patterns before
-    emission. Services must register PII-bearing fields with the redaction registry.
-26. Audit logs that require PII (e.g., access logs for compliance) are stored in a segregated
-    audit log store with stricter access controls and encryption-at-rest.
+1. Personally identifiable information (PII) must not appear in log fields except `audit`-classified logs with explicit
+   data handling approval.
+2. Secrets, tokens, passwords, and private keys must never be logged, even at `debug` level.
+3. The logging SDK must provide a redaction hook that masks known-sensitive field patterns before emission. Services
+   must register PII-bearing fields with the redaction registry.
+4. Audit logs that require PII (e.g., access logs for compliance) are stored in a segregated audit log store with
+   stricter access controls and encryption-at-rest.
 
 ## Distributed Tracing
 
 ### Framework
 
-27. All services instrument using OpenTelemetry (OTel). Vendor-specific tracing SDKs are prohibited
-    as the primary instrumentation layer. OTel exporters may target any approved backend.
-28. Trace context is propagated using the W3C TraceContext standard (`traceparent`, `tracestate` headers).
-    Proprietary propagation formats (B3, X-Cloud-Trace-Context) are acceptable as secondary propagation
-    only for legacy integration.
+1. All services instrument using OpenTelemetry (OTel). Vendor-specific tracing SDKs are prohibited as the primary
+   instrumentation layer. OTel exporters may target any approved backend.
+2. Trace context is propagated using the W3C TraceContext standard (`traceparent`, `tracestate` headers). Proprietary
+   propagation formats (B3, X-Cloud-Trace-Context) are acceptable as secondary propagation only for legacy integration.
 
 ### Propagation Policy
 
-29. Every inbound request must extract trace context from headers if present, or generate a new root
-    span if absent.
-30. Every outbound call must inject the current trace context into request headers.
-31. Internal background jobs and queue consumers must attach to the trace context embedded in the
-    job/message payload.
-32. Trace context must cross service, database, queue, and cache boundaries. Traces that terminate
-    at a service boundary rather than propagating downstream are a defect.
+1. Every inbound request must extract trace context from headers if present, or generate a new root span if absent.
+2. Every outbound call must inject the current trace context into request headers.
+3. Internal background jobs and queue consumers must attach to the trace context embedded in the job/message payload.
+4. Trace context must cross service, database, queue, and cache boundaries. Traces that terminate at a service boundary
+   rather than propagating downstream are a defect.
 
 ### Sampling
 
-33. Production sampling: head-based sampling at 1% for high-volume steady-state traffic, with tail-based
-    sampling capturing 100% of error traces and traces exceeding the p99 latency threshold.
-34. Sampling configuration is centralized (not per-service). Services do not configure their own sampling
-    rates without approval.
-35. Staging and development environments use 100% sampling.
+1. Production sampling: head-based sampling at 1% for high-volume steady-state traffic, with tail-based sampling
+   capturing 100% of error traces and traces exceeding the p99 latency threshold.
+2. Sampling configuration is centralized (not per-service). Services do not configure their own sampling rates without
+   approval.
+3. Staging and development environments use 100% sampling.
 
 ## Audit Logging
 
 ### Immutability and Trail Requirements
 
-36. Sensitive actions (authentication events, authorization decisions, configuration changes, data
-    exports, administrative actions) must emit an `audit`-classified log entry.
-37. Audit logs are written to an append-only, tamper-evident store. Application processes have write-only
-    access; no application process may read, modify, or delete audit log entries.
-38. Every audit log entry includes: `timestamp`, `actor_id`, `actor_type` (human or service),
-    `action`, `resource_type`, `resource_id`, `outcome` (success or failure), `client_ip`, `trace_id`.
-39. Access to resources and modifications to data are logged, including read access to sensitive data.
+1. Sensitive actions (authentication events, authorization decisions, configuration changes, data exports,
+   administrative actions) must emit an `audit`-classified log entry.
+2. Audit logs are written to an append-only, tamper-evident store. Application processes have write-only access; no
+   application process may read, modify, or delete audit log entries.
+3. Every audit log entry includes: `timestamp`, `actor_id`, `actor_type` (human or service), `action`, `resource_type`,
+   `resource_id`, `outcome` (success or failure), `client_ip`, `trace_id`.
+4. Access to resources and modifications to data are logged, including read access to sensitive data.
 
 ### Retention
 
-40. Audit logs are retained for a minimum of 7 years unless a longer period is required by applicable
-    regulation.
-41. Audit log exports for compliance review require dual-approval and are themselves logged.
+1. Audit logs are retained for a minimum of 7 years unless a longer period is required by applicable regulation.
+2. Audit log exports for compliance review require dual-approval and are themselves logged.
 
 ## Alerting
 
 ### Thresholds and Routing
 
-42. Every SLO has an associated burn-rate alert. Alerts fire at 2× burn (page candidate) and 10× burn
-    (immediate page).
-43. `error` and `fatal` log events that exceed a per-service threshold trigger an alert.
-44. Alert routing follows the on-call schedule managed in the central incident management platform.
-45. Alerts include: service name, environment, metric/log source, threshold breached, current value,
-    link to the relevant dashboard, and link to the runbook.
-46. Runbook links in alerts must resolve. Broken runbook links are treated as a P2 incident.
+1. Every SLO has an associated burn-rate alert. Alerts fire at 2× burn (page candidate) and 10× burn (immediate page).
+2. `error` and `fatal` log events that exceed a per-service threshold trigger an alert.
+3. Alert routing follows the on-call schedule managed in the central incident management platform.
+4. Alerts include: service name, environment, metric/log source, threshold breached, current value, link to the relevant
+   dashboard, and link to the runbook.
+5. Runbook links in alerts must resolve. Broken runbook links are treated as a P2 incident.
 
 ## Do Not