What a day is worth.

On Tuesday we published Reality Capture Value, a calculator that shows what the reality capture running on a project is worth against its delay in start-up cover. Today, we work through one example project.

One thing before the numbers. Every input figure below is invented. Your figures will be different, and the calculator exists so you can use your own. It runs in dollars, pounds or euros.

The example project

A commercial development, insured for delay in start-up, with these details agreed at binding:

• DSU sum insured: US$20,000,000
• Indemnity period: 12 months
• Waiting period: 30 days
• DSU rate: 0.4%, giving a premium of US$80,000
• Reality capture running on site, costing US$150,000 across the build

Six figures. Five of them can be pulled straight off the policy schedule; the sixth is what is already being spent on site for cameras, walk-throughs and sensors. Nothing needs estimating - that is the property that makes the whole exercise possible.

One assumption to state plainly, because the arithmetic depends on it. This invented project has the same party carrying the DSU cover and the cost of the capture. Where those sit with different parties - the employer insuring the delay, the contractor buying the technology - the offset still exists but has to be worked through between them, and this article does not attempt that.

Worth knowing before we start which figures actually drive the result. The offset depends on two of them only: the capture spend and the sum insured. The rate and the premium play no part in it. They appear later purely as a comparison, and it is worth keeping the two things separate.

Step one: what a day is worth

The sum insured covers the indemnity period, so the daily value is the sum insured divided by the length of that period. Here the indemnity period is twelve months:

US$20,000,000 ÷ 365.25 days of indemnity = US$54,757 a day.

That is the daily value of the delay exposure this policy describes. Not a forecast of anything - the policy's own figures, divided. Note that the divisor is the indemnity period, not a calendar year: on an eighteen-month indemnity period the same sum insured spreads across half as much again, and a day is worth proportionately less.

On the divisor itself: the calculator uses 365.25 days to the year, averaging in leap years. Divide by 365 instead and you get US$54,795. The difference changes nothing material, but it will stop your arithmetic matching the tool's, so it is worth knowing which one you are using.

Step two: what the cover costs

The premium is the rate applied to the sum insured: 0.4% of US$20,000,000 is US$80,000.

Worth pausing on the relationship between the last two numbers. US$80,000 buys cover on an exposure running at US$54,757 a day. The whole premium is worth about a day and a half of the thing it covers. Days are large units on a project this size, and that is the fact the rest of this rests on.

Step three: the offset

Now the question the calculator actually answers: how many days off the waiting period would offset the entire capture spend?

The waiting period is the part of any delay the insured carries themselves before the policy responds - a time deductible. Each day inside it is a day of exposure sitting on the insured's own balance sheet. So a day off the waiting period moves US$54,757 of exposure - at the policy's own average daily value - off that balance sheet and onto the policy.

The capture spend was US$150,000. So:

US$150,000 ÷ US$54,757 a day = 2.74 days.

That is the offset. The calculator reports in whole days and shows three, since fractions of a day are not something anyone negotiates. On these invented figures, three days off the waiting period would offset the entire capture spend with room to spare - not in cash, in cover.

Against a 30-day waiting period, 2.74 days is under a tenth of it. That is the arithmetic doing what adjectives cannot: the scale of the exposure makes the cost of observing it look small, and nothing in that conclusion depends on the rate or the premium.

Step four: past the threshold

The threshold is where the spend is offset. Everything past it is gained, and the calculator lets you move the waiting period to see how much.

Move it by five days - from 30 to 25 - and five days of exposure transfer at US$54,757 each:

5 × US$54,757 = US$273,785 of cover.

That is more exposure transferred than the capture cost, and more than the whole DSU premium. Both comparisons move with the rate, which is why the offset above is the number worth keeping; the multiples are context, not the result. Five days is not a large number compared to thirty. The cover it represents is a large number against everything else on the page.

What this number is not

It is not a prediction. Nothing above estimates how many days a continuous account of the site would actually save - that remains an open question, and it is not ours to answer with a number. The calculator never asks for it, because a days-saved assumption is an argument dressed up as a number, and we would rather show you a threshold than sell you a forecast.

It is not a promise, either. Whether the waiting period moves, and by how far, is an underwriter's decision, on their risk. What the arithmetic shows is only what such a recognition would be worth - on figures the reader supplies, checkable by anyone who can divide.

It is not expected value, either, and this is the disclaimer that matters most. The capture spend is certain; the cover is contingent. That US$273,785 pays only if a delay occurs, is covered, and runs past the reduced waiting period. What the arithmetic compares is a cost against an amount of exposure transferred - not against money anyone expects to receive. Whether a narrower time deductible is granted, priced for, or not offered at all is an underwriter's decision on their risk, and not our call.

And it is not universal. DSU is not on every project, and the offset moves with the figures. Halve the sum insured to US$10M and a day is worth US$27,379, so the same capture spend needs 5.5 days to offset rather than 2.74 - six days as the tool reports it, against three. Run your own numbers and see where the threshold lands. That is what the tool is for.

The part we cannot put a number on

Everything above is arithmetic, which is why we are willing to publish it. There is a second question sitting behind it, and we cannot answer that one at all.

What is a day worth to the parties working through a difficult DSU claim who have a granular account of how the project actually performed?

We have no data to settle it. A claim of that kind is rare and the evidence is private to the parties involved. We have not found a published body of it, and we have looked; if one exists we would like to see it. So we will not put a figure on it, and anyone who does should be asked where the figure came from.

What we have instead is reasoning, offered as reasoning. Two things follow from having a continuous, time-stamped account of a project rather than a reconstruction of one.

The first is that the sequence is on the record. A delay claim is an argument about sequence - what happened, when, and what followed from it. Where that sequence was observed and time-stamped as it occurred, it does not have to be reconstructed. What that is worth to the parties is theirs to judge, not ours.

The second matters more, and it is specific to DSU. If a change on site is visible while it is developing, the people responsible see it sooner. What follows from that is theirs, and we have no data on it. But it is the direction the logic runs.

What makes it unusual is that both parties want the same thing. A smaller loss means the insured is operating sooner, and it means the insurer pays less. There is no side of that trade which prefers the delay to run longer.

Priceless is a word to be careful with, so take it literally rather than loosely. We cannot put a price on this, and we are not going to pretend a calculator does. Our view is that this is the part that matters most when it finally matters, and it is the part the arithmetic will never reach. That is a view, not a finding. The arithmetic above is the part we can prove, and it stands on its own - which is precisely why we have kept the two apart.

The one-sentence version

On a project where a day of delay exposure runs to five figures, the reality capture already running on the site costs less than three days of it. Everything else in the argument is detail.

Pikt gives risk engineers continuous visibility of the projects they oversee, by connecting to the technology already running on site. The full argument is in A start-up owes you a number; the arithmetic, on your figures, is at Reality Capture Value.