How the register
is put together.

Start here

Four steps, in this order. A pilot session gets through all four with your own data in it; on your own it is an afternoon.

1. 1

   Pick an industry pack

   It seeds your categories, custom field definitions, renewal lead times and vocabulary. Nothing in it is locked — the pack is a starting point, not a mode the product runs in.

2. 2

   Import the spreadsheet

   Map your columns, run a dry run that shows exactly what will be created, fix the rows the error report flags, then commit. The whole import is one batch you can undo in a single action.

3. 3

   Attach the obligations

   A licence, permit, certification, calibration, warranty or contract, each with its own expiry, cancellation deadline and renewal lead time. This is where the alerting gets its dates.

4. 4

   Name who is responsible

   Alerts go to a person, not to a shared inbox where they go to die. Set the owner on the asset, and the escalation path on the organisation.

Core concepts

Pulling these apart is what makes the alerts correct and the audit trail defensible. It is also why one product serves a dental lab and an aerospace machine shop without becoming two products.

Asset

A serialised physical thing with a category, a location, an owner and a lifecycle.

Obligation

Anything time-boxed attached to an asset, with up to three dates that matter.

Plan

The recurring commitment — a calibration interval, a maintenance schedule.

Evidence

What happened and the certificate that proves it, including as-found and as-left values.

Organisation

The tenant boundary. Every query is scoped by it, and that scoping is tested on every endpoint.

Event log

Append-only history written in the same transaction as the change it records.

API

A REST API over the same handlers the interface uses, authenticated with an organisation-scoped key. Lists are keyset paginated — you follow next_cursor, never an offset, so a page cannot shift under you while a colleague is editing.

Everything due in the next thirty days

curl https://api.example.com/v1/orgs/acme/entitlements   -H "Authorization: Bearer $ACT_KEY"   -G -d status=due -d within=30d -d limit=50

{
  "entitlements": [
    {
      "id": "412",
      "name": "Pressure vessel inspection",
      "asset": { "id": "31", "asset_tag": "AUT-002", "name": "Autoclave 2, Room B" },
      "expires_on": "2026-03-31",
      "days_remaining": 22,
      "status": "due"
    }
  ],
  "next_cursor": "eyJpZCI6NDEyfQ"
}

An expiry is a calendar date, not an instant. A permit expiring on 31 March expires on the 31st where the site is, and a site in another country keeps its own calendar.

The full reference — every endpoint, how keys work, and the error envelope. It is generated from the service’s own routing table, so it describes what is running rather than what was written down.

Educational content

Explainers about the problem rather than about our buttons. They are worth reading even if you end up tracking all of this somewhere else.

• Getting off a spreadsheet without losing the historyHow to map a column that holds three different dates, and what to do with the rows nobody can explain any more.
• Choosing renewal lead times that are actually trueA permit that takes twelve weeks to process needs a twelve-week lead time, not a thirty-day reminder. How to find the real number.
• Designing an escalation path people do not muteWhy an alert that fires twice trains everyone to ignore it, and how acknowledgement changes the arithmetic.
• Recording evidence an inspector will acceptPass, fail and conditional are equal outcomes. As-found and as-left values are the finding. Here is what a defensible evidence record contains.
• Custom fields without building a second productWhen a field belongs on the asset, when it belongs on the obligation, and when it belongs in the evidence record.
• Calendar dates, timezones, and the 31st of MarchWhy an expiry is a calendar date rather than an instant, and what that means for sites in other countries.

Help center

Task-shaped answers for the things people ask while they are already in the product.

• Getting startedFrom an empty organisation to a register that sends its first alert.
• The registerAssets, obligations, maintenance and the evidence that proves it was done.
• Alerts and notificationsWhen alerts fire, who they reach, and how escalation works.
• Accounts, roles and permissionsWho can see what, and how to change it.
• Import, export and reportsCSV mapping, dry runs, undoing a batch, and what an auditor gets.
• IntegrationsThe API, signed webhooks, chat channels and calendar feeds.
• BillingPlans, limits, and what happens when a payment fails.
• Security and troubleshootingHow your data is kept apart, and what to check when something is quiet.

Nothing here covering it? Email us — during the pilot programme that reaches the engineer who wrote the feature, not a ticket queue.

Writing

Longer notes on the parts that turned out to be harder than they looked. No schedule and no newsletter — we publish when something is worth writing down.

• Scheduling notifications exactly once, and proving itA reminder that fires twice trains people to mute the channel. Here is the ledger that makes duplicate alerts structurally impossible rather than unlikely.
• Why the event log has no update or delete grant, for any roleAn audit trail that the application can rewrite is not an audit trail. The guarantee has to come from privileges the running service does not hold.
• Testing tenant isolation on every endpoint, on every pull requestMulti-tenant leaks are not caused by hard problems. They are caused by one handler that forgot a where clause — so the test has to be mechanical.