PolymerOS Design

Status: public-facing draft. This is not a release announcement, security assurance claim, artifact publication, or native hardware runtime claim.

Summary

PolymerOS is the product layer above Spectrum. Spectrum provides the base operating system and VM-oriented compartment model. PolymerOS adds product identity, platform policy, release metadata, update publication, service VM catalogs, the Micromer appliance library, the Monomer VM layer, and the Covalent security framework and temporary security framework.

The design target is one coherent system that can be reviewed across Apple Silicon, amd64, QEMU, and Cloud Hypervisor without mixing their evidence lanes.

Architecture

flowchart TB
  user[User / operator]
  polymer[PolymerOS product layer]
  spectrum[Spectrum base OS]
  monomer[Monomer VM layer]
  frameworks[covalent bonds and temporary bonds]
  catalog[Service VM catalog]
  bonds[Permission/attestation bonds]
  vms[Service and app VMs]

  user --> polymer
  polymer --> spectrum
  polymer --> monomer
  polymer --> frameworks
  polymer --> catalog
  frameworks --> bonds
  monomer --> vms
  catalog --> vms
  bonds --> vms

Security Model

PolymerOS does not treat VM-to-VM access as a blanket permission. The design uses two framework names and one concrete permission object:

Covalent security framework: scoped cooperation between known,

policy-registered, or measured components.

temporary bond model: constrained handoffs across a trust gradient,

such as browser downloads, untrusted documents, clipboard transfers, and removable-media intake.

Bond: the permission/attestation object issued, verified, revoked, and

audited by either framework.

The current bond material is a planning contract and fail-closed schema audit, not active runtime enforcement.

Micromer And Monomer

Micromer is the reusable appliance library boundary for appliance and service VM roles. Monomer is the runnable VM layer that catalogs and composes those roles. Current roles include network security, secrets, admin, browser handoff, untrusted import, developer workflow, media/document intake, and transport smoke tests.

The first concrete Monomer payload evidence is direct-boot runtime work. A development-signed dm-verity rootfs candidate exists, but strict artifact/catalog review, a reviewed public artifact URL, release-signing policy, and publication review remain unresolved.

Evidence Gates

Current public wording should stay within these bounds:

Area	Public-safe wording	Required before stronger claim
Product architecture	Design draft and review model exist.	External review and release packet.
amd64 build parity	Selected sandboxed build checks include recorded integration, installer, and a KVM-backed Wayland check pass; KVM daemon-sandbox access is current-boot proof.	Persistent KVM ACL policy, broader runtime evidence, and release review.
Apple Silicon	Non-mutating live artifact postbuild evidence exists; runtime proof is review-gated.	Explicit runtime review authorization and recorded pass/fail packet.
QEMU-L1	Refreshed 16K proof reaches nested KVM and Cloud Hypervisor API startup; app VM EROFS root mount is pending.	Passing rebuilt disk rung, then refreshed vsock, virtio-fs, and vhost-user-net rungs.
Service VM catalog	Catalog shape is planned.	Strict artifact manifest and catalog review with signed payloads.
covalent bonds and temporary bonds	Planning schema and review contracts exist.	Runtime verification and audited activation path.

Review Source

Reviewer-facing source material is maintained in the internal claim map, review index, status lanes, and next-packet notes. Public copies should cite reviewed evidence categories without exposing internal operational details.