Runtime Behavior

Status: living

This document describes how Dubnium behaves while switching between host-local modes.

Modes

desktop

Intent:

• interactive workstation and development mode

Expected runtime facts:

• graphical session available
• ordinary audio available
• display GPU protected for UI
• vLLM inactive in v1
• k3s may remain active with bounded platform pressure

studio-local

Intent:

• low-latency local audio profile when studio capability remains on this host

V1 representation:

• overlay on desktop
• studio-local-policy.service
• audio-priority.service
• no first-class studio-local.target

Expected runtime facts:

• graphical session available
• audio-priority policy active
• AI suppressed or inactive
• heavy background pressure reduced

compute

Intent:

• headless throughput mode for AI/platform work

Expected runtime facts:

• graphical session absent or non-authoritative
• compute target active
• vLLM active when enabled
• AI resources assigned according to configured compute GPU profile
• k3s remains active with mode-appropriate platform budget

Supported V1 Transitions

desktop -> studio-local
studio-local -> desktop
desktop -> compute
compute -> desktop

studio-local -> compute should route through desktop policy unless a future transition contract explicitly allows direct promotion.

desktop -> studio-local

Actions:

1. validate studio capability is local
2. stop vLLM if active
3. verify or isolate desktop.target
4. start studio-local-policy.service
5. start audio-priority.service
6. re-observe

Success predicates:

• observer reports studio-local
• graphical session is available
• studio policy marker is active
• audio-priority overlay is active
• vLLM is inactive

studio-local -> desktop

Actions:

1. stop audio-priority.service
2. stop studio-local-policy.service
3. isolate or verify desktop.target
4. re-observe

Success predicates:

• observer reports desktop
• studio policy marker is inactive
• audio-priority overlay is inactive
• graphical session remains available

desktop -> compute

Actions:

1. observe source state
2. validate local compute capability
3. check audio idle
4. check graphical session is terminable
5. notify or terminate graphical session when configured
6. wait for session exit
7. check GPU display release predicate
8. stop studio-local overlay services if active
9. isolate compute.target
10. start or verify vllm.service
11. re-observe

Success predicates:

• observer reports compute
• graphical session is absent or non-authoritative
• compute target is active
• vLLM is active when enabled
• GPU ownership evidence satisfies compute profile

Acceptable degraded compute examples:

• vLLM active on a reduced GPU profile while meeting minimum compute policy
• non-critical desktop service remains but does not conflict with compute
• residual display allocation is below configured threshold

Failed transition examples:

• source cannot be classified
• audio guard blocks transition
• graphical session cannot terminate
• GPU release predicate returns execution error or unsafe conflict
• compute target starts but observer remains conflicted

compute -> desktop

Actions:

1. observe source state
2. check vLLM drainability
3. stop vllm.service
4. isolate desktop.target
5. start or verify graphical/session path
6. re-observe

Success predicates:

• observer reports desktop
• vLLM is inactive
• graphical session is available
• no compute-only conflict remains

Rollback must be validated through the same post-action observation rules.