← All case studies
mastOS · Multi-Tenant AI Infrastructure Platform
Production AI operating platform for regulated, multi-tenant healthcare environments.
Engines
5
Harbors live
H001
PHI exposure
ZERO
Infrastructure
Azure-native
01 · CONTEXT
Who. What scale. What was at stake.
Mast Labs needed a platform that could deploy AI across multiple regulated verticals without rebuilding the intelligence layer for each one. The first vertical was physical therapy. The second, third, and fourth would follow. Every deployment had to be PHI-safe, HIPAA-compliant, and clinically accountable from day one. The constraint was not building one product. The constraint was building a platform that made every future product structurally cheaper to ship.
02 · CONSTRAINT
The architectural problem.
Most healthcare AI platforms are monoliths built for a single use case. When the second vertical arrives, the team rebuilds. When the third arrives, they fork. mastOS had to solve a different problem: shared intelligence, isolated data, sealed per-tenant deployments, and a governance layer that could not be bypassed at the application level. The intelligence layer and the PHI layer could not be the same layer. That separation had to be structural, not policy.
03 · DECISION POINTS
Three decisions that shaped everything downstream.
Decision 01
Medallion data architecture
Five-layer data model. Bronze: raw, immutable, append-only. Silver: normalized, Postgres and ADLS Parquet. Gold: aggregated business truth for analytics. Cosmos: operational hot store for real-time reads. Archive: 7-year HIPAA retention. Engines read from Gold and Cosmos. They never touch Bronze. This created the structural separation between intelligence and PHI.
Decision 02
Harbor isolation at the infrastructure level
Each Harbor is a sealed Azure resource group. Dedicated Cosmos DB, Postgres, Key Vault. Customer-managed encryption keys. Isolated network boundaries. A configuration change, billing event, or data incident at one Harbor has no path to another. Enforced by Azure Resource Group RBAC, not application logic.
Decision 03
De-identification as middleware, not policy
A de-identification pipeline runs as middleware before every AI call. Names, dates of birth, contact information stripped before they reach any model. Cannot be disabled. The intelligence layer receives only de-identified clinical context and identity tokens. Decisions happen without reading clinical content.
04 · SYSTEM
What was built.
Five engines on a single control plane: Acquisition, Operations, Clinical Intelligence, Analytics, and Governance. All engines share the same taxonomy, the same audit trail, and the same de-identification boundary.
MILO: patient-facing AI assistant. Conversational intake via SMS, care plan delivery, exercise program guidance, appointment coordination. Operates 24/7. Escalates to human only when clinical judgment is required.
MIRA: operator analytics layer reading from the Gold data tier. Natural language business intelligence for clinic leads and administrators.
RBAC: six-tier permission model. Permissions are arrays, never role strings. Every channel runs AI first. Deterministic escalation path: AI resolves, then cx_agent, then clinical_lead, then harbor_admin.
Harbor architecture: buildTheme(scheme, brand) allows every visual token to be overridden per Harbor with zero code changes. White-label per clinic.
HEP data engine: home exercise program assignments with weight_bearing flags filtering clinical suggestions. MILO will not suggest load-bearing exercises for post-op patients.
05 · OUTCOMES
All metrics from production systems.
Five engines operational on a single control plane.
Harbor H001 live in production.
Zero PHI exposure across every engine, by architecture.
De-identification middleware cannot be disabled at any layer.
MILO handling intake, HEP delivery, and patient engagement autonomously.
Admin tooling shipped: PT Directory, Patient Directory, Harbor Settings, Billing Export.
Platform designed for multi-vertical expansion without rebuilding the intelligence layer.
06 · DISCUSS FURTHER
The architecture above is public. What follows is a conversation.
Medallion data architecture design, Harbor provisioning workflow, de-identification pipeline implementation, RBAC permission model, engine orchestration patterns, MILO agent specification, and the specific Azure resource topology are shared in a 30-minute conversation with executives evaluating similar platform work.