# Estimating Modernisation Cost, Duration and Confidence From Application Evidence > A proposed evidence-linked model for assessing whether a modernisation plan can meet its budget, deadline and acceptance criteria, grounded in Harten's public PRSD-IWS analysis and one-week analysis objective. Paper: Technical paper — 06 Published: 2026-10-16 Canonical: https://harten.io/papers/estimating-modernisation-cost-duration-and-confidence/ Cover illustration: [View the title image](https://harten.io/media/papers/covers/v1/estimating-modernisation-cost-duration-and-confidence.png?v=b4c4f24b9369). Illustrative cover artwork, not an application screenshot or a record of measured results. **Lavan Nallainathan | Harten Technical Papers** **16 October 2026** *Expanded on 16 October 2026 to explain the equations through a continuing shipment-service example, worked calculations and a reproducible spreadsheet layout. A further revision on the same date brings the calculation before the notation, explains the mathematical foundations, links a finding to a programme estimate and corrects spreadsheet input handling. The original publication date, evidence boundaries and proposed status of the confidence model are unchanged.* [Download the worked-example spreadsheet (.xlsx, 22 KB)](https://harten.io/assets/papers/modernisation-confidence/modernisation-confidence-worked-examples.xlsx) *An editable companion with illustrative scenarios, revised-evidence calculations, work-package estimates and forecast checks. These are teaching examples, not Wayfinder delivery forecasts.* ## Abstract A modernisation proposal needs to explain what the organisation intends to achieve, how much the work is likely to cost, how long it is likely to take and what supports confidence in those estimates. Application analysis can improve that assessment, but the amount of code processed is not a measure of delivery confidence. Nor does a complete repository necessarily describe the complete service. This paper proposes an evidence-linked approach to modernisation assessment. It separates observations about the existing applications, decisions about required future behaviour, assumptions about delivery and probabilities assigned to possible outcomes. It defines delivery confidence as the conditional probability of achieving agreed acceptance criteria within specified cost and time limits, and explains how a scenario model can calculate that quantity without treating unrelated scores as probabilities. Harten's published PRSD-IWS analysis provides a concrete example of the documentation, recovered specification and proposed modernisation plan that can inform such an assessment. The wider engineering objective is to analyse any codebase and return useful, evidence-backed information within one week. The probabilistic model presented here is a proposed method, not a claim that Wayfinder already produces calibrated forecasts of programme success. ## 1. The Questions Behind a Modernisation Commitment The questions people ask about modernisation are usually direct. How long will it take? How much will it cost? What do we know about the applications now? What have we not established? How confident should we be that the proposed work can be delivered? Those questions are the starting point for this paper. The mathematics should help answer them, rather than require the reader to translate their problem into unfamiliar notation before they can begin. The first two questions concern the delivery estimate. The next two concern the basis of that estimate. The last asks what we can reasonably conclude from both. I would keep all five visible in the assessment, but I would not treat them as five interchangeable numerical coefficients. A budget has a unit, an unresolved business rule has a consequence, and a probability describes a specified outcome. Combining them requires explaining the relationships between them. We will follow a hypothetical replacement of a shipment-administration service, informed by the kinds of findings visible in Harten's public PRSD-IWS analysis. The public material provides the application context; the budgets, delivery times, scenario probabilities and forecast results below are invented teaching examples. None is a forecast for DEFRA or a measured Wayfinder delivery outcome. [7] Consider a programme proposing to replace an established service. The organisation has a target budget and a desired completion date. Engineers can describe the replacement technology, and a delivery plan identifies the main components to build. Before those numbers become commitments, however, somebody needs to ask what the estimates assume about the service being replaced. Does the plan include the reporting processes that read directly from its database? Has it accounted for historical records that do not satisfy today's validation rules? Does the replacement need to reproduce a document format because another organisation depends on it? Who can decide whether an unusual behaviour should be preserved, corrected or removed? These questions connect application understanding to cost and duration. An unanswered question may require additional investigation, add implementation work, change the migration approach or prevent acceptance. Equally, investigation may establish that a costly compatibility requirement is no longer necessary. Understanding can change the amount of work in either direction. In *Legacy systems are expensive because knowledge has decayed*, I explored the cost of reconstructing how an application works before changing it. In *Architecture should be a consequence of evidence*, I considered how those findings affect the replacement's design. This paper develops the next connection: how the findings should affect the delivery assessment itself. [1, 2] The purpose is not to wait until everything is known. It is to make the best assessment supported by the evidence available, show what remains unresolved and explain which additional findings could materially change the decision. ### A First Calculation Before the Notation Suppose the shipment-service replacement has a budget limit of £1.2 million and a ten-month deadline. Success also requires the agreed shipment behaviour, permissions, historical records and operational handover. We begin with four possible complete outcomes, not four independent risks. Their probabilities are invented teaching assumptions; the later sections explain what would be needed to support real inputs. | Illustrative scenario | Probability | Cost | Duration | Acceptance achieved | Meets all three conditions | |---|---:|---:|---:|:---:|:---:| | Work proceeds within the initial scope | 0.55 | £0.8m | 7 months | Yes | Yes | | Additional integration work is required | 0.25 | £1.1m | 9 months | Yes | Yes | | Substantial historical-data reconciliation is required | 0.15 | £1.5m | 12 months | Yes | No | | The implementation fails an essential acceptance condition | 0.05 | £0.9m | 8 months | No | No | ![Four illustrative cost and duration outcomes. S1 and S2 meet all three conditions. S3 exceeds both limits; S4 is within the limits but fails the requirements.](/assets/papers/modernisation-confidence/scenario-summary.png) *Figure 1. The four illustrative outcomes against the £1.2 million budget and ten-month deadline. Shading shows only the cost-and-time window. S4 is inside it but fails the requirements, so only S1 and S2 count towards the 80% result.* [Open the scenario chart at full size](https://harten.io/assets/papers/modernisation-confidence/scenario-summary.png) The first two outcomes meet all three conditions. Their probabilities are 55% and 25%, so the assessed chance of meeting the whole commitment is **55% + 25% = 80%**. The costly, late outcome does not count towards that total. Neither does the cheap, quick outcome that fails an essential requirement. Counting two successful rows out of four would give 50%, but would wrongly treat the rows as equally likely. This is the calculation the notation will formalise. It does not tell us that we understand 80% of the application. It tells us what follows from this particular set of assumed outcomes and probabilities. Section 6 returns to each outcome and then changes the evidence and the commitment separately. ## 2. A Definition of Delivery Confidence Cost and duration should retain their ordinary units. A programme costs money and takes time; neither becomes a probability simply because it is normalised to a value between zero and one. A weighted score combining affordability, speed and confidence can express preferences, but it cannot automatically express the probability of successful delivery. For our shipment-service example, suppose the proposed commitment is **£1.2 million within 10 months**, with agreed acceptance criteria covering the required shipment behaviour, permissions, historical data and operational handover. These are separate conditions. Finishing for £900,000 in eight months would not fulfil the commitment if the replacement allowed a shipment that should have been refused. In everyday language, the question is: **what is the chance that this plan meets the budget, the deadline and the required result together?** The equation below records exactly that question. It does not calculate the probability from the codebase by itself. Let \(\pi\) denote a particular delivery plan, including its scope, target design, staffing assumptions, migration approach and acceptance criteria. Let \(C_\pi\) be its eventual cost and \(T_\pi\) its elapsed duration. Define \(Y_\pi=1\) when the agreed acceptance criteria are achieved and zero otherwise. For a budget limit \(B\) and duration limit \(D\), define: \[ q_\pi(B,D\mid E,A,M) = P\left(C_\pi\leq B,\ T_\pi\leq D,\ Y_\pi=1\mid E,A,M\right). \] Here, \(E\) is the available evidence, \(A\) the explicit assumptions and \(M\) the model used to turn them into an assessment. Including \(M\) matters: two competent teams can examine the same evidence and reach different forecasts because their delivery assumptions and estimation models differ. The question is therefore specific: given this evidence, these assumptions and this model, how likely is this plan to deliver the agreed outcome within the available money and time? Read the equation from left to right as: delivery confidence equals the probability of meeting all three conditions, given our evidence, assumptions and model. The vertical bar means **given**, not divided by. The less-than-or-equal sign means that finishing exactly on the budget or deadline still counts. The commas between the conditions mean **and**: all must hold in the same outcome. The letters are labels, not extra complexity. B is the budget limit and D the duration limit. C and T are the eventual cost and time, which are not yet known. Y is a yes-or-no acceptance result, represented by 1 or 0. The Greek letter pi identifies the plan; it does not mean the constant 3.14159 here. A subscript pi means "for this plan", not multiplication. q is the resulting probability, so 0.80 means 80% under the model. For this example, E could contain source-derived findings about shipment validation and financial-guarantee checks. A might include the assumed team capacity and availability of the service owner. M is the procedure that turns the work, dependencies and uncertain events into possible costs, durations and acceptance outcomes. A different migration approach is a different plan, even when it starts from the same source code. NASA's joint confidence level provides an established precedent for assessing cost and schedule together. Its integrated cost and schedule risk analysis combines uncertainty in activity durations and costs with discrete risks. The formulation here additionally makes the acceptance outcome explicit. The probability machinery is established; this paper's focus is its connection to evidence recovered from software estates. [3] The acceptance definition must include the conditions that matter to the organisation. Depending on the programme, these may include required behaviour, security controls, reconciled data, operational ownership and a recoverable production transition. Passing a build or completing the planned development tasks is not sufficient when the agreed outcome includes those additional conditions. Longer-term benefits require their own evaluation horizon; meeting delivery commitments does not automatically establish that every expected business benefit was realised. Cost boundaries also need to be fixed. A forecast covering development alone cannot be compared directly with one including migration, parallel operation, assurance and retirement. Duration needs a defined start, finish and calendar. Those definitions should accompany every comparison. ### The Established Mathematics Used Here The starting point is the delivery question, not a formula selected because it looks authoritative. We first define the event that matters: the same delivery outcome must meet the money, time and acceptance conditions. In probability theory this is a joint event. We then make the evidence, assumptions and model explicit because the assessment depends on them. NASA's joint cost and schedule confidence level is a relevant project-estimation precedent, not a source for a uniquely Harten equation. [3] The remaining mathematical steps have different jobs. Adding the probabilities of non-overlapping successful outcomes uses the standard addition rule for mutually exclusive events. Writing the same addition as a dot product is algebraic notation, not another forecasting technique. The pass/fail indicator translates the agreed conditions into a 1 or 0. Later, the Brier score measures forecast error rather than delivery confidence. [14, 15] | Practical question | Mathematical operation | What supplies the inputs | |---|---|---| | Does this possible outcome meet the commitment? | Check the cost, duration and acceptance conditions together. | Agreed limits, requirements and a specified outcome. | | How much probability belongs to successful outcomes? | Add their probabilities; equivalently multiply probabilities by 1-or-0 indicators and add. | A supported scenario model, not a code-coverage percentage. | | What work, cost and time does a finding imply? | Calculate effort-based costs and schedule dependencies. | Reviewed findings, delivery records and explicit estimating assumptions. | | Did our past probability forecasts perform well? | Compare each recorded probability with its later outcome using a scoring rule. | Preserved forecasts and comparable, completed delivery outcomes. | The contribution proposed here is the reviewable connection from application findings to delivery assumptions and decisions. The probability rules are established mathematics. Whether this approach produces useful or well-calibrated forecasts remains a question to test, not a result established by writing the equations correctly. ## 3. What We Know and What We Still Need to Establish The amount of material examined is useful operational information. It tells us something about analysis progress and the scope of the input. It does not tell us, by itself, how much of the service has been understood. An application might contain thousands of straightforward presentation functions and one difficult allocation rule. If that rule determines whether two concurrent requests can create conflicting records, it may matter more to the replacement than most of the presentation code. Counting both as equivalent units of knowledge would conceal the delivery consequence. I would therefore represent application knowledge through reviewable claims and questions rather than a single percentage. A claim should identify what is being asserted, the evidence supporting it, the conditions under which it applies and any conflicting material. An unresolved question should identify what is missing, what decision depends on it and what evidence could resolve it. The distinction between observation and interpretation needs to survive this process. Finding a validation method supports a statement about that method. It does not necessarily establish that every production entry point invokes it. Finding no access check in one repository method does not establish that the operation is unprotected; the check may occur elsewhere. A test may document an expected result without proving that the deployed system currently produces it. Provenance helps reviewers inspect these distinctions. The W3C PROV model describes entities, activities and responsible agents involved in producing information. That provides a useful foundation for recording where a finding came from and how it was derived. Provenance does not itself establish that the interpretation is correct. [4] For planning purposes, an important finding should therefore remain distinguishable as directly supported, inferred, disputed, unresolved or not assessed. These are review states, not probabilities. Multiple summaries of the same underlying observation should not be counted as independent corroboration. For the shipment service, an evidence register might record that selected movement-creation paths check financial-guarantee conditions, while leaving the complete concurrency and enforcement behaviour unresolved. The published specification makes distinctions of this kind. It does not establish that every production path behaves identically. [7] A useful planning record would carry five labelled fields: **finding**, **supporting source**, **what remains unconfirmed**, **possible delivery consequence**, and **next check or decision**. For the hypothetical replacement, the next check might be a representative concurrent-submission test, followed by a service-owner decision about the required outcome. That is more informative than reducing the finding to "90% known". The register describes what we have learned; it does not yet supply a probability that the programme will finish on time. There is also no defensible denominator for everything that might matter but has not yet been discovered. Source access may exclude operational procedures, external consumers, production configuration or historical decisions. Those boundaries should be stated, without pretending that the remaining uncertainty can always be counted. ## 4. Connecting Application Findings to Delivery Work The central technical problem is not calculating a score. It is explaining how a finding changes the delivery model. Suppose analysis identifies that shipment processing depends on the relationship between a notification, its financial guarantee and the state of an earlier movement. The next step is not to assign a confidence value to the sentence. The team needs to determine what that relationship means for the intended change. If the relationship is required, the future specification must describe the relevant conditions. The implementation plan needs work to reproduce or deliberately replace them. Verification needs representative valid and invalid cases. Migration needs to establish how historical records map to the new model. An unresolved interpretation may require a decision from the service owner before those activities can be completed. The dependency can be recorded as a chain: a source observation supports a behavioural claim; an authorised decision establishes the future requirement; that requirement creates implementation, verification and transition work; the resulting work affects estimated effort, duration or acceptance risk. Where the chain depends on an assumption, the assumption remains visible. This is consistent with established estimating practice rather than a replacement for it. The US Government Accountability Office's cost-estimating guidance links reliable estimates to a technical baseline, work breakdown structure, assumptions, collected data, estimation methods, sensitivity analysis and updates from actual costs. Application analysis can improve the technical baseline and expose missing work, but cannot supply every other input automatically. [5] Consider one work package within our hypothetical replacement: mapping and testing historical shipment records. Initially we allow **100 person-days at £800 per person-day**. The labour estimate is 100 multiplied by £800, or **£80,000**. Further investigation might reveal additional historical variants, increasing the allowance to 160 person-days. At the same rate the labour estimate becomes **£128,000**. The finding has changed the estimated work by 60 person-days and the labour cost by £48,000; it has not supplied a mysterious confidence multiplier. Duration needs a separate calculation. For this deliberately simplified task, assume two people can share all the work evenly and both remain available. One hundred person-days then take 50 working days of active work. Add ten non-overlapping working days waiting for review and the task takes 60 elapsed working days. At 160 person-days, the same assumptions produce 80 active working days plus ten waiting days, or 90 elapsed working days. This example excludes labour charges during waiting, other costs, leave, handovers and serial bottlenecks. A real estimate must address them. These task figures illustrate the method; they are not the derivation of the later whole-programme scenario totals. The worksheet inputs are therefore ordinary labels: **effort in person-days**, **cost per person-day**, **available people**, and **waiting time**. The outputs are **labour cost** and **elapsed working days**. We must state the assumptions that make dividing effort by the number of people valid; it is not a general rule for an entire programme. ### Following a Finding Into the Programme Estimate To connect the task calculation to an actual planning decision, the companion now includes **Finding to plan**, linked to **Work package**. It follows one hypothetical historical-data finding. Suppose the available material points to historical variants, a data review confirms the additional cases, and the service owner decides that the replacement must preserve their meaning. An estimator then identifies extra mapping and test work. The 60 additional person-days remain an illustrative estimating judgement, not a number inferred automatically from finding 60 files or 60 rules. For this separate teaching plan, assume other programme work costs £720,000 and requires 80 sequential working days. Those allowances explicitly exclude this work package. To keep the arithmetic reproducible, assume 20 working days per teaching month, no overlap between the task and the other work, and the same capacity assumptions as before. Actual delivery needs real calendars and a dependency schedule; 20 is not a universal month conversion. Before the additional work, the total is **£720,000 + £80,000 = £800,000**. Its duration is **(80 + 60) / 20 = 7 months**. After the additional work, the total is **£720,000 + £128,000 = £848,000**, and duration is **(80 + 90) / 20 = 8.5 months**. Both versions fit the illustrative £1.2 million and ten-month limits. That does not establish acceptance or tell us how likely either complete outcome is. The new sheet makes those links inspectable. Its effort, rate, staffing and waiting inputs reference Work package. Its programme totals add the separate allowances without charging the task twice. Its budget and time limits reference Scenarios. Changing a task input changes the linked estimate; it does not change the original four-outcome probability exercise. Scenarios and Revised evidence retain their independent teaching inputs, so the reader does not accidentally mistake a task edit for a complete reassessment of the programme. The point where evidence enters is now concrete: a reviewed finding changes the required work. The additional estimation inputs still need their own basis. A useful record identifies the finding, source, decision, affected work, estimating basis, owner and date. **Finding to plan deliberately displays delivery probability as Not estimated.** A valid cost calculation cannot fill that gap by itself. ![A historical-data finding is reviewed before an estimator increases the work allowance from 100 to 160 person-days. The linked cost and duration calculations change; delivery probability remains not estimated.](/assets/papers/modernisation-confidence/finding-to-estimate.svg) *Figure 2. Following the historical-data example from an application finding through human review and estimating judgement to revised costs and duration. The lower calculations use the same assumptions as the linked spreadsheet.* [Open the finding-to-estimate diagram at full size](https://harten.io/assets/papers/modernisation-confidence/finding-to-estimate.svg) A practical model can represent the resulting outcomes as: \[ (C_\pi,T_\pi,Y_\pi)=F_M(\pi,\theta,Z). \] In this equation, F means the calculation procedure, not a new law of modernisation. The bracket on the left groups three outputs: cost, duration and acceptance. The inputs on the right are the plan, uncertain quantities and possible delivery events. For the task just described, uncertain effort belongs among the quantities; an unavailable review environment is an example of a delivery event. The formula records the model's job. The work breakdown, dependency schedule, cost rules and evidence must still define how it does that job. The parameters \(\theta\) represent uncertain quantities such as work effort, delivery rates, dependency behaviour and rework. \(Z\) represents possible events and operating conditions during delivery. The model must explain which evidence constrains those inputs and which values come from comparable delivery records or explicit expert judgement. Source code can reveal that a migration must preserve several distinct lifecycle states. It cannot, on its own, establish how quickly a particular team will implement that migration, how long a supplier will take to provide access or when a business owner will be available to resolve a policy question. Cost and duration must also be calculated together where they share causes. Additional data reconciliation may require more specialist effort, extend the transition and increase the cost of running both systems. Treating those effects as unrelated would misrepresent the possible outcomes. The UK Infrastructure and Projects Authority's guidance similarly links estimates to scope, schedule, evidence and risk, although its primary scope is infrastructure rather than software. [6] Programme duration is not simply total effort divided by headcount. Dependencies, scarce skills, review capacity and calendars constrain what can happen concurrently. Cost categories must be defined so the same risk is not charged twice, once in a work-package estimate and again as an unrelated contingency. For a greenfield replacement, the model must include the period during which the existing service continues, the transfer of data and authority, and the conditions for retirement. For an incremental approach, it must include compatibility and temporary integration work. The existing repository structure should not silently determine either the future architecture or the delivery plan. ## 5. Adding the Probabilities of Outcomes That Meet the Commitment Once the model describes possible whole-programme outcomes, the next calculation is straightforward: identify which outcomes meet all three conditions and add their probabilities. A scenario that is within budget and time but fails an essential shipment rule does not contribute to the success total. Its probability has not disappeared; it remains part of the model's failure probability. ### Why the Successful Probabilities Are Added Our success event consists of the successful complete outcomes. Because the scenario rows do not overlap, we do not count any possible outcome twice. The probability addition rule therefore tells us to add the probabilities of those successful rows. The rule also requires non-negative probabilities and a total of one across the represented scenario space. This is the basis for the sum, not an empirical claim about how software programmes behave. [14] Multiplying each row by 1 when it passes and 0 when it fails lets us write that addition over every row without changing the answer. That produces the indicator-and-sum expression below. Writing the sum as a dot product simply gives the same operation a compact name. No independence assumption between cost and duration is required, because the model keeps them together within each complete outcome. A row must be detailed enough to determine its pass/fail result. If a broad category could contain both successful and unsuccessful outcomes, split it further or model the conditional chance of success within that category. Giving an uncertain category a definite 1 merely because its central estimate fits the limits would misstate the probability. The mathematical name for the calculation is a dot product. The vectors are not pounds, months and an arbitrary knowledge score. One list contains the scenario probabilities. The other contains a 1 for each successful scenario and a 0 for each unsuccessful scenario. Suppose the model contains \(m\) mutually exclusive scenarios that exhaust its represented possibilities. Each scenario \(s\) has a probability \(p_s\), a cost \(C_s\), a duration \(T_s\) and an acceptance result \(Y_s\). Define an indicator: \[ v_s(B,D)=\mathbf{1}\{C_s\leq B,\ T_s\leq D,\ Y_s=1\}. \] The indicator v is just that 1-or-0 test. For example, an accepted £1.1 million outcome taking nine months scores 1 against our £1.2 million and ten-month limits. An accepted £1.5 million outcome taking twelve months scores 0. Here Y describes whether the required result is achieved; v additionally checks money and time. Neither number says whether an outcome has already happened. At planning time these are descriptions of possible futures. Then: \[ q_\pi(B,D)=\sum_{s=1}^{m}p_s v_s(B,D)=\mathbf{p}^{\mathsf T}\mathbf{v}(B,D), \qquad p_s\geq0,\quad\sum_s p_s=1. \] The large summation sign means "add the terms". The index s identifies a scenario, and m is the number of scenarios. For each one, multiply its probability p by its 1-or-0 result v. The superscript T means transpose, arranging the lists for this multiplication; it does not mean duration or a power of time. The final conditions say that probabilities cannot be negative and must total one, or 100%. For example, the lists [0.55, 0.25, 0.15, 0.05] and [1, 1, 0, 0] give **(0.55 × 1) + (0.25 × 1) + (0.15 × 0) + (0.05 × 0) = 0.80**. Counting "two successful scenarios out of four" would give the wrong answer because the scenarios are not equally likely. The worked example below explains what each row could mean for the shipment service. The conditioning on evidence, assumptions and model is suppressed here only to simplify the notation. Cost and duration determine whether each scenario meets the commitment; the scenario probabilities determine how much each outcome contributes to the final assessment. A list of risks is not automatically such a scenario set. Risks can occur together. The model must represent their combinations and dependencies rather than adding overlapping probabilities. For example, an integration problem and a historical-data problem could occur together. A model using them as separate risk flags must represent "neither", "integration only", "data only" and "both", with any other relevant distinctions. The four teaching rows below are assumed to be non-overlapping complete outcome bundles, not four independent events. For a larger model, simulation can approximate the same quantity by drawing joint outcomes and counting the proportion that meet all three conditions. If a model generates 10,000 equally weighted possible outcomes and 8,000 meet the budget, duration and acceptance conditions, the simulation estimate is 8,000 divided by 10,000, or 80%. These are modelled outcomes, not 10,000 completed programmes. The simulation must retain linked effects, such as reconciliation work increasing both cost and elapsed time. More simulation runs reduce numerical sampling error; they do not repair omitted dependencies, unsupported probabilities or an incorrect acceptance definition. NASA's integrated risk-analysis approach is a relevant implementation precedent. [3] The resulting value lies between zero and one. A higher value means a greater assessed likelihood of meeting the specified commitment under the model. It does not mean that the application is more completely understood. Even a value of one is conditional on what the model represents, not proof that an unmodelled event cannot occur. ### How an Assessor Supports the Scenario Probabilities The calculation is exact for its inputs. The more difficult question is why a scenario was assigned 25% rather than 10% or 40%. Neither the dot product nor a language model's confidence in its own wording establishes that input. An assessor should first define the complete outcomes and the evidence that distinguishes them. In the shipment example, a reporting dependency, difficult historical records and a failure to preserve a required control can have linked consequences. A risk register lists concerns; it does not automatically provide non-overlapping programme outcomes. The model must show how those concerns affect work, sequencing, cost and acceptance, including combinations that can occur together. Where relevant completed-delivery records exist, observed frequencies can inform an initial estimate. For example, **25 comparable outcomes among 100 completed cases gives an observed proportion of 25/100 = 25%**. This is a hypothetical illustration, not a Harten dataset. Before using such a proportion, the assessor must examine the definition of the outcome, sample uncertainty, selection effects, forecasting horizon, team capability and whether the cases genuinely resemble the current plan. Finding 25 difficult files among 100 is not equivalent to observing 25 programme outcomes. Where judgement supplies an input, name it as judgement and record the assessor's basis. Where the available evidence cannot support a numerical probability, retain **not yet estimated**, a range or a sensitivity analysis rather than manufacture a precise percentage. This follows the estimating discipline of separating the technical baseline, assumptions, data and risk analysis. [5] A bounded sensitivity example can still support a decision. Suppose we hold the illustrative acceptance-failure probability at 5%, and test whether the separate, non-overlapping historical-data outcome has a probability between 10% and 40%. Assume all remaining probability belongs to successful outcomes. The resulting delivery probability then ranges from **100% - 5% - 10% = 85%** down to **100% - 5% - 40% = 55%**. Each scenario set must still total 100%; the remaining successful probability changes accordingly. This is an assumed sensitivity range, not a statistical confidence interval. It shows that the historical-data assessment could materially affect the decision, without pretending that we have established its true probability. For the next review, the useful question is specific: what data profiling, representative migration rehearsal or service-owner decision would narrow that uncertainty enough to change the plan? Wayfinder's role is to help expose and organise the application evidence. The assessor remains responsible for the estimation model and its unsupported inputs. ## 6. A Worked Example of a Changing Assessment Consider a proposed replacement with a budget limit of **£1.2 million** and a duration limit of **10 months**. The four outcomes introduced in section 1 are deliberately simplified. None of their values is a PRSD-IWS measurement or a Wayfinder forecast. We now follow the practical meaning of each row before changing the assessment. **In the first outcome**, the candidate specification and delivery assumptions prove adequate for the defined commitment. The replacement preserves the agreed notification and movement controls, historical records can be mapped as planned and the service passes acceptance. Its illustrative £800,000 cost and seven-month duration are within both limits, so all of its 55% probability contributes to the success total. **In the second outcome**, suppose the team confirms that a reporting consumer depends on an existing interface. Preserving or deliberately replacing that contract creates integration and test work. In this possible future, the work raises the total to £1.1 million and nine months but acceptance is still achieved. The entire 25% contributes too. Finding additional work does not necessarily mean the programme misses its commitment. **In the third outcome**, suppose historical shipment records require considerably more mapping and reconciliation than expected. The eventual service works, but the modelled total reaches £1.5 million and twelve months. This outcome contributes zero to the chance of meeting the original promise because it exceeds both limits. Its 15% remains a risk the sponsor needs to consider. The example does not claim that this data problem was observed in PRSD-IWS. **In the fourth outcome**, suppose the replacement is delivered cheaply and quickly but fails an agreed financial-guarantee or permission condition. Its £900,000 and eight months do not rescue it: acceptance is not achieved. Its 5% also contributes zero. This is a hypothetical acceptance failure, not a security or correctness finding about the public application. For this model: \[ q=0.55+0.25=0.80. \] Ignoring acceptance would produce 0.85, because the final scenario stays within budget and time while failing to deliver an essential outcome. This is why cost and schedule alone cannot define successful modernisation. Now suppose further investigation changes the analyst's scenario assessment. Historical data appears more difficult to reconcile than initially assumed. For illustration, the probabilities are revised to 0.25, 0.30, 0.40 and 0.05 respectively, while the scenario costs and durations remain unchanged. The revised result is: \[ q'=0.25+0.30=0.55. \] These revised weights are illustrative assumptions, not a statistically fitted update. In a real assessment, the analyst would need to explain the finding, why it changes the weights and how sensitive the conclusion is to that judgement. Read q prime as "the revised probability". We have changed the inputs describing which complete outcomes appear likely, not redefined the success conditions. The four probabilities still add to 100%. This numerical update is not automatically derived from how many files Wayfinder has read: someone must justify the connection between the new finding and the revised scenario assessment. The important result is that the team has learned something useful while confidence in the original commitment has fallen. That is not a failure of discovery. It gives the organisation a chance to change scope, resolve the difficult data issue, alter the transition or reconsider the budget and date. Increasing the budget or extending the deadline can also raise the calculated probability without changing the implementation. Comparisons must therefore retain the same constraints or explicitly show which commitment has changed. The objective is not to make the number increase; it is to select an acceptable plan on a more defensible basis. ### The Difference Between Changing the Evidence and Changing the Promise Return to the original probabilities, not the revised ones. If we increase the budget to £1.5 million but keep the ten-month deadline, the result remains 80%: the historical-data outcome still takes twelve months. If we also allow twelve months, that outcome now passes and the result becomes 55% + 25% + 15% = **95%**. The acceptance-failure outcome still does not count. The engineering has not improved; we have relaxed the commitment. Holding the plan and scenario model fixed makes that distinction visible. A probability-weighted average answers another question. In the original table the average cost is **£985,000** and the average duration is **8.3 months**. Those averages are within the limits, but 20% of the represented probability still belongs to outcomes that fail the whole promise. A comfortable average is not the same as a high enough chance of meeting the commitment. Nor should we multiply separate budget, time and acceptance percentages unless the necessary independence assumptions are justified. In this table the within-budget probability is 85%, the on-time probability is 85% and the acceptance probability is 95%. Multiplying them gives about 68.6%, not the correct joint result of 80%. The historical-data outcome is both expensive and late, so these are linked conditions rather than unrelated chances. ### Reproducing the Calculation in a Spreadsheet [Download the companion spreadsheet (.xlsx)](https://harten.io/assets/papers/modernisation-confidence/modernisation-confidence-worked-examples.xlsx) The following layout turns the abstract notation into editable inputs and visible calculations. Use one sheet named **Scenarios**. These are teaching inputs, not numbers extracted from a Wayfinder analysis. Keep a separate record of the evidence and reasoning used to assign probabilities before using the layout for a real decision. | Cell or range | Spreadsheet label | Example input or purpose | |---|---|---| | B4 | Budget limit (£) | 1200000 | | B5 | Duration limit (months) | 10 | | B6 | Acceptance definition | The agreed shipment-service criteria | | B8 | Plan and evidence snapshot | The specific plan and dated assessment | | A12:A15 | Complete outcome | The four scenario descriptions above | | B12:B15 | Scenario probability | 55%, 25%, 15%, 5% | | C12:C15 | Cost (£) | 800000, 1100000, 1500000, 900000 | | D12:D15 | Duration (months) | 7, 9, 12, 8 | | E12:E15 | Would meet requirements? (1 or 0) | 1, 1, 1, 0 | | F12:F15 | Within budget, time and requirements? | Calculated for each outcome | | G12:G15 | Probability counted towards success | Calculated for each outcome | | H12:H15 | Evidence or assumption basis | Why each scenario and probability is included | In **F12**, enter the following formula and copy it down to F15: =IF(AND(C12<=$B$4,D12<=$B$5,E12=1),1,0) The formula asks whether the cost is within the budget, the duration is within the limit and acceptance is achieved. AND requires all three. IF returns 1 when they are all true and 0 otherwise. The dollar signs keep the budget and duration-limit cells fixed as the formula moves down the rows. It should return 1, 1, 0 and 0. The documented behaviour of IF and AND is the direct spreadsheet counterpart of the indicator equation. [13] In **G12**, enter the following formula and copy it down to G15: =B12*F12 This multiplies each probability by its pass/fail indicator, producing contributions of 55%, 25%, 0% and 0%. Add them with SUM(G12:G15), or calculate the same result directly with: =SUMPRODUCT(B12:B15,F12:F15) This is the dot product in a spreadsheet: corresponding entries are multiplied and their products added. The two ranges must have matching dimensions. [12] Check the inputs before displaying the result. B12:B15 must contain four numerical probabilities between zero and one which total one; costs and durations must be numerical and non-negative; acceptance must be exactly 0 or 1; and the two limits must be positive numbers. An empty cell must not quietly become a zero-cost or immediate-delivery assumption. Do not normalise an incomplete scenario set simply to force its probabilities to total 100%. For the fixed four-row layout, **B18** can contain =SUM(B12:B15). **B19** should show Numerical inputs valid only after the numerical checks above pass; the complete automatic check is included in the spreadsheet formula reference at the end of this paper. In **B20**, display the probability only after that check: =IF(B19="Numerical inputs valid",SUMPRODUCT(B12:B15,F12:F15),"Check inputs") Format B20 as a percentage: it should show **80%**. Save the original sheet before substituting the revised probabilities of 25%, 30%, 40% and 5%; the revised sheet should show **55%** at the same limits. Numerical validation cannot check whether the scenarios are complete, their probabilities are defensible or their interpretation is correct. Those remain review questions. If more rows are added, extend the ranges and update the fixed row counts. The formulas shown use English function names and comma separators. This is also why the five starting questions should remain visible. The spreadsheet contains the budget and time conditions. The evidence register explains what we know and have not established. The scenario model connects those findings to possible delivery outcomes. The final probability is an assessment from that combined material, not a substitute for it. ## 7. The Published PRSD-IWS Example Harten's PRSD-IWS case study provides a concrete example of the information that can support this process. The public case-study manifest records an analysis scope of **423,897 source lines** from the DEFRA repository for the International Waste Shipments application. The repository's licence attributes copyright to the Environment Agency and releases the source under the Open Government Licence v3.0. [7, 8] The case study publishes three connected outputs: [current-system documentation](https://harten.io/case-studies/prsd-iws/documentation/00-readme/), a [recovered specification](https://harten.io/case-studies/prsd-iws/specification/overview/) and a [proposed modernisation plan](https://harten.io/case-studies/prsd-iws/modernisation/modernisation-plan/). The documentation explains the application through business capabilities, actors, journeys, rules, information, components, integrations and operational concerns. Its introduction states that factual claims refer to retained analysis artefacts and that important behaviours which cannot be established are recorded as open questions. The specification develops a source-level account of behaviours and constraints rather than claiming to establish every production process. [7] For example, the specification discusses financial-guarantee conditions in movement processing while retaining questions about concurrency, lifecycle interpretation and wider enforcement. Those distinctions matter to delivery. An implementation team needs to know not merely that a guarantee status exists, but which combinations of state, identity and timing the future service must allow. An unresolved combination becomes investigation or decision work, not permission for an agent to choose a convenient interpretation. [7] The proposed modernisation plan carries such issues into delivery concerns, including baseline recovery, behavioural characterisation, identity, lifecycle rules, calculations, migration and operational readiness. Its baseline-recovery activity has low, central and high planning scenarios of 15, 30 and 60 working days. It also identifies scarce reviewers, dependency access and business decisions as potential constraints. Those are planning scenarios, not demonstrated P10, P50 and P90 forecasts, and the plan does not establish a cost baseline. [7] This is evidence of a published analysis and planning package, not a completed replacement or a validated probability of programme success. Its practical value is that readers can inspect what was produced and examine the findings and open questions behind the proposal. The probabilistic method in this paper describes how such material could be connected to an explicit delivery model once the necessary delivery and acceptance inputs are available. The case study is independent Harten analysis of public source code. It should not be interpreted as a DEFRA-commissioned engagement or an endorsed modernisation programme. [7] ## 8. The Analysis Currently in Progress As at 16 October 2026, Harten is also analysing the Department for Education's publicly available Explore Education Statistics codebase. The working scope reported for this run is approximately one million lines. At the reported checkpoint, about a day and a half into the run, the process showed approximately 8% progress. These are in-progress figures reported by the author, not an independently audited benchmark. The progress measure describes the running analysis; it does not establish that 8% of the service's meaning has been understood, or that the remaining work will proceed at a constant rate. The repository describes public and administrative applications, multiple APIs, data processing and publishing components, and SQL Server and PostgreSQL dependencies. Its root software licence is MIT, distinct from PRSD-IWS's OGL licence. [9] This ongoing run is relevant to the engineering objective, but it is not evidence that the one-week target has been met. A completed, reviewable result and its measured elapsed time are needed to assess that. ## 9. The One-Week Engineering Objective Our goal for Wayfinder is to be able to analyse any codebase and return useful, evidence-backed information within one week. The intended output is an account of the application, a recovered specification, a proposed route to modernisation and an explicit account of what the evidence does not yet establish. That is an ambitious engineering target. It is not a claim that every service can be understood completely from source, or that a week of analysis replaces every conversation with the people who operate it. The objective is to shorten the time before an organisation can examine a substantial, reviewable account of its applications and use it to make better decisions. A result can be useful before every question has been answered. It can identify a previously unrecognised dependency, show that a proposed boundary needs reconsideration, recover a condition that tests must preserve or explain why a budget assumption needs further investigation. Its usefulness depends on what those findings allow the organisation to decide, not simply how much documentation has been generated. The one-week objective must be measured against a defined delivery, not against the last successful model call. Benchmark reports should record the agreed input snapshot, scope and exclusions, available compute, human involvement, processing failures, review work and the time at which the information was ready to inspect. They should state whether durations are elapsed or working days. Where the clock starts after access is provided, the preceding access delay should still be reported rather than disappearing from the end-to-end account. Generality also needs evidence across languages, frameworks, sizes and application structures. The target is not satisfied by silently dropping difficult files, omitting cross-application dependencies or returning a fixed template that leaves the important questions unanswered. Missing material and unsupported areas need to remain visible in the delivered result. The week applies to producing the analysis and planning information. It does not imply that the modernisation itself can be completed in that period. ## 10. Testing the Quality of the Assessment Three different claims need separate evaluation: whether the analysis is useful, whether the turnaround target is met and whether numerical delivery forecasts are reliable. Success on one does not establish the others. For the application analysis, evaluation should inspect representative findings against their cited source, test whether conditions and exceptions have survived interpretation, and seek important omissions through independent review. Reviewers should include operational and domain knowledge where available. When that evidence is unavailable, the evaluation should state which claims could and could not be checked. For estimates, the relevant test is against later delivery outcomes using a defined baseline. Forecasts should retain their scope, evidence date, model version, budget, duration limit and acceptance criteria. A revised forecast must not overwrite the original. Otherwise a programme can appear accurately predicted simply because its forecast was repeatedly moved towards the result. For numerical confidence, calibration asks whether events assigned similar probabilities occur at approximately those frequencies over suitable repeated cases. A classification model's confidence is not automatically calibrated, as Guo and colleagues demonstrated in neural-network experiments. Their work is not evidence about Wayfinder or programme delivery, but it illustrates why a numerical confidence output needs evaluation rather than trust in its presentation. [10] A delivery-forecast evaluation can use the binary form of the Brier score: \[ \operatorname{BS}=\frac{1}{N}\sum_{i=1}^{N}(q_i-y_i)^2, \] where \(q_i\) is a recorded probability and \(y_i\) is one if the corresponding commitment was met and zero otherwise. Lower values indicate lower squared forecast error. The score is a forecast-quality measure, not a complete calibration test; it should be accompanied by reliability analysis and comparison with a relevant baseline forecast. [11] To see what the Brier equation means, suppose a recorded delivery forecast was 80%. If the commitment is eventually met, y is 1 and its squared error is **(0.80 - 1) squared = 0.04**. If the commitment is not met, y is 0 and the error is **(0.80 - 0) squared = 0.64**. Squaring prevents positive and negative differences from cancelling and gives a larger penalty to a confidently wrong forecast. Suppose, purely for illustration, we have ten recorded 80% forecasts and observe eight successes and two failures. Add eight errors of 0.04 and two errors of 0.64, then divide by ten: **(8 × 0.04 + 2 × 0.64) / 10 = 0.16**. N in the equation is the number of forecasts; the index i identifies each one. The division by N calculates the average error. A Brier score of 0.16 is not a 16% failure rate. Higher delivery probability means a greater assessed chance of success; lower Brier score means smaller forecast errors on the evaluated cases. A spreadsheet can reproduce this on a separate **Forecast check** sheet. Put the ten probabilities in B9:B18 and the actual 1-or-0 results in C9:C18. The underlying arithmetic is (B9-C9)^2. The downloadable sheet wraps that arithmetic in checks so missing or invalid inputs remain unscored. A standalone guarded formula for D9, copied down to D18, is: =IFERROR(IF(AND(COUNT(B9:C9)=2,B9>=0,B9<=1,OR(C9=0,C9=1)),(B9-C9)^2,""),"") For this fixed ten-case exercise, =IF(COUNT(D9:D18)=10,AVERAGE(D9:D18),"Check inputs") returns 0.16 only when all ten row scores are valid. The workbook also withholds the comparison summaries for an incomplete set and updates their headings when the comparison probabilities change. A blank outcome is not a failure. Use completed, comparable commitments and do not overwrite their original forecasts. Predicting 50% for all ten of these teaching cases would score 0.25; predicting 100% for all ten would score 0.20. The 80% forecasts score better than those two alternatives in this constructed example. This is not evidence that the model is generally good. Calibration asks a related but different question: across enough comparable real forecasts assigned about 80%, are commitments actually met about 80% of the time? Ten invented cases demonstrate the calculation, not its reliability. ### Why This Score Measures Probability Error We need a way to compare a probability stated before delivery with the result observed afterwards. Marking every forecast simply right or wrong loses the distinction between a 55% forecast and a 95% forecast. Brier's squared-error score is an established way to retain that distinction; the modern binary form used here is not a Harten invention. [11] There is a reason for choosing this rule beyond the convenience of squaring a number. Suppose the genuine chance of meeting a particular commitment is r, and we report q. The squared error is (q - 1) squared on success and q squared on failure. Weighting those errors by their respective chances gives the expected error: \[ L(q,r)=r(q-1)^2+(1-r)q^2=(q-r)^2+r(1-r). \] L is the average error we would expect under that hypothetical genuine probability. On the right, r(1-r) does not change when we change our report. The remaining term, (q-r) squared, is smallest when q equals r. Thus the rule rewards reporting the correct probability in expectation rather than always claiming certainty. This property is called strict propriety. It is a reason to use the score, not evidence that we know r or that the current model is calibrated. [15] For example, if r is 0.8, reporting q = 0.8 gives expected error 0.16. Reporting certainty gives 0.20; reporting 0.5 gives 0.25. These are the same values illustrated by the ten teaching cases, now with the reason for the calculation made explicit. In practice we observe a finite set of results, not an accessible true r for each unique programme. Sampling variation, case differences and intervention still matter. The evaluation set must also be credible. Repeated checkpoints from one programme are not independent programmes, and forecasts made a day before completion should not be compared uncritically with forecasts made before delivery begins. Cases should be grouped by relevant characteristics and forecasting horizon, with uncertainty reported where the sample is small. The evaluation should also distinguish revisions to an unchanged plan from interventions that changed what was delivered. Until there is enough evidence to support a probability, scenario ranges, sensitivity analysis and explicit judgements remain useful outputs. A low, central and high estimate should not acquire percentile labels merely because a dashboard expects three numbers. The absence of a calibrated probability is not the absence of useful analysis. ## 11. The Consequence for AI-Assisted Modernisation For an AI-assisted engineering system, this approach changes the purpose of analysis. The system is not being asked merely to describe files or to express confidence in its own explanation. It is being asked to assemble findings that can inform consequential decisions and to preserve the distinction between evidence, interpretation and authority throughout that work. Agents can help trace dependencies, recover candidate requirements, prepare tests and investigate alternative designs. They can also help identify which unanswered questions could most change the estimate. They should not manufacture missing delivery rates, treat an inferred business rule as approved or remove an unresolved acceptance condition to make a forecast look better. The organisation still decides what must be delivered, what may change and which risks it will accept. An evidence-linked model gives that judgement something concrete to inspect: the required outcome, the proposed work, the assumptions affecting cost and duration, and the findings that could change the assessment. For Harten, that is the connection between evidence-first software intelligence and the practical modernisation decision. We want to return the best account we can support from the available material, quickly enough to influence the programme before its assumptions become expensive commitments. The one-week objective concerns how quickly that account becomes available. The confidence model concerns what the organisation can reasonably conclude from it. ## Spreadsheet Formula Reference The longer input check is kept here so the calculation in section 6 can be read without losing the shipment-service example. It implements the numerical checks described there; it does not judge the evidence or approve a plan. | Spreadsheet cell | Automatic input-validation formula | |---|---| | Scenarios B19 | =IF(AND(COUNT($B$4:$B$5)=2,MIN($B$4:$B$5)>0,COUNT(B12:E15)=16,MIN(B12:D15)>=0,MAX(B12:B15)<=1,COUNTIF(E12:E15,0)+COUNTIF(E12:E15,1)=4,ABS(SUM(B12:B15)-1)<0.000000001),"Numerical inputs valid","Check inputs") | COUNT checks that the required inputs are numerical. MIN and MAX reject values outside the permitted ranges. COUNTIF checks that all four acceptance inputs are 0 or 1. ABS checks that the probability total is sufficiently close to one, allowing only a small rounding tolerance. The formula returns Check inputs rather than producing a delivery probability when these checks fail. Its counts of 16 numerical scenario inputs and four acceptance results apply to this four-row teaching example, not an arbitrary-length register. ### How the Companion Checks Inputs The workbook's label **Numerical inputs valid** means only that numerical values pass the checks. It is not a statement that a plan is approved, complete or well calibrated. Work package rejects missing or negative effort, rate or waiting time and requires positive available capacity. Its linked outputs are withheld when those checks fail. Forecast check leaves a missing or invalid outcome unscored in every comparison column and withholds the fixed ten-case summary until all cases are valid. These checks prevent accidental arithmetic results from being mistaken for evidence. ## References and Source Notes [1] Nallainathan, L. (2026). [Legacy systems are expensive because knowledge has decayed](https://harten.io/papers/02-02-legacy-systems-are-expensive-because-knowledge-has-decayed/). Harten Papers. [2] Nallainathan, L. (2026). [Architecture should be a consequence of evidence](https://harten.io/papers/05-architecture-should-be-a-consequence-of-evidence/). Harten Papers. [3] NASA. [Project Planning and Control Glossary](https://www.nasa.gov/ocfo/ppc-corner/ppc-glossary/). Entries on joint confidence level, integrated cost and schedule risk analysis and basis of estimate. Consulted 16 October 2026. [4] W3C (2013). [PROV-DM: The PROV Data Model](https://www.w3.org/TR/2013/REC-prov-dm-20130430/). W3C Recommendation, 30 April 2013. [5] US Government Accountability Office (2020). [Cost Estimating and Assessment Guide: Best Practices for Developing and Managing Program Costs](https://www.gao.gov/products/gao-20-195g). GAO-20-195G. The overview identifies the technical baseline, assumptions, work breakdown, sensitivity analysis and validation within the estimating process. [6] Infrastructure and Projects Authority (2021). [Cost Estimating Guidance](https://www.gov.uk/government/publications/cost-estimating-guidance/cost-estimating-guidance). Used here for its principles concerning evidence, scope, schedule, ranges and assumptions, not as a software-specific forecasting standard. [7] Harten (2026). PRSD-IWS public case study: [documentation](https://harten.io/case-studies/prsd-iws/documentation/00-readme/), [specification](https://harten.io/case-studies/prsd-iws/specification/overview/) and [proposed modernisation plan](https://harten.io/case-studies/prsd-iws/modernisation/modernisation-plan/). The 423,897-line figure is the scope recorded in Harten's case-study manifest, not a fresh independent count. The manifest identifies a retained source-archive hash and states that the analysed upstream commit has not been verified; this paper does not equate the analysed snapshot with the repository's current branch. [8] DEFRA / Environment Agency. [PRSD-IWS source repository](https://github.com/DEFRA/prsd-iws) and [licence notice](https://github.com/DEFRA/prsd-iws/blob/master/LICENSE). Source copyright: © 2014 Environment Agency. [Open Government Licence v3.0](https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/). Contains public sector information licensed under the Open Government Licence v3.0. No departmental endorsement is implied. [9] Department for Education, Analytical Services. [Explore Education Statistics repository](https://github.com/dfe-analytical-services/explore-education-statistics) and [MIT licence](https://github.com/dfe-analytical-services/explore-education-statistics/blob/dev/LICENSE). Source copyright: © 2018 Department for Education – Analytical Services. The runtime checkpoint in section 8 is the author's report on 16 October 2026, not a repository-derived performance measurement. [10] Guo, C., Pleiss, G., Sun, Y. and Weinberger, K. Q. (2017). [On Calibration of Modern Neural Networks](https://proceedings.mlr.press/v70/guo17a.html). Proceedings of the 34th International Conference on Machine Learning, PMLR 70, 1321–1330. [11] Brier, G. W. (1950). [Verification of Forecasts Expressed in Terms of Probability](https://journals.ametsoc.org/view/journals/mwre/78/1/1520-0493_1950_078_0001_vofeit_2_0_co_2.xml). Monthly Weather Review, 78(1), 1–3. This paper uses the modern one-sided binary score, ranging from zero to one, rather than the original sum across both outcome categories. [12] Microsoft. [SUMPRODUCT function](https://support.microsoft.com/en-gb/excel/functions/sumproduct-function). The function multiplies corresponding entries and adds the products. Consulted 16 October 2026. [13] Microsoft. [Using IF with AND, OR, and NOT functions](https://support.microsoft.com/en-gb/excel/using-if-with-and-or-and-not-functions-in-excel). Used for the spreadsheet's explicit three-condition test. Consulted 16 October 2026. [14] Pennsylvania State University. [Properties of Probability, STAT 414](https://online.stat.psu.edu/stat414/Lesson02). The axioms and addition rule support summing the probabilities of non-overlapping successful outcomes. Consulted 16 October 2026. [15] Gneiting, T. and Raftery, A. E. (2007). [Strictly Proper Scoring Rules, Prediction, and Estimation](https://doi.org/10.1198/016214506000001437). Journal of the American Statistical Association, 102(477), 359-378. The squared-error derivation above illustrates why the binary Brier score encourages accurate probability reports in expectation; it is not a validation result for Wayfinder.