An encrypted offline record base that synchronises across devices, with every merge rule declared per field
Registry is an encrypted record base for work orders, inspections, stock counts and approvals; it works without a network and synchronises across devices and with your own backend. Each field is declared in a versioned entity model with its own merge rule, such as a state machine for statuses. Where no rule describes a conflict, Registry quarantines the record rather than guessing. Every mutation is audited with its origin device, so a field’s current value can be traced to the competing writes and the rule applied. Self-hosted by default.
A CRDT guarantees that replicas which have seen the same operations end in the same state. It does not guarantee that the state is right. The canonical failure here is a card moved to two different columns by two people who were both offline, merging into a card that is in both columns: technically consistent, operationally nonsense. Every sync engine ships last-write-wins or CRDT convergence, and for a work order, a stock level or an approval step both are wrong.
Everything Harbour Registry reads, and nothing beyond it. Inputs that widen quietly after an evaluation make the evaluation worthless, so this list is part of what you are buying.
| Source | Cadence | What it contributes |
|---|---|---|
| Device mutation queue | continuous when connected | The outbox from each device — every local write, with its client-generated identity, its idempotency key and the causality metadata needed to place it against other edits to the same field. |
| Entity model and merge policy | on change, versioned | Your declaration of what each field is and how it merges. Registry treats this as code: versioned, reviewable, and refused at deploy time if a policy contradicts the field type it is attached to. |
| Backend change feed | continuous | Writes arriving from your system of record — Postgres, MongoDB, MySQL, or an ERP behind an adapter. Server-side edits compete with device edits under the same declared policy, not a separate one. |
| Connectivity and transport events | continuous | Per-device connection state, transport class and measured throughput. Recorded because connectivity in the field is a spectrum rather than a switch, and an incident cannot be replayed without it. |
| Device and identity inventory | on change | Enrolment records from your MDM and identity provider, so that a shared tablet handed to a different technician is a known event rather than an anomaly in the audit trail. |
| Bandwidth budget and cost model | on change | A data allowance per device class, a priority ordering over entity types and a cost per gigabyte. Sync plans are computed against these rather than against a fixed timer. |
Every signal below is computed from the inputs above by a documented formula. Nothing here is a black box: an output nobody can explain is an output that gets overruled the first time it is inconvenient.
| Signal | Scale | How to read it |
|---|---|---|
| Quarantine depth | records | Records held back because no declared policy describes the conflict. Meant to be small and non-zero: zero usually means the policies are too permissive, not that the fleet is healthy. |
| Outbox age | hours … days | Time since the oldest unacknowledged mutation on a device. The most useful single number an operator has, because it separates a device that is offline from a device that is stuck. |
| Maximum data loss window | hours | Time since the last durable flush, per device, against the figure written in your configuration. Exceeding it raises an alert rather than waiting for someone to notice at the end of a capture session. |
| Retention headroom | 0–100% | Local storage remaining before the device reaches its bounded quota. Warnings fire early and loudly; the failure we refuse to ship is running out quietly at hour seven of an eight-hour survey. |
| Schema parity | % of fleet on current version | Distribution of app and schema versions across the fleet, with the oldest version still accepted. Migration is measured as a curve, not declared complete on the day it is deployed. |
| Conflict rate | per 1,000 mutations | Conflicts by field and by policy kind. A field whose rate climbs after a process change is usually telling you the process changed, not that the software broke. |
A CRDT gives you a strong and genuinely useful promise: any two replicas that have seen the same set of operations will agree, whatever order those operations arrived in. That is hard to build and worth having. It is also a promise about agreement, not about being right, and the gap between the two is where this category keeps failing.
The example everyone uses is a Kanban card. Two people, both offline, move the same card to different columns. The merge converges, both replicas agree, and the card is in both columns. No data was lost, nobody saw an error, and the board is nonsense. Substitute the objects your business runs on and the shape is identical: a work order closed in the field and reassigned by dispatch the same afternoon; a stock level decremented twice from two vans; a quantity field where one edit corrected a typo and the other added new material.
Last-write-wins resolves these in favour of whichever device held the later timestamp, which has no relationship to which answer was correct. CRDT convergence resolves them on data structure — a set union or a register merge chosen by a library author years ago for reasons that had nothing to do with your domain. Neither mechanism has been told what the field means, so neither can be right except by accident. And the cost is not mainly the wrong value: it is that synchronisation reported success. A visible failure creates a ticket; a silent incorrectness creates a record that looks settled, and nothing triggers an investigation until somebody reconciles stock against a physical count six weeks later and finds the trail has gone cold.
Registry starts from a different assumption. The merge rule is a property of the field, it is known by people in your business rather than by us, and it belongs written down where it can be reviewed, versioned and read back. Where the rule covers the case, Registry applies it on the server and records why. Where it does not, Registry stops. It does not pick.
A merge policy in Registry attaches to a field, not to the store. There are five kinds, and the constraint that keeps them honest is that each resolves only the cases it can actually reason about.
A state machine policy governs fields whose values are steps rather than data: work-order status, inspection outcome, approval stage. You declare the states and the legal transitions. Two concurrent transitions from the same origin merge only if the machine says one dominates; concurrent moves to unrelated states do not merge at all. This is the policy that prevents the card in two columns, because it is the only one that understands the columns are exclusive.
A monotonic counter governs values that move one way only — an odometer, a meter reading, cumulative running hours. The maximum wins, and a lower value arriving late is recorded as observed without moving the field. An additive quantity governs the case last-write-wins damages most: two vans each consuming four units of stock produce a decrement of eight, not of four. Additive fields carry a floor, and a merge that would breach it is not silently clamped — it goes to quarantine, because a negative stock level is usually two problems rather than one.
Last-writer-with-evidence is last-write-wins with the argument it always needed. The winning write must carry something more defensible than a device clock: a server-observed arrival, a signed capture event, a supervisor attestation. Where the evidence is comparable it resolves; where it is not it escalates. Manual quarantine is then a policy in its own right, chosen deliberately for fields where automation should never act — a price, a dosage, a regulator-facing attestation, a signature. Declaring it is a decision, and the resulting work is expected rather than a symptom.
The most production-complete sync engine on the market answers the conflict question with “you implement it in your server API”. That is flexibility in the way an empty room is spacious. It moves a hard, domain-specific problem into a place with no vocabulary for it, no versioning, no audit trail and no way for anyone but the engineer who wrote it to see what the rule is. We think the rule belongs in a declaration a domain expert can read, a reviewer can challenge and an auditor can be shown.
Sync defects do not reproduce on demand. They reproduce under one particular interleaving of edits and connectivity — this device wrote, then lost signal, then that device wrote, then the first reattached weakly near a main road and got halfway through an upload. Without a record of the interleaving, the only debugging method available is asking a technician what they remember doing on Tuesday.
Registry records the interleaving as first-class data: every mutation with its origin, causality and client-generated identity; every connectivity transition; the schema and policy versions in force at the time. Any window can be replayed deterministically, and replaying it twice gives the same answer — the property that turns “the app lost my inspection” into a test case that fails until somebody fixes it. Replay also runs against a policy version other than the one that was live, so you can ask what last month’s conflicts would have done under the state machine you are considering, and see how many would have quarantined instead.
This capability is sold on support cost, and we would rather say so than dress it up as insight. The market evidence is unusually clear. Buyers on Gartner Peer Insights report Field Service sync issues their own teams could not unblock; Salesforce’s own knowledge base names data-hygiene causes — an orphaned appointment, a missing field-level permission — that a technician in a plant room can neither see nor fix. The problem is not incompetence. It is that the diagnostic surface lives outside the customer’s building, so every incident becomes a queue.
Registry’s replay runs on your infrastructure, against your data, operated by your people. We would like to be involved in your hard bugs. We would not like to be the only route to your ordinary ones.
Ask anyone who has shipped offline-first business software which problem cost them most and the answer is not conflict resolution. It is migrating a schema across thousands of devices on different app versions, with no maintenance window and no ability to force an upgrade. The problem does not exist server-side, it is named repeatedly as the hardest structural issue in offline-first ERP and CRM, and it is worst in exactly the deployments worth having, because those are the ones where the schema is customised per customer.
Registry treats schema and policy versions as data the server reasons about. A device on an older release keeps syncing the fields it understands. Fields introduced after that release are preserved on passthrough rather than dropped, so an old client cannot silently erase a new column by writing a record back. A mutation from a version below the declared floor is refused with a specific error telling the client to upgrade, not a generic failure that leaves it retrying. Migration is watched as a curve across the fleet, and the floor moves when the curve says it can.
Two smaller things matter more than their size suggests. Records created offline carry client-generated identities, so an inspection written on a tablet in a tunnel does not become two inspections when it finally reaches the server. And every mutation is idempotent, because a lost acknowledgment is not exotic — it is the ordinary outcome of a connection dropping at the wrong moment, and it means the same operation will sometimes arrive twice. Teams that discover this after launch have already written duplicate work orders into production.
The error model is typed, and each type maps to exactly one client behaviour. Transient network: retry with backoff. Auth: re-authenticate. Permission: stop, surface to the user, do not retry. Validation: stop, surface, keep the record local. Conflict: hand to policy. Unsupported version: stop and prompt to upgrade. Server failure: retry, escalate if it persists. Collapsing these into one generic failure is how a permission rejection becomes a device that retries forever, burns a data allowance and raises a support incident that looks like a network problem and is not.
Encryption is where fleets and consumer software part company most sharply. The consumer pattern — a recovery phrase, a device keychain, another logged-in device as authenticator — assumes one person who owns their own hardware. It does not survive 400 technicians sharing, losing and replacing tablets, and the documented end of that road is somebody screenshotting a recovery code so that it syncs to cloud storage. Registry’s default is recovery keys held in your MDM, retrievable from a second device with SSO validation and an access event log. You may run end-to-end encryption without escrow instead, and some of you must. We will write down what that costs before you switch it on.
A product whose entire pitch is “works without signal” is selling into a shrinking surface, and you should hear that from us rather than work it out after signing. Starlink Maritime now advertises 400+ Mbps with service-level agreements, and mining performance kits reach comparable throughput at roughly twenty milliseconds of latency. On surface mining sites and on vessels the offline requirement is being removed by satellite rather than solved by software, and at least one maritime connectivity provider argues the distinction between offshore and onshore is disappearing altogether.
What remains is narrower and more stubborn. Satellite does not penetrate tunnels, so underground mining still depends on wired backhaul, fibre relay or wireless mesh extending a surface connection, with store-and-forward behaviour at the edge of it. Aircraft cabins in flight are genuinely disconnected, which is why the clearest commercial peer-to-peer deployments in this market are cabin-crew applications. Secure facilities are disconnected by policy and will stay that way. Capped and pooled data plans make connectivity a budget rather than a switch. And rural field work has not moved at all: in one published government field test across five schools, two sites had no coverage whatsoever and staff synchronised by travelling to signal roughly every ten days, with guaranteed local retention for weeks written into the requirements so that a missed trip cost nobody their records.
Those five cases are what Registry is built for, and they share a property worth naming: the constraint is cost or policy, not the absence of radio. That is why bandwidth is configuration here rather than an implementation detail. Registry takes a data allowance per device class, a priority ordering over entity types and a cost per gigabyte, and plans what to send against them. Signed inspections and safety events go first; photographs and attachments go overnight or on a cheaper transport; low-value telemetry may not go at all.
Integrators in maritime and energy have built this by hand for years — burst on demand over a fast link, bulk transfer overnight over a slow one, hybrid routing that materially cuts satellite consumption in coastal operations, application prioritisation so operations software outranks streaming. The defence tactical-edge platforms have the right model too: decide what is worth backhauling rather than queueing everything and hoping. Neither approach has been commercialised for ordinary business operations, and every sync engine we surveyed still syncs on a timer or on reconnect.
The retention guarantee belongs to the same argument. Bounded local storage, a stated maximum-data-loss window between durable flushes and loud early failure on quota exhaustion are the difference between a ten-day gap being routine and a ten-day gap being a disaster. Those figures sit in Registry’s user-facing documentation, where a field worker can find them, rather than in a project report nobody outside the project reads.
The last section is about who fixes things, because in this category that question decides running cost more surely than the licence does.
Registry exposes per-device state as a first-class surface: outbox depth and the age of the oldest unacknowledged mutation, cursor position and whether it is consistent, schema and app version, retention headroom, time since the last durable flush, and the records currently quarantined. Outbox age is the number to watch, because it separates the two situations that look identical on a dashboard — a device that is offline and behaving correctly, and a device that is connected and stuck.
Three levers sit beside that view. Manual retry, for the transient case. Full resync, which re-hydrates the device from the server. Local rebuild, which discards derived state on the device and reconstructs it. All three are operated by your support desk under your own access controls, and every use is attributed and logged. An agent can call the same operations through the MCP server with the same attribution, which is the point of exposing them there rather than keeping them in a console only we can open.
One measurement discipline underpins the rest. Counting a local save as a server success is the most common instrumentation error in offline software, and it hides failures completely: the dashboard shows a healthy product while records sit stranded on devices in a car park. Registry emits local save, sync success, sync failure, conflict and offline duration as five separate events, and the distance between the first and the second is the figure your operations lead should read weekly.
None of this makes Registry a system of record for your business. It holds what your field devices create and argue about, resolves what it has been told how to resolve, refuses what it has not, and hands the settled result to whatever already owns your ledger, your assets and your customers.
The top tier is not a bigger licence. The five policy kinds, the quarantine, the replay and the per-device state surface are identical in every deployment, and not one of them improves because a contract is larger. What changes is the list of things we are obliged to in writing, and that composition is the whole of the difference. Where an obligation belongs to the Harbour platform or to the portfolio rather than to this product, it says so below, because a shared promise sold twice is a shared promise sold once too often, and a reviewer who catches one is entitled to stop reading the rest.
The obligation that is genuinely Registry’s own is fidelity to the declared semantics. The merge rules are the product: you wrote them, we enforce them, and the top tier attaches money to the difference. If the server applies a mutation that contradicts the declared rule — a floor breached without the declared refusal, a determination made where the rule names none — a credit ladder printed in the contract applies, accrued from our own replay of the incident rather than from your having to notice and file. Every refusal names the rule that produced it, and every quarantined record stays surfaced to a human with that reason attached: a quarantine that silently ages out is a merge we never admitted to, and it is the failure mode this product exists to make impossible. A disputed determination goes to an independent examiner rather than to our own support desk, because a warranty whose trigger the vendor adjudicates is a warranty the vendor has written itself permission to refuse.
The demonstration is the offline acceptance test you witness: a physically disconnected enclave, a protocol agreed with you beforehand, repetition after every major release, and your right to refuse the release if the final state does not come out identical whichever order the sites reconnect in. One concession about the machinery behind that test, made before a reviewer makes it for us: the standing rig it runs on — the matrix of break, duration, operation order and client version — is our regression suite, and we do not bill you for it. It is the thing you would refuse to buy a sync product without, not a deliverable a larger contract purchases.
Two obligations in this tier are not Registry’s, and both are usually sold as if they were. The air-gapped release train is a property of the Harbour platform: Registry, Flow and Watch ship from the same train, and what the posture is worth in the market is published if only in one place — Google’s air-gapped Distributed Cloud lists at USD 300,000 a month — while the tier convention around us says the same thing more quietly, with Ditto selling Self-Managed and BYOC only in its Enterprise tier and PowerSync keeping hardened images and advance access to CVE-patched images there too. Field co-determination belongs to the portfolio: you employ one set of works councils, and per-device state is performance-adjacent data about identifiable technicians, so in Austria §96(1)(3) is a consent no arbitration body can substitute and a council that says no ends the deployment in that country. Neither is charged whole against this product, and a vendor billing either against each product separately is charging you several times for one delivery.
And one admission about the arithmetic this page deliberately refuses. The argument a fleet of this size usually reaches for — the published endpoint rates times the device count — has to stop being made somewhere, and we would rather name the place than have a procurement reviewer find it: below roughly fifty thousand devices the volume comparison carries no weight at all, and the tier stands on the composition of obligations above and nothing else. If your fleet is smaller than that and the obligations still read as worth having, buy them; if they do not, the ordinary self-hosted deployment is the honest purchase.
The unit is one autonomous site — a place, vessel or enclave that has to keep working through a disconnection, counted where it is and not by what is in it. Not devices, not mutations, not connections. A site is the thing whose work continues when the network does not, it is the thing your operations lead already counts when they plan a rollout, and it is the one unit in this category that survives a storm: a metered alternative that bills by the gigabyte makes its largest charge on the day a fortnight of offline work comes home, which is precisely the day the product earned its fee.
Why devices were given up is worth saying in full, because it is our own dead model. Registry used to be quoted per device per month with a small-deployment floor, and the arithmetic behind that quote is the arithmetic that does not survive contact with the market at scale: list prices do not become contract prices. CrowdStrike publishes Falcon Pro at $99.99 and Falcon Enterprise at $184.99 per device per year, and the largest CrowdStrike deal in Vendr’s observed sample is $337,442 a year — roughly fifty-five times smaller than the list rate multiplied by a hundred thousand devices. The comparison is arithmetically correct and commercially false, and no honest vendor should make it at fleet scale, in either direction — including against our own former rate. Devices are not counted, and the published rates above are offered as the reason, not as a comparison we win.
What the unit gives up is visible, and we would rather you saw it. A buyer with two hundred autonomous sites pays two hundred units, however few devices each one carries; a vessel with eight devices and a plant with three hundred are one unit each, and the price is fixed for the term in either case — no true-up as the fleet grows, and no clause preventing the figure falling when the estate shrinks. The metered alternative’s trajectory is a matter of public record: successive GSA Fleet telematics calls ran $12.2 million, $16.7 million, $18.4 million and $25.6 million, and the VA’s ServiceNow spend went from $116.2 million across 2020–2023 to $312.6 million across 2023–2026, a factor of 2.69 in one three-year cycle.
We are not going to publish a number either, and the reason is not coyness. An individual, a fifty-device workshop and a national operator running this across a hundred and eighty sites pay amounts two orders of magnitude apart; a single figure on a web page is a lie at one end of that distribution and an insult at the other. What is published instead is the unit, the list of things that are never metered, and the five properties that qualify a buyer for the obligation tier — which is more than the category next door publishes, and it is the part you can check on your own systems before speaking to anyone here. Below those thresholds the ordinary self-hosted deployment runs the same five policy kinds, quarantines the same records and replays the same windows, and the obligation tier is weight you would be carrying for nothing.
An agent working against field data needs two things ordinary APIs hide: whether the record in front of it is settled or contested, and why a field holds the value it does. Registry answers both, and lets an agent resolve a conflict or force a resync under the same policy and audit trail as a human.
Server
hlebourg-registry
| Tool | Effect | What it does |
|---|---|---|
| registry.get_entity | read | Fetch a record with its per-field merge state — settled, pending or quarantined — so you can tell a confirmed value from a contested one. Do not treat a quarantined field as a value. |
| registry.list_conflicts | read | List open conflicts and quarantined records, filtered by entity type, field, device or policy kind. Call this before reporting that a dataset is complete. |
| registry.get_device_state | read | Sync state for one device or a fleet slice — outbox depth and age, cursor position, schema version, retention headroom, last durable flush. Look here first when data is missing rather than wrong. |
| registry.explain_merge | read | Return the full derivation of a field's current value: the competing writes, their origin devices and causality, the policy that applied and the version of that policy. Answers why, not only what. |
| registry.replay_window | read | Deterministically replay a window of mutations and connectivity events for a device or entity, optionally against a different policy version, and return the resulting states. Read-only; nothing is written. |
| registry.resolve_conflict | write | Settle a quarantined record by choosing one candidate state or supplying a merged value, with a required reason. The resolution is attributed to the calling operator and is itself replayable. |
| registry.set_merge_policy | write | Attach or amend a merge policy on a field, creating a new policy version. Existing records are not retro-merged; the change applies from this version forward. |
| registry.force_resync | act | Trigger a full resync or local rebuild on a named device. It discards local derived state and re-hydrates from the server, so confirm the outbox is empty first or you will ask someone to redo their morning. |
Claims a buyer cannot test are worth nothing. Each of these is verifiable during an evaluation, without our involvement.
This section is written before the rest of the page, not after. If one of these limits is a dealbreaker, better to find out now.
Registry refuses to merge what the declared policy does not describe, and quarantines the record instead of guessing. A badly specified policy therefore produces work rather than silence. We think that is the right trade, but it is a real cost and it lands on your team, not ours.
Registry is not a real-time collaborative text editor and is a poor choice for one. Character-level merging of prose is solved well by Yjs and by Automerge; use those, and let Registry hold the record the document hangs off.
If you run end-to-end encryption without escrow, a lost device's keys are lost. We cannot recover them, your support desk cannot recover them, and there is no support path that changes it. If that is unacceptable, turn escrow on before you deploy — deciding afterwards is deciding too late.
Initial sync of a very large table is a design problem, not a setting. A sync vendor in this market has published its own failure to hydrate a roughly two-million-row summary table inside a two-minute target, and the fix was restructuring the data. We will tell you during evaluation whether your largest table needs restructuring, rather than after go-live.
Registry is not an ERP and does not want to be. No general ledger, no procurement, no payroll, and no roadmap item that adds them. It holds the records your field devices create and argue about, and hands them to the system that already owns the rest.
We cannot take a US federal contract of the size the largest Registry deployments run at, and the sectors listed above are full of them. Hlebourg is a UAE company, the UAE is not a Trade Agreements Act designated country and is not a WTO GPA observer, and the threshold is $174,000 — which a deployment of this shape clears many times over. DFARS 252.204-7012 and CMMC subcontract work is open to us today, and the gate there is the data, not our nationality: CMMC assessment runs on US soil only, and export-controlled CUI reaches us only under its own licences. Primes clear those gates on paper, and we make the paperwork easy. Prime work at this scale is not, and it changes only with a US entity and a documented country of origin. Neither exists yet.