Nothing you write down gets quietly lost.
A logbook is only worth what it can proveA vessel record is read, eventually, by somebody who was not there. A surveyor. An insurer after a claim. A buyer's broker. The captain who takes over when you don't. It is worth exactly as much as its weakest entry — and most boat records have a lot of weak entries.
The question behind every record
Two boats, same year, same hours, both with a folder of maintenance receipts. One of them can show you the temperature note from March, the issue it was promoted to in April, the work order that closed it in May, who signed it off, and the sea trial that verified it held. The other has an invoice that says "service."
Those two boats are not worth the same money and they do not present the same at renewal. The difference is not how well they were maintained. It is how well the maintenance was recorded.
Anyone can write "fixed." A record is what you have when somebody asks how you know.
Closed with a reason, not a checkbox
"Fixed" is not one thing, and treating it as one thing is how records lose their meaning. A fault found, repaired, and proven on a sea trial is a fundamentally different record from one worked around while the part is on back-order — and from one that simply stopped happening and was never reproduced.
So closing a record in theONE asks which. There are eight typed outcomes, and each one says something specific and true:
| Outcome | What it actually claims |
|---|---|
| Fixed — verified | Root cause addressed, and the fix was proven afterwards. Records who verified it and when. |
| Fixed — not re-tested | Addressed, believed good, not yet proven under way. Honest, and common. |
| Worked around | Mitigated. The cause is still there. Needs a note saying what the workaround is. |
| Not reproducible | It stopped. Nobody knows why. Recorded as exactly that rather than as a fix. |
| Deferred | A decision to wait, with the reason attached. |
| Vendor declined | The yard would not or could not take it on. |
| Design-inherent | It is how the boat is built. Not a fault to be chased again next season. |
| Captain accepted | A conscious decision to live with it. |
Read the two lines the app puts under that picker, because they are the whole design argument in the app's own voice. Under the kinds: “The kind you pick is saved with this record. When a later one matches it, Foresight can show how this one was resolved.” And at the bottom, an escape hatch that tells you its own price: Just mark resolved — no details, “Closes the incident without recording how it was resolved.”
The lazy option is there, and the app tells you exactly what it costs. That is the difference between a system that nags and one that explains.
A verified fix carries the name of whoever verified it and the moment they did. Not the name of whoever changed the status — those are different people more often than you would think, and a record that confuses them is a record that will not hold up when somebody reads it carefully.
Corrected, never erased
People close the wrong record. A tap lands on the row above. Something judged fixed comes back in August. A record system that cannot absorb those without damage is a record system people quietly stop trusting.
- Archive rather than delete. A vendor, an issue, a work order or a stored credential can be archived — off the working list, history and photos and links intact — instead of destroyed. Deleting still exists, deliberately, as the second choice rather than the only one on offer. An observation archives the same way, and restores from the menu, then Archive. An incident never hard-deletes at all — it closes, and a closed incident can be re-opened and corrected, which is the part that matters for it.
- Re-opening keeps the close. Re-open an incident or an observation and it goes back on the list — with the original close still in its timeline, word for word, including the note and who wrote it. The current state changes; what happened does not.
- Incidents are append-only. The core of an incident — what happened, when, where, who was aboard — is frozen after a short edit window. Everything after that is an addendum: added, attributed, timestamped, never overwriting what came before.
- The things that matter leave a ledger entry. Permission changes, incidents, and record status changes each write who changed what and when. Not visible clutter, but there when a question needs an answer. It is not a keystroke-level audit of everything and we would rather say so than imply one.
Incidents: the record you want to already have
The soft grounding leaving the channel. Contact with a piling at the fuel dock. A crew member's slip on a wet swim platform. These are the records nobody wants to write and everybody eventually needs, and they are the ones most likely to be reconstructed from memory weeks later — which is precisely when they are worth least.
theONE records an incident with the position it happened at, the crew who were aboard frozen at that moment, the external parties involved — insurer, yard, tow service, USCG — and the evidence: photographs taken at the scene, attached to the record rather than lost in a camera roll. Then it closes with one of the eight outcomes above.
And look at what it says where it has nothing. No crew snapshot was captured. No insurer, yard, tow service or authority recorded yet. No photos, jots or documents on this incident yet. Three admissions on one screen, each naming exactly what is missing.
A record that tells you what it does not contain is worth more than one that leaves you to assume.
Because the alternative — a blank space, or a section that simply is not drawn — reads as “nothing happened” rather than “nobody wrote it down”, and eighteen months later nobody can tell the difference.
The conversation lives with the record
Most of what is actually known about a job or an incident never reaches the record. It is in a text thread with the yard, an email to the insurer, and something somebody said on the dock. Eighteen months later the record says impeller replaced and the reasoning is gone.
So vendors, issues and incidents each carry a Comm Log — a thread of posts attached to that one thing, each with its author and its date. Not a chat app bolted on; a place for the sentence that explains why, sitting on the record it explains, where the next person to open that record on that phone will actually find it.
The Comm Log lives on the records themselves. Separately, the Insurance Export carries a maintenance activity log — who did what, and when — generated from the actions taken rather than from what anyone wrote about them.
Six exports, each for a specific reader
| Export | Written for |
|---|---|
| Vessel Briefing | Surveyors and relief captains — a read-only snapshot of the boat's state. |
| Departure Brief | Per-leg: tide at ETA, crew aboard, what is still open. |
| Trip Summary | The whole cruise, ready when the lines are made fast. |
| Deck Logbook | Chronological log with watch intervals. |
| Insurance Export | Maintenance posture, recent service, vendor sign-offs. |
| Owner Week Digest | One page for the owner who isn't aboard. |
One tap each. The reason there are several rather than one configurable report is that a surveyor and an absent owner want almost nothing in common, and a document written for both serves neither.
What the boat cost, over any span you choose
The six above are written for a reader. This one is written for a question — what did she cost me last quarter — and the answer changes with the dates, so you pick them.
Seven ranges sit across the top: a week, a month, a quarter, six months, the year to date, a year, or two dates off the calendar. Tap one and the totals redraw underneath — what was recorded, how many bills, the daily average, then the same money broken out by category and by month. The figures on screen are the figures that print; the report and the PDF read the same numbers, so they cannot drift apart.
Then it exports as a PDF: summary, category, month, payees, and every line item with the amounts aligned on a monospaced column, because a document whose job is being checked has to be checkable.
Two decisions worth knowing about
Fuel is an expense, so it is in the total — and counted once. A fill you logged in the Fuel Log is money that left the account, and it belongs in what the boat cost you. So priced fills ride in the total, in the category breakdown and in the payee list like any other bill. If you also filed the dock's invoice for that same fill, theONE treats the two as one purchase — same day, same fuel, within a hair on the amount — and keeps the invoice, because that is the figure the bank saw and it carries the payee you typed. Two fills on a day you invoiced once still contribute the second: the matching is deliberately narrow, because guessing wider would quietly delete money you spent. A fill logged without a price shows as nothing at all — not as zero, because a fill without a price is not a fill that cost nothing.
An empty range says so, in words. Ask for a month with no bills in it and theONE answers “No bills recorded in this range” and then, underneath, “that means nothing was entered for these dates — not that nothing was spent.” It would be easy to print $0.00 there and it would look more finished. It would also be a claim the app is in no position to make.
These are your own entries, totalled. theONE does not connect to a bank or a card, and the report is not reconciled against a statement — it says so on the export itself.
In the Help Center
Honest about the edges
These are not insurance-approved documents. The exports are formatted for use with insurance and survey — they are the record, presented clearly. No underwriter has blessed the format, and theONE does not represent otherwise.
A record is only as honest as the person closing it. Eight outcomes make it easy to be precise; nothing makes it impossible to close everything as "fixed — verified." If you do that, you will have a tidy log that means nothing, and Foresight will hand it back to you on the next match.
theONE's safety features supplement, never replace, proper seamanship and USCG requirements. Recording an incident well is not the same as reporting it where reporting is required.
Why we built it this way
Because a boat's record is an asset, and almost nobody treats it like one until the moment they need it — at which point it is too late to have kept it properly. The whole design here is aimed at one thing: that when somebody who was not there finally reads it, it holds.