You do not distrust the dashboard because it is wrong. You distrust it because you cannot check it.
That is a different complaint, and it has a different fix. A wrong number gets corrected. An unverifiable number gets worked around — and the workaround is the spreadsheet you still keep open beside the system you bought. Nobody decided to run two systems. It happened the first time you had to defend a figure in a meeting and could not say where it came from.
So you rebuilt it by hand. And once a number has been rebuilt by hand, the rebuild is the number you actually trust, and the platform has become a place where data goes.
This is the most expensive failure in this category and it is almost never discussed, because it does not look like a failure. Every screen loads. Every total adds up. The system works exactly as sold and it has still lost the only argument that matters.
(If you want the argument about why your forecast was wrong to begin with, that is a separate piece. This one is about whether you can believe the number in front of you.)
What fiber construction management software offers you, and what it asks for
Look at how platforms in this category present themselves — we read the public pages of the two most credible on 23 September 2026.
Sitetracker leads with “Manage What’s Critical” and positions as asset lifecycle management, aimed at asset owners and operators. Render Networks leads with “Stop compromising. Deploy and operate with complete confidence”, coins the category “System of Execution”, calls itself AI-native, and does something we respect: it ties unit-based tracking to cost, and it names field crews, construction leaders, project managers and finance as distinct users.
Both are serious products. Read the promise in each headline, though. Manage. Confidence. Those are offers of a number, and requests for trust.
On the pages we read, neither company made a traceability claim — neither said, anywhere we could find, that a figure on the dashboard opens the field report it was computed from. That is an observation about marketing pages on one day, not a claim about what their software does internally; we have not used either product and cannot speak to their architecture. But it is telling on its own terms. If a vendor could let a PM click a disputed cost and land on the crew’s own voice note, that would be the first thing on the page. It is too good a demo to leave off.
And the real alternative for most contractors is not either of them. It is WhatsApp and a spreadsheet — free, already adopted, liked by the crews. That alternative has one property the platforms lack: when a number is challenged, you scroll up. The evidence is right there, in order, with the photo attached. Terrible as a system of record; unbeatable as an audit trail.
Any platform worth replacing it has to win on both, not trade one for the other.
Traceability is a property of the data model, not a feature
Here is the claim this whole page rests on, and it is a structural claim rather than a marketing one.
You cannot add traceability later.
A feature can be added later. A drill-down view, an export, an audit log, a “view source” panel — all of those are work you can schedule for the next quarter. Traceability is not one of them, because it is not a way of displaying data. It is a constraint on how data is allowed to be created.
The link between a number and its origin either exists at the moment the number is written, or it does not exist at all. Nothing downstream can recover it. If the ingestion path was listen to the voice note, work out which site it was, type 110 into a field — the person who did the working-out is the only place that link ever lived, and they went home. The UI cannot fetch it. No model can infer it. The provenance was destroyed at write time, and every screen built on top of that row inherits a number whose parentage is gone.
This is why “we’ll add drill-down” is not a roadmap answer. Drill-down into what?
And it is why the honest way to evaluate fttx software is not to look at the dashboards. Dashboards demo well and all of them look the same. Look at what happens on the way in.
Three things that have to be true before a click can work
These are non-negotiable invariants in our own MVP specification, not a feature list. We are stating them so they can be checked, and so you can hold any vendor to the same three.
One — every fact carries the id of the message it came from. Not a timestamp near it. Not a user who entered it. The actual message identifier, on the row. Progress reports carry it, cost entries carry it, blockers carry it. One field, one foreign key, present at insert or the insert is wrong.
Two — corrections are new rows, never edits. Progress and cost records are append-only. A correction is a new record that supersedes the old one and points at it. So is a bid revision: a new version supersedes rather than edits, and a reason is required on every version after the first. This is the part people skip, and skipping it quietly undoes the other two — an edited row is a row whose message id now points at a message that says something else. You can trace it, and the trace lies. Append-only is what keeps “what did we say this would cost in March?” answerable in June.
Three — derived numbers are computed, never stored as truth. Forecast, variance, progress percentage, cost to date: all recomputed from rows, none of them cached as a fact in their own right. A stored total is an assertion that has slipped its evidence. Recomputing is slower and it is the only version that can be audited, because the recomputation is the audit.
Three constraints. Together they mean any figure on any screen decomposes into rows, and every row names a message. That is what makes the click possible, and none of the three is a feature.
The corollary is uncomfortable for us too: these have to hold on the boring rows. A day where nothing happened — 110 m in soil, no costs, no blockers — has to be captured with the same fidelity as the day the crew hit rock. Systems tend to get the dramatic days right.
The click, walked end to end
Everything below is the illustrative pilot scenario from our specification — seed data we build and test against. Harmis has no customers and no pilots yet. There is no contractor in this story and these are not anyone’s invoices. We would rather show you the mechanism honestly than a result dishonestly.
The site is bid at $35,000: 1,150 m of trench at $18.50/m is $21,275, which is 60.8% of the money in one line item.
On day 14, the dashboard says cost to date is at 78% of bid while the work is 61% complete. That is the number that starts the argument, because it is the number that means somebody has to tell the client something.
So click it.
78% of bid decomposes into cost entries. One of them is $5,800 of plant hire, flagged as committed rather than incurred — a breaker attachment at $1,450 a day, four days booked. Click that.
It resolves to a message from the crew lead: “breaker hire booked 4 days 1450 a day.” Sent on day 4. There is the sender, the time, and the site it was attributed to.
Click again and you are in the message log for that site, in order — and just above it sits day 3: “we hit solid rock at the 200 mark, cant get through with the 3t”, with a photo of the rock.
Notice what just happened to the conversation. The question was never really “is the 78% right?” It was “what is going on at this site?” — and the number was only ever the way in. Ninety seconds of clicking and the answer is a photograph of the actual reason, dated eleven days before the invoice would have carried it.
Now the same walk on the other number, which matters more than it looks: the 61% progress is value-weighted, computed as quantity done times unit price over the bid total, not as a count of finished tasks. Half the trench dug on this site is 30.4% of the bid, not 50% — because trenching is 60.8% of the money and half of 60.8 is 30.4. You can check that on an envelope, which is the point. A progress figure that counts tasks agrees with the crew and is wrong, and it is wrong in the direction that feels good until the last task turns out to hold most of the money.
Both ends of the range work the same way. In our spec’s favourable case, a crew finds 480 m of usable existing duct along a fence line on day 2, the bid drops from $38,500 to $19,800 and the site lands at $17,400 — traced to the message “we can pull straight through.” Good news has to arrive as loudly as bad, or the PM learns that opening the dashboard means being told off, and stops.
What traceability does not fix
A page that only made claims would not be worth citing. These limits are in our own spec as open questions, and they are the ones we would want asked of us.
It does not make the parse correct. A message understood wrongly produces a wrong row that traces perfectly to its source. What traceability buys is that the error is findable — you open the message, see the mismatch, and correct it as a new row. It converts silent wrongness into visible wrongness, which is a real gain and not the same as accuracy.
It does not make the forecast right. Ours extrapolates the unit rate actually being achieved across the work remaining, measured over a rolling fourteen calendar days and clamped between half and three times the bid rate. On a small site early on, that is crude: one rock day on a thin measurement window forecasts a number nobody would sign, and the clamp bounds the ratio without making that number sane. We would rather say so than imply a clamp makes one bad day safe. A traceable forecast is still a forecast.
It does not prove the crew was right. It proves what they said, when, and with what photo attached. That is evidence, not truth. It is also considerably more than a retyped cell.
It cannot trace a cost nobody reported. Our data model requires a site on every cost entry, because an unattributed cost is the exact failure we are trying to kill — but a receipt that stays in someone’s van is not in the system at all, and no invariant reaches it. Traceability is a property of captured data. Capture is the harder half.
And it does not make the number obvious. A PM still has to look. What changes is that looking takes one click instead of an afternoon in a thread — which is the whole argument, because a check that takes an afternoon does not get done on the day it would have mattered.
Five questions to ask any FTTH management software vendor
Use these on us too. They are answerable in a demo, none of them can be satisfied by a roadmap, and each has a wrong answer that sounds fine.
- “Click that number. Where does it come from?” Watch whether you land on evidence or on another aggregate. Drilling from a total to a subtotal is not traceability; it is division. Wrong answer that sounds fine: “you can export the underlying data.”
- “Show me a message the system failed to understand.” If there is no such screen, either the system discards what it cannot parse, or nobody has looked. A parse failure the worker never hears about is worse than no system, because they believe they reported it. Ours stores it, flags it for review, tells the worker a person will look — and if it is still unhandled after four business hours, raises it.
- “Someone typed a number in wrong three weeks ago. Walk me through fixing it.” Listen for whether the original survives. If the answer is “you edit the field”, the audit trail has a hole exactly where the dispute will be.
- “How stale is this screen right now, per crew?” Freshness is a number the system should show you unprompted. If you cannot tell which crews reported yesterday, you cannot tell whether the dashboard is a picture of the job or a picture of the reporting.
- “What does the crew have to install, and what do they have to learn?” Every validation rule at the point of entry is a message you do not receive. A crew lead with gloves on in the rain sends one message; a system that needs them to open an app, log in and complete a form will get the dramatic days and lose the ordinary ones.
If you only ask one, ask the first.
What this is not, so nobody wastes a call
People searching for ftth planning software are often looking for two quite different products, so plainly: Harmis does not do network design. No route design, no GIS or map view, no KML import, no as-built drawing generation — all four are named as out of scope in our own specification. If you need to design the network, we are the wrong page, and we would rather say so here than in week three of an evaluation.
What we do is narrow and we would rather be judged on it: ask crews for what they did, what it cost and what is blocking them, on the channel they already use; turn the answers into rows on bid lines; and make every number open the message it came from.
One thing to take away
Every platform in this category asks you to trust a number. The question is not whether the number is good. It is whether there is anything underneath it when you push.
A claim you cannot check is a claim you will re-check in Excel — and then you have two systems and no truth.
Ask for the click.
Frequently asked
Is this just an audit log?
No, and the difference is the direction. An audit log records what the system did — who changed which field when. This records what the field said, and binds every stored fact to it. An audit log tells you a number was edited by a person on Tuesday. Traceability tells you the number came from Ray, from the trench, with a photo, on day 4.
Does this require crews to use an app?
No. If it did, it would not work, and the traceability would be the first thing to go — because a system that needs a form completed gets the dramatic days and loses the ordinary ones. Crews send a message: text, voice note, or photo, in the app they already have open.
What about a message from a number you do not recognise?
It is stored as an unknown sender and never creates a report. Storing it matters — it is how a new subcontractor’s crew lead messaging in for the first time becomes a thing you can see rather than a thing that vanished.
Who can report a cost?
Only workers flagged for it — crew leads and supervisors. If anyone else sends a cost, the message is stored, no cost entry is created, and the crew lead is asked to confirm it. The message survives either way; that is the invariant doing its job.
Do you have customer results?
No. Harmis is pre-pilot: no customers, no published results, no case studies, and nothing from the field to show you. Every number on this page is from the illustrative pilot scenario in our own specification, labelled as such. When we have a pilot’s numbers they will be that pilot’s numbers and we will say whose.
Sources. Product facts are from the Harmis MVP specification (invariants 1 and 2, §2, §4.4, §5). The pilot scenario is illustrative seed data from that specification, not a customer deployment. Competitor positioning was read from sitetracker.com and rendernetworks.com on 23 September 2026 and describes those pages on that date.