Technology
Run local today, HDTS-hosted next, and bring-your-own-cloud on the roadmap. The Banister is built on a governed stack with a clear decision order — and portability so you're never locked in.
Where it runs — your choice
You pick how much we run and how much you keep in-house — the platform meets you at any of three points:
- Run local. The team runs as sessions on a workstation — no cloud dependency required. This is how it operates today.
- HDTS-hosted. We run and manage your Banister on our infrastructure — the HDTS team does the hands-on work, billed hourly under a Statement of Work. We manage; you decide — you stay the decision-maker. (The first cloud step; pilot activating.)
- Bring your own cloud (BYOC). The Banister deployed into your tenant, with your data's residency and governance under your control. On the roadmap — not built yet, but where the residency model is headed.
The residency law
The bottom line for you: your data is never mixed with anyone else's. Client-restricted data is never co-mingled on a shared store — each client's data is isolated by construction. In HDTS-hosted mode that isolation is enforced per-client on our tenant; under BYOC (on the roadmap) the data lives entirely in your own tenant. Either way, isolation is enforced at the architecture level, not by policy — a promise the design keeps for you, not one you have to trust.
The stack decision tree
Technology choices follow a ratified order of preference — not per-project taste:
The internal stack
| Concern | Built on | Why |
|---|---|---|
| Models | Anthropic Claude, portable by design | Best-on-merit, never single-vendor-locked. |
| Compute | Azure Functions (serverless) | No servers to run; scale to zero. |
| Client portal | Per-client SPA at <you>.hdtsllc.com | Own repo, own subdomain, own resource group. |
Full stack, technical detail:
| Concern | Built on | Why |
|---|---|---|
| Models / reasoning | Anthropic Claude (primary), portable by design | Best-on-merit, with the abstraction to route to other providers — never single-vendor-locked. |
| Compute | Azure Functions (serverless) | No servers to run; scale to zero; pay for what executes. |
| Coordination bus | Azure Service Bus | Durable, broker-confirmed messaging — the source of truth for team comms (Layer 5). |
| Knowledge / vector | Postgres + pgvector, one DB per client | Grounded retrieval with row-level security; isolation exercised by a conformance suite (Layer 6). |
| State / board | Azure Table storage | The authoritative work board and comms ledger (Layer 3). |
| Identity / secrets | Managed identity + per-client key vault | Keyless where possible; a persona structurally can't read a peer's mailbox. |
| Client portal | Per-client SPA at <you>.hdtsllc.com | Vendored per client — own repo, own subdomain, own resource group. |
The residency law, in the architecture
Client-restricted data is never co-mingled on a shared store — each client's data is isolated by construction. In HDTS-hosted mode that isolation is enforced per-client on our tenant; under BYOC (on the roadmap) the data lives entirely in your own tenant. Either way, isolation is enforced at the architecture level, not by policy.
