Scenario 4 is the one that matters. In scenarios 1 to 3 Pensieve, or someone contractually bound to step into Pensieve's place, is still able to act. In scenario 4 Pensieve's promises are worth what an insolvency estate says they are worth. Everything in this plan is therefore designed so that the hospital's position does not depend on Pensieve being able to act at the moment it matters.

Read that ranking honestly. The strongest protection is the one the hospital can take unilaterally, today, without Pensieve's cooperation. The weakest is the promise. Most vendors present the ranking the other way round.

3.1 Notice. If Pensieve resolves to cease operating the Platform as a business, every affected customer is notified in writing at least one hundred and eighty (180) days before the date the Platform ceases to be operated. The notice is also published on the Trust Center so that no customer can be missed.

3.2 What continues during the 180 days.

3.3 Sequencing. Pensieve will notify customers before it notifies the market, and will not schedule the cessation date to fall inside a customer's known peak period, an accreditation assessment, a financial year end, or a scheduled migration, where it can avoid it.

3.4 Order of shutdown. Production services are the last thing to be switched off. Marketing, sales, new-customer onboarding and non-production environments go first.

3.5 Funding. Pensieve maintains its financial planning so that the run-out at 3.2 can be met from available resources; that is, so that the cost of operating the infrastructure and retaining the people required for 180 days is covered by cash and receivables rather than by new sales. The current position is stated in the going-concern statement (STM-GL-033), which is available under non-disclosure with the audited financial statements (REG-IN-023).

3.6 The limit of 3.5. A run-out plan funded from available resources is a plan, not a guarantee. If the reason Pensieve is winding down is that the resources are gone, 3 becomes scenario 4 and 4 is what operates. This is said here rather than discovered later.

4.1 What escrow is for. So that a hospital can keep running the Platform, or have someone run it, when Pensieve cannot, including when an insolvency process means Pensieve has no say in the matter. The deposit is held by an independent escrow agent under a tri-party agreement (ADD-GL-011) between Pensieve, the agent and the beneficiary hospital.

4.2 What is deposited.

• The complete source code of the Platform.
• Build scripts, dependency manifests and lock files.
• Deployment automation and infrastructure-as-code definitions.
• Environment configuration templates, with secrets excluded and their required shape documented.
• Database schema and migration scripts.
• The build and recompilation instructions necessary for a reasonably skilled person to build and deploy the Platform without further assistance.
• The technical documentation set and the data dictionary.
• The list of third-party components and their licences, and the software bill of materials.
• The names and roles of the third-party services the running Platform depends on, so a beneficiary knows what accounts it must open.

4.3 What is not deposited, and why. Customer Data is not deposited: it is not Pensieve's to deposit, and the hospital already has it under 5. Production secrets, keys and credentials are not deposited, because an escrow deposit is not a safe place for them; their shape and rotation procedure are documented instead.

4.4 Cadence. The deposit is updated on the cadence recorded in ADD-GL-011, and in any event at each major release and not less than every six (6) months. Each deposit is accompanied by a manifest with a file inventory and hashes.

4.5 Verification. Pensieve supports the agent's verification service at the level recorded in ADD-GL-011, up to and including a build verification in which the agent, or a third party the agent engages, confirms that the deposited materials compile and produce a deployable artefact. An unverified escrow deposit is close to worthless, and a hospital evaluating this arrangement should ask which verification level has actually been performed and when. Pensieve will answer with a date.

4.6 Becoming a beneficiary. A hospital becomes a beneficiary by executing the accession joinder to ADD-GL-011. It is a short joinder, not a fresh negotiation. Where the Order Form records that Pensieve bears the agent's accession fee, Pensieve bears it.

4.7 Release events. The agreement provides for release of the deposit to the beneficiary on:

4.7.1 an insolvency event in relation to Pensieve;

4.7.2 Pensieve ceasing to carry on the business of supporting the Platform;

4.7.3 Pensieve's failure to provide support in material breach of the agreement, uncured after notice; or

4.7.4 assignment of the agreement to a person that does not assume Pensieve's obligations.

4.8 Licence on release. On a valid release, the beneficiary receives a non-exclusive, non-transferable, perpetual, irrevocable licence to use, compile, maintain, correct and modify the released materials solely to support its own use of the Platform for its internal business purposes, and to engage a third party under written confidentiality obligations to do so. It does not permit distribution, resale or the provision of services to any third party. The released materials remain Pensieve's confidential information.

4.9 Escrow and insolvency. A tri-party escrow held by an independent agent is designed to survive the depositor's insolvency, because the beneficiary's right to release arises under its own contract with the agent rather than out of the estate. That is the design intention and it is why escrow ranks above the run-out commitment at 2. [UNVERIFIED: the treatment of an escrow release in an Indian insolvency proceeding under the Insolvency and Bankruptcy Code, 2016, and in particular the effect of a moratorium on a release request, should be confirmed with counsel before this document is relied on as definitive. Pensieve states the uncertainty rather than asserting a clean answer.]

5.1 The commitment. The hospital's data is the hospital's, at all times, in a form it can use, at no charge, however the relationship ends. The scope, formats, timing, documentation and integrity evidence are the Exit & Data Portability Commitment (WPR-GL-400) and the format specification (DIS-GL-401).

5.2 Why a promise is not enough here. A promise to deliver an export is only as good as the party making it. If Pensieve is in an insolvency process, nobody at Pensieve may be in a position to run an export on request. The plan therefore does not rely on that request being answered.

5.3 The three mechanisms that do not depend on Pensieve acting at the moment of failure.

5.3.1 Self-service export. The Platform provides a self-service export the hospital runs itself, at any time, without asking Pensieve. It is not gated on a support ticket, an approval, an invoice or a notice period.

5.3.2 Scheduled export to storage the hospital controls. Pensieve will configure, at no charge and on request at any time, a scheduled export of the hospital's complete data set to a storage location the hospital owns and pays for: its own cloud bucket, its own on-premise storage, or an appliance in its own server room. Cadence is the hospital's choice; daily is available. Once configured, a current copy of the hospital's data sits outside Pensieve's control permanently.

This is the single most effective thing a hospital can do about supplier risk, it costs nothing, and Pensieve recommends every customer turn it on at go-live. It is on the go-live checklist for that reason.

5.3.3 The deployment model. Under DM-3 and DM-4 the data is already in the hospital's environment and 5.3.2 is a formality.

5.4 What the export contains. Structured records in documented non-proprietary formats with referential keys preserved; clinical records as HL7 FHIR R4 resources where representable; imaging in DICOM; documents in their original formats with an index; a human-readable PDF rendering of each encounter sufficient to answer a medico-legal request with no software at all; configuration and application definitions; audit logs; a data dictionary and entity-relationship description; and a manifest with per-file SHA-256 hashes and record counts. Full detail is in WPR-GL-400 clause 3.

5.5 The rendered-record point. 5.4 includes a PDF rendering of every encounter because a hospital in the middle of a supplier failure needs to be able to answer a court, a patient and a regulator without first standing up a system to read a database export. That is the artefact that keeps a hospital lawful on day one of a bad week.

5.6 No lien, no set-off, no conditions. Pensieve waives any lien, right of retention or right of set-off over Customer Data. The export is not conditional on payment, on the resolution of a dispute, on a release or waiver, or on the return of equipment. This is unconditional and is within the never-limited category at POL-GL-050 clause 18.1.

6.1 The honest statement. Edsol Edtech Pvt. Ltd. is a small company. A small company has key-person risk, and Pensieve does not pretend otherwise. The relevant question is not whether the risk exists but what has been done about it.

6.2 What has been done.

6.3 Why the open items are shown. A continuity document that lists only what is in place is a marketing document. The two open items above are real, they are on the founder's own risk register, and a hospital is entitled to weigh them. The current position is maintained in the Key Person Dependency & Succession Statement (STM-GL-324).

6.4 The effect on the hospital. Loss of a key person degrades Pensieve's ability to develop and support the Platform. It does not, of itself, stop a running deployment, does not affect the data guarantee at 5, and does not affect the escrow at 4. Where it makes Pensieve unable to provide support in material breach of the agreement, it becomes a release event under 4.7.3.

7.1 A change of control is not, of itself, a release event. An acquisition can be the best outcome available: the Platform continues, with more resources behind it.

7.2 The conditions. On a change of control or a transfer of the business:

7.2.1 the acquirer must assume Pensieve's obligations under the customer's agreement, including this plan, WPR-GL-400 and POL-GL-064;

7.2.2 Pensieve notifies each customer within thirty (30) days of completion, identifying the acquirer;

7.2.3 the escrow arrangement transfers with the business and the deposit remains current;

7.2.4 an assignment to a person that does not assume Pensieve's obligations is a release event under 4.7.4; and

7.2.5 the customer's rights on change of control in MSA-IN-001 clause 28.7 apply, including the right to terminate and exit under WPR-GL-400 where the acquirer is a competitor of the customer or is a person the customer is prohibited from dealing with.

7.3 What Pensieve will not do. Pensieve will not use a change of control to increase Charges outside POL-GL-065, to withdraw a capability outside POL-GL-064, or to make the data guarantee at 5 conditional on accepting new terms.

This is the sequence a hospital should expect, written so that a Chief Operating Officer can plan against it. Durations assume DM-1 or DM-2, which is the worst case.

8.1 In an insolvency, the timeline compresses and control passes. The 180-day sequence assumes an orderly wind-down. In an insolvency the notice may be days rather than months and the decisions are an insolvency professional's. That is precisely why 5.3.2, the daily export to storage the hospital owns, is the recommendation that matters. A hospital running that export loses, at worst, one day of data and the running system; it does not lose its records.

8.2 Clinical continuity in the interim. The hospital's own documented clinical downtime procedures (MSA-IN-001 clause 8.7 and POL-GL-050 clause 16.5) are what keep patient care safe during any gap. They are the hospital's obligation, they are independent of any service level, and this plan does not substitute for them.

8.3 What the hospital can still do with the export on day one. Answer a medico-legal request from the PDF rendering. Continue billing and claims from the structured export. Load clinical records into a FHIR- capable successor. View images from the DICOM export in any standard viewer. None of that requires Pensieve to exist.

9.1 Pensieve maintains professional indemnity and cyber liability cover. The certificates are published at the NDA-accepted tier as REG-IN-025 and REG-IN-026, and the schedule of limits is ADD-GL-021.

9.2 What insurance does and does not do here. Insurance responds to a claim: a loss caused by a Pensieve error or a security incident. It does not keep a platform running, and it is not a continuity mechanism. It is listed in this document only so that nobody mistakes it for one.

Stated in one place, without hedging, because a continuity plan with no limitations section is not credible.

10.1 It does not warrant solvency. Pensieve may fail. This plan says what happens then; it does not say it will not happen.

10.2 Contractual promises are weakest in an insolvency. The run-out at 3 depends on Pensieve being able to perform. An insolvency estate is not obliged to continue performing an unprofitable contract, and a moratorium may restrict what anyone can do. The escrow and the hospital's own data copy are the mechanisms that do not depend on that.

10.3 An escrow deposit is source code, not a running hospital system. Releasing it gives the hospital the materials to build and operate the Platform. Doing so requires competent engineers, cloud accounts, budget and time. A 60-bed hospital will not do this itself, and should assume it needs an incoming supplier or a systems integrator engaged to do it under the licence at 4.8.

10.4 Escrow release is not instant. A release request is a process with the agent: notice, a period for the depositor to object, and verification. It takes weeks, not hours. It is not a disaster-recovery mechanism and must not be planned as one.

10.5 The escrow does not include third-party services. The Platform depends on cloud services and other third-party providers listed in DIS-GL-009. A beneficiary that builds from the deposit must open its own accounts with those providers and bear their cost.

10.6 The escrow does not include Pensieve's people. Code without the people who wrote it is harder to operate than code with them. The verification level at 4.5 and the documentation at 4.2 reduce that gap; they do not close it.

10.7 DM-3 and DM-4 reduce the exposure but do not remove it. The system keeps running, but without updates, without security patches and without support. A deployment that stops receiving security patches becomes a risk over months, not years, and the hospital must plan a migration rather than treat the running deployment as a permanent answer.

10.8 Two open items are disclosed at 6.2 (the named alternates and key-person insurance) rather than concealed.

10.9 Escrow treatment under Indian insolvency law is not settled in this document. See the marker at 4.9.

10.10 This plan is a disclosure, not a warranty. The contractual force comes from MSA-IN-001 clause 23, WPR-GL-400, POL-GL-064 and ADD-GL-011. Where this document and one of those differ, the executed contract governs.

Listed briefly, because the mechanisms above matter more than the mitigation.

11.1 Pensieve runs a low fixed-cost operation on managed cloud services, so that the cost of continuing to operate an existing customer's deployment is small relative to the revenue it produces. A deployment that is cheap to run is a deployment that survives a bad quarter.

11.2 The commercial model takes a fixed platform fee in advance, which means revenue is collected before the cost of delivery is incurred rather than after.

11.3 Pensieve does not take on a deployment it cannot support with the people it has. Where a prospective engagement would breach that, Pensieve declines or sequences it.

11.4 Financial statements are prepared and audited on the statutory cycle, and are available under non-disclosure as REG-IN-023 with the going-concern statement STM-GL-033. A hospital's finance director is entitled to look at them and Pensieve does not treat the request as unusual.

11.5 Concentration risk is tracked: the proportion of revenue from any single customer, and the proportion of cost in any single supplier.

Pensieve would rather a customer did these than took the plan on trust.

Items 1, 2, 4 and 5 cost nothing and are worth more than every commitment in this document.

13.1 Export test. Pensieve performs a full export-and-verify test for each production customer at least annually, and records the result. The evidence is available to that customer on request.

13.2 Escrow currency. The date of the most recent deposit and the most recent verification are stated on request and are recorded in the Business Continuity Test Register (REG-GL-211).

13.3 Restore test. Backup and restore testing, with the measured recovery times, is covered by DIS-GL-014 and DIS-GL-015, and is not restated here.

13.4 Review. This document is reviewed at least annually, and on any material change to Pensieve's financial position, ownership, escrow arrangement or key-person position. The review date is 31 January 2027. Where a material change occurs, this document is updated before the next sales conversation, not after it.