Prepare Unbounded Kubernetes for CNCF Sandbox application

## Objective

Prepare Unbounded Kubernetes for a CNCF Sandbox application and maintain an evidence-backed, public-safe worksheet before opening the final application in `cncf/sandbox`.

This issue is the **public project-side coordination point**. Do not submit the final CNCF Sandbox issue until the proposed application has been approved by the project maintainers and the authorized contributing or sponsoring entity.

> This is a public issue. Record only public-safe facts, decisions, and approval status here. Do not post personal data, confidential legal advice, internal approval records, credentials, non-public asset inventories, security configuration, recovery contacts, access methods, or transfer procedures. The final CNCF application is also public, so designated contacts must consent before their information is published.

## Sources and status

Evidence was checked on **2026-07-29 UTC** against:

- [Current CNCF Sandbox application form](https://github.com/cncf/sandbox/issues/new?template=application.yml)
- [CNCF Sandbox process](https://github.com/cncf/sandbox/blob/main/README.md)
- [CNCF project lifecycle and process](https://github.com/cncf/toc/blob/main/process/README.md#cncf-project-lifecycle--process)
- [CNCF IP policy](https://github.com/cncf/foundation/blob/main/charter.md#11-ip-policy)
- [CNCF dependency-license allowlist](https://github.com/cncf/foundation/blob/main/policies-guidance/allowed-third-party-license-policy.md)
- [CNCF Sandbox support and marketing expectations](https://contribute.cncf.io/resources/project-services/maturity-levels/#sandbox)
- [llm-d Sandbox application example](https://github.com/cncf/sandbox/issues/462)
- [Unbounded repository](https://github.com/Azure/unbounded), documentation, source, releases, issues, and project policy files

Status terms used below:

- **Verified**: directly supported by a linked public source.
- **Proposed**: issue-ready wording inferred from verified sources; maintainers must approve it.
- **Owner input required**: the public record does not establish the answer. The responsible role and source of truth are named.

## Evidence-backed application worksheet

### Project summary

**Status: Proposed**

Unbounded Kubernetes extends a conformant Kubernetes control plane with worker nodes across remote infrastructure, on-premises environments, bare metal, and edge sites, with integrated node provisioning and cross-site networking.

**Evidence:** [README: What is Unbounded Kubernetes?](https://github.com/Azure/unbounded#what-is-unbounded-kubernetes) and [Project Overview](https://unbounded-cloud.io/concepts/overview/).

**Public routing owner:** [`@Azure/unbounded-dev`](https://github.com/Azure/unbounded/blob/main/.github/CODEOWNERS), the repository-wide CODEOWNER team. CODEOWNERS is not itself proof of CNCF maintainer status; the current project owner must identify the people authorized to approve this wording.

**Name confirmation required:** the README uses **Unbounded Kubernetes**, while some documentation uses **Project Unbounded** or **Unbounded**. The project owner and trademark counsel must confirm the official contribution and trademark name before the final application.

### Project description

**Status: Proposed**

Unbounded Kubernetes extends a conformant Kubernetes control plane so worker nodes can run across on-premises environments, bare metal, edge sites, and remote infrastructure while remaining part of one cluster. It addresses node provisioning and pod networking when workers do not share the control plane's VPC or LAN.

The project provides a node bootstrap agent; a Kubernetes controller for SSH provisioning; a PXE, Redfish, and TPM-based bare-metal path; and a multi-site CNI and networking system. The networking layer allocates pod CIDRs and connects sites using WireGuard, GENEVE, VXLAN, IPIP, direct routing, and an eBPF dataplane. The project also exposes Kubernetes custom resources for machines, sites, gateway pools, and site peering. A separate cloud-API/Karpenter provisioning path is documented as intended architecture that is still being designed and built.

The implementation uses Kubernetes APIs and controller-runtime, containerd, OCI artifacts, Prometheus metrics, and standard Kubernetes node components. Its goal is to let operators add heterogeneous compute capacity to an existing Kubernetes control plane without operating a separate Kubernetes cluster at each location.

**Evidence:** [Project Overview](https://unbounded-cloud.io/concepts/overview/), [Architecture](https://unbounded-cloud.io/reference/architecture/), [README features](https://github.com/Azure/unbounded#key-features), and [Go dependencies](https://github.com/Azure/unbounded/blob/main/go.mod).

**Approval owner:** `@Azure/unbounded-dev`.

### Organization repository URL

**Status: Verified answer**

`N/A`. The application is not for all repositories in the `Azure` organization.

**Reason:** the CNCF form requests an organization URL only when all repositories under that organization are in scope. The proposed primary scope is the single repository below.

**Confirmation owner:** `@Azure/unbounded-dev` must confirm that this is the intended scope.

### Primary project repository URL

**Status: Verified**

https://github.com/Azure/unbounded

### Additional repositories in scope

**Status: Proposed answer, maintainer confirmation required**

`N/A` based on the current public tree. [PR #49](https://github.com/Azure/unbounded/pull/49) merged the former unbounded-net codebase into this repository. Networking code is now present under [`api/net`](https://github.com/Azure/unbounded/tree/main/api/net), [`cmd/unbounded-net-controller`](https://github.com/Azure/unbounded/tree/main/cmd/unbounded-net-controller), [`cmd/unbounded-net-node`](https://github.com/Azure/unbounded/tree/main/cmd/unbounded-net-node), [`internal/net`](https://github.com/Azure/unbounded/tree/main/internal/net), and [`deploy/net`](https://github.com/Azure/unbounded/tree/main/deploy/net).

The README still links to the former `Azure/unbounded-net` repository, which does not currently resolve publicly, and the architecture source still describes networking as a “separate repo.” Both should be corrected before submission: [README component link](https://github.com/Azure/unbounded/blob/main/README.md#components) and [architecture source](https://github.com/Azure/unbounded/blob/main/docs/content/reference/architecture.md).

**Confirmation owner:** `@Azure/unbounded-dev`; repository owners must identify any additional code, documentation, package, or website repositories intended for contribution.

### Website URL

**Status: Verified**

https://unbounded-cloud.io

The repository homepage points to this domain, and the former GitHub Pages URL redirects to it. Documentation is published there.

**Evidence:** [repository metadata](https://github.com/Azure/unbounded), [documentation](https://unbounded-cloud.io/), and [README documentation section](https://github.com/Azure/unbounded#documentation).

### Roadmap

**Status: Owner input required**

No dedicated public roadmap or GitHub milestone was found. The [open issue list](https://github.com/Azure/unbounded/issues?q=is%3Aissue%20is%3Aopen%20sort%3Aupdated-desc) and [`designs/`](https://github.com/Azure/unbounded/tree/main/designs) show active work, but neither is explicitly designated as the project roadmap.

**Required action:** publish a stable roadmap URL that states priorities, intended outcomes, and time horizons without exposing confidential commitments.

**Owner:** `@Azure/unbounded-dev`. The maintainers should approve the roadmap; component leads should provide their planned work. If an internal roadmap exists, the project owner should publish a public-safe version rather than linking internal planning systems.

### Roadmap context

**Status: Owner input required**

Interim public evidence shows an early-development project with ongoing work in node bootstrap, networking, operator lifecycle, GPU support, release upgrades, storage, image distribution, and management UX. The repository explicitly warns that it is suitable for experimentation and prototyping and may make breaking changes.

**Evidence:** [README early-development notice](https://github.com/Azure/unbounded#unbounded-kubernetes), [open issues](https://github.com/Azure/unbounded/issues?q=is%3Aissue%20is%3Aopen%20sort%3Aupdated-desc), and [design documents](https://github.com/Azure/unbounded/tree/main/designs).

**Owner:** `@Azure/unbounded-dev` must turn this evidence into an approved roadmap narrative and explain the intended project direction.

### Contributing guide

**Status: Verified**

https://github.com/Azure/unbounded/blob/main/CONTRIBUTING.md

The guide documents issue reporting, pull requests, build and test expectations, and the Microsoft CLA process.

### Code of Conduct

**Status: Verified**

https://github.com/Azure/unbounded/blob/main/CODE_OF_CONDUCT.md

The project currently adopts the Microsoft Open Source Code of Conduct.

### Adopters

**Status: Owner input required**

No `ADOPTERS.md` or equivalent public adopter list was found. GitHub contributors, issue reporters, stars, or forks are not sufficient evidence of production adoption.

**Where to find the answer:** verifiable public deployment references, public talks, case studies, or adopter statements approved by the adopting organizations.

**Owner:** `@Azure/unbounded-dev` should ask known users for consent and open a PR adding `ADOPTERS.md`. Each entry should be supplied or confirmed by the adopter. If no public adopters can be verified, leave this optional CNCF field blank rather than infer adoption.

### Maintainers file

**Status: Owner input required**

The repository has a [CODEOWNERS file](https://github.com/Azure/unbounded/blob/main/.github/CODEOWNERS) assigning all paths to `@Azure/unbounded-dev`, but it does not identify individual maintainers, roles, affiliation, selection process, or emeritus status. CNCF asks for a maintainers file or `.project` repository.

**Required action:** publish `MAINTAINERS.md` or a `.project` repository with the current maintainers and roles.

**Owner:** the current `@Azure/unbounded-dev` team and Azure repository administrators. Only current project owners can authoritatively name maintainers; commit counts must not be used as a substitute.

### Governance

**Status: Owner input required**

No public governance document was found. The public record establishes code ownership but not how decisions are made, maintainers are added or removed, conflicts are resolved, or organizational neutrality is protected.

**Required action:** publish a governance document covering decision-making, roles, maintainer lifecycle, voting or consensus rules, conflicts of interest, and dispute resolution.

**Owner:** `@Azure/unbounded-dev` and the current project owner. The contributing entity's open source program office should review the document for consistency with the proposed foundation contribution.

### Security policy

**Status: Verified, CNCF-readiness review still required**

https://github.com/Azure/unbounded/blob/main/SECURITY.md

The policy directs vulnerability reporters to Microsoft's security reporting process and prohibits public issue reports. Before submission, maintainers should compare it with the [CNCF security guidance and templates](https://contribute.cncf.io/maintainers/security/security-guidelines/#3-securitymd) and decide whether project-specific supported versions, response expectations, and disclosure handling need to be documented.

The public architecture documentation also identifies an unresolved readiness issue: [SSH host-key verification is currently disabled](https://github.com/Azure/unbounded/blob/main/docs/content/reference/architecture.md#security-model) using `InsecureIgnoreHostKey`; a fingerprint status field exists but verification is not enforced. Security maintainers should resolve or explicitly risk-assess this before submission.

**Owner:** project security maintainer(s) named in the future maintainers file, with the contributing entity's security response team.

### Standard or specification?

**Status: Proposed answer**

`N/A`. The public repository implements software and project-specific Kubernetes CRDs; it does not present those APIs as an independent industry standard or specification.

**Evidence:** [CRD overview](https://unbounded-cloud.io/concepts/overview/#key-custom-resources) and [`api/`](https://github.com/Azure/unbounded/tree/main/api).

**Confirmation owner:** `@Azure/unbounded-dev`. If maintainers intend any API to be a portable standard independent of this implementation, they must describe that scope and governance.

### Business product or service to project separation

**Status: Proposed factual baseline; contributing-entity input required**

The repository is hosted in the `Azure` GitHub organization, its core license carries Microsoft copyright, and its contribution process uses the Microsoft CLA. At the same time, the public project states that it works with conformant Kubernetes control planes including AKS, EKS, GKE, kubeadm, and k3s. The current source registers machine-operation providers for Azure VMs and OCI instances; broader cloud-API provisioning is documented as planned architecture.

**Evidence:** [LICENSE](https://github.com/Azure/unbounded/blob/main/LICENSE), [CONTRIBUTING](https://github.com/Azure/unbounded/blob/main/CONTRIBUTING.md), and [README features](https://github.com/Azure/unbounded#key-features).

The public record does **not** establish the project's relationship to a specific commercial product, staffing independence, roadmap independence, or future neutral governance. The final answer must explain any related products or services and how branding, governance, development, releases, and roadmaps are separated.

**Owner:** the project owner plus the authorized contributing or sponsoring entity's open source program office and product/legal representatives. Publish only the approved public-safe answer.

### Why CNCF?

**Status: Proposed**

Unbounded is built around Kubernetes node lifecycle, container runtime, OCI artifact, observability, and networking primitives. CNCF stewardship could provide a neutral venue for collaboration among Kubernetes users, infrastructure providers, hardware vendors, and adjacent cloud native projects; make governance and ownership independent of a single vendor; and help the project align with CNCF expectations for security, legal hygiene, community growth, and project sustainability.

**Evidence boundary:** this is a proposed rationale, not evidence of existing neutral governance. The final wording must be approved by maintainers and the contributing entity.

### Benefit to the cloud native landscape

**Status: Proposed**

Unbounded addresses a specific gap between single-cluster node lifecycle and multi-location infrastructure: adding real Kubernetes worker nodes from remote infrastructure, on-premises environments, bare metal, and edge sites to one conformant control plane, while also provisioning cross-site pod connectivity. Its current public implementation combines SSH and PXE/Redfish/TPM provisioning, node bootstrap, machine operations for Azure VMs and OCI instances, and multi-site networking behind Kubernetes APIs. Cloud-API/Karpenter provisioning is planned, not yet a shipped differentiator.

Its proposed differentiator is the combined treatment of remote-node provisioning and intra-cluster cross-site networking. This should be validated with users and compared explicitly with the projects below before submission.

**Evidence:** [Project Overview](https://unbounded-cloud.io/concepts/overview/) and [Architecture](https://unbounded-cloud.io/reference/architecture/).

**Approval owner:** `@Azure/unbounded-dev`; external users should validate the problem statement.

### Cloud native fit

**Status: Proposed**

Unbounded is Kubernetes-native: desired state is represented with custom resources; controllers reconcile machines, sites, gateways, and networking; the provisioned hosts join as Kubernetes Nodes; and deployment is reconciled by an operator. It extends declarative Kubernetes APIs to infrastructure and network lifecycle across dynamic, heterogeneous environments.

A likely CNCF Landscape fit is **Provisioning / Automation & Configuration**, with substantial overlap with **Runtime / Cloud Native Network**. The current [CNCF Landscape taxonomy](https://landscape.cncf.io/) and [TAG Infrastructure scope](https://github.com/cncf/toc/tree/main/tags/tag-infrastructure) should be used to confirm categorization.

**Evidence:** [Architecture](https://unbounded-cloud.io/reference/architecture/) and [CRDs](https://unbounded-cloud.io/concepts/overview/#key-custom-resources).

### Cloud native integration

**Status: Verified technical evidence; maintainer review required for completeness**

- **Kubernetes:** the project uses Kubernetes APIs, CRDs, kubelet, kubeadm bootstrap, client-go, controller-runtime, and the aggregated API machinery. Sources: [architecture](https://unbounded-cloud.io/reference/architecture/), [go.mod](https://github.com/Azure/unbounded/blob/main/go.mod), and [`api/`](https://github.com/Azure/unbounded/tree/main/api).
- **containerd:** provisioned worker nodes run containerd; the project directly depends on containerd APIs and libraries. Sources: [agent overview](https://unbounded-cloud.io/concepts/overview/#unbounded-agent-node-bootstrap-agent) and [go.mod](https://github.com/Azure/unbounded/blob/main/go.mod).
- **Prometheus:** project components expose Prometheus metrics and directly use `prometheus/client_golang`. Sources: [published networking operations source](https://github.com/Azure/unbounded/blob/main/docs/content/reference/networking/operations.md) and [go.mod](https://github.com/Azure/unbounded/blob/main/go.mod).
- **OCI / ORAS:** the project consumes and publishes OCI artifacts and directly uses `oras-go` and Open Containers image specifications. Sources: [architecture netboot OCI images](https://unbounded-cloud.io/reference/architecture/#netboot-oci-images), [go.mod](https://github.com/Azure/unbounded/blob/main/go.mod), and [release artifacts](https://github.com/Azure/unbounded/releases).
- **Karpenter ecosystem (planned, not a current integration):** the [Cloud API guide](https://unbounded-cloud.io/guides/cloud-api/) explicitly says this path is still being designed and built; it describes intended Karpenter-based provisioning for unschedulable pods. Do not claim a shipped Karpenter integration until implementation and tests are linked.
- **Azure VM and OCI instance machine operations:** the current machine-operations controller registers Azure VM and OCI instance providers for host lifecycle operations. Source: [`cmd/machine-ops-controller/main.go`](https://github.com/Azure/unbounded/blob/main/cmd/machine-ops-controller/main.go).
- **Existing CNIs:** docs state that clusters with an existing CNI such as Cilium or Calico can set `manageCniPlugin: false`; Unbounded can also serve as the CNI when none exists. Source: [architecture network section](https://unbounded-cloud.io/reference/architecture/#network-architecture).

Do not claim integration with an entire project solely because a similarly named library appears in `go.mod`. Maintainers should confirm which integrations are tested and supported.

### Cloud native overlap

**Status: Proposed comparative analysis of CNCF projects**

- [Kubernetes](https://github.com/kubernetes/kubernetes): Unbounded extends Kubernetes node, API, controller, and networking behavior rather than replacing Kubernetes.
- [KubeEdge](https://github.com/kubeedge/kubeedge): both reach edge hosts. KubeEdge emphasizes cloud-edge synchronization, edge autonomy, applications, and devices; Unbounded's public scope is worker-node provisioning and cross-site networking.
- [OpenYurt](https://github.com/openyurtio/openyurt): both preserve Kubernetes APIs while extending nodes across edge or remote regions. OpenYurt also addresses disconnected operation, node pools, and cross-region pod connectivity, making it one of the closest functional comparisons.
- [Metal3](https://github.com/metal3-io/metal3-docs): both provide Kubernetes-native bare-metal lifecycle management and use Redfish; Unbounded also includes remote-node bootstrap and multi-site networking.
- [Karmada](https://github.com/karmada-io/karmada): both address multi-cloud and hybrid-cloud operations. Karmada orchestrates across multiple clusters; Unbounded's stated model keeps one control plane and adds worker nodes from multiple locations.
- [Kairos](https://github.com/kairos-io/kairos): both address edge, cloud, and bare-metal Kubernetes node lifecycle and can span regions; Kairos emphasizes immutable OS images and atomic upgrades.
- Existing CNI projects such as Cilium and Calico overlap with pod networking. Unbounded docs explicitly describe coexistence mode and position its own CNI around cross-site routing and tunnels.

### Similar projects

**Status: Proposed list covering CNCF and external projects**

- [Cluster API](https://github.com/kubernetes-sigs/cluster-api) provides declarative lifecycle management for Kubernetes clusters and infrastructure providers. Unbounded focuses on adding worker nodes and networking them into an existing conformant control plane.
- [Submariner](https://github.com/submariner-io/submariner-operator) connects networks across Kubernetes clusters. Unbounded networking connects sites and worker nodes within one Kubernetes cluster.
- [Karpenter](https://github.com/kubernetes-sigs/karpenter) provisions nodes for unschedulable Kubernetes pods. Unbounded's cloud-API guide describes a planned Karpenter-based path, but explicitly says it is still being designed and built.
- [Liqo](https://github.com/liqotech/liqo) builds transparent multi-cluster topologies, virtual-node workload offload, and cross-cluster networking. It federates independent clusters rather than joining remote machines as ordinary nodes of one cluster.
- KubeEdge, OpenYurt, Metal3, Karmada, Kairos, Cilium, and Calico are also relevant for the overlap reasons above.

**Required validation for both sections:** maintainers should correct the analysis and document protocol/API compatibility, feature boundaries, and collaboration opportunities. Relevant project communities should be contacted where overlap is material.

### Cloud Native Landscape

**Status: Verified as not currently identified**

No entry matching `Azure/unbounded`, `unbounded-cloud.io`, or “Unbounded” was found in the [canonical CNCF Landscape data](https://github.com/cncf/landscape/blob/master/landscape.yml) on 2026-07-29.

**Proposed application answer:** `No.`

**Owner/action:** `@Azure/unbounded-dev` should confirm and, if appropriate, use the Landscape contribution process after the project scope and category are settled.

### LFX Insights

**Status: Not currently identified; owner confirmation required**

No Unbounded entry was identified in the public [Open Source Index](https://insights.linuxfoundation.org/open-source-index) on 2026-07-29.

**Proposed application answer:** `No public LFX Insights project page identified as of 2026-07-29.`

**Owner/action:** `@Azure/unbounded-dev` should confirm with Linux Foundation project services or use the [LFX Insights project submission entry point](https://insights.linuxfoundation.org/open-source-index) if enrollment is desired.

### Trademark and accounts

**Status: Owner input required; no attestation can be made yet**

Public assets currently identified are the [GitHub repository](https://github.com/Azure/unbounded), [project website/domain](https://unbounded-cloud.io/), [GitHub releases](https://github.com/Azure/unbounded/releases), and project artifacts/images published through GitHub release and registry workflows. This list is not proof of ownership or transfer authority.

The CNCF form requires agreement to donate project trademarks and accounts if accepted.

**Owner:** the current asset owners, Azure organization administrators, domain/registry owners, and the authorized contributing entity's open source and legal representatives. They must identify all transferable assets internally, confirm authority, approve the public attestation, and ensure designated contacts consent. Do not post access or recovery details here.

### IP policy attestation

**Status: Owner input required; no attestation can be made yet**

The CNCF form requires the applicant to agree that the project will follow the [CNCF IP Policy](https://github.com/cncf/foundation/blob/main/charter.md#11-ip-policy) if accepted. This approval is distinct from the license-exception answer below.

**Owner:** copyright holder(s), authorized contributing entity, and qualified open source legal counsel must approve the public checkbox attestation. The repository-wide CODEOWNER team can provide the technical inventory but cannot establish legal authority.

### Will the project require a license exception?

**Status: Legal/owner decision required**

Verified facts:

- The project's core [LICENSE](https://github.com/Azure/unbounded/blob/main/LICENSE) is MIT and names Microsoft Corporation as copyright holder.
- CNCF Charter section 11 states that new inbound and outbound code uses Apache License 2.0, while documentation is received and made available under CC BY 4.0; alternative code licenses require an exception.
- CNCF's dependency allowlist applies to third-party components and does not by itself resolve the core project's MIT license.
- The generated [NOTICE](https://github.com/Azure/unbounded/blob/main/NOTICE) inventories Go and frontend dependencies and their declared licenses; it is evidence for a full dependency review, not proof that every CNCF condition is satisfied.
- `NOTICE` states that it is generated from `go.mod` and `frontend/package.json`; it does not inventory the Rust dependencies in [`Cargo.toml`](https://github.com/Azure/unbounded/blob/main/cmd/unbounded-storage/Cargo.toml) and [`Cargo.lock`](https://github.com/Azure/unbounded/blob/main/cmd/unbounded-storage/Cargo.lock), or the pinned native [libfabric and OpenSSL dependencies](https://github.com/Azure/unbounded/blob/main/Makefile#L147-L179). These surfaces must be included in the license and provenance review.

**Current application answer:** cannot yet be `N/A`. The contributing entity must choose and approve one of these outcomes: relicense the core project to Apache-2.0, obtain an applicable CNCF license exception, or establish another CNCF-approved path.

**Owner:** copyright holder(s), authorized contributing entity, and qualified open source legal counsel. `@Azure/unbounded-dev` should provide the complete code/dependency inventory; legal counsel must supply the final public answer.

### Project Domain Technical Review

**Status: Not completed in the public record; optional for Sandbox**

The CNCF Sandbox process says a General Technical Review is voluntary, not required. The current TAG structure places data, storage, network, compute, edge, and load balancing under [TAG Infrastructure](https://github.com/cncf/toc/tree/main/tags/tag-infrastructure), making it the strongest initial contact. [TAG Workloads Foundation](https://github.com/cncf/toc/tree/main/tags/tag-workloads-foundation) may also be relevant for worker execution environments and lifecycle.

**Where to start:** use the public TAG Infrastructure meeting, mailing list, or Slack links listed in its [current TAG record](https://github.com/cncf/toc/blob/main/tags.yaml), or complete the [General Technical Review questions](https://github.com/cncf/toc/blob/main/toc_subprojects/project-reviews-subproject/general-technical-questions.md).

**Owner:** an approved project maintainer should present and record public meeting notes or questionnaire links. Do not list a CNCF person as a project contact until that person has engaged with and consented to being named for this application.

### Application contact emails

**Status: Owner input required**

No contact should be inferred from commit metadata, issue activity, or generic policy addresses.

**Owner/source of truth:** `@Azure/unbounded-dev` and the project owner must designate one or more application contacts, confirm that they can represent the project, and obtain consent to publish their email addresses in the public CNCF issue.

### Contributing or sponsoring entity and signatory

**Status: Owner input required**

Repository ownership, copyright notices, and a CLA process do not by themselves prove which legal entity will contribute the project or who has signature authority.

**Owner/source of truth:** the current project owner and asset owners, working with the authorized contributing entity's open source program office and legal counsel. They must provide the legal entity name, address, entity type, authorized signatory name/title, and approved email address required by the CNCF form. Keep authorization evidence internal; publish only the approved final values with consent.

### CNCF contacts

**Status: None verified**

No public evidence reviewed establishes that a CNCF TOC or TAG leader is already familiar with and prepared to answer questions about Unbounded.

**Where to find contacts:** begin with [TAG Infrastructure's public contacts](https://github.com/cncf/toc/tree/main/tags/tag-infrastructure). After a public presentation or review, ask participating leaders whether they consent to being named. Until then, leave this optional application field blank.

### Additional information

**Status: Proposed evidence**

- The project identifies itself as early-development software for experimentation and prototyping: [README](https://github.com/Azure/unbounded#unbounded-kubernetes).
- It has a public release pipeline and published releases, including [`v0.2.0`](https://github.com/Azure/unbounded/releases/tag/v0.2.0).
- GoReleaser configuration generates checksums, keyless Sigstore signing for the checksum artifact, and SPDX SBOMs for configured binary archives: [`.goreleaser.yml`](https://github.com/Azure/unbounded/blob/main/.goreleaser.yml). Other artifact types require separate workflow evidence and should not be implied by this file alone.
- The repository provides public support through GitHub Issues: [`SUPPORT.md`](https://github.com/Azure/unbounded/blob/main/SUPPORT.md).
- CNCF's current Sandbox marketing guidance provides a TOC mailing-list announcement and media introductions only when media contacts CNCF; it does not provide press outreach, a CNCF/TOC briefing, a CNCF blog post, or a social card. It prescribes “Cloud Native Sandbox” or “CNCF Sandbox projects” terminology: [Sandbox marketing guidance](https://contribute.cncf.io/resources/services/marketing/#sandbox).
- The [Sandbox process](https://github.com/cncf/sandbox/blob/main/README.md) asks projects that are primarily operators enabling another open source project to contact that project about becoming a subproject first. Unbounded contains an operator but also implements node bootstrap, machine lifecycle, bare-metal provisioning, storage, image distribution, and networking. The current project owners must still determine whether CNCF would consider it “primarily an operator” and document any upstream outreach if applicable.

Maintainers should decide which maturity, testing, security, release, and community evidence best supports the final application without overstating production readiness.

## Pending actions and owners

### Project maintainers (`@Azure/unbounded-dev`)

- [ ] Approve or correct the proposed summary, description, CNCF rationale, landscape fit, integrations, overlap, and similar-project analysis.
- [ ] Confirm the official contribution and trademark name: Unbounded Kubernetes, Project Unbounded, or another approved name.
- [ ] Confirm that only `Azure/unbounded` is in scope and fix stale `Azure/unbounded-net` links.
- [ ] Publish `MAINTAINERS.md` or `.project` data.
- [ ] Publish governance and roadmap documents.
- [ ] Confirm whether the CRDs are only implementation APIs or include an intended standard/specification.
- [ ] Collect consented adopter evidence or leave the optional field blank.
- [ ] Designate consenting application contacts.
- [ ] Decide whether to request an optional TAG Infrastructure or TAG Workloads Foundation review.

### Project owner and contributing entity

- [ ] Approve pursuing CNCF contribution.
- [ ] Identify the contributing or sponsoring legal entity and authorized signatory.
- [ ] Provide the approved product/service separation statement.
- [ ] Confirm ownership and transferability of public project trademarks, domains, repositories, registries, and accounts.
- [ ] Approve the trademark/account-donation and CNCF IP-policy attestations.
- [ ] Obtain publication consent for all names, titles, addresses, and emails used in the final public application.
- [ ] Confirm whether the project is primarily an operator under the CNCF Sandbox process; if so, document outreach to the relevant upstream project.
- [ ] Acknowledge Sandbox support and marketing limits and approve public terminology/announcement plans.

### Open source legal and security reviewers

- [ ] Decide whether to relicense the MIT core project to Apache-2.0 or seek a CNCF exception.
- [ ] Review all dependency licenses using `NOTICE`, Go modules, frontend lockfiles, container images, bundled binaries, and generated artifacts.
- [ ] Extend the dependency inventory to Cargo/Rust and native libfabric/OpenSSL components; `NOTICE` currently covers only Go and npm sources.
- [ ] Confirm code and asset provenance across the proposed contribution scope.
- [ ] Review `SECURITY.md` against CNCF project security expectations.
- [ ] Resolve or explicitly risk-assess the documented disabled SSH host-key verification before submission.

### External users and adjacent communities

- [ ] Validate the problem statement and differentiator.
- [ ] Provide adopter statements only with organizational approval.
- [ ] Review overlap and collaboration opportunities with Cluster API, KubeEdge, OpenYurt, Metal3, Submariner, Karmada, Kairos, Liqo, Karpenter, and CNI communities.

## Submission gate

- [ ] Every mandatory CNCF form field has either an approved answer or an approved public URL.
- [ ] Maintainers have approved all technical statements.
- [ ] The contributing entity has approved all legal, IP, trademark, transfer, contact, and signatory statements.
- [ ] Every named person has consented to public publication.
- [ ] The complete final `cncf/sandbox` issue has been reviewed without submitting it.
- [ ] The final CNCF Sandbox application is submitted and linked here.
- [ ] Contribution Agreement status and TOC outcome are tracked here using only public-safe information.

Do not describe the project as donated, contributed, accepted, or an official CNCF project until the TOC has approved the application and the Contribution Agreement has been signed.

Start with the worksheet and its linked CNCF Sandbox form and process documents, then verify the repository evidence in README.md, docs/content/reference/architecture.md, CONTRIBUTING.md, SECURITY.md, and .github/CODEOWNERS. Track maintainer decisions and owner input for the roadmap, adopters, maintainers, governance, naming, and repository scope. Done means the project has approved, public-safe answers and all required supporting documentation before the final application is opened.

Written by the indexing model from the issue text.