The Systems watch

What this watch is

Turning a working instrument into a network.

There is a node aboard the first hull. It runs unattended on a few watts, keeps UTC-disciplined append-only records, and produces bundles that validate offline with no server in the loop. Someone possessing a bundle can check it without contacting us. That property is the whole design and it is not negotiable.

It works on exactly one hull, in one place, tended by the person who built it.

Making it true for fifty — cold, wet, mostly offline, tended by nobody — is the work. And doing it without the record ever degrading into something you have to take our word for.

The reason this matters commercially: a scattered set of assets and a network are the same steel. The difference is entirely whether we know where each one is, how it is being used, and what its history says. This watch is that difference.

What you are inheriting

One node, in service, with a documented calibration traceable to a physical reference and a findings register that is still open.

A data contract that has survived a full unattended endurance run at high capture rate. Ordinary formats on purpose — readable in twenty years, checkable with common tools, portable away from us entirely.

No fleet backend. No cloud. No dashboard. No alerting. Those are deliberate omissions, not a backlog: nothing higher gets built until the layer under it is trustworthy, and the first layer is only trustworthy on one hull so far.

You are also inheriting a decision we have already made and will defend: the record is authoritative locally. Connectivity is a convenience. If that ordering seems backwards to you, this is not your watch.

The numbers you own

Utilization, measured. Right now it is a forecast at an assumed ratio, and it is labeled as such wherever it appears. Turning it into a measurement changes what the company can honestly claim about itself.

Capture rate. What fraction of hull-hours are actually recorded, fleet-wide. A utilization number is only as good as this one.

Mobilization time, measured rather than remembered.

Condition signals that precede a failure — and, just as importantly, an honest count of how often they fire and nothing was wrong.

Build cost and maintenance hours belong to Steel. Price and demand belong elsewhere.

The problems

1. Fifty hulls, intermittent connectivity, much of the operating area with no cellular service at all, and nobody aboard whose job is the instrument. Design the sync. State what happens to the record when a hull is out of contact for six weeks, and what happens when it comes back.

2. Utilization is currently an assumption. What is the minimum sensing that turns it into a measurement — and how do you distinguish working from moored from idle from adrift, using signals a cheap node can actually produce?

3. "A record you do not have to trust us about." Hash-chaining is the easy part. Name the hard part, and tell us where the property actually breaks in practice.

4. One node has been calibrated by hand against a traceable reference, by the person who built it. Describe calibration at fifty nodes when there is no bench, no lab, and no specialist.

5. A sensor stops returning data. The record must be able to distinguish nothing happened from the sensor is dead from the data is bad from the power was out. How do you make that distinction structural rather than something inferred later by whoever is reading?

6. The node draws a few watts. It is dark for much of the winter at this latitude. Solar, battery swap, or something else — and, more interestingly, what measurement would settle it rather than an argument?

7. In two years, a customer disputes what happened during an operation. Walk through exactly what you hand them, and why they should believe it.

Your first ninety days

By day 30 you have pulled a bundle off the hull, validated it offline on your own machine with no help from us, and written down what you do not trust in it. That last document is the one we care about.

By day 60 a second node exists, is installed, and is producing records — and you can tell us the first thing the two nodes disagree about. There will be something.

By day 90 utilization is a measurement rather than a forecast, and you are publishing the Systems report weekly.

Why this might be the wrong job for you

You want to work on models. There is no machine learning here and there will not be for a long time. The whole argument of this company is that you cannot ground intelligence in a physical record that is missing, ambiguous, or unverifiable — so the record comes first, for years.

You want to rewrite it. Something works. Your job is to harden and extend it, and to change it where you can show it is wrong, which is a different discipline from starting over.

You want users to talk to. For a while your users are an operator, a founder, and a hull.

You want scale. Fifty nodes is not scale. The hard part is not the number — it is that they are cold, wet, powered by not very much, and offline.

You need the cloud to be the source of truth. Here it is a copy. That is settled.

One problem before you write

Use whatever tools you use at work. We do.

The arithmetic is not the test. A model will do that part in seconds and we know it. What we are reading is which answer you believe, what you would do next, and what you noticed that nobody told you to look for. That part is still yours.

Here is a record bundle. It is thirty-six kilobytes zipped, a hundred and thirty unpacked: a manifest, four observation streams, a README, and checksums.

It is synthetic — no real operating data, no positions — but structurally it is what we produce.

Validate it offline. Then tell us what you do not trust.

There is at least one thing wrong with it on purpose. There are probably others we did not plan. We are more interested in the second kind.

Half a page, and an hour. We mean an hour.

Download the bundle