feat(blog): compliance results news and GTR page

content/en/blog/2026-08-31-cozystack-certified-kubernetes-conformance/index.md

@@ -0,0 +1,44 @@
+---
+title: "Cozystack Is Certified Kubernetes: v1.35 and v1.34 in the CNCF Conformance Record"
+slug: cozystack-certified-kubernetes-conformance
+date: 2026-08-31
+author: "Timur Tukaev"
+description: "Tenant Kubernetes clusters created by Cozystack pass the CNCF conformance suite in full on five releases, and the v1.35 and v1.34 results are accepted into the CNCF conformance record."
+images:
+  - "k8s-conformance.png"
+article_types:
+  - news
+topics:
+  - kubernetes
+  - platform
+---
+
+{{< figure src="k8s-conformance.png" alt="Cozystack is Certified Kubernetes — conformance results for Kubernetes v1.31 to v1.35" width="720" >}}
+
+Cozystack is now listed as a Certified Kubernetes distribution. The conformance results for
+Kubernetes v1.35 and v1.34 are accepted and published in the CNCF conformance repository, at
+[`v1.35/cozystack`](https://github.com/cncf/k8s-conformance/tree/master/v1.35/cozystack) and
+[`v1.34/cozystack`](https://github.com/cncf/k8s-conformance/tree/master/v1.34/cozystack).
+
+The tested artifact is the tenant Kubernetes cluster a user creates from the catalog. Clusters
+on five releases, from v1.31 to v1.35, ran the full suite with Sonobuoy in
+`certified-conformance` mode on a Cozystack v1.6.1 installation, and every run finished with
+zero failed tests.
+
+Conformance answers the question every evaluation starts with: is this real Kubernetes? A
+conformant cluster runs standard manifests, Helm charts and operators without a vendor dialect.
+Passing on older releases matters too — when migrating from an existing platform, you can move
+onto Cozystack at the Kubernetes version you run today and upgrade later on your own schedule.
+
+Hikube, a hosted platform built on Cozystack, holds its own CNCF listings for v1.35, v1.34 and
+v1.33.
+
+The full results and methodology are on the
+[Kubernetes Conformance](/compliance/kubernetes-conformance/) page.
+
+## Join the community
+
+- [Cozystack on GitHub](https://github.com/cozystack/cozystack)
+- Telegram [group](https://t.me/cozystack)
+- Slack [group](https://kubernetes.slack.com/archives/C06L3CPRVN1) (Get invite at [https://slack.kubernetes.io](https://slack.kubernetes.io))
+- [Community Meeting Calendar](https://calendar.google.com/calendar?cid=ZTQzZDIxZTVjOWI0NWE5NWYyOGM1ZDY0OWMyY2IxZTFmNDMzZTJlNjUzYjU2ZGJiZGE3NGNhMzA2ZjBkMGY2OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t)

content/en/blog/2026-09-15-cozystack-kubernetes-ai-conformance/index.md

@@ -0,0 +1,49 @@
+---
+title: "Cozystack Passes CNCF Kubernetes AI Conformance"
+slug: cozystack-kubernetes-ai-conformance
+date: 2026-09-15
+author: "Timur Tukaev"
+description: "Tenant Kubernetes clusters created by Cozystack meet all twelve requirements of the CNCF Kubernetes AI Conformance programme, and the v1.35 self-assessment is accepted into the CNCF record."
+images:
+  - "ai-conformance.png"
+article_types:
+  - news
+topics:
+  - kubernetes
+  - gpu
+  - platform
+---
+
+{{< figure src="ai-conformance.png" alt="Cozystack passes Kubernetes AI Conformance — all twelve CNCF requirements met" width="720" >}}
+
+Cozystack meets all twelve requirements of the CNCF Kubernetes AI Conformance programme. The
+v1.35 self-assessment, filed by Ænix for Cozystack v1.6.1, is accepted and published in the
+CNCF repository at
+[`v1.35/cozystack`](https://github.com/cncf/k8s-ai-conformance/tree/main/v1.35/cozystack).
+
+Base Kubernetes conformance answers "is this real Kubernetes". AI conformance answers a more
+practical question: will an AI workload that runs on one conformant platform run here too,
+without platform-specific workarounds.
+
+The requirements span accelerators, networking, scheduling, observability, security and
+operators. On a tenant Kubernetes cluster, Cozystack covers them with:
+
+- the Dynamic Resource Allocation API and the NVIDIA GPU Operator as a cluster addon;
+- GPU sharing through MIG partitions or HAMi time-slicing;
+- GPUs attached to virtual worker nodes, declared in the node pool definition;
+- Gateway API with weighted and header-based routing for model serving;
+- gang scheduling with Kueue and node pools that scale on GPU demand, down to zero;
+- accelerator and workload metrics collected through DCGM and VMAgent.
+
+Because tenant workers are separate virtual machines with their own kernel, a GPU attached to
+one tenant's node pool is not reachable from another tenant's workloads.
+
+Each requirement, the mechanism behind it and the command that verifies it are on the
+[AI Conformance](/compliance/ai-conformance/) page.
+
+## Join the community
+
+- [Cozystack on GitHub](https://github.com/cozystack/cozystack)
+- Telegram [group](https://t.me/cozystack)
+- Slack [group](https://kubernetes.slack.com/archives/C06L3CPRVN1) (Get invite at [https://slack.kubernetes.io](https://slack.kubernetes.io))
+- [Community Meeting Calendar](https://calendar.google.com/calendar?cid=ZTQzZDIxZTVjOWI0NWE5NWYyOGM1ZDY0OWMyY2IxZTFmNDMzZTJlNjUzYjU2ZGJiZGE3NGNhMzA2ZjBkMGY2OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t)

content/en/blog/2026-09-29-cozystack-cncf-general-technical-review/index.md

@@ -0,0 +1,50 @@
+---
+title: "Cozystack Completes the CNCF General Technical Review"
+slug: cozystack-cncf-general-technical-review
+date: 2026-09-29
+author: "Timur Tukaev"
+description: "Cozystack has completed the CNCF General Technical Review for incubation, with overhead, load and upgrade behaviour measured on a reference bench and the open gaps listed plainly."
+images:
+  - "gtr.png"
+article_types:
+  - news
+topics:
+  - platform
+  - community
+  - security
+---
+
+{{< figure src="gtr.png" alt="Cozystack completes the CNCF General Technical Review — reference bench results" width="720" >}}
+
+Cozystack has completed the CNCF General Technical Review, the technical half of the due
+diligence for moving from Sandbox to Incubation. The snapshot is filed with the CNCF Technical
+Oversight Committee in [cncf/toc#2305](https://github.com/cncf/toc/pull/2305), and the living
+document is kept in the repository as
+[`GENERAL_TECHNICAL_REVIEW.md`](https://github.com/cozystack/cozystack/blob/main/GENERAL_TECHNICAL_REVIEW.md).
+
+The review asks what an operator asks before trusting a platform in production — how it is
+installed, upgraded and rolled back, what it costs to run, how it fails, and how security
+issues are handled — across Day 0 planning, Day 1 installation and Day 2 operations.
+
+Questions about overhead and scale were answered by measurement, on three servers with
+32 vCPU and 128 GB each:
+
+- the idle platform takes about one CPU core and 19 GiB of memory across all three nodes;
+- 71 managed PostgreSQL instances with replicated volumes ran with no failures;
+- a mixed load of about 76 applications and 402 pods reached Ready without hitting a compute,
+  memory or storage ceiling;
+- an upgrade converged in about three minutes, a downgrade in about four, and every
+  replicated volume survived all four version changes.
+
+The review also records what is still missing, including image signing, a published API
+stability policy and an aggregate `NOTICE` file. Each gap is tracked in the open.
+
+A summary of the review, with the measurements and the open items, is on the
+[General Technical Review](/compliance/general-technical-review/) page.
+
+## Join the community
+
+- [Cozystack on GitHub](https://github.com/cozystack/cozystack)
+- Telegram [group](https://t.me/cozystack)
+- Slack [group](https://kubernetes.slack.com/archives/C06L3CPRVN1) (Get invite at [https://slack.kubernetes.io](https://slack.kubernetes.io))
+- [Community Meeting Calendar](https://calendar.google.com/calendar?cid=ZTQzZDIxZTVjOWI0NWE5NWYyOGM1ZDY0OWMyY2IxZTFmNDMzZTJlNjUzYjU2ZGJiZGE3NGNhMzA2ZjBkMGY2OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t)

content/en/compliance/_index.md

@@ -39,3 +39,7 @@ command you can run against your own cluster.
   record, with the mechanism and a command behind each: DRA, GPU Operator and MIG/HAMi sharing,
   GPUs across the VM boundary, Gateway API inference routing, Kueue gang scheduling, and
   accelerator metrics.
+- **[General Technical Review](/compliance/general-technical-review/)** — the CNCF
+  due-diligence questionnaire answered for Day 0, Day 1 and Day 2: install paths, upgrade and
+  rollback, overhead and load measured on a reference bench, security response, and the gaps
+  that are still open.

content/en/compliance/general-technical-review.md

@@ -0,0 +1,117 @@
+---
+title: "CNCF General Technical Review of Cozystack"
+linkTitle: "General Technical Review"
+description: "The CNCF General Technical Review for Cozystack: how the platform is planned, installed, upgraded and operated, what was measured on a reference bench, and which gaps are still open."
+date: 2026-09-29
+type: "page"
+weight: 50
+---
+
+**Cozystack has completed the CNCF General Technical Review (GTR).** The review is the
+technical half of the due diligence a project goes through on its way from Sandbox to
+Incubation. Where conformance programmes ask whether a platform behaves as a standard says it
+should, the GTR asks the questions an operator asks before trusting a platform in production:
+how it is installed, how it is upgraded and rolled back, what it costs to run, how it fails,
+and how security issues are found and fixed.
+
+The questionnaire is answered in full and kept in the project repository as
+[`GENERAL_TECHNICAL_REVIEW.md`](https://github.com/cozystack/cozystack/blob/main/GENERAL_TECHNICAL_REVIEW.md).
+A dated snapshot is filed with the CNCF Technical Oversight Committee in
+[cncf/toc#2305](https://github.com/cncf/toc/pull/2305), alongside the Cozystack
+[incubation application](https://github.com/cncf/toc/issues/1916). This page summarises what
+the review records; the document itself is the source of every figure below.
+
+## What the review covers
+
+The template follows the life of a platform in three phases, and each answer points at code,
+documentation or a measurement rather than at intentions.
+
+- **Day 0, planning** — scope, target users, architecture, dependencies, API design, release
+  process, installation and the security posture of the project.
+- **Day 1, installation and deployment** — enabling and removing the platform in a live
+  cluster, resource cleanup, and upgrade and rollback planning.
+- **Day 2, operations** — scalability limits, observability, dependency management,
+  troubleshooting, compliance and security response.
+
+The review is answered for Cozystack v1.6.3, the latest stable release at the time of
+submission.
+
+## Deployment model
+
+One correction to a common assumption is worth stating first, because the review makes it
+explicit: **Cozystack is not Talos-only.** Talos Linux is the recommended path, where the
+platform owns the nodes and they run immutable, with no SSH and no shell. The same platform
+also installs on generic Linux — Ubuntu, Debian, RHEL, Rocky or openSUSE — through the
+Ansible collection, which bootstraps k3s, and onto an existing Kubernetes cluster. Every path
+recommends at least three servers.
+
+## Measured on a reference bench
+
+The questions about overhead, scale and upgrades were answered by running the platform rather
+than by estimating. The bench was three servers with 32 vCPU and 128 GB of memory each,
+installed on the generic Linux path.
+
+| What was measured | Result |
+|---|---|
+| Idle platform overhead | about 1 CPU core and 19 GiB of memory across all three nodes, before any tenant workload |
+| Concurrent managed databases | 71 PostgreSQL instances, each with a replicated volume, with no failures and no node pressure |
+| Mixed load across application types | about 76 applications and 402 pods — tenants, VMs, Redis, MariaDB, ClickHouse, Kafka — all Ready |
+| Upgrade to the next patch release | converged in about 175–200 seconds |
+| Downgrade back | converged in about 250 seconds |
+| Data across upgrade and downgrade | every replicated volume survived all four version changes |
+
+The ceiling the bench reached was not compute, memory or storage. It was the kubelet
+`max-pods` limit and the throughput of the Flux helm-controller — and when the helm-controller
+became congested, Cozystack's shard operator added a second shard on its own. The review also
+records one upgrade-time hazard found on the bench: after a control-plane node is replaced,
+the address of the original node must be repointed in the CNI configuration, or service
+networking can drop during the next reconcile.
+
+## Security
+
+The review is filed together with the Cozystack
+[security self-assessment](https://github.com/cozystack/cozystack/blob/main/docs/security/self-assessment.md),
+[threat model](https://github.com/cozystack/cozystack/blob/main/docs/security/threat-model.md)
+and [incident-response process](https://github.com/cozystack/cozystack/blob/main/docs/security/incident-response.md).
+It describes how vulnerabilities reach the project and how fast they are handled:
+
+- reports arrive through GitHub private vulnerability reporting, handled by a security
+  response team drawn from more than one organisation and more than one country;
+- every repository in the organisation is scanned with Trivy for vulnerable dependencies and
+  container images — critical findings every six hours, the rest weekly — and each actionable
+  finding becomes a tracked issue;
+- a rotating Security Champion owns the triage clock and runs a weekly pass;
+- monthly aggregate reports are published in
+  [`docs/security/reports/`](https://github.com/cozystack/cozystack/tree/main/docs/security/reports),
+  with identifiers withheld until a fix has shipped.
+
+## What is still open
+
+A review that lists only strengths is not useful to anyone evaluating a platform, and this one
+records its gaps plainly:
+
+- release images are not yet signed, build provenance is disabled, and SBOM generation is
+  implemented but off by default;
+- there is no published API stability and deprecation policy — the application API group is
+  still `v1alpha1`;
+- there is no top-level `NOTICE` file aggregating attribution for the bundled components;
+- no default Kubernetes audit policy ships with the platform;
+- the scheduled full end-to-end test run has been unreliable, so coverage rests on the
+  per-pull-request end-to-end job;
+- the upgrade matrix still needs a pristine three-node rerun and a run on the Talos path.
+
+Each of these is tracked in the open, and the review links to the issue where one exists.
+
+## Related results
+
+- [Kubernetes Conformance](/compliance/kubernetes-conformance/) — tenant clusters pass the
+  CNCF conformance suite in full, with v1.35 and v1.34 in the CNCF record.
+- [AI Conformance](/compliance/ai-conformance/) — all twelve requirements of the CNCF
+  Kubernetes AI Conformance programme met, with the v1.35 self-assessment accepted.
+
+## Notes
+
+The review follows version 1.0 of the CNCF
+[General Technical Review template](https://github.com/cncf/toc/blob/main/toc_subprojects/project-reviews-subproject/general-technical-questions.md).
+Bench measurements were taken on 18–19 September 2026 on the generic Linux path with the
+`isp-full-generic` variant.

hugo.yaml

@@ -349,6 +349,10 @@ menus:
     url: /compliance/ai-conformance/
     parent: compliance
     weight: 6
+  - name: General Technical Review
+    url: /compliance/general-technical-review/
+    parent: compliance
+    weight: 7
   - name: Community
     url: /community/
     parent: resources