Whether a change is material and adverse is assessed against what the Customer is using, not against Pensieve's view of how important the capability is. Where the parties disagree, 5.4 applies.

2.1 The table. Notice runs from the date the deprecation notice is issued to the Customer's notified contacts, not from the date it is published.

2.2 Longer where agreed. An Order Form may record a longer notice period. It may not record a shorter one for any row marked in bold.

2.3 Notice is per-Customer, not just published. Publication is not notice. Pensieve sends the notice to each affected Customer's notified contacts, and identifies whether that Customer is actually using the capability, based on telemetry where the deployment model permits it. A Customer that is not using the capability is told so, and does not have to work it out.

3.1 The notice states: the capability being removed; the removal date; whether the Customer is using it and, where Pensieve can tell, how much; the reason; the successor capability, or the statement that there is none; the migration path, with documentation; what Pensieve will do to help; the effect on Charges; and the named contact for questions.

3.2 During the notice window, Pensieve will:

3.2.1 keep the capability operating in full, at the same service level;

3.2.2 continue to apply security fixes to it;

3.2.3 publish the migration documentation at the start of the window, not at the end;

3.2.4 provide migration assistance: up to twenty (20) person-hours per affected Customer at no charge for a removal with no successor capability, and up to ten (10) person-hours otherwise, with further assistance chargeable at then-current rates;

3.2.5 not increase the Charges attributable to the capability during the window; and

3.2.6 send a reminder at the mid-point of the window and at 30 days before removal.

3.3 If the migration path is not ready. If Pensieve has not published a working migration path by the mid-point of the window, the removal date moves back by the number of days the documentation is late. Pensieve does not shift the cost of its own delay onto the Customer.

3.4 The deprecation register. Every deprecation is recorded in a public register at https://trust.pensievelabs.org/deprecations, with the announcement date, the removal date, the reason and the current status. Nothing is removed that is not on that register.

4.1 The honest position. Some capability depends on a system Pensieve does not control: a payment gateway, a messaging provider, a laboratory analyser interface, a national registry, a cloud service. If that operator withdraws, changes or breaks its interface, Pensieve cannot give six months' notice of a decision that is not Pensieve's.

4.2 What Pensieve commits to instead.

4.2.1 Pass on the whole of the notice Pensieve receives, within five (5) Business Days of receiving it.

4.2.2 Tell the Customer what Pensieve is doing about it, adapting the integration, finding an alternative, or neither, and by when.

4.2.3 Where an alternative exists, offer a migration path, with the assistance at 3.2.4.

4.2.4 Where none exists, say so plainly and early rather than implying one is coming.

4.2.5 Not charge for the work of adapting an integration to a like-for-like interface change. Where the operator's change requires materially more effort than the original integration, the work is chargeable by Change Order, and Pensieve says so before starting.

4.3 Charges. Loss of a third-party system does not of itself reduce the Charges; that position is in MSA-IN-001 clause 9.8, except where the integration was a priced line item on the Order Form, in which case that line is credited pro-rata from the date it stops working.

4.4 Not an excuse. 4 applies only where the third party's action is genuinely outside Pensieve's control. It does not apply where Pensieve chose to stop paying for, or stop maintaining, an integration.

5.1 Object. A Customer may object to a deprecation in writing within the first half of the notice window, stating the impact. Pensieve will respond within ten (10) Business Days, and will consider extending the window, providing additional migration assistance, or maintaining the capability for that Customer where it is technically feasible.

5.2 Terminate the affected part. Where a removal is material and adverse and is not resolved under 5.1, the Customer may terminate the affected part of the agreement, or the agreement as a whole where the capability was fundamental to it, by written notice given before the removal date, with:

5.2.1 a pro-rata refund of prepaid Charges for the terminated part from the removal date;

5.2.2 no early-termination charge, no clawback of any discount, and no liability for the remainder of the term for the terminated part; and

5.2.3 the full export and exit rights in WPR-GL-400 and MSA-IN-001 clause 22.

5.3 No penalty for leaving over a deprecation. A Customer that leaves because Pensieve withdrew something it was using is not in breach and is not treated as a defaulting customer.

5.4 Disagreement about materiality. Where the parties disagree on whether a change is material and adverse, the change is treated as material and adverse until the disagreement is resolved, and the notice window runs on that basis. Escalation follows MSA-IN-001 clause 25.

5.5 Service credits. Where a removal takes effect without the notice this Policy requires, the Customer is entitled to the remedy in POL-GL-063 in addition to 5.2.

6.1 Why this clause exists. Under DM-4, and to a lesser extent DM-3, the Customer decides when to install a new version. Pensieve cannot deprecate a version off the Customer's hardware. What Pensieve can do is state, in advance, how long each version is supported.

6.2 The commitment.

6.3 Minimum supported versions. Pensieve supports at least the current and the immediately preceding major version at all times, whatever the dates above produce.

6.4 Upgrade obligation and its limits. The Customer is expected to remain within the supported window. Pensieve provides the upgrade, the release notes, the compatibility statement and the rollback procedure. Pensieve will not force an upgrade onto Customer-controlled infrastructure, and will not disable a running deployment for being out of support.

6.5 Running an end-of-life version. A Customer may continue to run an end-of-life version. Pensieve will say plainly that it is unsupported, will not issue security fixes for it, and the availability service level ceases to apply to it. Pensieve will still deliver the export in WPR-GL-400 from it.

6.6 A security fix for an end-of-life version. Where a Critical vulnerability affects an end-of-life version still in use by a Customer, Pensieve will either issue a fix for that version or provide, at no charge, the upgrade and the migration assistance needed to move off it. Pensieve will not leave a hospital exposed and point at a support matrix.

7.1 The commitment. If Edsol Edtech Pvt. Ltd. resolves to cease operating the Pensieve platform as a business, it will:

7.1.1 notify every affected Customer in writing at least one hundred and eighty (180) days before the date the Platform ceases to be operated;

7.1.2 continue to operate the Platform and provide support at the contracted service level for the whole of that period;

7.1.3 not increase the Charges during that period;

7.1.4 provide the complete export in WPR-GL-400 on request during that period, at no charge and without waiting for termination;

7.1.5 keep the source-code escrow deposit current until the end of that period and cooperate with a release request under ADD-GL-011;

7.1.6 use reasonable efforts to identify and introduce a successor supplier or a migration path; and

7.1.7 publish the notice on the Trust Center as well as sending it, so that no Customer can be missed.

7.2 Where the detail lives. The mechanism (the escrow, the release events, the licence granted on release, the run-out funding, the handover pack, what happens to a live hospital, and the honest limitations of the arrangement) is the Business Failure Continuity Plan (DIS-GL-407). It is public. The contractual form is MSA-IN-001 clause 23.

7.3 Insolvency. 7.1 assumes Pensieve is able to choose. Where an insolvency event occurs, the escrow release mechanism in ADD-GL-011 and DIS-GL-407 is what operates, and DIS-GL-407 says so without pretending otherwise.

7.4 Deployment models DM-3 and DM-4. Where the Platform runs in the Customer's own cloud project or on the Customer's own hardware, a Pensieve sunset means the loss of support and updates, not the loss of the system or the data, both of which remain in the Customer's possession. The escrow licence extends to continuing to operate the deployed instance.

8.1 When. Pensieve may remove or disable a capability with less notice than 2 requires only where:

8.1.1 continuing to operate it presents a material and immediate security risk to Customer Data, to the Platform or to another tenant;

8.1.2 continuing to operate it would be unlawful, or breaches a binding order or a third party's rights; or

8.1.3 a third-party operator has withdrawn a dependency without notice, in which case 4 also applies.

8.2 Conditions. In every such case Pensieve will: remove the narrowest scope that addresses the cause; notify affected Customers at the time of the removal, with the reason; publish the removal on the deprecation register within one (1) Business Day; provide a workaround where one exists; and restore the capability as soon as the cause is resolved.

8.3 Not a general power. 8 is not a route around 2. A commercial or product-strategy reason is never an emergency. Where Pensieve invokes this clause, it records the ground relied on, and a Customer may challenge it under MSA-IN-001 clause 25.

8.4 Rights preserved. An emergency removal that is material and adverse still gives the Customer the rights at 5.2.

The following are not capable of deprecation under this Policy, and Pensieve will not remove, degrade, condition or charge for them:

9.1 the Customer's ability to export its own data, in the scope and formats in WPR-GL-400 and DIS-GL-401;

9.2 read access to the Customer's own clinical records for the purpose of patient care;

9.3 the audit log of access to the Customer's own tenant, for the retention period held; and

9.4 the Certificate of Data Deletion and the export documentation on exit.

These survive deprecation, end of life, sunset, suspension, dispute and insolvency to the extent Pensieve is able to perform at all.

10.1 How notice is given. By email to the Customer's notified contacts under MSA-IN-001 clause 27, by in-product notification where the deployment model permits, and by publication on the deprecation register and the Trust Center. The notice period runs from the email.

10.2 Change and release practice. Ordinary release communication, release notes and change windows are governed by DIS-GL-031 and SLA-GL-001. This Policy governs removal, not release.

10.3 Review. This Policy is reviewed annually, and on any change to the deployment models or the supported version scheme. The review date is 31 July 2027. A change to this Policy that reduces a notice period does not apply to a capability already in use by a Customer at the date of the change.