Environments and Controls

HybridOps treats an environment as a logical operating lane, not as a provider-specific slice.

One environment can therefore contain the on-prem, cloud, edge, and control-plane state that belongs to the same lane. shared is reserved for authorities and assets intentionally reused across lanes.

Related material:

• Environment policy design record
• Authoritative inventory design record
• Secrets Lifecycle

Environment binding rule

For normal operation:

• dev holds the on-prem, cloud, and edge state that belongs to the dev lane
• shared holds intentional cross-lane authorities
• other cross-environment references are exceptional and should be limited to controlled drills or migrations

Examples:

• dev on-prem platform, dev GCP burst, and dev recovery resources all use --env dev
• a dev workflow may consume an authority intentionally stored in shared
• long-lived dev-onprem and dev-gcp environments wired together through cross-environment state are not the normal model

Non-shared cross-environment state resolution fails unless the run explicitly allows it.

Inspect the current environment state with:

hyops show init --env <env>
hyops show module --env <env> <module-ref[#instance]>
hyops show env --env <env>

Why lanes exist

Environment lanes let HybridOps apply different operating rules without changing the capability being executed.

They allow:

• engineering work without touching live service lanes
• controlled recovery drills and migrations
• stable shared authorities
• stronger approval and timing requirements for live environments
• run records that show which lane was targeted and what happened

Common lane patterns

HybridOps does not require a fixed three-environment model.

Lane	Purpose	Notes
shared	Intentional shared authorities	Assets that are deliberately reused by more than one lane
dev	Integrated working lane	On-prem, cloud, and edge state for active engineering work
drill	Controlled rehearsal lane	Recovery proofs and destructive validation
staging	Pre-production lane	Optional formal sign-off before live change
prod	Live service lane	Strongest approval, timing, and scope controls

The important distinction is whether a lane is self-contained, intentionally shared, or an explicitly controlled exception.

How HybridOps applies environment controls

Before a managed action proceeds, HybridOps can:

1. require an explicit target environment
2. reject unexpected cross-environment state references
3. apply environment-specific scope, approval, and timing rules
4. check target readiness before higher-risk actions
5. attach the run to a stable execution record
6. preserve the observed result for later review

The exact policy depends on the environment and capability. A development run can be permissive where appropriate, while a production run can require stronger controls without changing the operator contract.

Authoritative inventory and addressing

HybridOps does not require individual execution paths to invent their own inventory or addressing decisions. Where a source of truth is configured, that authority remains responsible for the inventory, addressing, and topology data consumed by HybridOps.

The public reference implementation includes a NetBox integration for this role. The integration details belong in the focused design and HOWTO material rather than in the environment control model itself:

• Authoritative inventory design record
• Authoritative inventory deployment
• Inventory flow

Lane behaviour in practice

Engineering work in dev

An engineer targets dev explicitly. HybridOps keeps the change within that lane, checks the required preconditions, executes the requested capability, and records the result. A failure in dev does not silently redirect the run to prod.

Rehearsal in drill or staging

A recovery proof or release candidate targets drill or staging. HybridOps applies the policy configured for that lane, records the checks performed, and keeps the resulting evidence tied to that execution.

Controlled change in prod

A production action must target prod explicitly. HybridOps can require the configured approval, timing, scope, and readiness conditions before the action proceeds. The resulting run record shows what was requested, which environment was targeted, and the observed outcome.

Summary

• environments are logical operating lanes, not provider slices
• shared is the normal location for intentional cross-lane authorities
• other cross-environment state is exceptional and explicit
• environment policy can control scope, approvals, timing, and readiness
• authoritative inventory remains outside individual execution paths
• each meaningful run is tied to a reviewable execution record