Cohesix Use Cases

A team has a model on a Mac, a CUDA workload on a Jetson, and an operator who needs to know what actually ran. An agent can suggest a change, but it should not need a shell on either machine to make that change.

Cohesix gives the team a narrow control path:

Propose an action → check who may do it and within what limits → run it on the right host → inspect the observed result → recover or roll back when necessary.

The Cohesix Queen runs on a small seL4 system. Its Workers track bounded control, lease, telemetry, and receipt state. CUDA, MLX, model weights, training data, inference servers, containers, and application data remain on their ordinary hosts. Cohesix is useful when the decision to run or change something must be smaller, clearer, and easier to audit than the system doing the work. A request being accepted is not proof that its external effect happened.

This guide describes what to do with a matching Cohesix 1.2.0 installation: useful CUDA jobs, private adapter releases, Mac MLX work and agent clients that share one governed job and evidence model. Check the installed version, selected profile and Status before citing present availability; this guide is not a release certificate. The examples are deployment patterns, not claims that Cohesix supplies a finished medical, traffic, manufacturing or robotics application.

Mac and Linux hosts can use the same control model while needing different native tools. The skills below inspect the relevant OS, accelerator, runtime and selected provider, explain incompatible combinations, and suggest a supported setup or host before an operator applies a change.

The basic distinction is simple: Cohesix decides and records whether a specific action may run. The selected Mac, Jetson or other prepared host runs the model, service or container. The result needs observation and, when claimed as verified, the applicable independent evidence check.

What you can build

1. The Agent Action Airlock

Situation. An operations agent notices a failed service or a ready adapter. Giving it a machine-wide credential would let it do far more than restart that service or request a release. A bounded Kubernetes action could use the same pattern after its own provider integration.

Cohesix’s role. Give the agent a typed, allowlisted action with a subject, scope, deadline, budget, and explicit refusal. A host provider performs the approved effect and reports what it observed. The operator can distinguish the proposal, admission, native result, and verified outcome. If an answer is lost, the agent inspects the original job instead of blindly retrying the action.

An installed agent can discover selected operations over MCP, or delegate a durable job over A2A. A person can use CLI, Python or a Mac Shortcut for the same underlying action. With NeMo Agent Toolkit, a useful journey is: inspect available work, request a CUDA job or PEFT release, see a real denial for an out-of-scope action, disconnect, then recover the original result. Each client keeps the same subject, budget and job identity. Cohesix does not replace NeMo’s planner or model endpoint; tool and task responses do not independently certify the native outcome.

Use the agent delegation skill to select MCP versus A2A, scope a request and reconcile a lost response.

2. The Self-Healing Edge Swarm

Situation. Several camera, robot, or production-line hosts report degraded health. The team needs a common view and a safe way to restore one service without letting a classifier or dashboard acquire broad control.

Cohesix’s role. Heartbeat Workers and bounded telemetry show where to look. A host-side model can rank likely faults. Any remediation returns through a specific ticket or schedule request, with an observed provider result and a visible unresolved state when recovery is uncertain. Raw video, tensors, and high-volume event streams remain in the application data plane.

Start with fresh target and host observations, then request one allowlisted recovery action and observe the application afterward. Autonomous diagnosis, site-specific fail-safe behavior and recovery quality still need evidence for that site. The manufacturing and traffic playbooks below rehearse control relationships; they do not run a safety application. Use the edge recovery skill for the before/action/after workflow.

3. The GPU Flight Deck

Situation. A team wants to run batch inference or embedding work on a Jetson while other jobs share the device. They need to know which model and inputs were approved, whether the GPU was available, which process actually ran, and whether its outputs are the expected ones.

Cohesix’s role. An operator registers an approved, pinned workload with a fixed entry point, typed inputs, and resource limits. The Queen admits a job; a constrained host executor runs it on the selected NVIDIA device. The operator can inspect device freshness, queue and lease state, native execution, output hashes, and cancellation or recovery. An active lease is a control decision, not a claim of hard GPU isolation.

The selected CUDA reference uses digest-pinned workloads and independently checked useful work on a Jetson Orin through systemd and Docker. A different NVIDIA device, driver, container or executor profile needs its own compatibility and native-result check. See GPU Nodes and the GPU operations skill.

4. Model Rollout with a Flight Recorder

Situation. A team must decide which model or adapter should serve next. A developer explores a candidate on an Apple Silicon Mac, then compares it with a CUDA-backed deployment on a Jetson. They need to know which host did each stage, whether any private artifact moved, and which generation a real client reached after promotion or rollback.

A selected Mac MLX rollout or Linux CUDA rollout can stay on one host. The Mac-to-Jetson journey here shows the additional comparison and verified transfer steps when both hosts are selected.

Cohesix’s role. A governed rollout names the provider and host for each stage, checks capability and capacity, preserves one job lineage, and shows local Metal observations separately from verified remote CUDA outcomes. A model reference is not a file transfer. An accepted model choice is not a verified deployment. If distribution is selected, the host data path must deliver the bytes and verify the full destination hash before a separate activation decision.

The Mac path distinguishes local MLX/Metal exploration from an admitted Mac release. On an advertised profile, the admitted path can train, compare, serve a canary and recover the accepted generation, with optional vMLX serving bound to that generation. vMLX serving, vMLX as an MCP client and a separate A2A peer using its model endpoint are different integrations. A model response cannot certify a Cohesix job. Mixed MLX/CUDA work and verified weight distribution are usable only where the installed profile advertises and qualifies those paths. There is still no dedicated built-in Python playbook for a complete model rollout; the model rollout skill gives an operator a concrete comparison, transfer and serving checklist.

5. The Private LoRA Foundry

Situation. A team fine-tunes a small adapter for a local task. Training finished, but that alone does not answer whether the adapter improves the application, matches the intended base model, or is the version currently serving users.

Cohesix’s role. Keep the base revision, adapter, dataset snapshot, runtime, and request identity together. Train or import through an approved host path; compare the candidate with the base and incumbent on held-out data; check the artifact; stage it; observe a real inference canary; then promote or roll back the exact serving generation. A failed comparison stays visible. A lost response is followed under its original operation identity so it cannot quietly start a second effect. Private weights and data stay on the selected host unless a separately authorised transfer is made.

The private LoRA guide covers native training or import, evaluation, canary and verified rollback. A registry pointer is not proof of serving. The selected model, adapter and runtime pair must be compatible; the guide’s reference result does not qualify arbitrary LoRA, QLoRA or MLX combinations. Use the private adapter release skill to freeze the comparison and follow a real client to the accepted generation.

6. Multi-Hive Mission Control

Situation. An operator manages a Mac, a Jetson, and several edge hives. They want one read-only view of pressure and failures, but each hive must keep authority over its own mutations.

Cohesix’s role. Host-side fan-in gives a fleet picture. A bounded ticket relay can ask a selected hive to act while local admission still decides. Receipts retain the source and destination relationship; a relay cannot promise exactly-once behavior for an unobserved external effect. Leases, quotas, and provider evidence remain separate in the display.

Host-side composition and the Python playbooks provide starting points. Each live site still needs target, authentication, provider, failure and retention checks. The mixed factory and logistics names below describe possible uses of the pattern, not shipped industry integrations. Use the fleet operations skill to keep each hive’s freshness, authority and result visible.

Review an incident or a change after the fact

Situation. A rollout appears to have succeeded, but a user saw the old model, a service restarted twice, or a recovery request timed out.

Cohesix’s role. Capture bounded status and traces, compare before and after evidence packs, and build a source-linked timeline for incident, maintenance, rollout, or federation review. Keep the request, admission, provider observation, and signed result separate. A retained replay helps explain an event; it does not turn an old host observation into fresh target or hardware proof.

This operator workflow is useful on its own and is the evidence path behind the other scenarios. Use the evidence skill to build a case without turning a partial capture into a success claim.

What recent community discussions tell us

This is a snapshot of public engineering conversations checked on 26 September 2026. A thread shows a reported problem or design question; it does not mean every deployment has that problem or that Cohesix fixes the underlying library. It tells an operator what to observe and test.

Across these conversations, four checks matter: did useful CUDA work really run; did a private adapter improve and reach a real client; which work was local Metal versus remote CUDA; and could the agent recover after refusal or a lost response? Model runners and data stay on their hosts. Each model and runtime combination still needs its own compatibility check.

Try the nine control-model playbooks

The Python package contains nine named playbooks for exploring the approvals, schedules, leases, exports and local provider probes involved in these ideas. They are control-model rehearsals. The skills above guide real operating work against a matching deployment. From a source checkout:

python3 -m pip install -e tools/cohesix-py
cohesix-playbook --list
cohesix-playbook --playbook mixed-closed-loop-ai-factory --dry-run --mock
jq '{workflow_kind, use_case_id, plan_summary, production_use_case_accepted}' \
  out/examples/playbooks/mixed-closed-loop-ai-factory/report.json

The dry run’s report identifies a control model and says “production_use_case_accepted”: false. It does not train, serve, evaluate, deploy, or control a factory. Removing –dry-run –mock submits the generic control plan to the selected backend; it still does not create a complete sector workflow. Local probes inspect the machine running the playbook, so a Mac rehearsal cannot silently discover a remote Jetson.

The compiler-owned dependency graph and generated support table identify the playbook dependencies and evidence modes. The playbook catalogue helps design a deployment; it does not satisfy those dependencies or confer sector acceptance.

How to decide whether Cohesix fits

Cohesix fits when the hard part is deciding who may change what, keeping a job within declared limits, and finding out what happened after an interruption. It is especially useful where a powerful host runtime must remain outside a small control plane.

It is a poor fit if the proposed solution needs POSIX applications, CUDA or Metal kernels, raw model weights, a trainer, a general container runtime, high-volume media streams, arbitrary RPC, or an extra network listener inside the seL4 VM. Offline durability requires an accepted persistent target profile or host store; an in-memory Worker alone cannot promise it.

Before adopting a scenario, ask:

1. Which exact target and host profiles are in use, and which provider owns the real data plane?
2. What action, subject, bounds, and refusal authorize each mutation?
3. What proves that the external effect happened, beyond admission or HTTP success?
4. If a reply is lost or a process restarts, how is the original job found?
5. Where do private inputs, model bytes, credentials, and retained evidence go?
6. Which operations are qualified on this exact installed profile, and which examples are only fixtures or design patterns?

Start with the Quickstart, the Operator Walkthrough, or the Private LoRA guide. The Build Plan owns milestone scope, Status records current evidence, and the Test Plan defines the proof needed for a claim.

Bring a real workflow

A useful contribution is one narrow journey another engineer can reproduce: an approved workload, fixed inputs and quality measure, a native provider observation, a refusal or interruption, and an honest result. The repo-managed skills under skills/ give starting procedures; they do not activate capabilities or replace the installed guide and operator policy. For a new Mac or NVIDIA environment, start with AI host setup. For an unfamiliar Queen, start with read-only inspection.

Good additions include a reproducible model/runtime pair, a negative case that shows a refusal clearly, a better receipt or recovery view, or a sector integration with its own provider and safety evidence. The Build Plan owns scope and the Test Plan owns proof. See Contributing and Operator Recipes for the current entry points.