Asset and site context
Use a common organisation, site, asset, device, and sensor-channel model across current and future services.
The ciliot platform
ciliot provides the shared capabilities that connected-asset services need: tenant-aware identity and context, source-aware data, policy-driven conditions, accountable workflow, integrations, and reviewable operational evidence.
Designed to evolve
The first module is Refrigeration & Cold-Chain Monitoring. The platform deliberately separates reusable connected-asset capabilities from the domain rules that make a service useful to a particular team.
Use a common organisation, site, asset, device, and sensor-channel model across current and future services.
Keep immutable source evidence distinguishable from canonical, derived, and workflow records used by operational services.
Make policies, conditions, people, notifications, decisions, and reports part of a coherent operational record.
A repeatable operating flow
The platform is designed so an operational service can explain the condition it sees, its evidence and policy context, the people involved, and the outcome—not simply issue a notification.
Platform contracts
People, systems, and controls
A healthy IoT operating model has to serve local operations, specialist reviewers, customer IT, and platform support with explicit roles and a clear boundary between evidence and control.
Establish the organisation, sites, roles, entitlements, retention, and integration ownership.
Associate gateways, devices, sensor channels, assets, calibration evidence, and operational contacts.
Use role-relevant queues, dashboards, reports, exports, and integrations to manage the daily work.
Use incident, support, usage, audit, and benefit evidence to govern the service and its future changes.
A deliberate trust boundary
Platform controls support tenant-aware authorization, encrypted transport and storage, immutable source evidence, and audited workflows. They are not a blanket guarantee or a substitute for each customer’s governance and compliance responsibilities.
Plan organisation, tenant, role, entitlement, and support-access boundaries as explicit product controls.
Use defined interfaces, audit context, and evaluated support boundaries instead of unbounded connector promises.
Retain the source, configuration, response, and report context needed to understand scope and lineage.
A platform conversation
We start with the service and decision you need to support, then make the data, ownership, and integration boundaries explicit.