SERVICE LEVEL AGREEMENT
Version v1.4
THE LEVELS BINDING ON THE VENDOR FOR A CUSTOMER ARE THOSE ACTIVATED IN THAT CUSTOMER'S ORDER FORM. Under owner decision
owner-decision:2026-08-17-sla-activation-variant-bthree of the levels in clause 1.3 are approved for activation — Support first response, Daily backup with 14x24-hour retention, and Host-loss RPO — and each becomes binding for a Customer only when that Customer's Order Form carries the corresponding activation row and the evidence clause 1.3 names for it has been produced and retained. Every other level in this SLA remains a good-faith target. A level that appears in this document is not owed merely because it appears here, and no Service Credit accrues under an unactivated level.
This Service Level Agreement (the "SLA") is issued by NOVUS POINT LIMITED, a company incorporated in England and Wales with company number 08146241 and registered office at 124 City Road, London, England, EC1V 2NX (the "Vendor"), and applies to the "LEM" / "Lem Cloud" hosted personal AI operator service (the "Service") supplied to the business customer identified on the applicable Order Form (the "Customer").
This SLA forms part of the Master Services Agreement between the Vendor and the Customer (together with the documents it incorporates, the "Agreement") only where its exact title, version, effective date, filename and SHA-256 value are listed in the Contract Execution Manifest attached to the executed Order Form. An Order Form is executed in the manner provided in the Order Form and the Master Services Agreement, including by the Customer's recorded click acceptance of the delivered, versioned contract pack at first Workspace activation, evidenced by the tamper-evident acceptance record described there; references in this SLA to a signed or executed Order Form are read accordingly. Capitalised terms not defined in this SLA have the meanings given in the Agreement. The sole order of precedence is in clause 2.5 of the Master Services Agreement; this SLA does not restate or vary it.
This SLA is offered to business customers only and confers no rights on consumers.
1. PURPOSE AND POSTURE
1.1 This SLA sets out: (a) the Vendor's support channels and response targets; (b) incident priority definitions; (c) maintenance and change-management practices; (d) the monthly availability target and, from the date stated in clause 6, the service-credit regime; (e) how availability is measured and what is excluded; (f) backup and restore commitments; and (g) the Vendor's disaster-recovery statement.
1.2 Targets versus guarantees. Except where this SLA expressly states that a commitment is binding, the levels in this SLA are good-faith targets. The only binding operational levels are those expressly activated in the Order Form after the corresponding evidence gate in this SLA is closed. External uptime measurement, service credits, restore/RTO/logical-loss RPO and host-loss RTO are not activated and remain targets. Support first response, daily backup with 14x24-hour retention and host-loss RPO are approved for activation under owner decision owner-decision:2026-08-17-sla-activation-variant-b; each of those three binds the Vendor for a Customer only once that Customer's Order Form carries its activation row and the evidence named for it in Clause 1.3 has been produced and retained.
1.3 Activation table. The executed Order Form must identify the version and activation date of each binding level and the Vendor must retain the listed evidence:
| Level | Activation evidence | Status at 2026-08-18 |
|---|---|---|
| Support first response | Live monitored support channel, owner/deputy and timestamped test | Approved for activation (owner decision 2026-08-17); binds only on an Order Form activation row with the evidence in column 2 retained |
| Availability and Service Credits | External EU synthetic checks at the 60-second interval fixed by clause 7.1, raw-result retention, monthly calculator and claim/credit workflow | Not active |
| Daily backup / 14-day time-based retention | Catch-up scheduler, atomic verified archive, minimum 14×24-hour retention and missing-backup alert | Approved for activation (owner decision 2026-08-17); binds only on an Order Form activation row with the evidence in column 2 retained |
| Restore / RTO / logical-loss RPO | Full scratch restore including host, Workspace, DNS/TLS/secrets and measured drill report | Not evidenced |
| Host-loss RPO | Tested off-box backup in a separate failure domain | Approved for activation (owner decision 2026-08-17, conditional on an evidenced off-box restore; that restore was performed off-host on 2026-08-17); binds only on an Order Form activation row |
| Host-loss RTO | Measured full scratch restore to a replacement host, including retrieval from tested off-box backup in a separate failure domain | Not evidenced |
2. DEFINITIONS
In this SLA:
"Availability" means the Workspace responding to the Vendor's external monitoring checks as described in clause 7.1.
"Business Day" means a day other than a Saturday, Sunday, or public holiday in England.
"Business Hours" means 09:00–17:00 (UK time) on Business Days.
A period expressed in Business Hours runs only during Business Hours and is suspended outside them, measured from receipt or deemed receipt under clause 3.2. A period expressed in Business Days runs from the start of the next Business Day after receipt or deemed receipt and expires at 17:00 (UK time) on the last such Business Day; a period written in this SLA as "1 Business Day" is one (1) Business Day computed on that basis.
"Downtime" means a continuous period of five (5) minutes or more during which the Customer's Workspace fails the Vendor's external monitoring checks, excluding any period attributable to an Exclusion (clause 7.3). Periods of less than five (5) minutes do not count as Downtime. Whether a check has failed, when a failing period begins and ends, and how a failing period is converted into minutes, are determined by the measurement-conversion rule in clause 7.1. For the avoidance of doubt, the five (5) minute continuity test is applied to the observed continuous period during which the Workspace fails the Vendor's external monitoring checks before any Exclusion is subtracted. A period attributable to an Exclusion reduces the Downtime minutes counted in that period but does not break the continuity of the failing period for the purposes of this definition.
"Exclusion" means any of the matters listed in clause 7.3.
"First Response" means a substantive human acknowledgement of a support request by the Vendor (an automated receipt is not a First Response).
"Monthly Subscription Fee" means the recurring monthly subscription fee for the affected Workspace stated in the Order Form, excluding the Onboarding Fee, one-off fees, voice per-minute pass-through charges, and taxes.
"Monthly Uptime Percentage" means, for a calendar month: ((total minutes in the month − Downtime minutes in the month) ÷ total minutes in the month) × 100.
"Scheduled Maintenance" means maintenance notified to the Customer under clause 5.3.
"Service Credit" means a credit against future Fees calculated under clause 6.
"SLA Activation Date" means the date entered in the "Activation date" column against the "Availability and Service Credits" row of the SLA activation table in Section 10 of the Order Form.
"Tested" means, in relation to a notice channel or contact point, that a successful delivery test to that channel or contact point has been carried out and recorded in the Customer's tenant evidence pack.
"Workspace" has the meaning given in clause 1.1 of the Master Services Agreement.
3. SUPPORT
3.1 Channel. The Customer may raise support requests through jakub@novus-point.com and any additional tested support channel stated in the Order Form. Support is provided in English. No response target is activated merely by publication of the address; Clause 1.3 evidence remains mandatory.
3.2 First-response commitment. If activated in the Order Form, the Vendor will provide a First Response by the end of the next Business Day after receipt. A request received outside Business Hours is treated as received at 09:00 on the next Business Day. Example: a request received Friday at 16:00 before a non-holiday weekend is due by 17:00 Monday. No support target is binding before the live channel and staffing evidence in Clause 1.3 is recorded.
3.3 Scope of support. Support covers the operation of the Workspace and the Service features described in the Documentation (which is not contractual and does not enlarge the Service scope or the Vendor's obligations, per clause 1.1 of the Master Services Agreement). Support does not cover: (a) faults in Connected Accounts or other third-party services (including the Customer's Google Workspace, Telegram, or LLM-provider accounts); (b) training or consultancy beyond the onboarding and hypercare included in the Order Form; (c) issues arising from Customer acts or omissions described in clause 7.3(a).
3.4 Onboarding and hypercare. For thirty (30) days following acceptance under clause 4.3 of the Master Services Agreement, as recorded in the transaction-specific Statement of Work, the Vendor will apply an update cadence no less frequent than the P2 cadence in clause 4 to all Customer-reported issues, without reducing the cadence applicable to any higher priority. This cadence is a target under clause 1.2 unless expressly activated in the Order Form.
4. INCIDENT PRIORITIES AND TARGETS
4.1 The Vendor assigns a priority to each incident, acting reasonably and taking the Customer's classification into account:
| Priority | Definition | First Response (target) | Update cadence (target) | Resolution objective (target, not guaranteed) |
|---|---|---|---|---|
| P1 — Critical | The Workspace is unavailable, or an actual or reasonably suspected Security Incident (as defined in the Agreement) affects the Customer's Workspace or Customer Data. No workaround exists. | Within 4 Business Hours, and in any event by the end of the next Business Day under clause 3.2 | At least once per Business Day until resolved or downgraded | Restore Service or provide a workaround within 1 Business Day |
| P2 — Major | A core function of the Service (e.g., email drafting, calendar, dashboard access, or a channel separately activated in the Order Form) is materially degraded or unusable, but the Workspace as a whole remains operable, or a reasonable workaround exists. | Within 1 Business Day | At least every 2 Business Days until resolved or downgraded | Fix or workaround within 5 Business Days |
| P3 — Minor | Any other fault, cosmetic issue, question, or feature request with limited operational impact. | By the end of the next Business Day (clause 3.2) | On material progress, and on Customer request | Addressed in the ordinary release cycle; no committed date |
4.2 Figures shorter than the end-of-next-Business-Day commitment in clause 3.2 are targets only; the binding First Response commitment for every priority is clause 3.2. Periods expressed in Business Hours and Business Days are computed as provided in clause 2.
4.3 A P1 caused by an Exclusion (for example, an outage of the Customer's chosen LLM provider) will be acknowledged and triaged as a P1, but the associated Downtime is subtracted under clause 7.3 after the five (5) minute continuity test in clause 2 has been applied, does not count toward the availability calculation in clause 7, and third-party restoration timelines are outside the Vendor's control.
4.4 Security incidents involving personal data are additionally handled under the personal-data-breach provisions of the DPA, which prevail in respect of personal data. Nothing in clauses 3 and 4 extends, qualifies or postpones the Vendor's notification obligations under clause 7.3 of the Master Services Agreement or Clause 11 of the DPA, which run in calendar time.
5. MAINTENANCE AND CHANGE MANAGEMENT
5.1 Canary-first updates. Fleet updates to the Service are deployed canary-first: updates are released to a small subset of workspaces (or a vendor-internal workspace) and observed before being rolled out to the remaining fleet, including the Customer's Workspace. This reduces, but does not eliminate, the risk that an update affects the Customer.
5.2 Routine maintenance. Routine maintenance that is not expected to cause material Downtime (including canary-first fleet updates, security patching, and certificate renewal) may be performed at any time without notice.
5.3 Scheduled Maintenance with expected Downtime. Where the Vendor expects maintenance to cause material Downtime to the Customer's Workspace, the Vendor will give at least forty-eight (48) hours' notice through the Tested operational-notice contact recorded in Section 1 of the Order Form, will schedule the work outside Business Hours where reasonably practicable, and will state the expected duration. A disabled or untested channel is not notice. Downtime during properly notified Scheduled Maintenance is an Exclusion.
5.4 Breaking changes. Without prejudice to clause 3.5 of the Master Services Agreement (thirty (30) days' written notice and a right to terminate the affected Order Form with a pro-rata refund of prepaid unused recurring Fees for any change that materially degrades core functionality), where an update materially changes or removes a Service behaviour described in the Documentation (which is not contractual and does not enlarge the Service scope or the Vendor's obligations, per clause 1.1 of the Master Services Agreement) on which the Customer's workflows reasonably rely, and that change does not materially degrade core functionality (a "Breaking Change"), the Vendor will give at least fourteen (14) days' prior notice, except where a shorter period is required to address a security vulnerability, in which case the Vendor will give as much notice as reasonably practicable and explain the constraint.
5.5 Emergency maintenance. The Vendor may perform emergency maintenance without notice where reasonably necessary to protect the security or integrity of the Service or Customer Data, and will notify the Customer as soon as reasonably practicable afterwards. Downtime during emergency maintenance necessitated by a third-party vulnerability or an Exclusion is itself an Exclusion; other emergency-maintenance Downtime counts toward the availability calculation.
6. AVAILABILITY TARGET AND SERVICE CREDITS
6.1 Availability target. The Vendor targets a Monthly Uptime Percentage of 99.5% for the Customer's Workspace in each calendar month. During the first ninety (90) days following the Activation Date recorded in Section 6 of the Order Form (the "Stabilisation Period"), this figure is a target only and no Service Credits accrue.
6.2 Service-credit activation. The service-credit regime applies only from the later of: (a) the first full calendar month after the Stabilisation Period; and (b) the SLA Activation Date expressly stated in an executed Order Form after all availability evidence in Clause 1.3 is complete. Where the SLA Activation Date falls other than on the first day of a calendar month, the regime applies from the first full calendar month after it. It does not activate automatically through passage of time.
6.3 Service Credit tiers. If, in a calendar month after activation under clause 6.2, the Monthly Uptime Percentage for the Customer's Workspace falls below 99.5%, the Customer is entitled to a Service Credit calculated on the Monthly Subscription Fee for that Workspace for that month:
| Monthly Uptime Percentage | Service Credit |
|---|---|
| Below 99.5% but at or above 99.0% | 10% of the Monthly Subscription Fee |
| Below 99.0% | 25% of the Monthly Subscription Fee |
6.4 Claim procedure. To receive a Service Credit the Customer must submit a claim through the support channel within thirty (30) days after the end of the calendar month concerned, identifying the dates and approximate times of the Downtime relied on. The Vendor will verify the claim against its monitoring records (clause 7.2) and confirm or reject it, with reasons, within ten (10) Business Days.
6.5 Application of credits. Service Credits are applied against the next invoice(s) for the affected Workspace. Service Credits: (a) are not redeemable for cash, except against amounts owed on final invoice at termination; (b) are capped at 25% of the Monthly Subscription Fee in any calendar month; (c) do not apply to the Onboarding Fee, one-off fees, add-on pass-through charges, or taxes; and (d) do not accrue for any month in which the Customer's account has undisputed Fees overdue by more than fourteen (14) days.
6.6 Availability remedy. Once activated, Service Credits are the Customer's sole and exclusive financial remedy, whether in contract, tort or otherwise, for any failure to achieve the Monthly Uptime Percentage target, as clause 14.3 of the Master Services Agreement records. They do not exclude remedies for a breach of a distinct obligation under the MSA or DPA, confidentiality/security obligations, data loss, negligence or wilful misconduct, and remain subject to non-excludable rights and the liability provisions of the Agreement. Any Service Credit given in respect of an event is set off against, and counts towards, any damages payable for the same event and towards the aggregate ceiling in clauses 16.3 and 16.4 of the Master Services Agreement.
7. MEASUREMENT AND EXCLUSIONS
7.1 How availability will be measured after activation. Availability must be measured by independent external synthetic checks operated from documented EU infrastructure. The check must exercise the contracted Workspace surface recorded in the "Monitored Workspace surface (URL/route, authentication and expected response assertion)" row of the SLA activation table in Section 10 of the Order Form, not merely an in-container /health response. Current in-container health and dead-man monitoring are operational diagnostics and do not calculate Monthly Uptime Percentage.
Measurement-conversion rule. The following rule converts probe samples into Downtime minutes for the purposes of clause 2 and of the Monthly Uptime Percentage, and applies in place of any other sampling interval, incident-boundary or rounding practice. The requirement of a probe interval of "no more than five minutes" previously stated in this clause is replaced by limb (a):
(a) Interval. The probe interval is fixed at sixty (60) seconds.
(b) What counts as a failed check. A check fails if it results in a connection timeout, a TLS error, a 5xx response, or a response that fails the content assertion recorded in the "Monitored Workspace surface (URL/route, authentication and expected response assertion)" row referred to above. Any other result is a successful check.
(c) Incident boundaries. A failing period begins at the timestamp of the first failed check and ends at the timestamp of the next successful check. Each check describes the interval from its own timestamp until the next check, and the last check in a calendar month describes the interval from its own timestamp until the end of that month; consecutive failing intervals form one continuous failing period. A single failed check opens a failing period, which counts as Downtime only where the five (5) minute continuity test in clause 2 is satisfied.
(d) Conversion to minutes. Downtime accrues in seconds and is expressed in minutes; no part-minute is rounded up and no failing period is rounded up to a whole minute.
(e) Gaps in the probe series. A scheduled check for which no result was recorded is a gap. A gap is not evidence that the Workspace was available. Where the probe series for a calendar month contains a gap longer than the interval in limb (a), the Monthly Uptime Percentage for that month is indeterminate: no Monthly Uptime Percentage, no target verdict and no Service Credit percentage is produced from that series. The observed failing periods, their boundaries and the measurement coverage for that month are still recorded and provided under clause 7.2, and clause 7.2 continues to apply where the Vendor's records are manifestly incomplete or erroneous. A Service Credit claim in respect of a month that is indeterminate under this limb is made and assessed under clause 6.4, which this limb does not vary; this limb creates no additional right to a Service Credit and no additional route to evidencing one.
(f) Calendar month and timestamps. A "calendar month" for the purposes of this SLA begins at 00:00:00 UTC on the first day of that month and ends immediately before 00:00:00 UTC on the first day of the next month, and every timestamp used in the calculation is recorded and computed in UTC.
The five (5) minute continuity test in the definition of Downtime is applied to a failing period determined under this rule, and only then is any period attributable to an Exclusion under clause 7.3 subtracted.
7.2 Records. After activation, the Vendor shall retain raw timestamped probe results, incident-boundary decisions, exclusions and the reproducible monthly calculation for at least the contract term plus twelve months. The Vendor shall provide a Customer with the relevant summary and investigate reasonable contrary evidence; Vendor records do not control where manifestly incomplete or erroneous.
7.3 Exclusions. Downtime is first determined from the probe series under clauses 2 and 7.1. A period within Downtime so determined that is attributable to any of the following is then subtracted, and is excluded from the Monthly Uptime Percentage calculation:
(a) Customer-caused events — unavailability caused by the Customer's or its authorised users' acts, omissions, equipment, network, or software, including: revocation or expiry of OAuth grants to Connected Accounts; exhaustion, suspension, or misconfiguration of a Customer-owned LLM-provider API key; Customer-requested configuration changes; misuse of the Service or breach of the Agreement or the Acceptable Use Policy;
(b) Third-party LLM and AI-provider outages — unavailability or degradation of the large-language-model provider(s) serving the Workspace (whether under a Customer-owned key or a Vendor-billed account with the model provider recorded in the Order Form and DPA Annex 3), including rate limiting, model deprecations, and provider-side incidents;
(c) Other third-party services outside the Vendor's control — outages or degradation of Connected Accounts and customer-selected channels and add-ons, including Google services, Telegram, the Composio tool gateway, and (where the Voice Add-On is enabled) ElevenLabs and, where a telephone number is attached to a Voice Agent, telephony carriers, number providers and PSTN/SIP interconnect; provided that the Vendor remains responsible under the DPA for its choice and supervision of its subprocessors, and this exclusion operates for availability-measurement purposes only;
(d) Scheduled Maintenance notified under clause 5.3 and emergency maintenance within clause 5.5 (to the extent stated there);
(e) Suspension or termination of the Service exercised by the Vendor in accordance with the Agreement (including for non-payment or material breach);
(f) Force majeure — events beyond the Vendor's reasonable control as defined in the Agreement, including failure of an upstream data-centre or hosting provider caused by such an event, internet backbone failures, and denial-of-service or other attacks that the Vendor could not have prevented by measures consistent with the security commitments in the DPA;
(g) DNS, certificate, or connectivity failures attributable to systems the Customer controls or to the Customer's local environment.
7.4 For the avoidance of doubt, unavailability of the underlying infrastructure provider recorded in the Customer's approved provider evidence is not excluded under clause 7.3(c) and counts as Downtime, except to the extent it results from a force majeure event within clause 7.3(f).
8. BACKUP AND RESTORE
8.1 Backup target and activation condition. The Vendor targets at least one successfully completed and integrity-verified backup per UTC day of the reviewed allowlist of Workspace data for each Workspace, with each recovery point retained for at least 14×24 hours. The backup allowlist does not cover raw session files, per-profile sub-trees, or the top-level databases other than state.db and the commitments database. This becomes a binding commitment only when scheduler catch-up, atomic archive/integrity verification, first/missing-backup alerts, live daily runs and actual retention are evidenced under Clause 1.3.
8.2 Current backup location — transparency statement. Encrypted off-host replication of per-Workspace and fleet backups is active in production. Archives are produced by restic and encrypted on the host before any upload; the repository keys are generated on the host, held root-only, and are never transmitted to the storage provider, which holds ciphertext only. The storage Subprocessor, contracting entity and storage region are those recorded in Part A of Annex 3 to the DPA — presently Backblaze, Inc., bucket lem-backups, region US West, United States — together with the applicable transfer instrument; that region is outside the EEA and the UK, and clause 9.1(b) of the DPA governs the transfer. Scheduled backup runs and scheduled tenant and fleet restore drills are executed and their results are recorded. This clause is a description of the measure operated and activates nothing: no off-host backup commitment, recovery-point objective, recovery-time objective or host-loss recovery objective applies unless expressly activated for the Customer in the Order Form under clause 1.3, and clauses 8.5 and 9.3 are unaffected. The Vendor will notify the Customer through the Tested operational-notice contact recorded in Section 1 of the Order Form when an activated level changes or when the storage Subprocessor or storage region changes, and will update the frozen contract set through the Agreement's variation process.
8.3 Restore on request or incident. Following data loss or corruption, or on the Customer's reasonable request, the Vendor will use reasonable efforts to restore the Workspace from the most recent available verified backup. Any binding commencement or completion target must be stated in the Order Form after a representative full restore has been measured.
8.4 Restore testing. The Vendor performs a full scratch restore drill covering replacement host, Workspace, data, secrets, DNS and TLS before first production onboarding and at least quarterly thereafter, whether or not a restore level is activated in any Order Form, as part of its measures under Article 32(1)(c) and (d) UK GDPR (DPA Annex 2 §12), and records elapsed time, recovered point, integrity checks and failures. The drill verifies completeness against the live Workspace volume and not against the backup's own allowlist. Archive extraction and SQLite checks alone are integrity tests, not full disaster-recovery drills.
8.5 Recovery point. A 24-hour RPO may be stated only for logical corruption or loss where the host backup survives and the daily backup evidence gate is active. There is no guaranteed RPO for loss of the host or its failure domain until the Host-loss RPO level in Clause 1.3 is evidenced and expressly activated in the Order Form; the fact that off-host backup is operated as described in clause 8.2 does not by itself activate that level. Any shorter target requires separately evidenced architecture and an Order Form commitment.
8.6 Data export. Independent of backups, the Customer may export its data as described in clause 6.4(c) of the Master Services Agreement and Clause 13 of the DPA, and is encouraged to take periodic exports of business-critical content.
8.7 No liability for unactivated levels. This clause 8 creates no obligation, and no liability under clause 16.2(d) of the Master Services Agreement, in respect of any level that has not been expressly activated for the Customer in the Order Form under the SLA activation table.
9. DISASTER RECOVERY STATEMENT
9.1 Architecture. Each Customer is served from a single dedicated Workspace in the provider and region recorded for that tenant. No provider, location or EU-residency statement is effective until account-specific evidence is approved. The Service does not currently operate multi-region, active-active or automatic failover, and this SLA does not represent otherwise. Backup archives are replicated off-host to the separate storage failure domain described in clause 8.2; that replication activates no recovery objective except as provided in clauses 1.3, 8.5 and 9.3.
9.2 Recovery approach. In the event of loss of the host running the Customer's Workspace, the Vendor's recovery approach is to provision a replacement host at the provider and in the region recorded for that tenant under clause 9.1 and redeploy the Workspace from the most recent available backup, restoring DNS, TLS, and channel configuration.
9.3 Recovery targets not yet evidenced. No binding host-loss RTO or RPO applies until the full scratch restore and off-box evidence in Clause 1.3 is complete and the resulting targets are stated in the Order Form. Any incident clock begins at the earlier of automated detection or Customer report, not at a later discretionary confirmation by the Vendor. A host-loss event is treated as P1 and, where personal data is affected, under the DPA incident process.
9.4 Review. The Vendor reviews this disaster-recovery statement at least annually and on any material architecture change, and will update this SLA to reflect improvements (including off-box backup replication) as they enter production.
10. GENERAL
10.1 Changes to this SLA. A contractual change requires a bilateral written variation or signed supplemental manifest under the Agreement. Updating a website, support page, Documentation or later source file does not amend the frozen SLA. No change may retrospectively reduce an accrued right or rewrite measurement evidence.
10.2 Relationship to the Agreement. This SLA does not expand the Vendor's liability beyond the limitations and exclusions in the Agreement. Nothing in this SLA excludes or limits any liability that cannot be excluded or limited under applicable law.
10.3 Incorporated B2B only. The Service is sold only to companies, limited liability partnerships and equivalent incorporated organisations for business use. It is not offered to consumers or sole traders. Nothing in this SLA excludes rights or liabilities that cannot lawfully be excluded.
10.4 Governing law. This SLA is governed by, and construed in accordance with, the governing-law and jurisdiction provisions of the Agreement (England and Wales for the English-language document set).
Novus Point Limited — company number 08146241 — registered office 124 City Road, London, England, EC1V 2NX Document version: v1.4 — version date 2026-09-08 — v1.4 recut integrating the hosted subscription checkout billing route; the TOTP second factor remains per-tenant optional under owner decisions of 2026-08-21; approved for execution at the v1.4 re-cut ceremony of 2026-09-08 (counsel posture carried from owner decision counsel-waiver-decision:2026-09-07-owner-risk-acceptance-v14); the levels binding on the Vendor for a Customer are those activated in that Customer's Order Form under clause 1.3