@keelcore/standards 0.9.7

package/governance/observability.md

@@ -0,0 +1,158 @@
+# Observability Standards
+
+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
+
+## 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.
+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.
+
+### 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.
+
+### 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.
+
+## 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.
+
+### 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.
+
+### 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.
+
+### 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.
+
+### 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.
+
+## 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.
+
+### 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.
+
+### 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.
+
+## 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.
+
+### 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.
+
+## 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.
+
+## Do Not
+
+- Emit plain-text or unstructured logs in staging or production.
+- Log PII outside of approved audit log stores.
+- Log secrets, tokens, or credentials at any log level.
+- Define per-service sampling rates without central approval.
+- Omit required log fields.
+- Use vendor-specific tracing SDKs as the primary instrumentation layer.
+- Allow traces to terminate at a service boundary rather than propagating downstream.
+- Deploy a service without RED metrics, SLO definition, and a linked dashboard.
+- Ship alerts without runbook links.

package/governance/platform.md

@@ -0,0 +1,167 @@
+# Platform Architecture Standards
+
+These rules govern platform-level decisions across networking, DNS, TLS, WAF, and traffic management.
+They are non-negotiable unless explicitly superseded by a signed ADR.
+
+**Maturity:** Required
+**Version:** 1.0.0
+**Last Reviewed:** 2026-03-09
+
+## Governance Process
+
+### Decision-Making (DACI)
+
+1. All platform architecture decisions use DACI: one Driver, one Approver (Architecture Review Board
+   chair or delegate), Consulted stakeholders, and Informed parties.
+2. The Driver authors the RFC and owns shepherding it through review.
+3. The Approver has final authority; no decision is binding without Approver sign-off.
+4. Decisions that affect more than one service domain require ARB review before implementation.
+
+### RFC Process
+
+5. Any change to platform standards, vendor selection, or network topology requires an RFC.
+6. RFC template: problem statement, proposed solution, alternatives considered, rollout plan, rollback plan.
+7. RFC comment period is a minimum of five business days for standard changes; urgent security patches
+   may compress to 24 hours with ARB chair notification.
+8. Accepted RFCs are archived in `docs/rfc/` with status and the date of acceptance.
+
+### Architecture Review Board (ARB)
+
+9. ARB meets on a defined cadence (minimum monthly); decisions and attendance are published to the
+   engineering wiki within five business days of each meeting.
+10. ARB publishes a versioned Architecture Standards document at least once per quarter.
+11. Previous versions of Architecture Standards are archived and permanently accessible.
+
+## Domain and IP
+
+### Domain Registrar
+
+12. All domains are registered through the approved corporate registrar (documented in the internal
+    vendor registry). Personal or team-owned registrar accounts are prohibited for production domains.
+13. Domain transfers require ARB approval and a change record.
+14. WHOIS privacy protection is enabled on all externally registered domains.
+
+### IP Address Management
+
+15. IP allocations are managed through the approved IPAM vendor (documented in the internal vendor registry).
+16. All IP blocks are tagged with owner, environment, and region.
+17. IPv4 and IPv6 are both required for all new public-facing services. Dual-stack is the baseline; IPv4-only
+    services are not accepted for new deployments.
+18. Private RFC 1918 ranges are used for internal pod and node networks. Overlap with VPN or on-premises
+    ranges must be approved through the IPAM change process.
+
+## DNS
+
+### Zone Management
+
+19. DNS zones are managed through the approved DNS vendor (documented in the internal vendor registry).
+    Manual zone edits via vendor UI are prohibited except in a documented break-glass scenario.
+20. All zone changes are driven from infrastructure-as-code (Terraform, Pulumi, or equivalent) in a
+    version-controlled repository. Zone state is reconciled on every deployment.
+21. Internal and external zones are segregated. Internal zone resolvers are not exposed to the public internet.
+
+### Required Record Types
+
+22. Public services must expose: A, AAAA, and the appropriate CNAME or alias records.
+23. Email domains must have SPF, DKIM, and DMARC records. DMARC policy must be `p=quarantine` or stricter
+    in production.
+24. Wildcard DNS records (`*.example.com`) are permitted only for edge/ingress controllers that validate
+    per-host routing internally. Wildcard records must not resolve to application pods directly.
+25. Internal service discovery uses a dedicated internal TLD (e.g., `.internal` or cluster DNS suffix).
+    Internal records are never propagated to public resolvers.
+
+## TLS and Certificate Management
+
+### Certificate Issuance
+
+26. TLS certificates for public endpoints are issued from an approved CA vendor (documented in the internal
+    vendor registry). Self-signed certificates are prohibited on any public-facing endpoint.
+27. Certificate issuance and renewal must use the ACME protocol. Manual certificate downloads and uploads
+    are prohibited except in a documented break-glass scenario.
+28. Certificates are provisioned and renewed automatically. Expiry-based alerts fire at 30 days and again
+    at 7 days before expiration.
+
+### Mutual TLS (mTLS)
+
+29. East-west traffic between services must use mTLS. Plaintext service-to-service communication is
+    prohibited in staging and production.
+30. mTLS certificates are issued by the internal PKI (SPIFFE/SPIRE or equivalent). Leaf certificates
+    rotate on a maximum 24-hour lifetime. Rotation is automatic and zero-downtime.
+31. mTLS policy is enforced at the service mesh layer, not individually per application.
+
+### Supported Protocols and Cipher Suites
+
+32. Minimum TLS version: TLS 1.2. TLS 1.3 is required for all new integrations.
+33. TLS 1.0 and TLS 1.1 are prohibited on all endpoints.
+34. Cipher suites: prefer ECDHE key exchange with AES-GCM or ChaCha20-Poly1305. RC4, DES, 3DES,
+    and export-grade ciphers are prohibited. DHE suites below 2048-bit DH parameters are prohibited.
+35. HSTS is required on all HTTPS endpoints with `max-age` of at least one year.
+
+## Web Application Firewall (WAF) and DDoS
+
+### WAF
+
+36. All public HTTP/HTTPS ingress passes through the WAF layer before reaching application pods.
+37. The OWASP Core Rule Set (CRS) is enforced in blocking mode. Detection-only mode is not
+    acceptable for production. Tuning exceptions require a documented rule with justification.
+38. WAF rules are version-controlled. Rule changes follow the RFC process.
+39. WAF logs are ingested into the central log aggregation platform with a minimum 90-day retention.
+
+### DDoS Protection
+
+40. All public endpoints are protected by volumetric DDoS mitigation at the network edge.
+41. L7 DDoS (HTTP flood) mitigation is enforced by the WAF layer with rate limiting rules.
+42. Incident response runbooks for DDoS events are maintained and reviewed quarterly.
+
+## Security Headers
+
+43. All HTTP responses from public endpoints must include:
+    - `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`
+    - `X-Content-Type-Options: nosniff`
+    - `X-Frame-Options: DENY`
+    - `Content-Security-Policy` (service-specific, reviewed by security team)
+    - `Referrer-Policy: strict-origin-when-cross-origin`
+    - `Permissions-Policy` (restrictive default; expand per-service with justification)
+44. `Server` and `X-Powered-By` response headers must be suppressed or overridden to not reveal
+    implementation details.
+
+## Traffic Management
+
+### Payload Limits
+
+45. Default maximum upload size: 10 MB. Services requiring larger uploads must document and configure
+    an explicit limit; unbounded uploads are prohibited.
+46. Maximum request body size: 1 MB by default for API endpoints. Streaming endpoints must implement
+    backpressure.
+47. Maximum response size is bounded by the service contract. Unbounded response streaming must
+    implement flow control.
+
+### Rate Limiting
+
+48. Global rate limiting is enforced at the edge/ingress layer.
+49. Per-service rate limits are configured and documented in each service's runbook.
+50. Rate limit responses use HTTP 429 with a `Retry-After` header.
+51. Rate limit state is shared across edge replicas (e.g., Redis-backed or edge-native distributed
+    counters). Per-replica rate limiting that allows bypass via replica selection is prohibited.
+
+### Session Management
+
+52. Session tokens are cryptographically random with a minimum of 128 bits of entropy.
+53. Session lifetime: configurable per service, with a maximum idle timeout of 15 minutes and a
+    maximum absolute session lifetime of 8 hours for human-facing sessions.
+54. Sessions are invalidated server-side on logout. Client-side deletion alone is insufficient.
+55. Session refresh tokens must be rotated on every use.
+
+## Do Not
+
+- Register production domains outside the approved registrar.
+- Assign IP blocks without IPAM tracking.
+- Modify DNS zones outside of infrastructure-as-code.
+- Deploy new services without IPv6 support.
+- Use TLS 1.1 or below on any endpoint.
+- Issue certificates manually when ACME automation is available.
+- Allow service-to-service plaintext in staging or production.
+- Run OWASP WAF rules in detection-only mode in production.
+- Deploy public endpoints without DDoS protection.
+- Omit required security headers.
+- Accept unbounded file uploads without an explicit, documented size cap.

package/governance/release-policy.md

@@ -0,0 +1,171 @@
+# Release Policy
+
+**Maturity:** Required
+**Version:** 1.0.0
+**Last Reviewed:** 2026-03-11
+
+This document covers how Keel versions are tagged and released. The authoritative
+policy lives in the [keelcore/standards `ci.md`](ci.md)
+under **Release Tagging**. This document is the developer-facing how-to that
+complements that policy.
+
+---
+
+## Versioning Specification
+
+Keel follows **Semantic Versioning 2.0.0** — [https://semver.org](https://semver.org).
+That document is the canonical reference; the rules below are derived from it and
+must not contradict it.
+
+Key semver.org rules in force here:
+
+- Version numbers take the form `MAJOR.MINOR.PATCH` where each component is a
+  non-negative integer with no leading zeroes.
+- MAJOR is incremented for incompatible API changes; MINOR and PATCH reset to 0.
+- MINOR is incremented for new backward-compatible functionality; PATCH resets to 0.
+- PATCH is incremented for backward-compatible bug fixes only.
+- Major version zero (`0.y.z`) is for initial development. The public API is not
+  yet stable and anything may change at any time.
+- `1.0.0` defines the first stable public API.
+- Pre-release identifiers (`-alpha.1`, `-rc.2`, etc.) and build metadata (`+sha`)
+  are valid semver extensions but are **not supported by `create-release.sh`** at
+  this time. `--force` only accepts bare `MAJOR.MINOR.PATCH` versions.
+
+**Scope of automated detection:** The script detects breaking changes by diffing
+the config YAML field surface (`pkg/config/schema.yaml`). Other API-breaking
+changes — Go type signatures, HTTP API shape, security policy, behavior semantics
+— are not automatically detected. Use `--force` with the appropriate bump level
+for those cases.
+
+---
+
+## Core Rule: Tags Are Developer-Created, Never CI-Created
+
+CI reacts to pushed tags to run the release pipeline. CI never creates tags.
+A version tag is a human commitment about what a commit represents — that
+decision requires review and cannot be automated.
+
+---
+
+## Tooling
+
+| Script | Purpose |
+| --- | --- |
+| `scripts/release/create-release.sh` | Compute, approve, tag, and push a release |
+| `scripts/release/gen-schema.sh` | Regenerate `pkg/config/schema.yaml` after config changes |
+| `cmd/config-schema/main.go` | Go tool: reflection-walk of `config.Config` → dotted YAML paths |
+| `make gen-schema` | Alias for `gen-schema.sh` |
+| `make create-release` | Alias for `create-release.sh` (auto mode) |
+| `make create-release FORCE=v1.0.0` | Alias for `create-release.sh --force v1.0.0` |
+
+---
+
+## How Version Bumps Are Computed
+
+The script diffs `pkg/config/schema.yaml` at the previous tag against the file
+at `HEAD`. The schema lists every fully-flattened dotted YAML field path in
+`config.Config` (e.g. `sidecar.circuit_breaker.reset_timeout`).
+
+| Schema change | Bump level | semver.org rationale |
+| --- | --- | --- |
+| One or more fields **removed** | **major** — breaking change | Removing a field is an incompatible API change ([item 4](https://semver.org/#spec-item-4)) |
+| One or more fields **added**, none removed | **minor** — new feature | New fields are backward-compatible additions ([item 5](https://semver.org/#spec-item-5)) |
+| No field surface changes | **patch** — internal improvements | No public API surface change ([item 6](https://semver.org/#spec-item-6)) |
+
+---
+
+## Normal Release Flow
+
+```bash
+git checkout main && git pull --ff-only
+# ... merge your work ...
+./scripts/release/create-release.sh
+```
+
+The script will:
+
+1. Verify you are on `main`, your branch's configured upstream is in sync, and the working tree is clean.
+2. Compute the field diff and determine the bump level.
+3. Print the summary (fields added/removed, bump level, proposed tag message).
+4. Prompt for `y/N` approval.
+5. On approval: create a signed annotated tag and push it to the upstream remote.
+
+CI picks up the pushed tag and runs the release pipeline (build, sign, SBOM,
+publish).
+
+---
+
+## Forcing a Specific Version
+
+Use `--force vX.Y.Z` to override the computed version. Only bare `MAJOR.MINOR.PATCH`
+versions are accepted — pre-release extensions (`-alpha.1`) and build metadata
+(`+sha`) are not supported.
+
+```bash
+./scripts/release/create-release.sh --force v1.0.0
+```
+
+### Pre-1.0 rules (current major = 0)
+
+Per [semver.org item 9](https://semver.org/#spec-item-9), `0.y.z` is for initial
+development where the API is not yet stable. Only the following targets are accepted:
+
+- Any `0.x.y` where `0.x.y > current` — normal initial-development progression.
+- Exactly `v1.0.0` — the stable API promotion per [semver.org item 10](https://semver.org/#spec-item-10),
+  regardless of detected bump level.
+
+Forcing `v1.1.0`, `v2.0.0`, or any other version outside this range is rejected.
+
+### Post-1.0 rules (current major ≥ 1)
+
+Once `1.0.0` is released the public API is stable. `--force` is restricted to
+exact single-step increments per semver.org's ordering rules:
+
+| `--force` target | Condition | Result |
+| --- | --- | --- |
+| `cur_maj.cur_min.(cur_pat+1)` | any | **Allowed** — single patch step |
+| `cur_maj.(cur_min+1).0` | any | **Allowed** — single minor step (e.g. internal improvements not reflected in schema diff) |
+| `(cur_maj+1).0.0` | breaking changes detected AND matches computed version | **Allowed** |
+| `(cur_maj+1).0.0` | no breaking changes, or doesn't match computed | **Rejected** — major bump requires a detected breaking change |
+| anything else | — | **Rejected** — must be a single-step increment |
+
+---
+
+## Keeping schema.yaml Fresh
+
+`pkg/config/schema.yaml` is a committed artifact generated from `config.Config`
+by reflection. The pre-commit hook regenerates and stages it automatically
+whenever any `pkg/config/*.go` file is part of a commit — no manual step required.
+
+To regenerate it outside of a commit (e.g. to inspect the current output):
+
+```bash
+./scripts/release/gen-schema.sh
+# or
+make gen-schema
+```
+
+The consistency test suite enforces that `schema.yaml` is never stale — a
+mismatch between the committed file and the reflection output fails CI.
+
+---
+
+## What Goes in the Tag Message
+
+The script auto-generates a signed annotated tag with a structured message:
+
+- **Subject line:** `{bump}: {short summary}` (e.g. `minor: added 2 config field(s)`)
+- **Body:** full field list, bump level, previous/new version, commit SHA, and
+  provenance trailers (`Generated-by:`, `Schema:`)
+
+The GitHub Release body is populated directly from the tag message via
+`gh release create --notes-from-tag`.
+
+---
+
+## Emergency / Break-Glass
+
+If a critical patch must ship and the normal flow is blocked, follow the
+break-glass procedure in `docs/break-glass.md`. The bypass still requires two
+senior engineers and an incident record — it does not bypass the tag-creation
+requirement, only the precondition checks.

package/governance/runtime.md

@@ -0,0 +1,165 @@
+# Runtime and Orchestration Standards
+
+These rules govern container design, orchestration, deployment, and policy compliance.
+They are non-negotiable unless explicitly superseded by a signed ADR.
+
+**Maturity:** Required
+**Version:** 1.0.0
+**Last Reviewed:** 2026-03-09
+
+## Containers and Artifacts
+
+### Versioning
+
+1. All published artifacts (container images, packages, binaries) use Semantic Versioning (SemVer).
+   Unversioned or date-stamped-only artifacts are prohibited.
+2. The artifact tag is the SemVer string. The `latest` tag must not be used in staging or
+   production manifests.
+
+### Container Design
+
+3. One process per container. Process supervisors (supervisord, s6) and multi-process containers
+   are prohibited except for sidecar patterns enforced by the service mesh.
+4. Multiple entry points (different commands/args) for the same image are allowed where the image
+   provides genuinely distinct modes (e.g., `serve` and `migrate`). Each entry point must be
+   documented in the image's README.
+5. Containers run as a non-root user. `USER root` in the final image stage is prohibited.
+6. Container filesystems are read-only where possible. Writable directories are explicitly declared
+   and limited to ephemeral paths (`/tmp`, named volumes).
+
+### Artifact Metadata
+
+7. Every artifact must embed: Git commit SHA, repository URL, branch, build timestamp, and SemVer.
+   These are queryable via a `version` subcommand or equivalent metadata endpoint.
+8. Artifacts are tagged with: SemVer, commit SHA short form, and environment target (`dev`, `staging`,
+   `prod`). Promotion from one environment to the next reuses the same image digest — it is never rebuilt.
+
+### Registry Lifecycle
+
+9. Image promotion lifecycle: `dev` registry → `staging` registry → `prod` registry.
+   Artifacts flow in one direction; no artifact is pulled from `prod` into `dev`.
+10. Artifacts not promoted to `staging` within 30 days of build are expired from the `dev` registry.
+11. Artifacts in `prod` are retained for a minimum of 12 months.
+
+### Security Scanning
+
+12. CVE scanning runs on every artifact before it is pushed to any registry. The approved scanner
+    is documented in the internal vendor registry.
+13. Critical CVEs block promotion. High CVEs require a documented exception with an accepted
+    remediation timeline (maximum 30 days). Medium and below are tracked but do not block promotion.
+14. A Software Bill of Materials (SBOM) in SPDX or CycloneDX format is generated for every release
+    artifact. The SBOM is attached to the release and stored alongside the artifact digest.
+
+## Orchestration
+
+### Declarative Manifests
+
+15. All workloads are declared via version-controlled orchestration manifests (Kubernetes YAML,
+    Helm charts, Kustomize overlays, or equivalent). Manual `kubectl apply` of locally generated
+    YAML in production is prohibited.
+16. Manifests are validated (lint + schema check) as a required CI step before merge.
+
+### Probes
+
+17. Every container that serves traffic must define `livenessProbe`, `readinessProbe`, and
+    optionally `startupProbe`.
+18. Readiness probes must reflect actual service readiness (e.g., database connection established,
+    cache warm) not just process startup.
+19. Liveness probe failures must trigger a container restart, not a silent hang. Liveness probe
+    endpoints must not have side effects.
+
+### Resource Quotas
+
+20. Every workload declares `resources.requests` and `resources.limits` for CPU and memory.
+    Pods without resource declarations are rejected by admission control.
+21. Resource requests must reflect measured steady-state usage. Over-requesting by more than 3×
+    the p99 measured usage requires justification.
+22. Namespace-level `ResourceQuota` and `LimitRange` objects are applied to all tenant namespaces.
+
+### High Availability
+
+23. All production workloads run in a minimum of two availability zones. Single-zone deployments
+    are prohibited in production.
+24. `PodAntiAffinity` rules are configured to prevent all replicas of a deployment from scheduling
+    onto a single node or zone.
+25. Minimum replica count for production services is 2. Services with replica count 1 require
+    documented justification and ARB approval.
+
+## Deployment
+
+### Deployment Strategy
+
+26. All production deployments use a rolling, blue/green, or canary strategy. Big-bang
+    (recreate) deploys are prohibited in production.
+27. Deployments support rollback to the previous artifact version within 5 minutes.
+28. Deployment events are logged in the audit log with: artifact version, deploy actor, environment,
+    start time, end time, and outcome.
+
+### Zero-Downtime Deployment
+
+29. Zero-downtime deployment capability is required for all production services.
+30. Traffic shaping during rollout: network load balancer or service mesh gradually shifts
+    traffic from the old version to the new version. Hard cutover is prohibited.
+31. APIs must be backward-compatible across a deployment window. Breaking API changes require
+    a versioned endpoint strategy before the old version is retired.
+32. Schema migrations (database, event schema) are non-breaking and phased:
+    - Phase 1: add new column/field (backward-compatible with old code).
+    - Phase 2: deploy new code that writes both old and new.
+    - Phase 3: backfill and migrate data.
+    - Phase 4: remove old column/field only after old code is fully retired.
+33. Feature flags or service mesh routing rules are used to gate new behavior during deployment.
+    A feature can be promoted or rolled back independently of the artifact version.
+
+### Service Mesh
+
+34. All east-west (pod-to-pod) traffic runs through the service mesh. Direct pod-to-pod
+    communication bypassing the mesh is prohibited in staging and production.
+35. The mesh enforces mTLS, authorization policy, and traffic observability on all managed traffic.
+36. Circuit breakers and retry budgets are configured per service. Default retry-all-failures
+    behavior is prohibited; retries must be limited and idempotent-safe.
+
+### Secrets Management
+
+37. Application secrets (database passwords, API keys, private keys) are injected at runtime
+    from the approved secrets manager. Secrets must not be embedded in container images,
+    manifests, environment variable literals, or version-controlled configuration.
+38. Secrets are mounted as in-memory volumes or environment variables injected by the secrets
+    sidecar/operator. Secrets written to the container filesystem at rest are prohibited.
+39. Secret access is logged by the secrets manager. Unexpected access patterns alert the
+    security team.
+
+## Policy and Compliance
+
+### Change Management
+
+40. All infrastructure changes are managed via GitOps or a declarative change management system.
+    Out-of-band changes (manual console, ad-hoc CLI) are prohibited in staging and production and
+    will be detected and reverted by reconciliation.
+41. Production changes require approval from at least one person who is not the change author.
+42. Every production change record includes a rollback plan. Changes without a tested rollback plan
+    are not approved.
+43. CTO and ARB policy documents are archived and versioned. Historical policy versions are accessible.
+
+### Compliance
+
+44. The platform maintains SOC-2 Type II compliance. Evidence collection is automated where possible.
+45. GDPR and CCPA requirements apply to all data processing pipelines. Privacy impact assessments
+    are required for new data processing features that handle personal data.
+46. A Secure Development Lifecycle (SDL) is followed: threat modeling, SAST, DAST, dependency
+    scanning, and penetration testing are performed on a defined cadence.
+47. ISO 27001 and NIST SP 800-53 are used as optional benchmarks to inform control selection.
+    Controls are documented but full certification is optional unless contractually required.
+
+## Do Not
+
+- Use the `latest` tag in staging or production manifests.
+- Run containers as root.
+- Deploy workloads without liveness and readiness probes.
+- Deploy workloads without CPU and memory resource limits.
+- Run a production service with fewer than two availability zones.
+- Perform big-bang (recreate) deploys in production.
+- Embed secrets in images, manifests, or version-controlled configuration.
+- Allow service-to-service traffic to bypass the service mesh in staging or production.
+- Perform breaking schema migrations in a single phase.
+- Make infrastructure changes outside of the approved GitOps workflow.
+- Approve a production change without a rollback plan.