@keelcore/standards 0.9.7 → 0.10.0

package/governance/runtime.md

@@ -1,154 +1,146 @@
 # 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.
+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
+**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.
+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).
+1. One process per container. Process supervisors (supervisord, s6) and multi-process containers are prohibited except
+   for sidecar patterns enforced by the service mesh.
+2. 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.
+3. Containers run as a non-root user. `USER root` in the final image stage is prohibited.
+4. 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.
+1. 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.
+2. 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.
+1. Image promotion lifecycle: `dev` registry → `staging` registry → `prod` registry. Artifacts flow in one direction; no
+   artifact is pulled from `prod` into `dev`.
+2. Artifacts not promoted to `staging` within 30 days of build are expired from the `dev` registry.
+3. 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.
+1. CVE scanning runs on every artifact before it is pushed to any registry. The approved scanner is documented in the
+   internal vendor registry.
+2. 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.
+3. 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.
+1. 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.
+2. 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.
+1. Every container that serves traffic must define `livenessProbe`, `readinessProbe`, and optionally `startupProbe`.
+2. Readiness probes must reflect actual service readiness (e.g., database connection established, cache warm) not just
+   process startup.
+3. 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.
+1. Every workload declares `resources.requests` and `resources.limits` for CPU and memory. Pods without resource
+   declarations are rejected by admission control.
+2. Resource requests must reflect measured steady-state usage. Over-requesting by more than 3× the p99 measured usage
+   requires justification.
+3. 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.
+1. All production workloads run in a minimum of two availability zones. Single-zone deployments are prohibited in
+   production.
+2. `PodAntiAffinity` rules are configured to prevent all replicas of a deployment from scheduling onto a single node or
+   zone.
+3. 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.
+1. All production deployments use a rolling, blue/green, or canary strategy. Big-bang (recreate) deploys are prohibited
+   in production.
+2. Deployments support rollback to the previous artifact version within 5 minutes.
+3. 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.
+1. Zero-downtime deployment capability is required for all production services.
+2. 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.
+3. APIs must be backward-compatible across a deployment window. Breaking API changes require a versioned endpoint
+   strategy before the old version is retired.
+4. 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.
+5. 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.
+1. 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.
+2. The mesh enforces mTLS, authorization policy, and traffic observability on all managed traffic.
+3. 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.
+1. 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.
+2. 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.
+3. 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.
+1. 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.
+2. Production changes require approval from at least one person who is not the change author.
+3. Every production change record includes a rollback plan. Changes without a tested rollback plan are not approved.
+4. 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.
+1. The platform maintains SOC-2 Type II compliance. Evidence collection is automated where possible.
+2. GDPR and CCPA requirements apply to all data processing pipelines. Privacy impact assessments are required for new
+   data processing features that handle personal data.
+3. A Secure Development Lifecycle (SDL) is followed: threat modeling, SAST, DAST, dependency scanning, and penetration
+   testing are performed on a defined cadence.
+4. 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
 

package/governance/security.md

@@ -1,139 +1,131 @@
 # Security Standards
 
-These rules govern identity and access management, encryption, key management, and data handling.
-They are non-negotiable unless explicitly superseded by a signed ADR.
+These rules govern identity and access management, encryption, key management, and data handling. They are
+non-negotiable unless explicitly superseded by a signed ADR.
 
-**Maturity:** Required
-**Version:** 1.0.0
-**Last Reviewed:** 2026-03-09
+**Maturity:** Required **Version:** 1.0.0 **Last Reviewed:** 2026-03-09
 
 ## Identity and Access Management
 
 ### Federated Authentication
 
-1. All human-facing authentication uses a federated identity provider (IdP) via OIDC or SAML 2.0.
-   Local username/password stores are prohibited for production systems.
-2. The approved AuthN vendor(s) are documented in the internal vendor registry. No additional identity
-   providers are introduced without ARB approval and a security review.
-3. Multi-factor authentication (MFA) is required for all human accounts. Phishing-resistant MFA
-   (FIDO2/WebAuthn) is required for privileged and production access.
+1. All human-facing authentication uses a federated identity provider (IdP) via OIDC or SAML 2.0. Local
+   username/password stores are prohibited for production systems.
+2. The approved AuthN vendor(s) are documented in the internal vendor registry. No additional identity providers are
+   introduced without ARB approval and a security review.
+3. Multi-factor authentication (MFA) is required for all human accounts. Phishing-resistant MFA (FIDO2/WebAuthn) is
+   required for privileged and production access.
 
 ### Workload Identity
 
-4. Service-to-service authentication uses SPIFFE/SPIRE (or an equivalent SVID-based workload identity
-   system). Static shared secrets for service identity are prohibited.
-5. SPIFFE Verifiable Identity Documents (SVIDs) are issued with a maximum 24-hour TTL and rotated
-   automatically.
-6. JWT-based identity is acceptable for external API integrations where SPIFFE is not available.
-   JWTs must be signed (RS256 or ES256 minimum) and have an explicit `exp` claim. Unsigned or
-   HS256-signed JWTs are prohibited in production.
+1. Service-to-service authentication uses SPIFFE/SPIRE (or an equivalent SVID-based workload identity system). Static
+   shared secrets for service identity are prohibited.
+2. SPIFFE Verifiable Identity Documents (SVIDs) are issued with a maximum 24-hour TTL and rotated automatically.
+3. JWT-based identity is acceptable for external API integrations where SPIFFE is not available. JWTs must be signed
+   (RS256 or ES256 minimum) and have an explicit `exp` claim. Unsigned or HS256-signed JWTs are prohibited in
+   production.
 
 ### Token Lifecycle and Revocation
 
-7. Access tokens have a maximum lifetime of 15 minutes. Refresh tokens have a maximum lifetime of
-   8 hours for human sessions; service refresh tokens do not exist (workload identity handles renewal).
-8. Token revocation is effective within 60 seconds. Caches that hold token validation results must
-   honor the revocation TTL.
-9. Refresh tokens are single-use and rotated on every use. Reuse of a refresh token triggers
-   immediate session termination and a security alert.
-10. All issued tokens are logged with: issuer, subject, audience, `jti`, issued-at, and expiry.
+1. Access tokens have a maximum lifetime of 15 minutes. Refresh tokens have a maximum lifetime of 8 hours for human
+   sessions; service refresh tokens do not exist (workload identity handles renewal).
+2. Token revocation is effective within 60 seconds. Caches that hold token validation results must honor the revocation
+   TTL.
+3. Refresh tokens are single-use and rotated on every use. Reuse of a refresh token triggers immediate session
+   termination and a security alert.
+4. All issued tokens are logged with: issuer, subject, audience, `jti`, issued-at, and expiry.
 
 ## Authorization
 
 ### Service-Level Routing AuthZ
 
-11. API gateways and ingress controllers enforce coarse-grained authorization (service-to-service
-    trust boundaries) before traffic reaches application pods.
-12. Services must not trust the caller's claimed identity from request headers alone; the identity
-    assertion must be cryptographically verified (mTLS client cert or verified JWT) by the mesh or
-    gateway layer.
+1. API gateways and ingress controllers enforce coarse-grained authorization (service-to-service trust boundaries)
+   before traffic reaches application pods.
+2. Services must not trust the caller's claimed identity from request headers alone; the identity assertion must be
+   cryptographically verified (mTLS client cert or verified JWT) by the mesh or gateway layer.
 
 ### Role-Based Access Control (RBAC)
 
-13. RBAC roles are defined at the minimum privilege required for each function. There are no
-    "superuser" roles in production except for documented break-glass accounts.
-14. Role assignments are reviewed quarterly. Stale role assignments are revoked automatically after
-    90 days without reaffirmation.
-15. Role definitions and assignments are stored in version-controlled configuration. Manual UI-based
-    role grants that bypass version control are prohibited.
+1. RBAC roles are defined at the minimum privilege required for each function. There are no "superuser" roles in
+   production except for documented break-glass accounts.
+2. Role assignments are reviewed quarterly. Stale role assignments are revoked automatically after 90 days without
+   reaffirmation.
+3. Role definitions and assignments are stored in version-controlled configuration. Manual UI-based role grants that
+   bypass version control are prohibited.
 
 ### Attribute-Based Access Control (ABAC)
 
-16. Fine-grained access decisions (data-level, row-level) are implemented via ABAC policies in the
-    centralized policy engine (OPA or equivalent).
-17. ABAC policies are co-located with the service that owns the resource. Cross-service policy
-    definitions require ARB approval.
+1. Fine-grained access decisions (data-level, row-level) are implemented via ABAC policies in the centralized policy
+   engine (OPA or equivalent).
+2. ABAC policies are co-located with the service that owns the resource. Cross-service policy definitions require ARB
+   approval.
 
 ### Centralized Policy Engine
 
-18. The approved policy engine (OPA or equivalent) is the single source of truth for all
-    authorization decisions. Services must not implement ad-hoc authorization logic that duplicates
-    or overrides centralized policy.
-19. Policies are version-controlled. Every policy change requires a review and an audit log entry.
-20. The policy engine exposes a health endpoint; its unavailability must cause authorization
-    decisions to fail closed (deny), not fail open (permit).
+1. The approved policy engine (OPA or equivalent) is the single source of truth for all authorization decisions.
+   Services must not implement ad-hoc authorization logic that duplicates or overrides centralized policy.
+2. Policies are version-controlled. Every policy change requires a review and an audit log entry.
+3. The policy engine exposes a health endpoint; its unavailability must cause authorization decisions to fail closed
+   (deny), not fail open (permit).
 
 ### Policy Versioning and Rollback
 
-21. Policies are tagged with a version identifier. The current version in force is queryable from
-    the policy engine.
-22. Any policy change can be rolled back to the previous version within 5 minutes via the policy
-    engine's rollback mechanism.
+1. Policies are tagged with a version identifier. The current version in force is queryable from the policy engine.
+2. Any policy change can be rolled back to the previous version within 5 minutes via the policy engine's rollback
+   mechanism.
 
 ### Delegated Permissions
 
-23. Delegated admin domains (e.g., team-level RBAC management) are scoped to the team's namespace.
-    Cross-namespace privilege delegation requires ARB approval.
-24. OAuth 2.0 delegated scopes must be explicitly documented per API. Broad wildcard scopes
-    (e.g., `*`, `admin`) are prohibited unless the API is itself an admin API.
+1. Delegated admin domains (e.g., team-level RBAC management) are scoped to the team's namespace. Cross-namespace
+   privilege delegation requires ARB approval.
+2. OAuth 2.0 delegated scopes must be explicitly documented per API. Broad wildcard scopes (e.g., `*`, `admin`) are
+   prohibited unless the API is itself an admin API.
 
 ## Encryption
 
 ### Encryption in Transit
 
-25. All traffic between pods, nodes, and external systems is encrypted. Plaintext communication
-    inside the cluster is prohibited in staging and production.
-26. Service-to-service encryption is enforced via mTLS at the service mesh layer.
-27. Traffic to external APIs uses TLS 1.2 minimum; TLS 1.3 preferred. See `governance/platform.md`
-    for cipher suite requirements.
+1. All traffic between pods, nodes, and external systems is encrypted. Plaintext communication inside the cluster is
+   prohibited in staging and production.
+2. Service-to-service encryption is enforced via mTLS at the service mesh layer.
+3. Traffic to external APIs uses TLS 1.2 minimum; TLS 1.3 preferred. See `governance/platform.md` for cipher suite
+   requirements.
 
 ### Encryption at Rest
 
-28. All persistent data stores (databases, object storage, message queues, caches) encrypt data
-    at rest using AES-256 or equivalent.
-29. Encryption keys for data at rest are managed by the approved key management service (KMS)
-    and never stored alongside the data they protect.
-30. Backup and snapshot data is encrypted with the same or stronger controls as primary data.
+1. All persistent data stores (databases, object storage, message queues, caches) encrypt data at rest using AES-256 or
+   equivalent.
+2. Encryption keys for data at rest are managed by the approved key management service (KMS) and never stored alongside
+   the data they protect.
+3. Backup and snapshot data is encrypted with the same or stronger controls as primary data.
 
 ### Key Management
 
-31. The approved KMS vendor(s) are documented in the internal vendor registry. Application-managed
-    key stores (manual key files, hardcoded keys) are prohibited.
-32. Encryption keys are rotated on a defined schedule: symmetric keys every 90 days, asymmetric
-    keys every 12 months, unless a shorter rotation is required by compliance or incident response.
-33. Key rotation is zero-downtime. Services must reload keys without restart.
+1. The approved KMS vendor(s) are documented in the internal vendor registry. Application-managed key stores (manual key
+   files, hardcoded keys) are prohibited.
+2. Encryption keys are rotated on a defined schedule: symmetric keys every 90 days, asymmetric keys every 12 months,
+   unless a shorter rotation is required by compliance or incident response.
+3. Key rotation is zero-downtime. Services must reload keys without restart.
 
 ### Formal Rapid Key Rotation
 
-34. The platform must support emergency key rotation with an SLA of 5 minutes or less for the
-    entire network.
-35. Services must reload encryption keys upon receiving a designated OS signal (e.g., SIGUSR1)
-    or a KMS-pushed notification, without process restart.
-36. Key rotation events are logged in the audit log with: key ID, rotation trigger (scheduled or
-    emergency), actor, and timestamp.
-37. Emergency key rotation is tested in staging at least quarterly. Results are documented.
+1. The platform must support emergency key rotation with an SLA of 5 minutes or less for the entire network.
+2. Services must reload encryption keys upon receiving a designated OS signal (e.g., SIGUSR1) or a KMS-pushed
+   notification, without process restart.
+3. Key rotation events are logged in the audit log with: key ID, rotation trigger (scheduled or emergency), actor, and
+   timestamp.
+4. Emergency key rotation is tested in staging at least quarterly. Results are documented.
 
 ## Data Classification and Handling
 
-38. All data is classified at creation time as one of: `public`, `internal`, `confidential`,
-    or `restricted`. Classification is stored as metadata alongside the data.
-39. `confidential` and `restricted` data must be encrypted at rest and in transit, accessed only
-    via authorized roles, and logged on every access.
-40. `restricted` data (e.g., payment card data, health records) must also be isolated in dedicated
-    storage with network-level segmentation from general-purpose stores.
-41. Data handling procedures for each classification level are documented in the internal data
-    handling policy. That policy is reviewed annually and after any significant breach or
-    compliance change.
+1. All data is classified at creation time as one of: `public`, `internal`, `confidential`, or `restricted`.
+   Classification is stored as metadata alongside the data.
+2. `confidential` and `restricted` data must be encrypted at rest and in transit, accessed only via authorized roles,
+   and logged on every access.
+3. `restricted` data (e.g., payment card data, health records) must also be isolated in dedicated storage with
+   network-level segmentation from general-purpose stores.
+4. Data handling procedures for each classification level are documented in the internal data handling policy. That
+   policy is reviewed annually and after any significant breach or compliance change.
 
 ## Do Not
 

package/governance/testing.md

@@ -2,17 +2,14 @@
 
 These rules govern all test code and test infrastructure in this project. They are non-negotiable.
 
-**Maturity:** Required
-**Version:** 1.0.0
-**Last Reviewed:** 2026-03-14
+**Maturity:** Required **Version:** 1.1.0 **Last Reviewed:** 2026-05-24
 
 ## Core Principle
 
 Unit tests do not cross system boundaries.
 
-A system boundary is anything that requires a network peer, an OS service, or an external process.
-If a test needs one of those, it is an integration test and belongs in BATS, Compose, or a
-cluster-level suite — not in a `_test.go` file.
+A system boundary is anything that requires a network peer, an OS service, or an external process. If a test needs one
+of those, it is an integration test and belongs in BATS, Compose, or a cluster-level suite — not in a `_test.go` file.
 
 ## What Goes in Unit Tests
 
@@ -36,8 +33,8 @@ cluster-level suite — not in a `_test.go` file.
 
 Do not mock external systems. Use real implementations in integration tests.
 
-Mocks replicate the mock author's understanding of a contract at a point in time. When the real
-system changes, mocks silently pass. Real tools catch contract drift.
+Mocks replicate the mock author's understanding of a contract at a point in time. When the real system changes, mocks
+silently pass. Real tools catch contract drift.
 
 Acceptable alternatives to real systems:
 
@@ -49,12 +46,12 @@ Acceptable alternatives to real systems:
 
 Every project MUST define the following test layers. Names and Makefile targets are fixed.
 
-| Layer | Makefile target | Scope | External deps |
-|---|---|---|---|
-| Unit | `make unit-test` | In-process logic; no system boundaries | None |
-| Integration | `make integration-test` | Binary + real peers | Test daemons on PATH |
-| Compose | `make test-compose` | Full stack via Docker Compose | Docker |
-| Kubernetes | `make test-k8s` | Helm deploy + pod probes | kind / Docker |
+| Layer       | Makefile target         | Scope                                  | External deps        |
+| ----------- | ----------------------- | -------------------------------------- | -------------------- |
+| Unit        | `make unit-test`        | In-process logic; no system boundaries | None                 |
+| Integration | `make integration-test` | Binary + real peers                    | Test daemons on PATH |
+| Compose     | `make test-compose`     | Full stack via Docker Compose          | Docker               |
+| Kubernetes  | `make test-k8s`         | Helm deploy + pod probes               | kind / Docker        |
 
 ## Test File Layout
 
@@ -70,15 +67,64 @@ Every project MUST define the following test layers. Names and Makefile targets
 - Upload JUnit XML as a workflow artifact for test history and flake detection.
 - Coverage profile MUST be produced on every unit test run.
 - `make coverage` prints: total %, uncovered statement count, total statement count.
-- `make ci-coverage-delta` compares PR head coverage against the merge-target base branch;
-  fails if coverage drops beyond the configured threshold.
+- `make ci-coverage-delta` compares PR head coverage against the merge-target base branch; fails if coverage drops
+  beyond the configured threshold.
+
+## Coverage Regression Policy
+
+**Per-file coverage SHALL NEVER decrease.** This is a non-negotiable, unwaivable invariant of every change. No
+`STANDARDS_OVERRIDES.md` entry can permit a regression; there is nothing to override because the rule is procedural,
+not policy.
+
+Granularity, baseline, comparison:
+
+- The unit of comparison is **per-file line coverage**: the ratio `LH / LF` for each `SF:` record in the LCOV report.
+  Totals or aggregate percentages are insufficient — a per-file improvement that masks a per-file regression is a
+  violation.
+- The baseline lives at `tests/coverage-baseline.lcov` in the consumer repo, tracked in git. It is updated only as
+  part of a change that strictly increases (or holds) coverage on every file present in both the baseline and the
+  current report, AND that meets the new-file floor (below) for every file added in that change set.
+- Comparison is `current vs baseline`:
+  - **Existing files** (`SF:` present in both): assert
+    `current.LH/current.LF >= baseline.LH/baseline.LF`. Equal or higher passes; lower fails.
+  - **New files** (`SF:` present only in current): assert
+    `current.LH/current.LF >= 0.95`. New files MUST land at ≥ 95% coverage. Files added with less than 95% per-file
+    coverage cause the gate to fail. This is an absolute floor — no override.
+  - **Deleted files** (`SF:` present only in baseline): drop out of comparison, but the baseline entry MUST be removed
+    in the same change set; otherwise the audit flags a stale baseline.
+- The enforcement target is `make ci-coverage-no-regression`. The implementation lives at
+  `scripts/test/coverage-no-regression.sh` (canonical; shipped). It consumes the LCOV from `make coverage` and the
+  baseline at `tests/coverage-baseline.lcov`; exits non-zero on any per-file regression OR new-file floor violation.
+
+Two consequences when a regression is detected:
+
+1. **CI gates the merge.** `make ci-coverage-no-regression` exits non-zero. The PR is rejected.
+2. **Assistant workflow procedure.** An assistant detecting a regression in its own work-in-progress MUST NOT present
+   the change for human approval. It MUST revert the offending change set, then report to the human: the file(s) whose
+   coverage decreased, the prior and current percentages, and the revert. The decision about next action belongs to
+   the human; the decision about whether to present is procedural and not the assistant's to make.
+
+Edge cases:
+
+- **Removing a file entirely is allowed.** When the file is removed, its baseline entry is removed in the same change
+  set. The comparison sees no `SF:` for that path in either side.
+- **Splitting a file** (one file becomes two) is treated as removal + two new files. Each resulting file is subject
+  to the new-file 95% floor from its first measurement; the original baseline entry is removed in the same change set.
+- **Baseline initialization** (the first run of `make coverage-baseline-init` against a repo with no prior baseline)
+  is exempt from the 95% new-file floor — every file is captured at its current ratio to seed the baseline. From the
+  second change set onward the rule binds in full: existing-file no-regression PLUS new-file 95% floor.
+- **Non-determinism in coverage tooling** (per-file numbers that drift across runs without code change) is itself a
+  violation. The cause must be fixed before the baseline can be trusted.
+
+This applies to every language with a per-file coverage report: Go (`go test -coverprofile`), Rust (`cargo-llvm-cov`
+LCOV), and any other.
 
 ## Test Modification Policy
 
 Test files are protected. Do not modify test files without explicit prior authorization.
 
-When a test fails, the correct response is to find and fix the root cause in production code —
-not to adjust the test to pass. A failing test is a signal, not an obstacle.
+When a test fails, the correct response is to find and fix the root cause in production code — not to adjust the test to
+pass. A failing test is a signal, not an obstacle.
 
 Exceptions require explicit approval:
 
@@ -88,8 +134,8 @@ Exceptions require explicit approval:
 
 ## FIPS Compatibility
 
-Tests that use `InsecureSkipVerify`, self-signed certs via `httptest`, or non-FIPS algorithms
-MUST be guarded with a FIPS skip:
+Tests that use `InsecureSkipVerify`, self-signed certs via `httptest`, or non-FIPS algorithms MUST be guarded with a
+FIPS skip:
 
 ```go
 if os.Getenv("GOFIPS140") != "" {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@keelcore/standards",
-  "version": "0.9.7",
+  "version": "0.10.0",
   "description": "Engineering standards for keelcore projects — coding, CI, and bash.",
   "keywords": [
     "standards",