Layer 6

Runtime

Runs local today, built to move to the cloud without changing who it is. A persona is the same identity whether it runs on a workstation or as a cell in the cloud.

Move, not clone

The migration path is designed as relocation, not duplication — a seat moves to the cloud, it doesn't fork into a second copy that drifts from the original. Identity is preserved across the move; only the runtime changes.

How you engage — four stages, at your pace

The Banister meets you where you are and grows with the relationship. You don't commit to the end state on day one — you start with a trial and move only as far as you want:

  1. Step 1 — the trial (a mutual try-out). Every engagement starts at Layer 1: HDTS stands up your team, ingests your company, and tunes it to you. That onboarding — the build, the tuning, the ingest — isn't billed; it's simply how a project begins. Only the actual work the Banister then does for you is billable — hourly, under a Statement of Work and NDA. HDTS runs it (local or in our Azure cloud) for the first months; we manage and do the design work, but we don't decide — you do. Begin with one of a few ready-made starter projects.
  2. Service contract. Move to an ongoing service where HDTS runs the full Banister in the cloud for you.
  3. Part-local, with your team. Bring it partly in-house — running alongside your own people.
  4. Bring your own cloud (BYOC). The whole thing — docs, plans, and runtime — lives in your ecosystem. (On the roadmap.)

From the service stage on, HDTS keeps a remote link into your Banister — so across stages 2–4 we upgrade its features, monitor for failures, and stay on-call. You're never running it alone.

The stack itself follows a governed order of preference — data residency in your tenant first, then serverless, cloud-native, with model portability so you're never locked in. The full stack and the decision tree are on the Technology page.

Per-client data isolation

Each client's data lives in its own database with row-level securityTermDatabase rules that filter which rows a query can even see — enforced by the database itself, not by application code remembering to ask nicely., and the isolation is exercised by a conformance test suite rather than assumed — a stronger answer to "prove one tenant can't see another" than most platforms offer.

Two planes, workstation and cloud, joined by one identity spine; migrate not clone; a per-client database with row-level security on the cloud side.
Same worker, new address — identity moves, it never forks. Download SVG ↓