Valeur.Sectors · Offshore Oil & Gas
Offshore has its own engine: two routes, three methods.
All thirty-two sectors carry an engine key. Five have an engine named after them, and four of those five can be reached over an HTTP route. The remaining twenty-seven are labelled with the names of two generic engines — and those two names stand as labels today. Offshore is the first of the four with a route. This page describes the whole of that engine: what it computes, with which threshold, and where its computation stops.
Every threshold below is the default in the code — the engine’s own constant rather than a number rounded for an example. Your numbers set the money side: the engine multiplies the delay days by a day-rate the caller supplies, so every figure on this page has an owner.
- Time entitlement from above-average weather standdown
- Cost of employer-caused vessel standby
Three methods written, two have a route.
The offshore engine carries three methods, and they fall into two kinds. Two are deterministic calculations: they turn the numbers sent to them into a time or a money claim, and the two routes on this page are their counterpart. The third is a reading of the contract that rests on a language model; because its output is of a different kind, it sits in a section of its own below. The record describes the engine in four rows.
- Why this sector is one of the four
- Each of the 32 sectors carries an engine key; 19 of them point to a shared performance engine and 8 to a shared delay engine. Five sectors have an engine named after them — offshore, mining, nuclear, tunnel, hydropower — and four of those five are reached over a route today. Offshore is one of the four, and that reach is what opened this page.
- What both calculations require
- Both are tied to a signed-in session: the company identity travels with every request. A call from a browser also carries the session token; a system connecting with its own key is verified by that key. Each has its own budget of 60 calls a minute — running the weather calculation leaves the vessel calculation’s share intact.
- Who supplies the input
- The caller supplies the whole of the input: the weather data, the historical average, the delay days and the day-rate. The engine counts, subtracts and multiplies. That is a deliberate design — having the caller pick the meteorological source keeps which source was picked visible in the basis of the claim.
- What this page covers
- The two calculations below, the FIDIC clauses they rest on, and the evidence lists the engine itself demands. The sector’s reference record also holds contract types, long-lead equipment and ITP checkpoints, and the last two are read from a separate catalog route. What this page is about is the engine itself, and its scope is drawn by these two calculations.
TODAY: THREE METHODS · TWO ROUTES · TWO DETERMINISTIC CALCULATIONS, ONE CONTRACT CHECK
Weather and vessel: two formulas, two bases.
Both work the same way: a threshold, a subtraction or a multiplication, and the name of the contract clause the result rests on. The difference between them is that one produces time and the other money.
-
01
Metocean extension of time, counted in D3 days
The engine asks one question of every weather record sent to it: was the operating threshold exceeded? If significant wave height passed 2.5 m or wind passed 15 m/s, that day is a D3 day — the vessel is down. The historical average is then subtracted from the count, because FIDIC 8.4(c) covers exceptional adverse weather only. The thresholds can be overridden per record; 2.5 and 15 are only the defaults.
D3 day = hs_m > 2.5 m OR wind_ms > 15 m/s
EOT = max(0, D3_actual − round(D3_historical_average))
entitled = EOT > 0 · basis = Sub-Clause 8.4(c)InputThe caller sends the historical average, and it sets the floor of the calculation. When that average arrives as zero, the allowance for ordinary weather is zero too and every D3 day becomes an entitlement. Choosing the source belongs to the caller — who supplied the meteorological record stays visible in the basis of the claim.
-
02
Vessel delay, behind a single true-or-false gate
The calculation itself is a multiplication: delay days times day-rate. What makes it a calculation is the gate in front of it — was it caused by the employer? Open, and the product is written; shut, and the result is 0.00 with ’contractor’s risk’ in the basis field. The caller sends that determination as a boolean, and the engine returns the same shape whichever way the answer goes.
claim = employer_caused ? round(delay_days × dayrate, 2) : 0.00
basis = Sub-Clause 2.1 (access) / 1.9 (delayed instruction)
otherwise = contractor’s risk · claim 0.00Input“Employer caused” is an input field: the caller supplies its value, and the engine either performs the multiplication or writes zero according to it. So this is less a place where responsibility is settled than one where a settled responsibility is priced. Where that decision came from stays in the basis.
Each calculation also names what will prove it.
Both answers carry an evidence list beside them. The lists are fixed: the items come from a constant array in the code and stay the same on every call. That is also where their value is — the output of a calculation arrives together with the name of the document needed to defend it.
Three items for metocean
Official meteorological data, the marine superintendent’s daily log, and an MWS-approved vessel downtime report. All three are documents expected in the annex of a claim; the engine names each of them beside the calculation.
Four items for vessel delay
The vessel log, the marine superintendent’s report, weather data, and the employer’s written approval. The fourth carries the real weight of the list: it is the only document that corroborates, from outside, the true-or-false gate in front of the calculation.
BOTH LISTS ARE FIXED · THEIR ITEMS ARE WRITTEN IN THE CODE · 7 ITEMS IN TOTAL
Knock-for-knock allocation, as a five-question check.
The third method examines knock-for-knock allocation: the arrangement where each side insures its own people and property — a provision written into the contract separately and known through the LOGIC standard. Running on its own, the method returns the five questions below in place of a guess: whether the provision exists, whether it conforms to the standard, a separate provision for pollution, the clarity of the “Group” definition, and cross-claim risk. The list below is the method’s own checklist.
- Is there a knock-for-knock provision in the contract?
- Does the provision conform to the LOGIC standard?
- Is there a separate provision for pollution?
- Is the definition of “Group” clear?
- In which circumstances does cross-claim risk arise?
FIVE FIXED QUESTIONS · THEIR ORDER IS WRITTEN IN THE CODE · THE WHOLE OF THE KNOCK-FOR-KNOCK CHECK
Frequently asked
Why do only four of the thirty-two sectors have a page like this?
Because the number of sectors whose own named engine a route reaches is four. All thirty-two have something shallower than this page, and that something genuinely runs: the sector-catalogue route returns a risk premium and risk drivers for all thirty-two, a long-lead equipment list for twenty-seven, and inspection checkpoints for two. Beyond that, all thirty-two also carry an engine name and an AI checklist written for their own sector — both of those are labels today rather than measurements: the name is read in one place and placed in a response as a string, and no route reaches the method that uses the checklists. The fifth dedicated engine was written for hydropower and is the largest of the five; the four with a page here were chosen by what a reader can open today rather than by size. That is this site’s rule: an engine gets a page when a route reaches it today.
Which numbers does the claim figure come from?
The money the engine produces is the product of two numbers the caller sends: delay days and day-rate. Both belong to you — one comes from your site record, the other from your contract. So the page shows the multiplication itself and the clause it rests on rather than an amount; your own numbers set the figure. The time side works the same way: the day count comes from your record too.
Does the engine decide for itself that a delay was caused by the employer?
The contract and the facts decide that. On the engine’s side it is an input field — the caller sends it true or false, and the engine either performs the multiplication or writes zero accordingly. Where responsibility sits stays a question for the contract and the parties; the calculation takes that answer as given and prices it. What keeps the calculation auditable is exactly that division.
Why does the third method sit in a section of its own?
Because it does a different kind of work. Metocean and vessel delay are deterministic calculations; the third is a reading of the contract that rests on a language model. If both kinds of output sit under one heading a reader gives them the same trust, and a section of its own keeps the difference visible. Three things are written there: what the method does, which standard it looks at, and the five fixed questions it returns when it runs on its own.
Let us look at your own offshore contract
Every threshold, every formula and every clause reference on this page can be checked at the code level. If you want to see what these two calculations would say on your own project, let us walk through an example together.