Orthevs Engineering Lab · OSEL

Operating systems as versioned products instead of individual installations.

The Operating System Engineering Lab connects Blueprints, package sources, image builds, provisioning, fleet operations, security and recovery across the entire Day 0 to Day N lifecycle.

View use cases Explore 48 Factories

Documented target state · Concept / Architecture Baseline

OS Product Lifecycle

InputDistributionRolesPolicies

Orthevs LabOSELControl Plane

OutcomeReleaseManaged HostEvidence

Inventory, drift, patch level and recovery feed back into the OS product

Domain application · target architecture

Independent engineering environment

The Lab is designed as a complete domain application with a workspace, editors, models and SDK-like interfaces. Its Factories are the specialist tools; Engines handle processing and execution. Shared Contracts connect it with other Labs.

Engineer operating systems, kernels, packages, distributions, images and VM tests.

From Engineering Contract to verifiable outcome

01
Contract & Foundation
Requirements and rules select the domain foundation.
02
Lab Workspace
Models, editors and tools address the domain problem.
03
Factory & Engine
Specialist tools create artifacts and use suitable execution mechanisms.
04
Validation & Product
Tests, evidence and approvals lead to a versioned outcome.

The workflows and capabilities shown describe the documented target model. Check availability and maturity for each release and capability.

Mission and ambition

An OS release is an auditable product bundle.

OSEL describes operating systems declaratively: distribution, package versions, roles, policies, images, installation methods and support boundaries are versioned rather than improvised host by host. Through build, test, approval and signing, a Blueprint becomes an immutable release candidate.

The Lab develops neither its own kernel nor a new distribution. It integrates established package managers, installers, image builders and configuration management systems through adapters. Linux forms the first reference path; Windows and specialized systems follow with explicit feature matrices.

OSEL combines immutable image pipelines with controlled mutable configuration management. This makes visible which state is owned in the image, at bootstrap or later in operation, and prevents competing ownership between tools and Labs.

Capability map

Twelve domains structure the Operating System Engineering Lab.

The domains organize responsibility and lifecycles. Within them, Factories deliver clearly bounded, versionable capabilities.

1 · OBF · OCTF · OCF · OPF

OS Architecture & Product Design

Define OS products, profiles, compatibility and catalogs with clear support boundaries.

2 · DRF · KEF · PKF · SRF

Sources & Package Engineering

Manage package sources, dependencies, custom packages and kernel configuration reproducibly.

3 · APF · ICF · LOF · IBF

Image & Distribution Engineering

Compose, build, package and publish images for different target media.

4 · BPF · CIF · ISF · PRF

Bootstrap & Provisioning

Combine installers, PXE, cloud initialization and OS provisioning into repeatable workflows.

5 · NCF · ORF · SFF · SCF

Configuration & Role Engineering

Apply system, network, storage and role profiles to hosts in a controlled manner.

6 · HIF · CMF · OHF · VSF

Identity, Security & Compliance

Integrate host identity, hardening, compliance, vulnerabilities and SBOMs into the lifecycle.

7 · HQF · OTF · PBF · RCF

Verification & Qualification

Demonstrate bootability, hardware suitability, performance and release quality before promotion.

8 · FDF · HEF · IDF · RSF

Delivery & Fleet Deployment

Distribute images, enroll hosts and steer rollouts with rings and halt criteria.

9 · HLF · IUF · OUF · PMF

Patch, Upgrade & Lifecycle

Coordinate patches, major upgrades, immutable updates and host lifecycle with a recovery path.

10 · BRF · DTF · DGF · HMF

Operations & Reliability

Bring together monitoring, drift, diagnostics, backup and restore for managed hosts.

11 · AHF · CHF · EEF · VHF

Specialized OS & Hardware

Represent container hosts, virtualization, edge, embedded, GPU and HPC as dedicated profiles.

12 · OAF · OIF · OLF · OWF

Developer Experience & Automation

Offer OS workspaces, pipelines, automation and integrations through the same APIs.

Use cases

OSEL starts with the complete engineering problem.

The scenarios combine several Factories into one dependable flow. They describe the documented target state, not a product function that is already committed.

1Golden Image

Publish a verified Ubuntu image

An OS Blueprint is validated against schema and policies, package sources are frozen, and the image is built in isolation, then booted, integration-tested, scanned and signed. Only a passed gate promotes the candidate into a release channel.

Repository snapshot and locks
Boot and integration test
SBOM, signature and promotion

OBF → SRF → ICF → IBF → OTF → VSF → APF

2Fleet Security

Roll out critical patches ring by ring

Advisories and inventory determine the affected hosts. OSEL creates a plan that requires approval, updates a canary ring first and extends the rollout only when health and SLO gates are passed.

Impact from real inventory
Canary and halt criteria
Recovery instead of blind retry

VSF → PMF → RSF → HMF → BRF

3Platform Nodes

Update Kubernetes workers under control

PEL hands over target identity and operational requirements, OSEL checks OS and hardware compatibility, coordinates drain, reboot and readiness, and returns the verified host state to PEL.

Explicit PEL/OSEL ownership
Drain and reboot impact
Host readiness as a contract

PEL → OSEL API → OUF → HMF → PEL

4Edge & Recovery

Provide edge or rescue systems reproducibly

Specialized hardware, limited connectivity and offline promotion are modeled as a profile. Signed live or rescue artifacts remain linked to sources, tests, target hardware and recovery procedures.

Hardware qualification
Offline-capable artifacts
Documented restart

HQF → EEF → LOF → IDF → BRF

End-to-end lifecycle

From the requirement to the controlled next state.

OSEL separates the lifecycle of the OS product from the lifecycle of a specific managed host and connects both through deployments and operations.

1
Discover
Capture target and hardware
Clarify use case, distribution, platform, devices and support requirements.
2
Design
Define the OS product
Version Blueprint, profiles, roles, packages, policies and compatibility.
3
Build
Build the image reproducibly
Lock sources, build in isolation and produce digests as well as build Evidence.
4
Verify
Qualify the release
Test boot, integration, hardware, performance, security and compliance.
5
Publish
Approve the release
Sign, promote and publish artifacts with support and channel status.
6
Provision
Install the target
Provision VM, bare metal, cloud or edge via declared installation profiles.
7
Configure
Apply roles
Configure system, network, storage and security state in a controlled manner.
8
Operate
Observe the fleet
Continuously capture inventory, health, drift, supportability and patch level.
9
Upgrade
Change ring by ring
Steer patches and upgrades with approval, canary, reboot and recovery gates.
10
Recover
Restore operations
Connect diagnostics, rescue, backup and restore with verified readiness.
11
Decommission
Decommission the host
Drain workloads, handle data, revoke identity and retain Evidence.

Closed feedback loop

Inventory, drift, patch level and recovery feed back into the OS product. Insights are not merely documented; they flow, versioned, into the next engineering cycle.

Reference architecture

OS product, host state and infrastructure resource keep unambiguous owners.

OSEL owns the operating system on the target; PEL owns the VM, hardware or cluster resource. Operation IDs and contracts connect both lifecycles.

Layer 1 · Shared foundation

Orthevs Platform

IAM, policy, audit, secrets, events, artifact storage and observability.

Layer 2 · OS Control Plane

OSEL Core & API

Blueprint registry, release catalog, fleet inventory, operation ledger and workflows.

Layer 3 · Engineering Capabilities

OSEL Factories

Build, provisioning, configuration, qualification, security, lifecycle and recovery.

Layer 4 · Targets & Adapter

OS Execution Plane

Image builders, package sources, PXE, cloud, hypervisors, configuration tools and managed hosts.

OS as a Product

Version, support, provenance and operational responsibility are part of the release.

Immutable + Mutable

Image and runtime configuration have separate, explicit ownership.

Operation Ledger

Mutations return operation ID, idempotency key, status, errors and audit link.

Declare rollback honestly

Non-atomic updates do not promise rollback when only recovery is possible.

Lab Core

Shared responsibilities keep the Factories integrable.

The Lab Core bundles the cross-cutting domain services; a Factory adds a capability without rebuilding these foundations in parallel.