Data — the nine domains

What the Data facet does, domain by domain.

In detail

1. Collecting — how data comes in

The file is the boundary. The device drops a file into the account's storage; the platform reacts, routes it and records it. There is no interface to call on the machine's side.

• It works even without Fleet: any producer able to place a file will do.
• The account comes from the location, never from the file's content.
• The folder states the nature: logs, telemetry, business operations.
• Attachments kept as they are — photographs and binary files are never truncated.
• Identity verified: a file that does not designate a valid device is refused and recorded.
• Direct interface for a third-party system, with the same mechanics.
• At least once, never twice: a replayed submission writes nothing.
• A faulty line is skipped and counted — never a blocking loop.
• Processing acknowledgement: the platform empties the file, the device cleans its storage.
• Nothing disappears: an unrouted record goes to a reserve feed, still readable.
• Operational alerts raised automatically: failed file, rejected lines.

2. Sampling — the feeds

Everything is a feed of records. A single engine filters them, and it is set in the portal with no redeployment.

• A pipeline = an input feed, a filter, an output feed.
• Several per feed: the raw data and the per-minute average, for instance.
• Nothing enters by accident: a feed with no pipeline is rejected and counted.
• Five filters: pass everything, filter on a list, compare a number, aggregate by window, or ignore tiny variations.
• A missing field keeps the line rather than losing it.
• Each point keeps its provenance — you know which pipeline produced it.
• Adjustable retention per output feed, with automatic purging.

3. Modelling — devices, feeds, records

What the platform keeps about a device, and in what form.

• A device exists from its first heartbeat, before any data.
• Identity comes from the device: recording only fills gaps.
• Three notions of type that check one another: technical, business, and the point of sale's.
• Data is kept raw: readings are accessed through declared paths.
• So no business columns: any sensor, any format.
• Two readings of presence: data freshness, and the observed sign of life.
• Random identifiers: a number never reveals a volume of activity.
• Non-conforming rows are set aside, not lost.

4. Alerting — alerts and notifications

An alert has to reach the person who can act. Everything else follows from that.

• An alert crosses a type, a level, a device and a message.
• Systematic record: even an alert no rule picked up stays visible.
• That is the tuning tool: "the alert arrived, nobody picked it up".
• A rule pairs a criterion with actions, one per channel.
• Three channels: email, SMS, notification in the portal.
• Messages composed from the event's own data.
• Dynamic recipients: the address of the consumer concerned, resolved at send time.
• Episodes: an alert opens then clears, with its counter.
• Unsubscription honoured on every send, manageable by each person.
• Ten ready-made rules for every new account.

5. Isolating — accounts, organisations, contexts

Each customer must see only their own machines. This is enforced server-side, not merely on screen.

• One database per account, with its own secret.
• The account derives from platform facts, never from content.
• The organisation is the account's customer, and the axis for breaking down sales.
• The context is a scope along eight combinable axes.
• One role per context, switched from the header.
• The user axis bounds the portal to the person signed in: that is the consumer site.
• Viewing as a user: read-only, no monetary action, every access logged.
• Display is never security: the scope is injected into every query.
• A context that selects nothing is flagged, rather than showing everything.
• Two keys per account: the administration one, and the machines' one with a bounded role.

6. Identifying — the octopod

The point of sale has its own identity, distinct from the machine fitted to it. That is what allows a box to be changed without losing anything.

• Dated and recorded binding, never deleted.
• Three pairing modes: the device draws its reference, the technician chooses, or the platform decides.
• Pairing works offline and reports at the first network connection.
• Explicit acceptance rules: a reference already bound elsewhere is refused and recorded.
• Preparing before the hardware arrives: the reference set on the device binds the expected point of sale.
• Qualification: a manager confirms the type, or rejects and frees the device.
• Technician application on the machine's screen, for pairing and testing.

7. Configuring — the site without development

Opening a new customer must require no code at all.

• Four levels: platform, deployment, account database, user preferences.
• All content is editable online, with no redeployment.
• Identity per site: title, icon, colours, theme, home page.
• Pages composed from a registry of known types.
• A page of an unsubscribed facet does not appear.
• Eight widgets: indicator, chart, histogram, gauge, table, alerts.
• One dashboard per context, or inherited from the site.
• Content translated into seven languages, one of them right to left.
• Search, filters, sorting and export on every list.

8. Reporting — exports and timelines

Exact figures, and a complete story for each machine.

• Four reports exact to the cent: sales, VAT, receipts, subsidies.
• Read "as at" a chosen day: the report as it stood on that date.
• Exact by construction, because it rests on facts that are never erased.
• Days in the site's time zone, and several currencies never added together.
• Unified timeline for a device: alerts, sales, logs and actions together.
• Action log: every act is dated and signed by its author.
• Anomaly detection: drifts spotted before the failure, exposed as alerts.

9. Operating — the account's deployment

What happens when you open a new customer.

• One gesture: their database, their ingestion route and their sites are raised and kept up to date.
• One account's failure affects no other: each deployment is isolated.
• Cost follows activity: the database pauses for a dormant account, is provisioned for an active one.
• States, not commands: switching a module on is a toggle, nothing is destroyed.
• Pinned versions, and the version actually served can be verified.
• Never a purge without an archive: retention archives before it erases.
• The licence decides which facets are active — an account cannot enable one by itself.