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 repay 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. Risk transfer, in the most literal sense.

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 repay the entire capture spend with change - 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 repaid. 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 1.8 times the capture spend and 3.4 times the whole DSU premium. Five days is not a large number compared to thirty. The cover it represents is a large number against everything else on the page.

Handle the premium multiple carefully, though, because it moves inversely with the rate. At 0.4% the premium is US$80,000 and the multiple is 3.4×. At 1% the premium would be US$200,000 and the same five days would be 1.4× it. The multiple says as much about the rate as it does about the capture, which is why the offset above is the number worth keeping.

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. A narrower time deductible would also ordinarily be priced for, and whether it is granted in recognition of the instrumentation or simply charged for is, again, 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 repay 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, the evidence is private to the parties involved, and nobody - us least of all - has a body of it to point at. 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 adjustment should be quicker and less contested. A delay claim is an argument about sequence - what happened, when, and what followed from it. That argument is shorter when the sequence is observable.

The second matters more, and it is specific to DSU. If a developing delay is visible while it is still developing, there is a chance to work against it. A loss that is understood earlier may simply be a smaller loss. We cannot prove that, and we are not going to claim it as a result. 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.