Security model
Privacy and security as multipliers, not costs
When identity is not co-ingested with every reading, edge credentials stop being the universal key to sensitive corpora.
Platforms emphasizes encrypted transport, topic- and tenant-level access controls, and deployment models that keep validation logic close to ingestion. The architecture assumes compromised devices are inevitable; the goal is to limit what those devices can authenticate to and what history they can exfiltrate.
Detailed threat models, SOC2 artifacts, and customer-specific control matrices are shared during enterprise evaluation—not published as generic marketing claims on this site.
Deployment posture
Dedicated regions, private networking, and observability hooks are discussed during implementation planning. Public security language is intentionally bounded and does not substitute for customer-specific service levels, control evidence, or compliance review.
Trust artifacts for qualified evaluation
Buyers should not rely on public security copy alone. A serious review should inspect the concrete documents and examples that define the pilot boundary.
Accountability during a pilot
Pilot scope should name owners on both sides, define the supported source set, document validation and exception language, and establish how support issues are triaged. If a reading is missing, late, duplicated, or under review, the buyer should know whether the next action belongs to Platforms, the customer system owner, the device owner, or the operations team.
Responsibility boundary
Risk mitigation works only when ownership is explicit. Platforms can reduce exposure in the collection and output path, while the buyer still owns business identity, final operating procedure, and approvals in its regulated or commercial context.
| Area | Platforms owns | Buyer owns |
|---|---|---|
| Collection path | Ingestion design, normalization, validation states, customer-safe output shape. | Representative sources, source access, workflow context, and operational acceptance criteria. |
| Identity association | Default identity-light signal path and documentation of where association can occur. | Systems of record, authorized join rules, patient/customer/account ownership, and downstream identity governance. |
| Security posture | Tenant boundary, service-account scope review, excluded internals, observability expectations, and deployment notes. | Security review requirements, environment constraints, compliance expectations, and approval process. |
| Operational use | Freshness, exception, unavailable, delayed, duplicate, and under-review states in the governed output. | Human review rules, escalation paths, user roles, and final operating procedure. |
| Claims and external use | Bounded product language and evidence artifacts for qualified review. | Approval of clinical, logistics, legal, compliance, or investor-facing use in the buyer's context. |
Triage expectations
A qualified pilot should define how risk signals are handled before the workflow becomes operationally important. These expectations are pilot-specific and do not replace customer-specific service levels or compliance review.
| Risk signal | Named owner | Expected response |
|---|---|---|
| Missing, stale, or delayed signal | Platforms technical lead + buyer operations owner | Inspect transport, freshness rules, device or tracker state, and unavailable-field behavior before operational reliance expands. |
| Unexpected identity association | Buyer system owner + Platforms technical lead | Pause the affected output path, review the association boundary, and confirm which downstream system is allowed to join identity. |
| Raw payload or internal field exposure | Platforms technical lead + buyer security owner | Remove the field from customer-facing output, review excluded internals, and update the pilot control matrix. |
| Credential or service-account scope concern | Buyer security owner + Platforms technical lead | Review service-account permissions, environment ownership, rotation expectations, and least-privilege boundaries. |
| Overbroad claim or operator interpretation | Buyer compliance owner + Platforms product lead | Hold publication, demo expansion, or workflow rollout until claim boundaries and next-action wording are corrected. |
Security review process
Data classification
Identify which fields are raw signal, provenance, operational state, customer context, patient context, or explicitly out of scope.
Identity boundary
Document where identity is excluded by default, where association may happen, and which external system controls that association.
Access and tenancy
Review tenant isolation, service-account boundaries, operator roles, audit expectations, and environment ownership.
Deployment posture
Align on region, networking, observability, incident visibility, secrets handling, and customer-specific control evidence.