CubeSTEM

Use case

The composed mission

Most engineering teams are not starting from nothing, and not starting from everything. They own part of a bench and need the rest. A composed mission is what happens when the platform stops assuming that all the hardware belongs to one organization.

The situation this exists for

You have an on-board computer on your desk. You do not have the power supply you need to characterise it against, and buying one to find out whether it fits would cost months. Meanwhile a laboratory two countries away has exactly that hardware, idle for most of the week, and no safe way to let anyone else near it.

  • Buying the missing subsystem freezes an architecture decision before you can evaluate it.
  • Shipping your hardware to someone else's bench means losing custody of it.
  • Letting a stranger reach into your laboratory means opening a network and trusting a policy you did not write.

A composed mission removes the choice. Each owner keeps physical custody, keeps local authority, and exposes only what they decide to expose — and the mission still sees one bench.

Bring the hardware you have. Reach the rest through the cloud.

YOUR APPLICATION

One Client SDK. One device model. One evidence trail.

TWINLINK

Discovery, leases, authorization, command routing, telemetry, audit

YOUR SITE

Hardware you already own

For example: your OBC

  • Your Bridge — software you run, dialling out
  • Your Connector — your protocol, mapped once
  • Your local safety — yours, and final

You contribute it. You keep it. You can withdraw it at any time.

VENDOR OR LABORATORY SITE

Hardware someone else owns

For example: their EPS

  • Their Bridge — software they run, dialling out
  • Their Connector — their protocol, mapped once
  • Their local safety — theirs, and final

They expose a capability subset to you under an explicit grant: scoped, time-limited, and revocable at any moment.

01Two leases, not one
A session lease is scoped to a single resource. A composed mission holds one lease per resource, each with its own command allowlist and its own expiry. Nothing about one lease is implied by the other.
02Two safety boundaries, both final
Local safety is per site and independent. Cloud policy can be stricter than an owner's limit; it can never be weaker. Neither owner's hard limits can be relaxed by the platform, by the other owner, or by you.
03Two owners, two independent revokes
Either side can withdraw unilaterally, without negotiation. The mission fails closed on that resource — and only on that resource. The rest of the composed bench keeps running.
04One interface
The same SDK, the same device model, the same command paths, the same evidence — regardless of who owns which resource or which country it sits in. Your application does not need to know the difference.

What each side actually does

IF YOU ARE THE MISSION TEAM

  1. 01Run a Bridge beside the hardware you already own. It is software on an ordinary lab PC, and it dials out.
  2. 02Map your hardware once with the Connector SDK — your protocol, your COM port, your CAN IDs, all staying local.
  3. 03Discover the resources you have been granted access to, alongside your own.
  4. 04Take a lease on each resource you need, and run the mission through one Client SDK.

IF YOU OWN THE OTHER HALF

  1. 01Run a Bridge beside your hardware. Nothing inbound is opened, and no equipment leaves your site.
  2. 02Declare the capability subset you are willing to expose — a cloud-safe manifest, with ports and secrets staying in a local config that never travels north.
  3. 03Grant a named organization a scoped, time-limited lease on that subset.
  4. 04Revoke it whenever you want. Discovery and bound sessions fail closed immediately.

Where this is real and where it is not

Resources carry an owning organization, a site, and an execution kind
IN THE PINNED CONTRACTS
A session lease is scoped to one resource, with a deny-by-default command allowlist
IN THE PINNED CONTRACTS
Local safety is declared per resource and cannot be weakened from the cloud
IN THE PINNED CONTRACTS
Cross-organization grants — scope, TTL, revocation, fail-closed discovery
EXPERIENCE LAYER ON THIS SITE, NOT A TWINLINK 0.3.0 API
Device-model coverage for on-board computers and power subsystems
NOT IN THE PINNED DEVICE MODEL
Any of this running against physical hardware
NOT CONNECTED YET

The composition you can exercise in the product experience runs on simulated resources across three organizations and three sites. The organization, site, lease and safety semantics it demonstrates are the pinned ones; the grant layer on top of them is this website's, and is labelled as such wherever it appears.

See it run in the product experience 3 min · interactive

OBC and EPS name the real-world shape of this use case, not shipped device classes — the TwinLink device model covers the resource classes it covers today, and this website is pinned to contracts 0.3.0. The cross-organization grant you can exercise in the product experience is an experience-layer capability, not a TwinLink 0.3.0 API.

Back to the platform overview