Classify a proposed change to a signed PPP contract, set out the procedure it must run through and who usually bears the time and the cost, and see which parts of the contract it reaches: risk allocation, the payment mechanism, financing consents, termination. A screen for the contracting authority's team before a change is agreed, not a determination of anyone's entitlement.
v1.0 — September 2026
Six change and relief mechanisms of a PPP project agreement, read as one workflow: trigger, qualification, notice, mitigation, decision, relief, money, remedy. The screen classifies the change, walks the procedure step by step, and reports impact by confidence (direct, indirect, not indicated) rather than by score. The vocabulary, the workflow and the "what to consider" text are ported from the PPP Contract Review & Operating Map. Paste the contract text and it proposes the parameters for you to confirm.
Stage, financing and revenue model are required before the screen runs. Financing decides whether the lender step applies; the revenue model decides which payment route is described.
Paste the agreement, schedules included. The tool looks for the change protocol, the event regimes, the notice and estimate periods, the base-case adjustment clause and the lender consent terms, and proposes the profile and the contract parameters on the Procedure tab. Nothing is filled in until you accept it; no answer is ever set. The text stays in this browser tab.
Tick everything the change or event affects. These drive the impact screen; they are read as your assessment, not derived.
What the executed contract says for this category. Optional; the contract-text step can propose them. Recorded in the export and shown beside the route.
One question per workflow step, in the order the product's change mechanisms run. Answer for the weakest part; a single lapse in a practice that otherwise works is "Partly". "Don't know" is treated as a finding.
Direct: the change touches the area on the facts you entered. Indirect: the area usually moves with this kind of change. Not indicated: nothing entered reaches it. A confidence class, never a score.
| Area | Indication | Why | Re-check after the change |
|---|
| Step | Status | Basis |
|---|
The band above is a suggestion computed from the entries. A named person records the decision; an override does not change the suggestion, it sits beside it in the export. The block clears whenever the screen is re-run.
The Variation and Change Impact Screen helps a contracting authority's team look at one proposed change or one event before it is agreed, classify it under the contract's own regimes, check that the procedure is being followed in the right order, and see which other parts of the contract it reaches. It is screening-level. It does not determine whether a claim is valid, what compensation is due, or whether a change should be approved; those are decisions for named people with the executed contract in front of them.
The screen is a port from PPP Contract Review & Operating Map v1.0.0 (Benchmark Baseline; formerly "PPP Contract Copilot"), a rules-based product built on the Saudi National Center for Privatization & PPP (NCP) Project Agreement Precedent Template. Four of its parts are used:
The product's amendment categories are used for one output: what kind of formal amendment the change would need, if any (payment-mechanism amendment, risk-allocation clarification, procedural amendment, governance amendment), as opposed to a change confirmed under the protocol with no amendment to the agreement's text.
| Area | Direct when | Indirect when |
|---|---|---|
| Risk allocation | You ticked risk allocation, or the change is permanent and touches the works, the services or the term | The category is a change in law, a compensation event or a relief event (each reallocates a risk for the event's duration), or capital expenditure is involved |
| Payment mechanism | You ticked the payment amount or formula, or a cost effect is entered under an authority change, a change in law or a compensation event | You ticked KPIs, the services or the output specification (deductions move with them), or a time effect is entered, or a private-party change carries a cost |
| Financing consents and the base case | You ticked financing or the base case, or capital expenditure is funded by the private party, or the cost is at least five per cent of the annual payment under project finance | Any cost effect under project finance, or a permanent change to the payment |
| Termination | You ticked termination provisions or the term | The category is a compensation event, a relief event or a change in law and a time effect is entered (each carries a prolonged-event termination limb), or the change is permanent and touches the works |
| KPIs and output specification | You ticked KPIs or the output specification | You ticked the services or the works |
| Insurance and security | You ticked insurance | You ticked the works or capital expenditure, or the category is a relief event (uninsurability sits in that regime) |
| Third parties and subcontracts | You ticked consents and permits or subcontracts | You ticked the works or the services |
The five-per-cent test for financing consents is the tool's own screening threshold, chosen because financing agreements commonly require lender consent for variations above a stated value and that value is contract-specific and usually cumulative over a year rather than per change. Enter the contract's own threshold in the parameters, add up the year's changes, and treat the tool's line as a prompt to check it.
Twelve questions, one per workflow step, answered Yes, Partly, No or Don't know (Not applicable is offered on the lender step only, and only where there are no third-party lenders; a relief event still requires full details of the relief claimed, so the estimate step always applies). Each answer becomes a status as in the Contract Health Check: a core question answered No is Action needed; a supporting question answered No is Watch; Partly is Watch; Don't know is Not evidenced and holds the step at Watch or worse. The band is then suggested. A Don't know on the notice or the qualification of a claim-type event is named in the band's reason, because those are the two steps on which entitlement turns:
No score, no weighting, no average. "Stop and regularise" means the team should not agree the change or the claim until the missing step is put right, because a step skipped is where entitlement is won or lost, in the product's words. The band is a suggestion that a named person accepts or overrides with a reason; both appear in the export.
The screen names, without counting, four kinds of mismatch: an initiator that does not fit the category (an authority-initiated change classified as a relief event, an external event classified as an authority change); a change-in-law category with no change-in-law type; a change in law claimed by the private party under a general change in law, where most contracts leave that risk with the private party; and a cost entered with no area ticked that could carry it. These are the overlap tests of the product's CR24 to CR27 rules, applied to entries rather than to text.
The optional step on the Contract tab is the same pattern engine as the Contract Health Check: presence patterns ported from the product's completeness tests and party aliases, a heading index for locators, hits ranked in the operative provisions ahead of the definitions block, values listed as phrases found near the term (up to three, each with a locator, outside square brackets) for the team to check. Here the targets are the change protocol, the notice and estimate periods, the change-in-law definitions and threshold, the compensation and relief event lists, the base-case adjustment clause, the no-better-no-worse basis and the lender consent terms. Proposals fill the profile and the contract-parameter fields only; they never set an answer, and each needs an explicit Accept. Drafting varies, so "not found" is not evidence of absence; no accuracy figure is claimed.