← Case Studies/Case #004 · ADR Registry

Local-First Remote Work Orchestration for Sensitive Compute

Case #004 · 16 knowledge artifacts · April 5, 2026 · YY Method™ Home Edition v2.3

Complete. Implemented under employer. Will be reopened as circumstances evolve and new technology arrives.

The founding argument in one sentence: window from operator into work. Work stays put.

C4-001 is the anchor — all 15 downstream decisions derive from the local-first trust-boundary principle. If C4-001's assumptions change, re-verify the entire case.

Abstraction Policy

Generalized

Device names reduced to roles. Model sizes reduced to workload classes. No hostnames, addresses, or ports.

Removed

Exact commands, pathnames, schedules, automation triggers, and client-identifying environmental markers.

Preserved

Tradeoffs, constraints, reverify conditions, dependency graph, and scars. The reasoning chain is intact.

Foundational Principles

Trust boundary, control/execution separation, private overlay, publication boundary
C4-001
Keep Sensitive Compute Local — Remote the Operator, Not the Data

Local-first is the governing principle, not an optimization. Remote access moves the operator to the work — never the work into a new trust domain. Sensitive computation stays on controlled work endpoints. Remote devices are control surfaces only. Scar: early framing centered on convenience. Trust-boundary primacy arrived late and should have been the first question.

Decided
C4-002
Separate Control Surfaces from Execution Surfaces

Control surfaces and execution surfaces are distinct by design. Personal devices control; work-managed endpoints execute. Mobile and portable devices remain lightweight and unencumbered by sensitive execution state. Role separation reduces leakage, ambiguity, and attack surface. Each device class does what it is best at — without being asked to do what it is not.

Decided
C4-003
Use a Private Overlay Network — Not Publicly Exposed Remote Services

Public exposure of management services is rejected. All remote access traverses a private overlay or equivalent zero-trust channel. The execution surface remains dark to the public internet while staying reachable from approved endpoints. Reduces brute-force exposure, port management complexity, and unsafe compensating controls.

Decided
C4-004
Preserve the Method — Do Not Publish the Client's Concrete Deployment

The case study preserves reasoning, constraints, tradeoffs, and scars. Client-identifying topology, commands, addresses, and defensive posture are abstracted or omitted. The method is teachable without disclosing the instance. Specificity degrades client security; omission loses methodological force. The balance is principled abstraction.

Decided

System Architecture

Machine roles, portable node, office node, mobile interaction, command system
C4-005
Assign Distinct Roles to Distinct Machines — No Unified Pattern

The environment has distinct endpoint classes: office-bound automation node, portable secure work node, and personal control surfaces. Each retains its own role, power policy, and interaction pattern. Forcing one machine pattern onto all creates wrong defaults on at least one class. Role specialization is not overhead — it is the architecture.

Decided
C4-006
Maintain a Portable Secure Work Node as the Primary Remote Execution Surface

One portable endpoint serves as the primary remote execution surface. Reachable from variable networks, supports heavier local workloads when required, and maintains continuity between office and travel contexts without moving sensitive work onto personal devices or cloud services. This is the endpoint the window opens onto.

Decided
C4-007
Keep the Office Automation Node Awake Only When Automation Is Active

The office-bound node supports ambient automation during office presence. Wakefulness is conditional: active during live automation windows, sleep allowed and preferred when automation ends or the machine is idle. 'Always awake' wastes power. 'Always sleep' breaks automation. Conditional wakefulness tied to active work is the correct policy.

Decided
C4-008
Prefer Command-First Mobile Interaction — Reserve Full Remote Desktop for Escalation

Mobile interaction defaults to secure command execution and status retrieval — not full graphical remoting. Phone-sized screens make visual remoting expensive for routine tasks: high bandwidth, latency-sensitive, poor ergonomics. Command-first is faster, more reliable on unstable networks, and suited to brief operational windows. Full remote desktop remains available as escalation.

Decided
C4-009
Build a Command System with Progressive Promotion — Repeated Actions Earn Their Shortcut

Three-layer interaction model: raw command access for full flexibility, reusable named commands for structured operations, shortcuts promoting only the most-repeated actions. Repeated actions become cheaper over time without surrendering the general case. Shortcut promotion is subordinate to the command layer — not a replacement for it. The future command set is emergent, not predetermined.

Decided

Operations & Safeguards

Admission control, recovery paths, power policy, dual-mode operation, tablet boundary
C4-010
Put Admission Control in Front of Heavy Local Inference

Heavy local inference is not a casual process class. A small number of overlapping launches creates disproportionate thermal and performance cost. The portable work node requires a guarded admission layer: check current load, enforce conservative concurrency limits, refuse unsafe starts with clear reasons. Safe refusal is preferable to opportunistic overload.

Decided
C4-011
Pair Every Guardrail with Status, Kill, and Recovery Paths

Blocking unsafe starts without paired observability creates a different kind of brittleness. Every heavy-work admission layer requires: a concise status command, a targeted kill path, a stale-state recovery path, and logs readable from mobile. Guardrails without recovery eventually produce unsafe bypasses. The operator needs fast emergency control from away.

Decided
C4-012
Set Power Policy by Machine Role — Not a Single Global Preference

Power policy is architectural. Different machine roles require contradictory power behavior: the office node sleeps when inactive, the portable node stays reachable but reduces idle draw, control devices are opportunistic and disposable. A single global rule — never sleep, or sleep aggressively — fails once machine roles diverge. Policy follows role.

Decided
C4-013
The Portable Work Node Must Support Both Remote and Local Use Without Reconfiguration Debt

The portable work node is not purely headless. It may be opened and used directly at the office, then returned to remote-optimized operation later. Mode transitions carry minimal cost by design. A device that works only when closed or only when open creates operational drag. Dual-mode is the correct baseline.

Decided
C4-014
Treat Tablet-Class Devices as Auxiliary Surfaces — Not Trust-Boundary Shortcuts

Tablet-class devices are optional — auxiliary display or control surfaces in travel contexts. Identity separation and device-role boundaries are preserved regardless of tablet presence. The trust model remains intact if the tablet is absent. Convenience at the tablet cannot justify collapsing separation that was intentionally preserved.

Decided

Governance

Method ownership, client boundary, publication and obfuscation standards