Unified access
Portal, workbenches, web, desktop, CLI, TUI and SDK provide different access paths to the same authorized capabilities. Interfaces receive no hidden bypasses to internal data or runtimes.
System architecture & operating model
Clear boundaries. Shared contracts. Connected with control.
Orthevs is designed as a modular and distributable engineering system. Platform Core, Engineering Labs, Factories, Engines and Foundations retain explicit responsibility boundaries. Versioned APIs, events, capability contracts, controlled identities and referenced artifacts connect local services, cloud environments and, eventually, Orthevs OS without dissolving data ownership or trust boundaries.
Architecture model
Four layers with explicit responsibility.
The architecture separates access, shared platform concerns, domain capabilities and technical execution. Each layer has a clear mandate and communicates with the next through documented contracts. Labs can therefore evolve independently while cross-domain workflows remain controllable and coordinated.
Shared control foundation
Identity, tenancy, policy, approval, registries, audit, events, artifact references, observability and cross-domain operation IDs are modeled as shared platform concerns without absorbing Lab-specific domain logic.
Labs, Factories and Engines
Each Engineering Lab is an independent domain application with an interface, domain logic, data responsibility and SDK-like access. Factories are its specialist tools; Engines handle processing and execution through published contracts.
Targets and runtime
Adapters, workers and jobs execute work in controlled target environments. Data, hardware access and sensitive artifacts can remain where location, protection needs, cost and operational responsibility require them.
Resources, Contracts and execution
One shared model. Domain-specific extensions.
The Universal Resource Model gives resources a shared identity, metadata, scope and references. Domain schemas remain with the Labs. Definitions, artifacts and runtime state have separate lifecycles.
- 01
Discovery & Contract
A wizard or editor records requirements in a versioned Contract revision.
- 02
Foundation & Baseline
Rules resolve suitable Foundations; an approved Baseline fixes the composition.
- 03
Capability & Plan
Required capabilities match compatible providers; a versioned plan is created when needed.
- 04
Execution & Evidence
Authorized workers execute; outcomes and evidence stay linked to the Contract revision.
Hybrid Modular Core & federation
Compose modules. Connect under control.
The Core has logical module boundaries; components can run in-process or as services. Capabilities are selected by contract, version, authorization and target environment. Federated instances exchange work only with explicit permission and retain local data authority.
Local
Minimal Core and selected Labs on a workstation or server.
Distributed
Separate services and workers near the relevant data and targets.
Federated
Authorized exchange among independent Orthevs instances.
Orthevs OS
Long-term desktop vision with local Runtime and optional connections.
Operating forms
Four operating forms. One shared system model.
A capability should run where data, resources, risk and operational responsibility require it. The control plane coordinates identity, contracts, decisions and status; execution and data storage can deliberately remain local, distributed or cloud-based. These profiles describe target product forms and are distinct from development, integration, staging or production environments.
Local service
Platform Core, selected Labs and capabilities run on a workstation, VM or single server. This profile suits development, laboratories, isolated environments and smaller teams. It preserves local data ownership and can consume selected federated services when required.
Private or public cloud
Platform, Lab and Engine services are designed for scale and high availability. Provider-specific functions remain bounded behind adapters, capability contracts and documented dependencies so domain models and workflows do not become implicitly tied to one provider.
Orthevs OS
The long-term target is an integrated distribution with Orthevs Runtime and a shared web, desktop, CLI and TUI experience. It is intended to execute local capabilities with control, account for hardware and offline contexts, and consume approved connected services.
Connected environment
Local, cloud and OS instances collaborate in a federated model. Workflows dispatch tasks to suitable execution targets. Identity, policy decisions, operation IDs, audit and provenance remain correlatable across handovers while every environment retains its own trust boundary.
Architecture principles
Guardrails for independent, verifiable evolution.
These principles limit coupling and make security-relevant and operational decisions visible. They apply to Platform Core, Labs, Factories, Engines, Foundations and their integrations.
API-first & Contract-first
Public and cross-Lab capabilities are described through versioned APIs, events, manifests and artifact schemas. Breaking changes require versioning, deprecation and a traceable migration path.
Explicit ownership
Platform Core owns shared concerns; Labs own their domains; Factories remain plugins of their respective Lab. Overlap is resolved through capability ownership and architecture decisions.
Least Privilege & Human-in-control
Access is scoped by tenant, project, Lab, capability and action. Risky or irreversible steps require policy decisions, preview or plan, and defined approvals.
No shared database
Platform and Labs retain their own data ownership. Integration uses contracts, events and referenced artifacts rather than direct access to internal databases, file systems or in-memory state.
Observable and auditable
Health, logs, metrics, traces, correlation IDs, operation IDs and audit events are part of the system contract. Technical diagnostics and the domain audit trail remain distinct but linkable records.
Lifecycle and evidence
Definition, validation, approval, operation, update and retirement are modeled together. Maturity or approval claims require versioned criteria, a named scope and traceable evidence.
Responsibility boundaries
Collaboration without hidden ownership.
The principal boundaries are stated explicitly so implementation, operations and governance use the same assignment of responsibility. No layer may expand its authority through direct access to another layer's internal state.
Platform Core ↔ Labs
The Core provides identity, policy, registries, audit, eventing and coordination. Domain state, decisions and execution remain with the responsible Lab and are addressed only through published capabilities.
Labs ↔ Factories
The Lab has an independent domain and operational boundary. A Factory supplies a bounded capability and may be implemented as a plugin, package, service or adapter as needed.
Foundations ↔ implementation
Foundations arrange processes, workflows, capabilities, reference architecture, guardrails and evidence into a versioned solution template. They replace neither Lab nor Factory and do not access their internal data implicitly.
Control Plane ↔ Execution
The control plane resolves capabilities, authorizes, plans and tracks operations. Workers, adapters and targets execute with scoped identities; large data and sensitive artifacts do not need to pass through central coordination.
Connection points
Connect without blurring boundaries.
The connection is not based on shared internal databases. It is formed through discoverable capabilities, controlled identities, versioned contracts, correlatable operations and referenced artifacts. Every handover therefore carries both domain and technical context.
Capability Contracts
Versioned APIs, events, manifests and artifact schemas define inputs, outcomes, failures, timeouts and compatibility. Consumers integrate a published capability, not its internal implementation.
Federated identity
Users, services and workloads act through short-lived scoped identities. Tenant, project, actor, capability and action form the authorization context; broadly shared credentials are not part of the target model.
Policy & trust
Each environment retains its own policies, approvals and trust boundaries. A federated request is evaluated again at the target boundary and cannot silently bypass local protection requirements.
Artifacts & provenance
Outcomes are linked through typed references, digests, signatures, SBOMs and provenance. Metadata can remain centrally discoverable while large or sensitive content stays in its controlled store.
Events & operation IDs
Long-running work returns an operation or job resource. Lifecycle events, correlation IDs and operation IDs make status, retries, failures and compensation traceable across system boundaries.
Targeted execution
Capability discovery and policy select a suitable permitted execution environment. Data and workloads remain where location, hardware, cost, latency or protection needs require them.
End-to-end operation flow
From intent to defensible evidence.
A cross-Lab operation is not treated as an opaque direct call. Resolution, authorization, execution, status and evidence form one coherent chain with explicit handovers.
- 01
Establish context
Tenant, project, actor, target, requested capability, scope and success criteria are identified explicitly.
- 02
Resolve capability
Registry and contract provide the permitted provider, compatible version, endpoint and valid input and output schemas.
- 03
Evaluate policy
Identity, permissions, risk, target boundary and, where required, approval or preview are evaluated before execution.
- 04
Execute deliberately
The responsible Lab delegates to a scoped worker, adapter or job in the suitable local, cloud or OS environment.
- 05
Correlate status
Operation ID, events, logs and traces connect progress, retries, failures and recovery without exposing internal state.
- 06
Evidence the outcome
Results, decisions, artifact digests and provenance are assigned to the defined scope and made referenceable for audit, qualification or lifecycle activities.
Status & claim boundary
A documented target model with visible maturity.
The architecture describes the intended direction and the binding system boundaries of the concept. It does not claim that every target component or operating profile has already been implemented for production in full.
Technical starting point
The existing Compose stack, Docker services, public website, documented Lab boundaries and local deployments form the verifiable basis available today.
Strategic target components
Federation, complete Platform registries, Foundation and qualification services, and Orthevs OS belong to the target model and are presented only with an explicit scope and maturity level.
Release-specific transparency
Supported capabilities, contracts, operating profiles, constraints and migrations are stated per release rather than inferred as broad product commitments from the target model.
Traceable decisions
Open technology, runtime, IAM and governance questions are resolved through documented architecture decisions before becoming binding contracts.
The operating forms and federated connection described here are the strategic target. Existing Docker services and local deployments are the technical starting point; maturity and supported scope will be stated per release.
Orthevs Architecture
Evaluate the architecture against a concrete engineering scope.
A defensible starting point begins with the objective, system boundaries, data ownership, risk profile and required capabilities. From these, the responsible Labs, contracts, operating form and a verifiable first vertical slice can be derived.