#Service Level Agreement

1.1 Definitions in the MSA. Terms defined in the Master Services Agreement (MSA-IN-001, the "MSA") have the same meaning in this Agreement unless this Agreement gives them a different meaning expressly. Terms defined in this Agreement have the same meaning wherever they are used in the MSA and in any document incorporated into it.

1.2 Definitions specific to this Agreement.

**"Ancillary Function"** means a function of the Platform that is not a Core Function, including analytical dashboards, batch and scheduled reports, bulk data export, scheduled outbound communications, archival retrieval, and any function expressly designated as an Ancillary Function on the Order Form. Ancillary Functions carry no availability target.

**"Availability"** means the state in which the Core Functions are Available, determined in accordance with 4.

**"Available"** means, in respect of a Core Function, that a Service Probe directed at that Core Function completes successfully within the Probe Timeout and returns a response that is not an error, in accordance with 4.3.

**"Core Function"** means each of the Platform functions listed in 3.2. Core Functions are the functions on which the availability commitment, the Service Credits and the Severity 1 definition operate.

**"Credit Reference Amount"** means the amount against which a Service Credit is calculated, determined under 8.3.

**"Disaster"** means an event that renders the production environment for the Customer's tenancy incapable of restoration in place within the Recovery Time Objective, and that Pensieve declares as a Disaster in accordance with 9.5.

**"Downtime Minute"** means a minute within a Service Month that is counted as unavailable under 4.4.

**"Emergency Maintenance"** means maintenance that Pensieve must perform without the notice period required for Planned Maintenance in order to preserve the security, integrity or continued operation of the Platform, as described in 10.4.

**"Excluded Event"** means an event listed in 4.6, the duration of which is excluded from the calculation of the Monthly Uptime Percentage.

**"Incident"** means an unplanned interruption to, or reduction in the quality of, the Platform or the Services, or the failure of a component of the Platform, whether or not it has yet affected a user.

**"Initial Response"** means the first substantive communication from a named Pensieve engineer or support specialist to the Customer's reporting contact in relation to a Ticket, which acknowledges the Ticket, confirms or corrects the Severity Level, states what is known and states the immediate next step. **An automated acknowledgement of receipt is not an Initial Response.**

**"Monthly Uptime Percentage"** means the percentage calculated for a Service Month under 4.5.

**"Planned Maintenance"** means maintenance performed within a Maintenance Window and notified in accordance with 10.

**"Platform Boundary"** means the network ingress point at which a request enters infrastructure that Pensieve operates for the Customer's tenancy. Availability is measured at the Platform Boundary; nothing on the Customer's side of it is measured.

**"Recovery Point Objective"** or "RPO" means the maximum period of data, measured backwards from the moment a Disaster is declared, that may be lost on recovery, as committed for the applicable Deployment Model in 9.

**"Recovery Time Objective"** or "RTO" means the maximum period, measured from the declaration of a Disaster under 9.5, within which Pensieve commits to restore the Core Functions to a working state for the applicable Deployment Model in 9.

**"Resolution"** means that the reported condition no longer occurs, whether by correction of the cause, by permanent configuration change, or by delivery of a correction to the Platform, and that the Customer has confirmed the Ticket may be closed or has been treated as having confirmed under 7.9.

**"Service Credit"** means a credit calculated under 8.

**"Service Month"** means a calendar month, measured in the Service Time Zone, during any part of which the Platform is in production use by the Customer. The first Service Month begins on the date of the Production Go-Live Certificate (CRT-GL-007).

**"Service Probe"** means an automated synthetic transaction executed by Pensieve's monitoring system against a Core Function, from at least two independent network locations, at intervals not exceeding sixty (60) seconds, as described in 4.3.

**"Service Report"** means the monthly report issued under 11.2.

**"Service Time Zone"** means the time zone recorded on the Order Form as Deal SLA service time zone, being the local time zone of the Customer's principal site. Every period, window and clock in this Agreement is measured in the Service Time Zone.

**"Severity Level"** means Severity 1, Severity 2, Severity 3 or Severity 4, determined in accordance with 7.2 and Schedule B.

**"Support Center"** means the support property operated by Pensieve at [TO BE SUPPLIED], through which Tickets are raised and tracked and through which help articles and operating documentation are published.

**"Support Hours"** means the hours recorded on the Order Form as Deal support hours, being either Business Hours Support or 24×7 Support as described in 7.4.

**"Ticket"** means a record raised in the Support Center in respect of an Incident, a service request or a question.

**"Workaround"** means a temporary means, communicated by Pensieve to the Customer, by which the Customer's users can continue the affected clinical or administrative process at an acceptable level of effort, notwithstanding that the underlying condition persists.

1.3 Interpretation.

1.3.1 A reference to a period of hours in relation to a Severity 1 or Severity 2 matter is a reference to elapsed clock hours, not to business hours, unless the table expressly says "Business Hours".

1.3.2 Where a target is expressed against a Business Day or Business Hour, and the Ticket is raised outside Support Hours, the clock starts at the beginning of the next period of Support Hours.

1.3.3 Percentages of availability are calculated to two decimal places and are not rounded up.

1.3.4 A reference to a Deployment Model is a reference to the model recorded on the Order Form as DM-1.

1.3.5 Headings and the publication note are for convenience and do not affect construction.

2.1 Incorporation. This Agreement is incorporated into the MSA under clause 2.2 of the MSA and forms part of it. It has no independent existence and terminates when the MSA terminates.

2.2 Precedence. On the subject matter of availability, support, incident response, recovery objectives and Service Credits, this Agreement prevails over the MSA and over every other document forming the Agreement other than the Order Form and, on the processing of Personal Data, the Data Processing Agreement (DPA-GL-001). Where ADD-GL-008 (On-Premise Supplement) or ADD-GL-009 (Delegated Cloud Access & Administration Agreement) is incorporated, and it states a variation of a matter in this Agreement for that Deployment Model, the variation prevails for that Deployment Model.

2.3 What this Agreement does not govern. This Agreement does not govern: the technical architecture of backup and recovery, which is described in DIS-GL-014 and DIS-GL-015; the information-security controls applied to the Platform, which are in the Security Addendum (ADD-GL-001); the handling of a Personal Data Breach, which is in DPA-GL-001 clause 10; the vulnerability-management and patching regime, which is in ADD-GL-001 and DIS-GL-017; or the scope of chargeable professional services, which is in the Statement of Work (ORD-GL-002).

2.4 Relationship to DIS-GL-014. DIS-GL-014 describes how backup and recovery work. 9 of this Agreement states what Pensieve contractually commits to. Where the two differ, 9 governs the commitment and DIS-GL-014 governs the description.

2.5 Commencement of service levels. The availability commitment, the Service Credits and the recovery objectives take effect from the date of the Production Go-Live Certificate (CRT-GL-007). The support commitments in 7 take effect from the date of the Order Form. During the Hypercare period described in the Order Form, Pensieve provides the enhanced coverage stated there in addition to, and not in substitution for, this Agreement.

2.6 No service level during evaluation. Where the Customer is using the Platform under a Pilot / Proof-of-Value Agreement (ADD-GL-013), in a non-production environment, or under Beta or Early Access terms (POL-GL-058), no availability commitment, Service Credit or recovery objective applies. This is stated in each of those instruments and is repeated here so that it cannot be missed.

3.1 The principle. Pensieve commits to what Pensieve controls. The four Deployment Models place control in different hands, and the commitment follows control rather than following the Customer's preference or Pensieve's commercial convenience.

3.2 Core Functions. The following are the Core Functions. They are the functions whose failure stops a hospital, and they are the only functions the availability commitment measures.

3.3 Everything else is an Ancillary Function. Analytics, dashboards, scheduled and batch reports, bulk export, outbound message dispatch, archival retrieval and administrative configuration screens are Ancillary Functions. Pensieve monitors them, reports on them in the Service Report, and treats their failure as an Incident at the appropriate Severity Level, but they do not enter the availability calculation. This is stated because an availability figure that includes a nightly analytics job is not a figure a hospital can use.

3.4 Availability targets.

The Service Level Tier for this Agreement is Deal SLA tier and the resulting target is Deal SLA availability target.

3.5 Conditions attaching to the Critical Tier. The Critical Tier is available only where the Order Form records all of the following, and it lapses to the Standard Tier for any Service Month in which any of them ceases to be true:

3.5.1 the database is provisioned in a high-availability configuration with automatic failover across at least two availability zones;

3.5.2 the application tier is provisioned with a minimum warm instance count of not less than one and with automatic scaling enabled;

3.5.3 the Customer bears the incremental infrastructure cost of 3.5.1 and 3.5.2, whether directly under DM-3 or through the Charges under DM-1; and

3.5.4 for DM-3, the Customer's cloud project carries a support plan from the cloud provider of a level not lower than the provider's standard production tier, and sufficient quota headroom.

3.6 Why not a higher number. Pensieve does not offer an availability target above 99.9% per Service Month. The Platform runs on managed cloud services whose own published service levels are of the order of 99.95% per region per month, and a supplier cannot responsibly commit above the level of the infrastructure beneath it once its own release, configuration and dependency risk is added. A vendor offering 99.99% on a single-region deployment is either not measuring it or not honouring it. (Cloud Run SLA)

3.7 No commitment is made about the Customer's side of the boundary. Availability is measured at the Platform Boundary. The hospital's local area network, wide-area links, internet service, Wi-Fi, endpoint devices, browsers, printers, label printers, card readers, biometric devices, local DNS and local power are outside the Platform Boundary and outside every commitment in this Agreement. Pensieve will assist in diagnosing a problem on that side of the boundary under 12.3, and that assistance does not convert the problem into a Pensieve service-level failure.

4.1 The commitment. For each Service Month, and for DM-1, DM-2 and DM-3 only, Pensieve will achieve a Monthly Uptime Percentage not less than the target stated in 3.4 for the Service Level Tier and Deployment Model recorded on the Order Form.

4.2 What "unavailable" means in practice. A Core Function is unavailable when a competent user of the hospital, working from a device and network that are functioning normally, cannot complete the transaction that Core Function exists to perform, because of a failure at or behind the Platform Boundary. Slowness severe enough that the transaction cannot complete within the Probe Timeout is unavailability. Slowness that is merely irritating is a performance matter under 11, not unavailability.

4.3 Measurement method.

4.3.1 Instrument. Availability is measured by Service Probes. A Service Probe executes a synthetic transaction against each Core Function, an authenticated, read-only or write-then-rollback operation against a dedicated monitoring tenancy or monitoring record, never against live patient data, from at least two independent network locations, at intervals not exceeding sixty (60) seconds.

4.3.2 Probe Timeout. The Probe Timeout is ten (10) seconds from request to complete response at the Platform Boundary. A Service Probe that does not complete within the Probe Timeout is a failed probe.

4.3.3 Error rate as a second instrument. Independently of the Service Probes, Pensieve measures the proportion of real user requests to Core Functions that return a server-side error, or an application error indicating that the transaction did not complete, measured per minute at the Platform Boundary. A minute in which that proportion exceeds five per cent (5%) of Core Function requests, where there are at least twenty (20) such requests in the minute, is a failed minute.

4.3.4 Retention of the record. Probe results, error-rate series and the derived Downtime Minutes are retained for not less than thirteen (13) months and are made available to the Customer on request and in the Service Report. Where the Processing is subject to Indian law these records are retained within India, consistent with ADD-GL-001 clause 9 and DIS-GL-034.

4.4 Downtime Minute. A minute in a Service Month is a Downtime Minute if, in that minute:

4.4.1 two or more consecutive Service Probes against the same Core Function fail from at least two independent probe locations; or

4.4.2 the minute is a failed minute under 4.3.3; or

4.4.3 the Core Function is knowingly taken out of service by Pensieve otherwise than as Planned Maintenance or Emergency Maintenance properly notified under 10;

and the minute does not fall within an Excluded Event.

A single failed probe from a single location is not a Downtime Minute. That tolerance exists so that a transient fault in the monitoring path is not recorded as an outage. It is not a grace period for the Platform.

4.5 Calculation. For each Service Month:

                    (Total Minutes − Excluded Minutes − Downtime Minutes)
Monthly Uptime  =   ─────────────────────────────────────────────────────  × 100
   Percentage             (Total Minutes − Excluded Minutes)

where Total Minutes is the number of minutes in the Service Month, Excluded Minutes is the number of minutes falling within an Excluded Event, and Downtime Minutes is the number of Downtime Minutes. Where more than one Core Function is unavailable in the same minute, the minute counts once; Downtime Minutes are not multiplied by the number of Core Functions affected.

4.6 Exclusions. The following are Excluded Events. Minutes falling within them are removed from both the numerator and the denominator in 4.5 and do not give rise to a Service Credit.

4.7 The BYOK/BYOC exclusion, stated plainly. The Platform connects to external systems using the Customer's own credentials, on the Customer's own authority, under the BYOK/BYOC Credential Handling Addendum (ADD-GL-007). Pensieve is not a participant in those systems and cannot make them work. If the ABDM gateway is down, if the payment gateway rejects a batch, if an insurer's portal changes its authentication, if the SMS provider throttles, or if a credential the Customer supplied has expired, the Platform is not unavailable; the external system is. Pensieve will detect the condition, raise it as an Incident at the appropriate Severity Level, tell the Customer what it observes, and assist the Customer in dealing with the external provider. That is the commitment. It is not an availability commitment and it does not attract a Service Credit.

4.8 Burden and evidence. Pensieve bears the burden of demonstrating that a period falls within an Excluded Event, and will identify each Excluded Event, with its duration and cause, in the Service Report for the Service Month in which it occurs. An Excluded Event that is not identified in that Service Report, and not notified to the Customer within thirty (30) days of the end of that Service Month, may not afterwards be relied on to reduce a Service Credit for that Service Month.

4.9 The Customer's own evidence. Where the Customer's records show unavailability that Pensieve's measurement does not, the Customer may submit those records with a Service Credit claim under 8.5. Pensieve will investigate, will provide the underlying probe and error-rate series for the period in question, and will adjust the Monthly Uptime Percentage where the Customer's evidence demonstrates a Downtime Minute that the measurement missed. The Customer is not required to treat Pensieve's instrumentation as conclusive.

4.10 Status page. Pensieve maintains a status page at Pensieve status page URL showing current state, open Incidents and Incident history. The status page is a communication tool. It is not the measurement instrument, and an entry on it, or the absence of one, neither creates nor removes a Downtime Minute.

This clause applies only where the Deployment Model is DM-3. It is retained in the published standard form so that a Customer evaluating DM-3 can read the commitment before selecting the model.

This clause applies only where the Deployment Model is DM-4. It is retained in the published standard form so that a Customer considering an on-premise deployment learns, before selecting it, that the availability service level will not apply.

7.1 How an Incident is raised.

7.1.1 Channels. The Customer raises a Ticket through the Support Center at [TO BE SUPPLIED], or by e-mail to info@pensievelabs.org, which creates a Ticket automatically. For a Severity 1 matter the Customer may in addition telephone the emergency support number [TO BE SUPPLIED], and should do so. A telephone report is recorded as a Ticket by Pensieve within fifteen (15) minutes; the response clock runs from the telephone call, not from the Ticket record.

7.1.2 Who may raise. Any of the Customer's Authorised Support Contacts listed in Schedule C may raise a Ticket at any Severity Level. The Customer may change that list at any time by notice to Pensieve, which takes effect on the next Business Day.

7.1.3 What a Ticket should contain. The affected Core Function or Ancillary Function; the site, department and users affected; the proposed Severity Level; the time the condition began; what the user was doing; any error message; and whether a Workaround is in use. A Ticket that omits some of this is still a valid Ticket and the clock still runs; incomplete information may extend the time to Resolution and is dealt with under 7.6.3.

7.1.4 Pensieve-detected Incidents. Pensieve raises a Ticket itself when its monitoring detects an Incident, notifies the Customer's Authorised Support Contacts, and does not wait for the Customer to report it. The response clock for a Pensieve-detected Incident runs from detection.

7.2 Severity definitions. Severity is a measure of operational consequence to the hospital, not of technical difficulty. It is determined by what the hospital cannot do, and by when it cannot do it.

7.3 Severity in hospital terms. The following examples are binding on the classification of an Incident of the same character. The complete list is in Schedule B.

7.4 Support Hours.

7.4.1 Business Hours Support. Business Hours are 09:00 to 19:00 in the Service Time Zone, Monday to Saturday, excluding public holidays at the Customer's principal site as listed in Schedule C.

7.4.2 24×7 Support. Continuous coverage, every day of the year.

7.4.3 Severity 1 is always 24×7. Severity 1 Tickets are received, acknowledged and worked twenty-four hours a day, seven days a week, on every tier, including Business Hours Support. A hospital does not have business hours. The Support Hours recorded on the Order Form determine the treatment of Severity 2, Severity 3 and Severity 4 only.

7.5 Response, update and restoration targets.

7.6 How the targets operate.

7.6.1 Initial Response and Workaround are commitments; Resolution is a target. Pensieve commits to the Initial Response times and to the update cadence, and Service Credits attach to the Initial Response times for Severity 1 and Severity 2. Pensieve commits to apply continuous effort towards a Workaround and a Resolution and to the escalation in 7.7. Pensieve does not commit to a guaranteed time to Resolution, because the time required to correct an unknown defect cannot honestly be guaranteed in advance. The consequence of a Severity 1 that persists is dealt with by the restoration credit in 8.4.3 and, where failure is persistent, by the Customer's termination right in MSA clause 21.3.4.

7.6.2 Continuous effort on Severity 1. From the Initial Response until a Workaround is in place, Pensieve applies continuous effort to a Severity 1, without interruption for night, weekend or holiday, and does not reduce the effort applied without the Customer's agreement.

7.6.3 Pausing the clock. A target clock is paused only while Pensieve is waiting for the Customer to supply information, access, a decision or a test that Pensieve has requested in writing and that Pensieve reasonably requires in order to proceed, and only from the time of the request until the time it is answered. Pensieve will record each pause in the Ticket, with its start and end. Pensieve will not pause a Severity 1 clock in order to await information that it can obtain itself.

7.6.4 Unreachable Customer. Where a Severity 1 requires a decision, an authorisation or an on-site action by the Customer and none of the Customer's Severity 1 contacts in Schedule C is reachable after three attempts across two channels over thirty (30) minutes, the clock pauses until contact is re-established. Pensieve will record each attempt.

7.6.5 Severity reassessment. Either Party may propose a change of Severity Level at any time, with reasons recorded in the Ticket. Where a Workaround is delivered and accepted, a Severity 1 becomes a Severity 2 and the Severity 2 clocks apply to the remaining work. Pensieve will not reduce a Severity Level unilaterally over the Customer's objection; where the Parties disagree, the Customer's assessment governs the response obligation until the disagreement is resolved under 7.6.6, and Pensieve may record its dissent.

7.6.6 Disputed severity. A disagreement about Severity that is not resolved within two (2) hours for a Severity 1, or two (2) Business Days otherwise, is escalated to level E-3 in 7.7 and to the Customer's equivalent. It is not a dispute under MSA clause 25 unless it remains unresolved after that escalation.

7.6.7 Repeated misclassification. Where the Customer repeatedly raises Tickets at a Severity Level materially above their operational consequence, Pensieve may raise the matter at the quarterly service review under 11.5. It may not, on that ground, decline to respond to a Ticket at the Severity Level the Customer has assigned.

7.7 Escalation matrix.

7.7.1 Automatic escalation. Escalation is automatic and does not require the Customer to ask. The times below run from the Initial Response for Severity 1 and Severity 2, and from the raising of the Ticket otherwise.

7.7.2 Customer-initiated escalation. The Customer may escalate any Ticket to any level at any time, without waiting for the automatic trigger and without giving a reason, by marking the Ticket for escalation in the Support Center or by telephoning [TO BE SUPPLIED]. Pensieve will acknowledge a customer-initiated escalation within thirty (30) minutes for a Severity 1 and within four (4) Business Hours otherwise.

7.7.3 Named individuals. The individuals occupying each Pensieve escalation level, and the Customer's corresponding contacts, are named with telephone numbers and e-mail addresses in Schedule C. Both Parties will keep Schedule C current; a change takes effect on notice and does not require an amendment to this Agreement.

7.7.4 Escalation is not a substitute for work. Escalation adds authority and attention to an open Ticket. It does not transfer the Ticket, does not restart any clock and does not reduce the effort applied.

7.8 Major incident management (Severity 1). On declaring a Severity 1, Pensieve will:

7.8.1 appoint a named Incident Commander who owns the incident until closure and who is not simultaneously performing the technical remediation;

7.8.2 open a communication bridge (a telephone or video channel) and give the Customer's Severity 1 contacts joining details in the Initial Response;

7.8.3 issue written updates at the cadence in 7.5, each stating what is known, what is not yet known, what is being done, what the Customer should do, and when the next update will come;

7.8.4 post the Incident to the status page at Pensieve status page URL where more than one customer is affected, and issue a Service Degradation Notice (NTC-GL-007) where the Incident is expected to exceed two (2) hours;

7.8.5 where the Incident is or may be a Personal Data Breach, run the notification obligations in DPA-GL-001 clause 10 in parallel and not in sequence: the four-hour notification there is not deferred by anything in this Agreement; and

7.8.6 issue a root-cause report within ten (10) Business Days of closure, containing the timeline, the technical cause, the contributing factors, what was done, what will be done to prevent recurrence, and by when, with a named owner for each preventive action.

7.9 Closure. Pensieve proposes closure of a Ticket when it believes the Resolution is complete. The Ticket closes when the Customer confirms, or five (5) Business Days after the proposal if the Customer has not responded, except that a Severity 1 or Severity 2 Ticket closes only on the Customer's express confirmation. A Ticket closed under this clause may be reopened within thirty (30) days if the same condition recurs, and the reopened Ticket carries the original Severity Level.

7.10 The Customer's obligations. The service levels in this clause are conditional on the Customer:

7.10.1 maintaining a current Schedule C, including at least two contacts reachable for a Severity 1 at any hour;

7.10.2 raising Tickets through the channels in 7.1.1 rather than through individual Pensieve personnel, personal messaging or social channels: a request made outside those channels does not start a clock;

7.10.3 providing the information, access, screenshots, sample records and test participation Pensieve reasonably requests;

7.10.4 ensuring that its users complete the training provided under the Statement of Work, and that supervisor-level users are available during the hours the hospital operates;

7.10.5 not making, and not permitting a third party to make, an unnotified change to the Customer Environment, the Customer Infrastructure or a Customer-controlled integration; and

7.10.6 applying updates to browsers, endpoints and locally installed components within thirty (30) days of Pensieve notifying that they are required.

8.1 Character of a Service Credit. A Service Credit is a reduction of the Charges. It is an agreed and proportionate allocation of the commercial consequence of a service-level failure, arrived at between commercial parties, and the Parties record that it operates as a maximum for the purposes of section 74 of the Indian Contract Act, 1872, and not as a penalty. It is not an admission of liability, is not a liquidated estimate of the Customer's loss, and does not preclude the remedies preserved by 8.9.

8.2 Availability credits. Where the Monthly Uptime Percentage for a Service Month falls below the applicable target, the Customer is entitled, on claim under 8.5, to a Service Credit calculated as a percentage of the Credit Reference Amount for that Service Month.

8.3 Credit Reference Amount. The Credit Reference Amount for a Service Month is:

8.3.1 where the Platform Fee is payable monthly, the Platform Fee for that Service Month;

8.3.2 where the Platform Fee is payable for a longer period, the Platform Fee for that period divided by the number of months in it;

8.3.3 where Deal commercial model is VALUE_SHARE and no Platform Fee is payable, the amount recorded on the Order Form as Deal SLA credit reference amount, which the Parties will record on the Order Form precisely so that this clause is capable of operation; and

8.3.4 in every case, exclusive of Taxes, of infrastructure charges borne by the Customer under DM-3 and DM-4, of any Value Share, and of any one-time Deployment & Activation Fee.

8.4 Response and restoration credits.

8.4.1 Severity 1 Initial Response. For each Severity 1 Ticket in a Service Month for which Pensieve fails to make the Initial Response within thirty (30) minutes: 2% of the Credit Reference Amount.

8.4.2 Severity 2 Initial Response. For each Severity 2 Ticket in a Service Month for which Pensieve fails to make the Initial Response within the applicable target: 1% of the Credit Reference Amount.

8.4.3 Prolonged Severity 1: the restoration credit. For each Severity 1 Ticket that remains without an accepted Workaround for more than eight (8) continuous hours measured from the Initial Response: 5% of the Credit Reference Amount, and a further 5% for each further complete period of eight (8) hours, subject to a maximum of 15% in respect of any single Ticket. Time during which the clock is paused under 7.6.3 or 7.6.4 does not count, and time within an Excluded Event does not count.

8.4.4 DM-4. Under DM-4, 8.4.1 and 8.4.2 apply and nothing else in this clause does.

8.4.5 Aggregate limit on response and restoration credits. Credits under 8.4 are limited in aggregate to 15% of the Credit Reference Amount for the Service Month, before the overall cap in 8.6 is applied.

8.5 Claiming.

8.5.1 How. The Customer claims a Service Credit by written request to info@pensievelabs.org, copied to the Support Center Ticket where one exists, identifying the Service Month, the ground of the claim and, where the claim relies on the Customer's own records, those records.

8.5.2 By when. Within thirty (30) days of the issue of the Service Report for the Service Month concerned, or within thirty (30) days of the end of the Service Month where no Service Report has been issued. A claim made later is not payable, save that a claim is not out of time where the ground for it was not disclosed in the Service Report and could not reasonably have been known to the Customer within that period.

8.5.3 Pensieve's response. Pensieve will accept or reject a claim in writing, with reasons and with the underlying measurement data, within ten (10) Business Days. A claim not answered within that period is treated as accepted.

8.5.4 Pensieve applies a credit without a claim where it can. Where Pensieve's own Service Report shows that the Monthly Uptime Percentage fell below target, Pensieve will apply the corresponding availability credit without requiring a claim, and will say so in the Service Report. 8.5.1 exists for claims Pensieve has not already applied, and for claims founded on the Customer's own evidence.

8.5.5 Disagreement. A disagreement about a Service Credit calculation is resolved under this clause and then, if still unresolved, under MSA clause 25. MSA clause 25.1 records that a Service Credit dispute is first pursued here.

8.6 Cap. The aggregate of all Service Credits accruing in respect of a Service Month, from every ground, may not exceed thirty per cent (30%) of the Credit Reference Amount for that Service Month.

8.7 Application. An accepted Service Credit is applied as a reduction of the next invoice issued after acceptance. Where no further invoice will be issued, whether because the Agreement has ended or otherwise, the Service Credit is paid to the Customer within thirty (30) days of acceptance or of the effective date of termination, whichever is later. A Service Credit is not payable in cash while an undisputed invoice remains unpaid, and may be set off against it. Service Credits are treated for tax purposes in accordance with POL-GL-063 and the Refund and Credit Note process in FIN-IN-003.

8.8 Sole financial remedy. Subject to 8.9, Service Credits are the Customer's sole and exclusive financial remedy for any failure by Pensieve to meet an availability target, an Initial Response target, a restoration target, a recovery objective or a performance target in this Agreement. This clause gives effect to MSA clause 18.9.

8.9 Carve-outs from 8.8. 8.8 does not limit, exclude or affect:

8.9.1 any liability of the kind listed in MSA clause 18.1, including death or personal injury caused by negligence, fraud, wilful misconduct and deliberate abandonment of obligations;

8.9.2 a claim arising from a Personal Data Breach, which is governed by DPA-GL-001 and MSA clauses 17.3 and 18.5, and which is not a service-level failure merely because it also caused unavailability;

8.9.3 a claim arising from breach of the Security Addendum (ADD-GL-001) or of the confidentiality obligations in MSA clause 12;

8.9.4 the Customer's right to terminate under MSA clause 21.3.4 for persistent failure of the availability target, or under MSA clause 21.3.1 for material breach;

8.9.5 the abatement of the Platform Fee for prolonged force-majeure unavailability under MSA clause 24.4;

8.9.6 the Customer's right to exit assistance and to return of its data under MSA clause 22; or

8.9.7 any remedy that cannot lawfully be excluded.

8.10 No credit in these cases. No Service Credit accrues in respect of: a period within an Excluded Event; a period during which the Customer is in the arrears described at E-10; a non-production environment; Beta or Early Access functionality; a Pilot under ADD-GL-013; the period before the Production Go-Live Certificate is issued; or a failure caused by the Customer's breach of 7.10.

8.11 Chronic failure. Where the Monthly Uptime Percentage falls below target in three (3) consecutive Service Months, or in four (4) Service Months in any twelve (12), then in addition to Service Credits Pensieve will, at no charge: produce a written remediation plan within ten (10) Business Days, with named owners and dates; implement it; and report progress at each monthly service review until the Customer accepts that the position is remedied. The Customer's termination right under MSA clause 21.3.4 is unaffected and may be exercised instead of, or after, accepting the remediation plan.

8.12 Credits do not accumulate into an entitlement. A Service Credit relates to the Service Month in which the failure occurred. It does not create an expectation, a course of dealing or a variation of the targets in this Agreement.

9.1 What these objectives are. The Recovery Time Objective and the Recovery Point Objective are commitments about recovery from a Disaster (the loss or corruption of a production environment) and not about routine Incidents. Routine Incidents are governed by 7. DIS-GL-014 and DIS-GL-015 describe the backup and continuity architecture; this clause states what Pensieve commits to.

9.2 Objectives by Deployment Model.

The objectives recorded on the Order Form for this Agreement are Deal RTO hours hours and Deal RPO minutes minutes; where those values differ from the table above, the Order Form prevails and the table records the standard position.

9.3 Why DM-2 has a longer RTO than DM-1, stated openly. Under DM-2 the Customer's data sits in a shared platform. Restoring a single tenant from a shared backup requires extraction and reconciliation steps that a dedicated restore does not, and a platform-wide event is worked in an order that Pensieve determines by clinical severity across all affected customers. That is a real difference between the models and it is stated rather than averaged away. A Customer for whom a four-hour RTO matters should select DM-1.

9.4 DM-3 conditions. Under DM-3 the objectives in 9.2 are conditional on: the Customer's cloud account being operational and not suspended; sufficient quota being available in the Customer's project or an alternative region to provision replacement resources; Pensieve holding the ADD-GL-009 roles at the time; and the Customer's key management service being available so that backups can be decrypted. Where any of those is not satisfied, the objective is suspended and Pensieve will restore as soon as it is satisfied, keeping the Customer informed at the Severity 1 cadence.

9.5 Declaration of a Disaster. Pensieve declares a Disaster when it determines that the production environment cannot be restored in place within the RTO. On declaration Pensieve will: notify the Customer's Severity 1 contacts immediately; state the recovery approach, the expected recovery point and the expected time to restoration; invoke the BC/DR Invocation Runbook (RBK-GL-020); and report at the Severity 1 cadence until the Core Functions are restored. The Customer may ask Pensieve to declare a Disaster; Pensieve will decide within one (1) hour and record the reason.

9.6 DM-4: no recovery objective, and why.

This sub-clause applies only where the Deployment Model is DM-4. It is retained in the published standard form so that the position is visible before the model is selected.

9.7 Evidence. Pensieve performs restore tests at the cadence in 9.2, records the recovery point and recovery time actually achieved, and makes the Restore/Recovery Verification Report (REP-GL-015) and the BC/DR Test Report (REP-GL-013) available to the Customer under the terms on which those artefacts are published. Where a test fails to meet the committed objective, Pensieve will say so in the next Service Report, state the cause, and state what it is doing about it.

9.8 Recovery does not displace breach notification. Where a Disaster involves or may involve Personal Data, the notification obligations in DPA-GL-001 clause 10 run in parallel and are not deferred by recovery work.

10.1 Maintenance Window. The standard Maintenance Window is Sunday 02:00 to 06:00 in the Service Time Zone, and any alternative window recorded on the Order Form as Deal SLA maintenance window. Pensieve will schedule Planned Maintenance within a Maintenance Window wherever it is able to.

10.2 Notice. Pensieve gives notice of Planned Maintenance by Planned Maintenance Notice (NTC-GL-005) to the Customer's Authorised Support Contacts and on the status page:

10.3 Content of a maintenance notice. Each notice states: what is being changed; why; the window; the maximum expected duration of any interruption; which Core Functions and Ancillary Functions are affected; whether any user action is required; the rollback position; and a contact for questions.

10.4 Emergency Maintenance. Pensieve may perform Emergency Maintenance without the notice periods in 10.2 where it is necessary to preserve the security, integrity or continued operation of the Platform, or to comply with a direction of a regulator or a court. Pensieve will notify the Customer at the time the maintenance begins, will confine it to what the circumstance requires, and will provide a written account within two (2) Business Days stating what was done, why the notice period could not be met, and what the effect was. Emergency Maintenance performed otherwise than in accordance with this sub-clause is not an Excluded Event.

10.5 Security patching takes precedence. Where a vulnerability is rated Critical or High under ADD-GL-001 clause 8, Pensieve will patch it within the timescales committed there, and will do so outside a Maintenance Window if the timescale requires it. The Customer acknowledges that a shorter notice period for a security patch is a benefit to the Customer and not a reduction of service.

10.6 Monthly cap on excluded maintenance. Not more than eight (8) hours of Planned Maintenance in any Service Month is treated as an Excluded Event. Minutes of Planned Maintenance beyond that cap are Downtime Minutes. Expedited security maintenance under 10.5 and Emergency Maintenance under 10.4 do not count towards the cap.

10.7 Blackout periods. The Customer may nominate, by not less than twenty-one (21) days' notice, up to six (6) blackout periods in any twelve (12) months, each of not more than seventy-two (72) hours, during which Pensieve will not perform Planned Maintenance. Blackout periods are recorded on the Order Form as Deal SLA blackout periods and are intended for accreditation assessments, statutory inspections, peak festival and seasonal demand, camps and audits. Pensieve will observe a blackout period unless Emergency Maintenance or security patching under 10.5 requires otherwise, in which case Pensieve will explain the necessity to the Customer before proceeding where time permits.

10.8 Deferral at the Customer's request. The Customer may request deferral of a Planned Maintenance once per instance, by notice given at least two (2) Business Days before the window. Pensieve will accommodate the request where it can. Where a deferral causes a security patch to be delayed beyond the timescale in ADD-GL-001 clause 8, Pensieve will record the deferral in writing and MSA clause 4.7.4 applies by analogy: Pensieve is not liable for loss arising from a vulnerability that the deferred patch would have remediated.

10.9 Release management. The manner in which changes are tested, released and rolled back is described in the Change Management & Release Disclosure (DIS-GL-031). Pensieve will not deploy a change to the Customer's production tenancy that has not passed the release process described there.

10.10 DM-4 and DM-3 maintenance. Under DM-4 the maintenance window is agreed with the Customer under ADD-GL-008 clause 6 and requires the Customer to make the Customer Infrastructure available; the notice periods in 10.2 apply to Pensieve's request. Under DM-3 the notice periods apply unchanged, and maintenance of the cloud provider's own platform is the provider's, notified by the provider to the Customer as its customer of record.

11.1 Only what is measurable is committed. Pensieve commits to performance targets that can be measured at the Platform Boundary from Pensieve's own instrumentation, without depending on the Customer's network, devices or browsers. Anything measured at the user's screen depends on the hospital's local area network, Wi-Fi density, endpoint age and browser version, and Pensieve will not commit to a number it cannot measure or influence. This is why 11.2 is expressed server-side.

11.2 Performance targets. Measured across each Service Month, server-side, from receipt of the request at the Platform Boundary to despatch of the complete response, excluding client rendering and any network segment on the Customer's side of the Platform Boundary:

11.3 Interface and batch targets.

11.3.1 Inbound instrument and interface messages. A conformant message received at the Platform Boundary from a laboratory analyser, an imaging modality or another integrated system is parsed and posted against the correct patient record within sixty (60) seconds at the 95th percentile. Time spent by the sending system, by the Customer's network, or by a middleware component the Customer operates, is not counted.

11.3.2 Scheduled jobs. Nightly scheduled jobs configured under the Statement of Work complete before 07:00 in the Service Time Zone on not less than 98% of days in a Service Month.

11.3.3 Bulk export. A standard data export requested under DIS-GL-401 is made available within the period stated in that document.

11.4 Conditions on the performance targets. The targets in 11.2 and 11.3 apply while: the concurrent user count and transaction volume remain within the sizing recorded on the Order Form or in the most recent capacity review; the Customer's data volumes are within the retained-volume assumption in that sizing; and, under DM-3 and DM-4, the infrastructure meets the specification Pensieve has issued. Where a threshold is exceeded, Pensieve will notify the Customer, propose the capacity change required, and the targets are suspended in respect of the affected transaction until the change is authorised and implemented.

11.5 Remedy for a performance failure. Failure to meet a target in 11.2 or 11.3 does not attract a Service Credit. It attracts the following, which is what a hospital actually needs:

11.5.1 identification in the Service Report, with the measured value and the affected transaction;

11.5.2 where the target is missed in two (2) consecutive Service Months, a written remediation plan within ten (10) Business Days, with a named owner, the diagnosis, the intended change and a date;

11.5.3 implementation of that plan at Pensieve's cost where the cause is within Pensieve's control, and at the Customer's cost where the cause is capacity the Customer has declined to authorise; and

11.5.4 where the degradation is severe enough that transactions do not complete, treatment as an Incident under 7 at the Severity Level its operational consequence warrants, which is the route by which a genuinely unusable Platform reaches Severity 1 without being an availability failure.

11.6 Monthly Service Report. Within ten (10) Business Days of the end of each Service Month, Pensieve issues a Service Report to the Customer's Authorised Support Contacts containing:

11.6.1 the Monthly Uptime Percentage, the Downtime Minutes and the calculation;

11.6.2 each Excluded Event, with its start, end, duration and cause;

11.6.3 every Ticket opened, closed and outstanding, by Severity Level, with Initial Response times and target attainment;

11.6.4 every Severity 1 and Severity 2 Incident with a short narrative and the status of its root-cause report;

11.6.5 the measured values for each target in 11.2 and 11.3;

11.6.6 Planned Maintenance performed and Planned Maintenance scheduled for the next Service Month;

11.6.7 any Service Credit Pensieve has applied under 8.5.4 and any claim outstanding;

11.6.8 the result of any restore test performed in the period; and

11.6.9 open remediation actions with owners and dates.

11.7 Monthly and quarterly reviews. Pensieve holds a service review with the Customer monthly for the first three (3) Service Months after Go-Live and quarterly thereafter, on the Service Report, open actions, capacity, upcoming change and any matter either Party raises. The Customer may require a monthly cadence to resume for as long as a chronic-failure remediation plan under 8.11 is open. The quarterly review is recorded and its record is an artefact of the Annual Service Review Certificate (CRT-GL-009).

11.8 Reporting under DM-4. Under DM-4 the Service Report contains the matters in 11.6.3 to 11.6.9, and reports observed availability of the on-premise instance as an item of information only, marked as such, with no service-level consequence attaching to it. Pensieve reports what it can see; where the Customer's environment prevents Pensieve from observing something, the Service Report says so rather than leaving a gap.

12.1 The Support Center is the channel; this Agreement is the commitment. The Support Center is a separate Pensieve Labs property. It is where Tickets are raised, tracked and answered, where the knowledge base, help articles, release notes and how-to documentation live, and where the Customer sees the current state of its Tickets. This Agreement states what Pensieve is contractually obliged to do. The Support Center states how it is done. Where a description in the Support Center appears to state a different commitment from this Agreement, this Agreement governs, and Pensieve will correct the Support Center. No content in the Support Center varies this Agreement.

12.2 Support included in the Charges. The following are included in the Platform Fee and are not separately chargeable:

12.2.1 receipt, triage, diagnosis, response and resolution of Incidents at every Severity Level, in accordance with 7;

12.2.2 correction of a defect in the Platform, including its delivery to the Customer's tenancy;

12.2.3 answering questions about how to use the Platform's standard capabilities;

12.2.4 routine user administration guidance, and creation, amendment and deactivation of users where the Customer's own administrator cannot perform it;

12.2.5 platform upgrades, security patching and maintenance under 10;

12.2.6 monitoring, alerting, backup operation and restore testing for DM-1, DM-2 and DM-3 in accordance with 9;

12.2.7 the Service Report and the service reviews under 11;

12.2.8 access to the Support Center knowledge base, release notes and operating documentation for all of the Customer's users;

12.2.9 re-running a standard report or a standard export that failed for a reason within Pensieve's control; and

12.2.10 configuration changes within the standard configuration surface: tariffs, users, roles, departments, print formats and templates, up to the monthly allowance recorded on the Order Form.

12.3 Assistance beyond the Platform Boundary. Where an Incident appears to originate on the Customer's side of the Platform Boundary, Pensieve will spend up to two (2) hours per Incident assisting the Customer's own team to isolate it, at no charge, including reviewing logs Pensieve can see and advising what to test. Beyond that, assistance is chargeable under 12.4. This clause exists so that nobody argues about whose problem it is while a hospital waits.

12.4 Chargeable work. The following are outside the Charges and are chargeable at the rates recorded on the Order Form, or under a Change Order (ADD-GL-015) or Statement of Work where the effort exceeds the threshold stated on the Order Form. Pensieve will estimate and obtain the Customer's written approval before performing chargeable work, except where the Customer instructs Pensieve to proceed in a Severity 1 and approval follows:

12.5 Language and channels. Support is provided in English. Where the Order Form records an additional language, it is provided in that language during the hours stated there. Support is provided remotely. DIS-GL-033 states the countries from which Pensieve personnel may access the Customer's tenancy, and DPA-GL-001 clause 6.4 governs access to Personal Data during support.

12.6 Authorised Support Contacts. The Customer nominates up to eight (8) Authorised Support Contacts in Schedule C, of whom at least two must be reachable for a Severity 1 at any hour. Users who are not Authorised Support Contacts use the Support Center knowledge base and their own hospital's internal escalation. This limit is separate from, and unrelated to, the Trust Center credential limit in POL-GL-500.

12.7 Support and the Support & Maintenance Addendum. Where the Order Form incorporates the Support & Maintenance Addendum (ADD-GL-002), that document governs the operational detail of maintenance releases, version currency and end-of-support for superseded versions. It does not vary the severity definitions, response targets, escalation or credits in this Agreement, which remain the source of truth.

12.8 Deprecation and end of support. Notice periods for the deprecation of a capability, and for the end of support of a Platform version, are in POL-GL-064. A capability that has been properly deprecated with notice is not a defect, and its removal is not an Incident.

12.9 Support of Third-Party Systems. Pensieve supports the Platform's side of an integration. It does not support, and cannot commit to, the third party's system, the Customer's contract with that third party, or that third party's own service levels. ADD-GL-007 allocates responsibility for systems accessed under the Customer's credentials, and DIS-GL-026 allocates responsibility for ABDM and NHCX specifically.

13.1 Changes to this Agreement. Pensieve may update the published standard form of this Agreement. An update does not alter the version agreed between the Parties, which is the version identified in the Order Form and recorded in Schedule A. A change to the version applying between the Parties is made by Change Order (ADD-GL-015) or by agreement in writing.

13.2 No reduction without notice and objection. Where Pensieve proposes to move the Customer to a later version of this Agreement that materially reduces a target, extends an exclusion or reduces a Service Credit, MSA clause 2.6 applies: thirty (30) days' notice, and a right for the Customer to object on reasonable grounds and remain on the prior version until the end of the then-current Term.

13.3 Annual review. The Parties will review this Agreement at each Annual Service Review (CRT-GL-009), against the Service Reports for the year, and may agree changes by Change Order. Neither Party is obliged to agree a change.

13.4 Effect of Deployment Model change. A change of Deployment Model changes what this Agreement commits to. MSA clause 4.2 requires a Change Order, and the Change Order will record the new targets, the new recovery objectives and, where the change is to DM-4, the fact that the availability service level ceases to apply.

13.5 Survival. Clauses 8 (in respect of Service Credits accrued before termination), 11.6 (in respect of the final Service Month) and 12 (in respect of exit assistance under MSA clause 22) survive termination.

13.6 Governing law and disputes. This Agreement is governed by, and disputes under it are resolved in accordance with, MSA clauses 25 and 26, subject to 7.6.6 and 8.5.5.