1008-00007 · Lumos Analytics Inc · Internal Memoranda

uptime-data-analysis-memo.docx DOCUMENT Litigation

8 / 12 ← → ✕

ATTORNEY-CLIENT PRIVILEGED AND CONFIDENTIAL — ATTORNEY WORK PRODUCT

MEMORANDUM

TO: Simone Laroche, Lead Associate, Calderwood & Harkness LLP Linda Osei, Responsible Partner, Calderwood & Harkness LLP

FROM: Jeffrey Park, Associate, Calderwood & Harkness LLP

DATE: June 12, 2023

RE: Uptime Data Analysis — Sentinel Uptime Services Telemetry vs. Pinnacle Financial Holdings LLC Claimed Outage Durations

MATTER: Lumos Analytics Inc. — Pinnacle SLA Credit Dispute (1008-00007)

CONFIDENTIALITY NOTICE: This memorandum is protected by the attorney-client privilege and the work product doctrine. It has been prepared in anticipation of litigation and solely for the purpose of rendering legal advice to our client, Lumos Analytics Inc. This memorandum should not be disclosed outside the engagement team or to any third party without the prior written approval of the responsible partner, Linda Osei. Any inadvertent disclosure does not constitute a waiver of any applicable privilege.

I. Executive Summary

The purpose of this memorandum is to analyze and compare the uptime telemetry data provided by Sentinel Uptime Services Inc. ("Sentinel"), Lumos Analytics Inc.'s ("Lumos") independent third-party infrastructure monitoring vendor, against the outage durations claimed by Pinnacle Financial Holdings LLC ("Pinnacle") in its May 1, 2023 demand letter and accompanying supporting documentation. This analysis was undertaken at the direction of the engagement team to evaluate the factual foundation of Pinnacle's SLA credit claims and to inform Lumos's defense strategy in the pending dispute.

The scope of this memorandum covers all four service incidents cited by Pinnacle as the basis for its SLA credit demand: Incident INC-4471 (October 12–13, 2022), Incident INC-4602 (November 28, 2022), Incident INC-4815 (January 9–10, 2023), and Incident INC-5033 (March 3–5, 2023). These four incidents span the six-month period from October 2022 through March 2023 and collectively form the basis of Pinnacle's claimed entitlement to $120,000 in SLA credits.

Bottom-Line Conclusion: Sentinel's independently recorded telemetry data shows materially shorter full-outage durations for all four incidents when compared to the durations claimed by Pinnacle. The discrepancies are substantial and consistent across all incidents, ranging from approximately 1 hour 31 minutes (INC-4602) to 12 hours 23 minutes (INC-5033). When the Sentinel data is applied to the SLA credit tier structure set forth in Exhibit C, Section 3.2 of the Master Services Agreement (MSA-PFH-2021-0015, dated January 15, 2021), total SLA credits based on Lumos's data amount to $90,000 — $30,000 less than Pinnacle's claimed $120,000.

This $30,000 reduction is itself a conservative figure. It does not account for two additional defenses that, if successful, would further reduce Lumos's SLA credit exposure: (a) a timeliness defense on INC-4471, where Pinnacle's credit request was submitted 14 days past the contractual deadline; and (b) a third-party causation defense on INC-5033, where the predominant portion of the claimed downtime was attributable to a configuration change by Pinnacle's own cloud infrastructure provider, Brindoval Cloud Infrastructure LLC ("Brindoval"). If both defenses succeed, Lumos's maximum SLA credit exposure drops to $30,000.

More broadly, the uptime data discrepancy materially supports Lumos's overall defense posture and undermines Pinnacle's broader $2,870,000 demand, which encompasses not only SLA credits but also consequential damages, remediation costs, and reputational harm claims. To the extent Pinnacle's outage duration claims are foundational to its entire damages theory, the Sentinel data reveals those claims to be systematically overstated.

II. Background

A. The Master Services Agreement and SLA Framework

Lumos Analytics Inc. and Pinnacle Financial Holdings LLC entered into a Master Services Agreement dated January 15, 2021, bearing the internal reference number MSA-PFH-2021-0015 (the "MSA"). Under the MSA, Lumos provides Pinnacle with access to its proprietary data analytics platform, including real-time financial data processing, portfolio risk modeling, and regulatory reporting functionalities delivered through a software-as-a-service ("SaaS") model.

The MSA has an initial term of three years, running from January 15, 2021 through January 14, 2024. Under Section 5.1 of the MSA, the annual subscription fee is $1,440,000, payable in equal monthly installments of $120,000. The MSA includes several exhibits, the most pertinent of which for present purposes is Exhibit C — the Service Level Agreement (the "SLA").

Exhibit C governs Lumos's uptime commitments to Pinnacle and establishes the credit structure applicable when those commitments are not met. The key provisions of Exhibit C are as follows:

Uptime Commitment (§2.1). Lumos commits to maintaining platform availability of 99.95% as measured on a calendar-month basis. For a standard 30-day month (comprising 43,200 total minutes), this equates to a maximum allowable downtime of approximately 21.6 minutes per month. For a 31-day month (comprising 44,640 total minutes), the maximum allowable downtime is approximately 22.3 minutes.

SLA Credit Tiers (§3.2). In the event that Lumos fails to meet the 99.95% uptime commitment in any given calendar month, Pinnacle is entitled to SLA credits calculated as a percentage of the applicable monthly subscription fee, according to the following tiered structure:

SLA Credit Cap (§3.4). The maximum aggregate SLA credits to which Pinnacle is entitled in any rolling twelve-month period shall not exceed thirty percent (30%) of the annual subscription fee, yielding a cap of $432,000 (i.e., 30% × $1,440,000).

Credit Request Procedure (§3.5). To be eligible for an SLA credit, the customer must submit a written credit request to Lumos within thirty (30) calendar days following the end of the affected calendar month. The credit request must specify the affected services, the dates and times of the claimed downtime, and any supporting evidence of the service disruption. Failure to submit a timely credit request constitutes a waiver of the customer's right to the applicable credit.

These provisions collectively establish a carefully calibrated remedial framework that serves as Pinnacle's exclusive remedy for uptime failures under Section 3.6 of Exhibit C, subject to the definitions, exclusions, and procedural requirements set forth elsewhere in Exhibit C. As discussed below, Pinnacle's claimed outage durations — and the resulting credit calculations — depart significantly from the durations recorded by independent monitoring.

B. Sentinel Uptime Services Inc. — Role and Data Source

Sentinel Uptime Services Inc. is a third-party infrastructure monitoring and incident-response logging provider retained by Lumos to provide continuous, automated monitoring of Lumos's production SaaS environment. Sentinel is an independent commercial entity headquartered at 2200 Mission College Blvd, Suite 100, Santa Clara, California 95054. Our primary contact at Sentinel is Brenda Hale, Director of Client Engineering.

Sentinel's monitoring service operates on a continuous basis, recording service availability at one-minute polling intervals from multiple geographically distributed check nodes located across North America, Europe, and the Asia-Pacific region. Sentinel's monitoring infrastructure is designed to provide a comprehensive and objective view of platform availability as experienced from diverse network locations and access paths.

Critically, Sentinel's data is generated and stored independently from Lumos's own internal systems, logging infrastructure, and operational dashboards. Sentinel maintains its own data centers, its own logging architecture, and its own audit trail mechanisms. This independence makes Sentinel's data a particularly credible and objective third-party record of Lumos platform availability — it is not generated by Lumos, not stored on Lumos's infrastructure, and not subject to manipulation or modification by Lumos personnel.

For purposes of this analysis, we obtained the following data from Sentinel, produced by Lumos's engineering team in response to our document request dated May 18, 2023:

• Monthly availability reports for October 2022, November 2022, January 2023, and March 2023;

• Detailed incident logs for each of the four incidents at issue (INC-4471, INC-4602, INC-4815, and INC-5033); and

• Raw telemetry data exports for the specific time windows encompassing each incident, including per-node availability readings, response time measurements, and status code logs.

All data was produced in native format and has been reviewed and indexed by our team. The data is subject to the litigation hold memorandum issued by Lumos's General Counsel, Adriana Voss, on May 15, 2023.

C. Pinnacle's Claimed Outages

Pinnacle's claims concerning the four service incidents are set forth in a demand letter dated May 1, 2023, transmitted by Pinnacle's outside counsel, Hargrove, Tillman & Burch LLP, under the signature of lead partner Katherine Hargrove. The demand letter asserts that Lumos experienced four significant service disruptions between October 2022 and March 2023 and claims total SLA credits of $120,000 plus $2,750,000 in additional damages, comprising $1,950,000 in consequential damages, $340,000 in remediation costs, and $460,000 in claimed reputational harm. The aggregate demand totals $2,870,000.

The demand letter attaches several exhibits, including internal Pinnacle incident reports, selected help-desk ticket summaries, and a spreadsheet purporting to calculate outage durations and SLA credit entitlements. However, Pinnacle did not produce raw monitoring data, did not identify the monitoring tools or methodology used to measure outage durations, and did not address the contractual definition of "Downtime" under Exhibit C, Section 1.1, or the exclusions set forth in Section 2.3.

This memorandum focuses solely on the factual analysis of outage durations and the resulting SLA credit calculations for each of the four incidents. The consequential damages claims, the contractual limitations on liability (including the mutual waiver of indirect and consequential damages under Section 11.3 of the MSA and the aggregate liability cap under Section 11.2), and additional contractual defenses (including the timeliness defense under Section 3.5 and the exclusive-remedy provision in Section 3.6) are addressed in separate memoranda being prepared concurrently by the engagement team.

III. Methodology

A. Sentinel Monitoring Architecture

A clear understanding of Sentinel's monitoring architecture is essential to evaluating the reliability of its data and the nature of the discrepancies with Pinnacle's claimed durations. Sentinel monitors Lumos's production SaaS environment through two complementary mechanisms:

Synthetic Transaction Checks. Sentinel deploys automated synthetic transactions that simulate typical end-user interactions with the Lumos platform. These synthetic checks execute predefined API calls against Lumos's primary production endpoints, measuring both availability (whether the endpoint returns a successful HTTP 200 response within the configured timeout window) and performance (the response time in milliseconds). The synthetic checks are configured with a timeout window of 30 seconds — meaning that if the primary API endpoint does not return a successful response within 30 seconds, the check is recorded as a failure for that polling interval.

Real-User Monitoring (RUM) Agents. In addition to synthetic checks, Sentinel deploys lightweight JavaScript-based RUM agents within the Lumos platform's front-end code. These agents capture actual end-user page load times, API response times, and error rates as experienced by real users accessing the platform in production. RUM data provides supplementary visibility into user-experienced performance but is secondary to the synthetic checks for purposes of availability measurement.

Polling Frequency and Node Distribution. Sentinel's synthetic transaction checks are executed at a polling frequency of every 60 seconds (i.e., one check per minute) from each of six geographically distributed monitoring nodes. The six nodes are located as follows:

1. US-East — Northern Virginia, United States

2. US-West — Oregon, United States

3. US-Central — Iowa, United States

4. EU-West — Dublin, Ireland

5. APAC-East — Tokyo, Japan

6. APAC-South — Sydney, Australia

This geographic distribution ensures that Sentinel's monitoring captures availability from a diverse set of network paths and access points, reducing the risk that localized network issues, ISP outages, or routing anomalies at any single location could distort the overall availability picture.

Outage Definition. Under Sentinel's standard monitoring protocol, an "outage minute" is recorded only when all six nodes simultaneously report service unavailability — i.e., when the primary API endpoint fails to return a successful HTTP 200 response within the 30-second timeout window from every monitoring node during a given one-minute polling interval. This is a deliberately conservative definition that minimizes false positives. If even one node reports the service as available during a polling interval, that interval is not counted as an outage minute.

Status Classifications. Sentinel distinguishes among three service-status classifications:

• Full Outage: Complete service unavailability as confirmed by all six monitoring nodes. This corresponds to the contractual definition of "Downtime" under Exhibit C, Section 1.1.

• Degraded Performance: The platform is accessible and functional (i.e., it returns successful HTTP 200 responses), but response times exceed contractual performance thresholds. Typical symptoms include elevated API response latency, slow page loads, and extended query execution times. Under the MSA, degraded performance triggers separate P1 incident response-time SLAs (acknowledgment within 15 minutes, resolution or workaround within 2 hours) but does not constitute "Downtime" for purposes of the uptime percentage calculation.

• Partial Outage: A subset of platform features or API endpoints is unavailable while the core platform remains accessible. Sentinel logs partial outages separately and does not count them as full-outage minutes unless the core platform functionality is wholly unavailable.

This tripartite classification is directly relevant to the discrepancies identified in this analysis because, as discussed below, Pinnacle appears to have treated degraded-performance periods and partial outages as equivalent to full outages, thereby inflating its claimed downtime durations.

Contractual Alignment. Exhibit C, Section 1.1 of the MSA defines "Downtime" as any period during which the Lumos platform is "wholly unavailable" to the customer, exclusive of scheduled maintenance windows (which are governed by Section 2.2 and require 72 hours' advance notice). This definition aligns precisely with Sentinel's "full outage" classification. Periods of degraded performance — even severe degraded performance — do not satisfy the "wholly unavailable" standard and therefore do not count toward the uptime percentage calculation under the SLA.

B. Pinnacle's Measurement Methodology (as Inferred from Demand Letter and Supporting Exhibits)

Pinnacle's May 1, 2023 demand letter does not describe in detail the monitoring tools, measurement protocols, or data sources used to derive its claimed outage durations. Based on our review of the demand letter and its supporting exhibits, we infer the following about Pinnacle's methodology:

First, Pinnacle appears to have measured downtime based on its own internal user-experience reports and help-desk ticket timestamps. The demand letter references "user-reported service disruptions" and attaches summaries of internal help-desk tickets opened by Pinnacle employees during each incident. Help-desk ticket timestamps — recording when users first reported problems and when they reported that service had been restored — appear to serve as Pinnacle's primary data points for calculating outage start and end times.

Second, Pinnacle's methodology appears to include periods of degraded performance (slow response times and elevated latency) and partial outages (individual feature unavailability) within its definition of "downtime." This is evident from the demand letter's own descriptions of the incidents, which frequently reference "severely degraded performance" and "unacceptable response times" alongside periods of complete unavailability, without distinguishing between the two for purposes of the uptime calculation. This conflation systematically inflates Pinnacle's claimed durations.

Third, Pinnacle's measurements do not appear to distinguish between downtime attributable to the Lumos platform and downtime attributable to Pinnacle's own infrastructure or third-party service providers. This is particularly relevant to Incident INC-5033, where — as discussed below — a significant portion of the claimed downtime was caused by a configuration change implemented by Pinnacle's own IaaS provider, Brindoval Cloud Infrastructure LLC. Under Exhibit C, Section 2.3 ("Exclusions from Uptime Calculation"), such third-party-caused downtime is expressly excluded from the uptime calculation.

Fourth, Pinnacle has not produced its raw monitoring data or described its measurement tools in its demand letter. The absence of this information makes it impossible to independently verify Pinnacle's claimed durations or to assess the reliability and precision of Pinnacle's measurement methodology. As discussed in the Recommendations section below, we should seek production of this data in any discovery or mediation exchange.

C. Reconciliation Approach

For each of the four incidents, this memorandum presents a side-by-side comparison of the following data points:

1. Sentinel's recorded full-outage duration — the total minutes during which Sentinel recorded a full outage (all six monitoring nodes reporting unavailability) during the incident window;

2. Pinnacle's claimed duration — the outage duration stated in Pinnacle's demand letter and supporting exhibits;

3. The resulting uptime percentage under each party's figures — calculated using total minutes in the relevant calendar month as the denominator; and

4. The corresponding SLA credit tier — determined by reference to the tiered credit structure in Exhibit C, Section 3.2.

Uptime percentages are calculated using the following denominators for each relevant calendar month:

• October 2022: 31 days × 24 hours × 60 minutes = 44,640 total minutes

• November 2022: 30 days × 24 hours × 60 minutes = 43,200 total minutes

• January 2023: 31 days × 24 hours × 60 minutes = 44,640 total minutes

• March 2023: 31 days × 24 hours × 60 minutes = 44,640 total minutes

The uptime formula applied throughout this memorandum is:

Uptime % = [(Total Month Minutes − Full Outage Minutes) / Total Month Minutes] × 100

None of the four affected months had any scheduled maintenance windows that would need to be excluded from the denominator under Exhibit C, Section 2.2. Accordingly, the full calendar-month minute totals are used without adjustment.

IV. Incident-by-Incident Analysis

A. Incident INC-4471 (October 12–13, 2022)

1. Pinnacle's Claimed Data. Pinnacle's demand letter asserts that Incident INC-4471 caused a service outage lasting 7 hours and 42 minutes (462 minutes), beginning at approximately 11:18 PM EDT on October 12, 2022 and concluding at approximately 7:00 AM EDT on October 13, 2022. Based on this claimed duration, Pinnacle calculates the October 2022 monthly uptime as follows:

Uptime = (44,640 − 462) / 44,640 × 100 = 98.97%

Pinnacle's demand letter states a claimed uptime of 98.93% for October 2022, which differs slightly from the arithmetic result of 98.97% and may reflect rounding or a slightly different minute count. Regardless, Pinnacle places October 2022 uptime below the 99.00% threshold and claims the maximum SLA credit tier of 30% of the monthly fee, yielding a claimed credit of $36,000.

2. Sentinel's Recorded Data. Sentinel's telemetry data for October 2022 records the INC-4471 incident as a full outage lasting 4 hours and 11 minutes (251 minutes). Sentinel's incident log shows the full outage commencing at 11:18 PM EDT on October 12, 2022 — consistent with Pinnacle's reported start time — and full service restoration occurring at 3:29 AM EDT on October 13, 2022. All six Sentinel monitoring nodes confirmed service availability by 3:29 AM EDT.

Based on Sentinel's recorded duration, the October 2022 monthly uptime is calculated as follows:

Uptime = (44,640 − 251) / 44,640 × 100 = 99.44%

A monthly uptime of 99.44% falls within the 99.00%–99.49% credit tier under Exhibit C, Section 3.2, yielding an SLA credit of 20% of the monthly fee, or $24,000. This is $12,000 less than Pinnacle's claimed $36,000 credit for this incident.

3. Discrepancy Analysis. The discrepancy between Pinnacle's claimed duration and Sentinel's recorded duration for INC-4471 is 3 hours and 31 minutes (211 minutes). This is a significant discrepancy that materially affects the applicable credit tier, moving the October 2022 uptime from below 99.00% (Pinnacle's calculation) to the 99.00%–99.49% range (Sentinel's calculation) and reducing the credit from $36,000 to $24,000.

The source of the discrepancy can be identified with reasonable confidence from Sentinel's detailed telemetry logs. Sentinel's data shows that full service was restored at 3:29 AM EDT on October 13, 2022, approximately 3 hours and 31 minutes before the 7:00 AM EDT timestamp that Pinnacle cites as the end of the outage. During the intervening 211-minute window (3:29 AM to 7:00 AM EDT), Sentinel's monitoring nodes recorded the Lumos platform as available — the primary API endpoint was returning successful HTTP 200 responses — but Sentinel's degraded-performance alerts were active throughout this period. Specifically, Sentinel's response-time monitoring shows that API response latency during this window ranged between 3 seconds and 8 seconds, well above the normal baseline of less than 500 milliseconds but still within the range of a functioning, accessible platform.

This pattern is consistent with a post-outage recovery period during which the platform was back online and functional but operating at reduced performance levels as backend systems (caches, connection pools, query optimizers) re-warmed following the outage. Such degraded-performance periods are common following significant outages and are a well-understood phenomenon in production SaaS environments.

Under Exhibit C, Section 1.1 of the MSA, "Downtime" is defined as periods during which the Lumos platform is "wholly unavailable" to the customer. The 211-minute degraded-performance period following the INC-4471 outage does not meet this definition. The platform was accessible, API calls were succeeding, and users could perform core functions — albeit with slower-than-normal response times. Degraded performance may trigger separate P1 incident response-time SLAs under the MSA, but it does not constitute "Downtime" for purposes of the monthly uptime percentage calculation.

Accordingly, the inclusion of this 211-minute degraded-performance period in Pinnacle's claimed outage duration is inconsistent with the contractual definition of "Downtime" and results in an overstated credit claim.

Timeliness Issue. In addition to the duration discrepancy, we note a significant procedural issue with Pinnacle's credit request for INC-4471. Under Exhibit C, Section 3.5, Pinnacle was required to submit its written credit request within 30 calendar days following the end of the affected calendar month (October 2022). The 30-day deadline expired on November 30, 2022. However, Pinnacle did not submit its credit request for INC-4471 until December 14, 2022 — 44 days after the end of October 2022 and 14 days past the contractual deadline. Under Section 3.5, failure to submit a timely credit request constitutes a waiver of the applicable credit. This timeliness defense is addressed in detail in the Contractual Limitations Memorandum but is noted here for completeness as it has the potential to eliminate the INC-4471 credit entirely.

4. Conclusion. Based on Sentinel's independently recorded telemetry data, the correct SLA credit for Incident INC-4471 is $24,000 (20% of the monthly fee), assuming the credit request is deemed timely — a proposition that Lumos disputes. This represents a $12,000 reduction from Pinnacle's claimed credit of $36,000. If the timeliness defense succeeds, the credit for this incident would be $0.

B. Incident INC-4602 (November 28, 2022)

1. Pinnacle's Claimed Data. Pinnacle's demand letter asserts that Incident INC-4602 caused a service outage lasting 3 hours and 18 minutes (198 minutes) on November 28, 2022. Based on this claimed duration, Pinnacle calculates the November 2022 monthly uptime as follows:

Uptime = (43,200 − 198) / 43,200 × 100 = 99.54%

Pinnacle places November 2022 uptime within the 99.50%–99.89% credit tier and claims a credit of 10% of the monthly fee, yielding a claimed credit of $12,000.

2. Sentinel's Recorded Data. Sentinel's telemetry data for November 2022 records the INC-4602 incident as a full outage lasting 1 hour and 47 minutes (107 minutes). Sentinel's incident log shows the full outage commencing at 2:14 PM EST on November 28, 2022 and full service restoration occurring at 4:01 PM EST on the same day. All six monitoring nodes confirmed platform availability by 4:01 PM EST.

Based on Sentinel's recorded duration, the November 2022 monthly uptime is calculated as follows:

Uptime = (43,200 − 107) / 43,200 × 100 = 99.75%

A monthly uptime of 99.75% yields an SLA credit of 5% of the monthly fee under the applicable tier, resulting in a credit of $6,000. This is $6,000 less than Pinnacle's claimed $12,000 credit for this incident.

3. Discrepancy Analysis. The discrepancy between Pinnacle's claimed duration and Sentinel's recorded duration for INC-4602 is 1 hour and 31 minutes (91 minutes). While this is the smallest discrepancy in absolute terms among the four incidents, it is proportionally significant — Pinnacle's claimed duration is approximately 85% longer than the actual full-outage duration recorded by Sentinel.

The pattern here mirrors that observed in INC-4471. Sentinel's telemetry data shows that following full service restoration at 4:01 PM EST, the platform entered a degraded-performance state lasting approximately 90 minutes. During this period, Sentinel's response-time monitoring recorded elevated API response latency ranging between 2 seconds and 5 seconds, compared to the normal baseline of less than 500 milliseconds. However, the platform was fully accessible throughout this period — synthetic transaction checks from all six nodes returned successful HTTP 200 responses, and RUM data confirmed that end users were able to access core platform functionality.

Once again, under Exhibit C, Section 1.1, this degraded-performance period does not satisfy the "wholly unavailable" standard required to constitute "Downtime" for purposes of the uptime percentage calculation. The inclusion of this 91-minute degraded-performance tail in Pinnacle's claimed outage duration inflates the claim beyond the contractually defined measurement.

We also note that Pinnacle's credit request for INC-4602 was submitted on December 22, 2022, which is within the 30-calendar-day deadline following the end of November 2022 (deadline: December 30, 2022). There is accordingly no timeliness defense available for this incident.

4. Conclusion. Based on Sentinel's independently recorded telemetry data, the correct SLA credit for Incident INC-4602 is $6,000 (5% of the monthly fee). This represents a $6,000 reduction from Pinnacle's claimed credit of $12,000.

C. Incident INC-4815 (January 9–10, 2023)

1. Pinnacle's Claimed Data. Pinnacle's demand letter asserts that Incident INC-4815 caused a service outage lasting 11 hours and 5 minutes (665 minutes), beginning on the evening of January 9, 2023 and extending into January 10, 2023. Based on this claimed duration, Pinnacle calculates the January 2023 monthly uptime as follows:

Uptime = (44,640 − 665) / 44,640 × 100 = 98.51%

Pinnacle's demand letter states a claimed uptime of 98.47% for January 2023. The minor difference from the arithmetic result likely reflects Pinnacle's rounding or a slightly different minute count. In either case, Pinnacle places January 2023 uptime below the 99.00% threshold and claims the maximum SLA credit tier of 30% of the monthly fee, yielding a claimed credit of $36,000.

2. Sentinel's Recorded Data. Sentinel's telemetry data for January 2023 records the INC-4815 incident as a full outage lasting 6 hours and 22 minutes (382 minutes). Sentinel's data reveals that the incident comprised two distinct outage windows:

• Primary Outage Window: Commencing at 9:47 PM EST on January 9, 2023 and ending at 3:22 AM EST on January 10, 2023 (approximately 5 hours and 35 minutes).

• Secondary Disruption: Following initial restoration at 3:22 AM EST, the platform operated normally for approximately 18 minutes before experiencing a brief secondary disruption from 3:40 AM EST to 4:27 AM EST (approximately 47 minutes), caused by a residual issue in the database replication layer that had not been fully resolved during the initial incident response.

The combined full-outage time across both windows totals 6 hours and 22 minutes (382 minutes). Based on this recorded duration, the January 2023 monthly uptime is calculated as follows:

Uptime = (44,640 − 382) / 44,640 × 100 = 99.14%

A monthly uptime of 99.14% falls within the 99.00%–99.49% credit tier under Exhibit C, Section 3.2, yielding an SLA credit of 20% of the monthly fee, or $24,000. This is $12,000 less than Pinnacle's claimed $36,000 credit for this incident.

3. Discrepancy Analysis. The discrepancy between Pinnacle's claimed duration and Sentinel's recorded duration for INC-4815 is 4 hours and 43 minutes (283 minutes). This substantial discrepancy moves the January 2023 uptime from below 99.00% (Pinnacle's calculation) to the 99.00%–99.49% range (Sentinel's calculation), resulting in a one-tier reduction in the applicable credit.

Sentinel's detailed telemetry data indicates that the 283-minute discrepancy is attributable to two factors:

Degraded Performance Periods. Consistent with the pattern observed in INC-4471 and INC-4602, Pinnacle's claimed duration appears to include degraded-performance periods both between the two outage windows and following final service restoration. Sentinel's response-time monitoring shows elevated latency during these windows, but the platform remained accessible and functional. Under Exhibit C, Section 1.1, these periods do not constitute "Downtime."

Customer-Side Connectivity Issues. Sentinel's per-node telemetry data reveals that during a portion of the period Pinnacle claims as downtime, the Lumos platform was accessible from all six Sentinel monitoring nodes but may have been intermittently inaccessible from Pinnacle's specific network environment. This pattern is consistent with connectivity issues on Pinnacle's side of the network path — potentially involving Pinnacle's own corporate network, firewall configuration, or VPN infrastructure — rather than unavailability of the Lumos platform itself. Exhibit C, Section 2.3 ("Exclusions from Uptime Calculation") expressly excludes from the uptime calculation any downtime "attributable to Customer's infrastructure, Customer's third-party service providers, or any services not provided by [Lumos]." To the extent that a portion of the claimed INC-4815 downtime was caused by Pinnacle-side connectivity issues, that time is excluded under Section 2.3.

Failure to Activate DR Failover. We also note that Pinnacle had the contractual right and technical ability to activate failover to Lumos's designated disaster-recovery environment in the US-West-2 region during this incident. Under the MSA's Business Continuity provisions (Exhibit D, Section 4.2), Lumos maintains a hot-standby disaster-recovery environment in a geographically separate Meridian Technologies region (US-West-2, Oregon), and Pinnacle's technical team has been provided with documented failover procedures and credentials. Pinnacle did not activate this failover during INC-4815. Had Pinnacle done so, the effective downtime experienced by Pinnacle's end users would have been substantially shorter — likely limited to the failover activation time (typically 10–15 minutes per the documented procedure). While this is primarily a mitigation defense (addressed in separate memoranda), it also explains part of the measurement discrepancy: Pinnacle continued to measure downtime against the primary production environment without accounting for the availability of the DR environment.

4. Conclusion. Based on Sentinel's independently recorded telemetry data, the correct SLA credit for Incident INC-4815 is $24,000 (20% of the monthly fee). This represents a $12,000 reduction from Pinnacle's claimed credit of $36,000.

D. Incident INC-5033 (March 3–5, 2023)

1. Pinnacle's Claimed Data. Pinnacle's demand letter asserts that Incident INC-5033 caused a service outage lasting 26 hours and 31 minutes (1,591 minutes), beginning on March 3, 2023 and extending through March 5, 2023. This is by far the longest and most consequential of the four claimed incidents, and it forms the foundation of Pinnacle's most significant consequential damages claims.

Based on this claimed duration, Pinnacle calculates the March 2023 monthly uptime as approximately:

Uptime = (44,640 − 1,591) / 44,640 × 100 ≈ 96.44%

Pinnacle's demand letter states a claimed uptime of 96.32% for March 2023. The discrepancy between the arithmetic result (approximately 96.44%) and Pinnacle's stated figure (96.32%) may be attributable to rounding, a different minute-count methodology, or the use of a slightly different denominator. Regardless of the precise figure, Pinnacle places March 2023 uptime well below the 99.00% threshold and claims the maximum SLA credit tier of 30% of the monthly fee, yielding a claimed credit of $36,000.

2. Sentinel's Recorded Data. Sentinel's telemetry data for March 2023 records the INC-5033 incident as a full outage lasting 14 hours and 8 minutes (848 minutes). This is substantially less than Pinnacle's claimed 26 hours and 31 minutes, representing a discrepancy of more than 12 hours.

Sentinel's incident log shows the full outage commencing at 1:36 AM EST on March 3, 2023 and total service restoration occurring at 3:44 PM EST on March 3, 2023, with the full-outage minutes during that window totaling 848 minutes when accounting for brief intervals of partial restoration that occurred during the incident response.

Based on Sentinel's recorded duration, the March 2023 monthly uptime is calculated as follows:

Uptime = (44,640 − 848) / 44,640 × 100 ≈ 98.10%

Sentinel's formal monthly availability report for March 2023 states an uptime of 98.04%, which is slightly lower than the strict arithmetic result of 98.10%. This minor discrepancy likely reflects sub-minute partial outage intervals or Sentinel's application of its standard rounding methodology to the raw per-minute data. For purposes of this analysis, we use Sentinel's reported figure of 98.04%.

A monthly uptime of 98.04% falls below the 99.00% threshold, placing it in the maximum credit tier of 30% of the monthly fee, or $36,000. Notably, both parties' calculations result in the same credit tier for this incident — the disagreement relates to the magnitude of the downtime and the resulting uptime percentage, not to the applicable credit amount. However, the dramatically different uptime percentages (Pinnacle's 96.32% vs. Sentinel's 98.04%) are highly relevant to the broader dispute because Pinnacle's consequential damages claims rely in significant part on the severity and duration of the INC-5033 outage as characterized in its demand letter.

3. Discrepancy Analysis. The discrepancy between Pinnacle's claimed duration and Sentinel's recorded duration for INC-5033 is 12 hours and 23 minutes (743 minutes) — by far the largest discrepancy among the four incidents, both in absolute terms and as a proportion of the claimed duration. Pinnacle's claimed duration is approximately 88% longer than the full-outage duration recorded by Sentinel.

This discrepancy has a distinct and critically important causation element that distinguishes it from the other three incidents. Specifically, the discrepancy is primarily attributable to a configuration change implemented by Pinnacle's own infrastructure-as-a-service provider, Brindoval Cloud Infrastructure LLC.

Root-Cause Analysis. Sentinel's detailed root-cause analysis, corroborated by Lumos's internal incident post-mortem report (prepared by Thomas Kwan, VP of Engineering / SRE, dated March 12, 2023), indicates that the INC-5033 incident involved two overlapping but distinct causes:

(a) Lumos-Side Database Failure (14 hours 8 minutes). The genuine Lumos-side component of the INC-5033 incident was a cascading failure in Lumos's database replication layer, triggered by an unexpected surge in write operations that overwhelmed the primary database cluster's replication capacity. This failure caused the Lumos platform to become wholly unavailable to all customers — not just Pinnacle — for a period of 14 hours and 8 minutes. Lumos acknowledges this outage and does not dispute that it constitutes "Downtime" under Exhibit C, Section 1.1.

(b) Brindoval-Caused Routing Disruption (approximately 12+ hours). During the same general timeframe, Brindoval Cloud Infrastructure LLC implemented a network configuration change in its cloud environment that disrupted BGP (Border Gateway Protocol) routing between Pinnacle's Brindoval-hosted cloud environment and Lumos's production servers hosted on a separate cloud infrastructure. This routing disruption caused the Lumos platform to be inaccessible specifically from Pinnacle's network environment for a period extending well beyond the resolution of the Lumos-side database failure.

Sentinel's Multi-Node Data Confirms the Brindoval Causation. The most compelling evidence for the Brindoval causation theory comes from Sentinel's per-node telemetry data. Sentinel's six monitoring nodes are located in diverse geographic and network environments and access the Lumos platform through independent network paths. During the period that Pinnacle claims as continued downtime (i.e., the approximately 12 hours following Lumos's restoration of service at 3:44 PM EST on March 3, 2023), Sentinel's monitoring data shows the following:

• All six Sentinel monitoring nodes — including nodes in US-East, US-West, US-Central, EU-West, APAC-East, and APAC-South — recorded the Lumos platform as fully available and responsive following restoration at 3:44 PM EST on March 3, 2023.

• No Sentinel monitoring node recorded any full-outage minutes after 3:44 PM EST on March 3, 2023 through the end of the claimed outage window on March 5, 2023.

• Sentinel's RUM data confirms that other Lumos customers (accessing the platform from non-Brindoval environments) experienced normal service during this same period.

This data strongly supports the conclusion that the Lumos platform was restored and available to the broader customer base by 3:44 PM EST on March 3, 2023, and that Pinnacle's continued inability to access the platform after that time was caused by the Brindoval routing disruption — not by any ongoing unavailability of the Lumos platform itself.

Contractual Exclusion Under §2.3. Exhibit C, Section 2.3 ("Exclusions from Uptime Calculation") expressly provides that the following categories of downtime are excluded from the monthly uptime calculation:

> "Unavailability attributable to Customer's infrastructure, Customer's third-party service providers, or any services not provided by Provider; connectivity or network issues beyond Provider's network demarcation point; or Force Majeure events as defined in Section 14.1 of the Agreement."

Brindoval Cloud Infrastructure LLC is Pinnacle's third-party infrastructure-as-a-service provider. The Brindoval-caused routing disruption falls squarely within the Section 2.3 exclusion as downtime "attributable to Customer's third-party service providers." Accordingly, the approximately 12 hours of Brindoval-caused inaccessibility should be excluded from the uptime calculation, and only the 14 hours and 8 minutes of genuine Lumos-side downtime should be counted.

Failure to Activate DR Failover. As with INC-4815, Pinnacle did not activate the contractual DR failover to Lumos's US-West-2 disaster-recovery environment during INC-5033. This is particularly significant for the INC-5033 incident because the DR environment — hosted in a different Meridian Technologies region with a different network path — may well have been accessible from Pinnacle's environment even during the Brindoval routing disruption (since the routing disruption specifically affected the path between Brindoval and Lumos's primary production environment). Pinnacle's failure to activate this failover both exacerbated the impact of the incident on Pinnacle's operations and contributed to the inflation of Pinnacle's claimed downtime duration.

4. Conclusion. Based on Sentinel's independently recorded telemetry data, the correct SLA credit for Incident INC-5033 is $36,000 (30% of the monthly fee). Both parties' calculations fall within the same credit tier (below 99.00%), so the credit amount is identical regardless of which party's figures are used.

However, the dramatic discrepancy in uptime percentages (Pinnacle's 96.32% vs. Sentinel's 98.04%) is highly significant for several reasons beyond the immediate credit calculation. First, it demonstrates that Pinnacle's characterization of the severity and duration of the INC-5033 incident is materially overstated, undermining the foundation of Pinnacle's consequential damages claims. Second, the Brindoval causation theory, supported by Sentinel's multi-node data, provides a strong basis for arguing under Exhibit C, Section 2.3 that a substantial portion of the claimed downtime should be excluded from the uptime calculation entirely — which could potentially eliminate or substantially reduce even the $36,000 credit. This third-party causation argument is preserved for further briefing and development as the dispute progresses.

V. Summary Comparison Table

The following table summarizes the incident-by-incident comparison between Pinnacle's claimed outage data and Sentinel's independently recorded telemetry:

Net Difference in SLA Credits: $120,000 (Pinnacle's claim) − $90,000 (Lumos's calculation) = $30,000 overstatement by Pinnacle.

The $90,000 figure calculated using Sentinel's data represents a maximum figure that does not account for two additional defenses:

(a) Timeliness Defense — INC-4471. Pinnacle's credit request for INC-4471 was submitted on December 14, 2022, which is 44 days after the end of October 2022 and 14 days past the 30-calendar-day deadline prescribed by Exhibit C, Section 3.5. If this defense is sustained, the $24,000 credit for INC-4471 is eliminated.

(b) Third-Party Causation Defense — INC-5033. As detailed in Section IV.D above, the predominant portion of the claimed INC-5033 downtime (approximately 12 hours of the 26 hours 31 minutes claimed, and a significant portion of even the 14 hours 8 minutes recorded by Sentinel to the extent the Brindoval disruption overlapped with the Lumos-side failure) is attributable to a configuration change by Pinnacle's own cloud provider, Brindoval Cloud Infrastructure LLC. Under Exhibit C, Section 2.3, such third-party-caused downtime is excluded from the uptime calculation. If this defense is sustained, the $36,000 credit for INC-5033 could be eliminated or substantially reduced.

Minimum Exposure Scenario. If both the timeliness defense on INC-4471 and the third-party causation defense on INC-5033 are successful, Lumos's total SLA credit exposure across all four incidents would be limited to $30,000, comprising only:

• INC-4602: $6,000

• INC-4815: $24,000

• Total: $30,000

This represents a 75% reduction from Pinnacle's claimed $120,000 in SLA credits.

VI. Key Observations on Measurement Methodology Differences

The systematic nature of the discrepancies between Pinnacle's claimed durations and Sentinel's recorded durations warrants several overarching observations regarding the parties' respective measurement methodologies. These observations are relevant not only to the SLA credit dispute but also to the broader credibility of Pinnacle's damages claims.

A. Definition of "Downtime" Under Exhibit C, §1.1

The MSA establishes a precise, contractual definition of "Downtime" in Exhibit C, Section 1.1, which governs the uptime percentage calculation. Under this definition, "Downtime" means periods during which the Lumos platform is "wholly unavailable" to the customer. Degraded performance — including slow response times, elevated latency, extended query execution times, and similar performance impairments — does not constitute "Downtime" for purposes of the uptime calculation, even when the degraded performance is severe.

This distinction is critically important because degraded performance triggers a separate remedial framework under the MSA. Specifically, degraded performance constitutes a Priority 1 ("P1") incident that triggers response-time SLAs requiring Lumos to acknowledge the incident within 15 minutes and to provide a resolution or workaround within 2 hours. The P1 response-time SLAs are governed by Exhibit C, Section 4.1 and carry their own remedial provisions. The uptime-based SLA credit structure in Section 3.2 is distinct from and in addition to the P1 response-time framework, and the two should not be conflated.

Pinnacle's measurements appear to systematically conflate full outages with degraded-performance periods, treating any period during which platform performance was impaired — regardless of whether the platform was actually unavailable — as "Downtime" for purposes of the uptime calculation. This conflation is evident across all four incidents and accounts for a significant portion of the aggregate 22-hour-and-8-minute discrepancy between Pinnacle's claimed durations and Sentinel's recorded durations. In INC-4471, the additional 211 minutes correspond to a degraded-performance tail. In INC-4602, the additional 91 minutes correspond to a similar degraded-performance tail. In INC-4815, the additional 283 minutes include both degraded-performance periods and customer-side connectivity issues. In INC-5033, the majority of the additional 743 minutes is attributable to third-party infrastructure issues, though degraded-performance periods likely account for a portion as well.

B. Third-Party Infrastructure Exclusion (§2.3)

Exhibit C, Section 2.3 establishes a clear exclusion from the uptime calculation for any downtime attributable to customer infrastructure, customer third-party service providers, or services not provided by Lumos. This exclusion reflects the fundamental principle that Lumos can only be held accountable for the availability of its own platform and infrastructure; it cannot be responsible for disruptions caused by the customer's own systems, network configuration, or third-party providers.

This exclusion is most directly relevant to Incident INC-5033, where the evidence strongly supports the conclusion that a Brindoval Cloud Infrastructure LLC configuration change disrupted network routing between Pinnacle's environment and Lumos's production servers, causing the Lumos platform to be inaccessible specifically from Pinnacle's network for approximately 12 hours after Lumos had restored service to its broader customer base. Sentinel's multi-node telemetry data confirms that the platform was accessible from all six geographically distributed monitoring nodes during this period, demonstrating that the unavailability was specific to Pinnacle's network path — not a platform-wide outage.

Pinnacle's measurements do not appear to distinguish between Lumos-caused downtime and Brindoval-caused downtime. Pinnacle's demand letter and supporting exhibits present the INC-5033 outage as a single, continuous 26-hour-31-minute disruption attributable entirely to Lumos, without acknowledging or accounting for the Brindoval routing disruption that was the predominant cause of the extended inaccessibility from Pinnacle's environment.

This failure to disaggregate Lumos-caused and Brindoval-caused downtime is not merely a methodological deficiency — it is inconsistent with the express terms of the SLA. If Pinnacle intends to maintain its claim that the full 26 hours and 31 minutes constitutes "Downtime" attributable to Lumos, it bears the burden of demonstrating that the Section 2.3 exclusion does not apply, which will require Pinnacle to explain why its own third-party provider's configuration change should be treated as Lumos-caused downtime.

C. Monitoring Data Provenance and Reliability

The relative reliability and credibility of the parties' respective data sources is a critical consideration in evaluating the competing outage-duration claims.

Sentinel's Data. Sentinel Uptime Services Inc. is an independent third-party vendor retained by Lumos for the specific purpose of monitoring platform availability. Sentinel has no financial interest in the outcome of this dispute — its monitoring contract with Lumos is a fixed-fee engagement that does not vary based on uptime results. Sentinel's data is generated automatically at fixed one-minute intervals using standardized monitoring protocols, stored in Sentinel's own infrastructure (separate from Lumos's systems), and contemporaneously logged with tamper-evident audit trails that prevent after-the-fact modification. Sentinel's methodology — six-node consensus-based outage detection with a 30-second timeout window — is conservative, well-documented, and industry-standard.

Pinnacle's Data. By contrast, Pinnacle's claimed durations appear to be derived from internal user reports and help-desk ticketing systems. These data sources are inherently less precise and less reliable than automated monitoring telemetry for several reasons. First, help-desk ticket timestamps depend on human judgment about when to open and close tickets, introducing subjectivity and imprecision into the measurement of outage start and end times. Second, user-experience reports are influenced by factors other than platform availability, including local network conditions, browser configuration, VPN connectivity, and individual user perception of performance. Third, Pinnacle has not produced its raw monitoring data, has not identified the specific tools or protocols used to measure availability, and has not described any quality-assurance measures applied to its duration calculations.

The superiority of Sentinel's data as an objective, independent, automated record of platform availability is a significant strength for Lumos's defense. In any mediation or litigation proceeding, Sentinel's data is likely to be viewed as substantially more credible than Pinnacle's internally generated help-desk records.

D. Disaster Recovery Failover (US-West-2) — Mitigation Failure

For both Incident INC-4815 and Incident INC-5033, Pinnacle had the contractual right and documented technical ability to activate failover to Lumos's designated disaster-recovery environment in the US-West-2 region (Oregon). The DR environment is maintained as a hot-standby replica of the production environment, with documented failover procedures and pre-provisioned credentials provided to Pinnacle's technical operations team. The documented failover activation time is typically 10 to 15 minutes.

Pinnacle did not activate this failover capability for either incident. Had Pinnacle done so, the effective downtime experienced by Pinnacle's end users would have been substantially reduced. In the case of INC-5033, the DR failover may have been particularly effective because the US-West-2 environment — hosted in a separate Meridian Technologies region with an independent network path — may not have been affected by the Brindoval-caused routing disruption that prevented access to the primary production environment.

While Pinnacle's failure to activate the DR failover is primarily relevant as a mitigation defense (which is addressed in separate memoranda being prepared by the engagement team), it also contributes to the measurement discrepancy at issue in this memorandum. Pinnacle's measurement of downtime was conducted against the primary production environment only, without acknowledging or accounting for the availability of the contractually provided DR environment. A proper assessment of the "downtime" experienced by Pinnacle should consider the totality of the service infrastructure made available to Pinnacle under the MSA, including the DR environment.

VII. Impact on Lumos's Overall Exposure Analysis

This uptime data analysis has significant implications for Lumos's overall exposure in the pending dispute with Pinnacle. Pinnacle's total demand, as set forth in its May 1, 2023 demand letter, is $2,870,000, comprising the following components:

SLA Credit Component. As demonstrated in this memorandum, the SLA credit component of Pinnacle's demand is overstated by at least $30,000. Sentinel's independently recorded telemetry data supports total SLA credits of $90,000, not $120,000. If the timeliness defense on INC-4471 and the third-party causation defense on INC-5033 are both successful, SLA credit exposure drops further to $30,000 — a 75% reduction from Pinnacle's claimed amount.

Consequential Damages and Additional Claims ($2,750,000). The consequential damages, remediation costs, and reputational harm claims — totaling $2,750,000 — are subject to several independent contractual defenses that are addressed in separate memoranda but are summarized here for completeness:

• Mutual Waiver of Consequential Damages (§11.3). Section 11.3 of the MSA contains a mutual waiver of indirect, incidental, special, consequential, and lost-profits damages. This waiver bars Pinnacle's $1,950,000 consequential damages claim and its $460,000 reputational harm claim in their entirety.

• Aggregate Liability Cap (§11.2). Section 11.2 of the MSA limits each party's aggregate liability under the Agreement to an amount equal to the total fees paid or payable during the twelve-month period immediately preceding the claim, yielding a cap of $1,440,000. Even if the consequential damages waiver were not applicable (which we do not concede), Pinnacle's total demand of $2,870,000 far exceeds this contractual ceiling.

• SLA Credit Cap (§3.4). Exhibit C, Section 3.4 provides that maximum SLA credits in any rolling twelve-month period shall not exceed 30% of the annual subscription fee, or $432,000. This cap provides an additional constraint on Lumos's credit exposure independent of the per-incident analysis.

• Exclusive Remedy (§3.6). Exhibit C, Section 3.6 provides that SLA credits constitute the customer's sole and exclusive remedy for any failure by Lumos to meet the uptime commitment. This provision, if enforced, would bar all of Pinnacle's claims beyond the SLA credit amount.

Overall Assessment. The Sentinel data materially strengthens Lumos's defense position across the entire dispute. By demonstrating that Pinnacle's claimed outage durations are systematically overstated — by a cumulative total of more than 22 hours — the data undermines not only Pinnacle's SLA credit calculations but also the factual predicate for its consequential damages claims, which are premised on the severity and duration of the outages as characterized in the demand letter. If the actual outages were materially shorter than Pinnacle claims (as Sentinel's data shows), then the downstream business impacts that Pinnacle attributes to those outages are necessarily overstated as well.

VIII. Recommendations

Based on the foregoing analysis, I recommend the following action items for the engagement team's consideration:

1. Preserve All Sentinel Data. Ensure that all raw telemetry exports, incident logs, availability reports, and associated metadata from Sentinel Uptime Services Inc. for the period September 2022 through April 2023 are fully preserved under the litigation hold issued on May 15, 2023. The litigation hold was communicated to Adriana Voss (General Counsel, Lumos), Thomas Kwan (VP of Engineering / SRE, Lumos), and Rachel Dominguez (Director of IT Operations, Lumos). Confirm with Lumos's legal team that Sentinel has been notified of the preservation obligation and that Sentinel's standard data-retention policies will not result in deletion or overwriting of the relevant data during the pendency of this dispute. Given the criticality of this data, we should request that Lumos obtain a written confirmation from Sentinel that the data has been placed on preservation hold.

2. Obtain a Declaration or Certification from Brenda Hale. Contact Brenda Hale, Director of Client Engineering at Sentinel Uptime Services Inc., and arrange for the preparation of a sworn declaration or formal certification confirming: (a) Sentinel's monitoring methodology, including polling frequency, node distribution, outage-detection criteria, and status classification definitions; (b) the integrity and authenticity of the data produced for this engagement, including confirmation that the data has not been altered or modified since its original recording; (c) the independence of Sentinel's monitoring infrastructure from Lumos's own systems; and (d) Sentinel's data retention and audit trail practices. This declaration should be prepared in a form suitable for submission in mediation, arbitration, or litigation proceedings. We should coordinate with Sentinel's legal department to ensure the declaration is appropriately reviewed before execution.

3. Request Pinnacle's Monitoring Data. In any discovery exchange, mediation information request, or pre-litigation correspondence, demand that Pinnacle produce: (a) the raw monitoring data and system logs underlying its claimed outage durations for all four incidents; (b) documentation of the monitoring tools, measurement protocols, and methodologies used by Pinnacle to determine outage start and end times; (c) all internal help-desk tickets, user-experience reports, and incident reports relating to the four incidents; and (d) any communications with Brindoval Cloud Infrastructure LLC regarding the March 3–5, 2023 routing disruption. Exposing Pinnacle's methodological deficiencies — particularly its apparent conflation of full outages with degraded performance — will be essential to establishing that Pinnacle's claimed durations are unreliable and contractually unfounded.

4. Request Brindoval Cloud Infrastructure LLC Records. Obtain or, if necessary, subpoena Brindoval Cloud Infrastructure LLC's change management logs, incident reports, network configuration change records, and customer notifications for the March 3–5, 2023 period. These records are essential to substantiating the third-party causation defense for INC-5033. Brindoval's own documentation of the BGP routing change that disrupted connectivity between Pinnacle's environment and Lumos's production servers would provide powerful corroboration of the Sentinel telemetry data showing that the Lumos platform was accessible from non-Pinnacle environments during the disputed period. We should also investigate whether Pinnacle received any notification or incident report from

ATTORNEY-CLIENT PRIVILEGED AND CONFIDENTIAL — ATTORNEY WORK PRODUCT
MEMORANDUM
TO: Simone Laroche, Lead Associate, Calderwood & Harkness LLP Linda Osei, Responsible Partner, Calderwood & Harkness LLP
FROM: Jeffrey Park, Associate, Calderwood & Harkness LLP
DATE: June 12, 2023
RE: Uptime Data Analysis — Sentinel Uptime Services Telemetry vs. Pinnacle Financial Holdings LLC Claimed Outage Durations
MATTER: Lumos Analytics Inc. — Pinnacle SLA Credit Dispute (1008-00007)
CONFIDENTIALITY NOTICE: This memorandum is protected by the attorney-client privilege and the work product doctrine. It has been prepared in anticipation of litigation and solely for the purpose of rendering legal advice to our client, Lumos Analytics Inc. This memorandum should not be disclosed outside the engagement team or to any third party without the prior written approval of the responsible partner, Linda Osei. Any inadvertent disclosure does not constitute a waiver of any applicable privilege.
I. Executive Summary
The purpose of this memorandum is to analyze and compare the uptime telemetry data provided by Sentinel Uptime Services Inc. ("Sentinel"), Lumos Analytics Inc.'s ("Lumos") independent third-party infrastructure monitoring vendor, against the outage durations claimed by Pinnacle Financial Holdings LLC ("Pinnacle") in its May 1, 2023 demand letter and accompanying supporting documentation. This analysis was undertaken at the direction of the engagement team to evaluate the factual foundation of Pinnacle's SLA credit claims and to inform Lumos's defense strategy in the pending dispute.
The scope of this memorandum covers all four service incidents cited by Pinnacle as the basis for its SLA credit demand: Incident INC-4471 (October 12–13, 2022), Incident INC-4602 (November 28, 2022), Incident INC-4815 (January 9–10, 2023), and Incident INC-5033 (March 3–5, 2023). These four incidents span the six-month period from October 2022 through March 2023 and collectively form the basis of Pinnacle's claimed entitlement to $120,000 in SLA credits.
Bottom-Line Conclusion: Sentinel's independently recorded telemetry data shows materially shorter full-outage durations for all four incidents when compared to the durations claimed by Pinnacle. The discrepancies are substantial and consistent across all incidents, ranging from approximately 1 hour 31 minutes (INC-4602) to 12 hours 23 minutes (INC-5033). When the Sentinel data is applied to the SLA credit tier structure set forth in Exhibit C, Section 3.2 of the Master Services Agreement (MSA-PFH-2021-0015, dated January 15, 2021), total SLA credits based on Lumos's data amount to $90,000 — $30,000 less than Pinnacle's claimed $120,000.
This $30,000 reduction is itself a conservative figure. It does not account for two additional defenses that, if successful, would further reduce Lumos's SLA credit exposure: (a) a timeliness defense on INC-4471, where Pinnacle's credit request was submitted 14 days past the contractual deadline; and (b) a third-party causation defense on INC-5033, where the predominant portion of the claimed downtime was attributable to a configuration change by Pinnacle's own cloud infrastructure provider, Brindoval Cloud Infrastructure LLC ("Brindoval"). If both defenses succeed, Lumos's maximum SLA credit exposure drops to $30,000.
More broadly, the uptime data discrepancy materially supports Lumos's overall defense posture and undermines Pinnacle's broader $2,870,000 demand, which encompasses not only SLA credits but also consequential damages, remediation costs, and reputational harm claims. To the extent Pinnacle's outage duration claims are foundational to its entire damages theory, the Sentinel data reveals those claims to be systematically overstated.
II. Background
A. The Master Services Agreement and SLA Framework
Lumos Analytics Inc. and Pinnacle Financial Holdings LLC entered into a Master Services Agreement dated January 15, 2021, bearing the internal reference number MSA-PFH-2021-0015 (the "MSA"). Under the MSA, Lumos provides Pinnacle with access to its proprietary data analytics platform, including real-time financial data processing, portfolio risk modeling, and regulatory reporting functionalities delivered through a software-as-a-service ("SaaS") model.
The MSA has an initial term of three years, running from January 15, 2021 through January 14, 2024. Under Section 5.1 of the MSA, the annual subscription fee is $1,440,000, payable in equal monthly installments of $120,000. The MSA includes several exhibits, the most pertinent of which for present purposes is Exhibit C — the Service Level Agreement (the "SLA").
Exhibit C governs Lumos's uptime commitments to Pinnacle and establishes the credit structure applicable when those commitments are not met. The key provisions of Exhibit C are as follows:
Uptime Commitment (§2.1). Lumos commits to maintaining platform availability of 99.95% as measured on a calendar-month basis. For a standard 30-day month (comprising 43,200 total minutes), this equates to a maximum allowable downtime of approximately 21.6 minutes per month. For a 31-day month (comprising 44,640 total minutes), the maximum allowable downtime is approximately 22.3 minutes.
SLA Credit Tiers (§3.2). In the event that Lumos fails to meet the 99.95% uptime commitment in any given calendar month, Pinnacle is entitled to SLA credits calculated as a percentage of the applicable monthly subscription fee, according to the following tiered structure:
SLA Credit Cap (§3.4). The maximum aggregate SLA credits to which Pinnacle is entitled in any rolling twelve-month period shall not exceed thirty percent (30%) of the annual subscription fee, yielding a cap of $432,000 (i.e., 30% × $1,440,000).
Credit Request Procedure (§3.5). To be eligible for an SLA credit, the customer must submit a written credit request to Lumos within thirty (30) calendar days following the end of the affected calendar month. The credit request must specify the affected services, the dates and times of the claimed downtime, and any supporting evidence of the service disruption. Failure to submit a timely credit request constitutes a waiver of the customer's right to the applicable credit.
These provisions collectively establish a carefully calibrated remedial framework that serves as Pinnacle's exclusive remedy for uptime failures under Section 3.6 of Exhibit C, subject to the definitions, exclusions, and procedural requirements set forth elsewhere in Exhibit C. As discussed below, Pinnacle's claimed outage durations — and the resulting credit calculations — depart significantly from the durations recorded by independent monitoring.
B. Sentinel Uptime Services Inc. — Role and Data Source
Sentinel Uptime Services Inc. is a third-party infrastructure monitoring and incident-response logging provider retained by Lumos to provide continuous, automated monitoring of Lumos's production SaaS environment. Sentinel is an independent commercial entity headquartered at 2200 Mission College Blvd, Suite 100, Santa Clara, California 95054. Our primary contact at Sentinel is Brenda Hale, Director of Client Engineering.
Sentinel's monitoring service operates on a continuous basis, recording service availability at one-minute polling intervals from multiple geographically distributed check nodes located across North America, Europe, and the Asia-Pacific region. Sentinel's monitoring infrastructure is designed to provide a comprehensive and objective view of platform availability as experienced from diverse network locations and access paths.
Critically, Sentinel's data is generated and stored independently from Lumos's own internal systems, logging infrastructure, and operational dashboards. Sentinel maintains its own data centers, its own logging architecture, and its own audit trail mechanisms. This independence makes Sentinel's data a particularly credible and objective third-party record of Lumos platform availability — it is not generated by Lumos, not stored on Lumos's infrastructure, and not subject to manipulation or modification by Lumos personnel.
For purposes of this analysis, we obtained the following data from Sentinel, produced by Lumos's engineering team in response to our document request dated May 18, 2023:
• Monthly availability reports for October 2022, November 2022, January 2023, and March 2023;
• Detailed incident logs for each of the four incidents at issue (INC-4471, INC-4602, INC-4815, and INC-5033); and
• Raw telemetry data exports for the specific time windows encompassing each incident, including per-node availability readings, response time measurements, and status code logs.
All data was produced in native format and has been reviewed and indexed by our team. The data is subject to the litigation hold memorandum issued by Lumos's General Counsel, Adriana Voss, on May 15, 2023.
C. Pinnacle's Claimed Outages
Pinnacle's claims concerning the four service incidents are set forth in a demand letter dated May 1, 2023, transmitted by Pinnacle's outside counsel, Hargrove, Tillman & Burch LLP, under the signature of lead partner Katherine Hargrove. The demand letter asserts that Lumos experienced four significant service disruptions between October 2022 and March 2023 and claims total SLA credits of $120,000 plus $2,750,000 in additional damages, comprising $1,950,000 in consequential damages, $340,000 in remediation costs, and $460,000 in claimed reputational harm. The aggregate demand totals $2,870,000.
The demand letter attaches several exhibits, including internal Pinnacle incident reports, selected help-desk ticket summaries, and a spreadsheet purporting to calculate outage durations and SLA credit entitlements. However, Pinnacle did not produce raw monitoring data, did not identify the monitoring tools or methodology used to measure outage durations, and did not address the contractual definition of "Downtime" under Exhibit C, Section 1.1, or the exclusions set forth in Section 2.3.
This memorandum focuses solely on the factual analysis of outage durations and the resulting SLA credit calculations for each of the four incidents. The consequential damages claims, the contractual limitations on liability (including the mutual waiver of indirect and consequential damages under Section 11.3 of the MSA and the aggregate liability cap under Section 11.2), and additional contractual defenses (including the timeliness defense under Section 3.5 and the exclusive-remedy provision in Section 3.6) are addressed in separate memoranda being prepared concurrently by the engagement team.
III. Methodology
A. Sentinel Monitoring Architecture
A clear understanding of Sentinel's monitoring architecture is essential to evaluating the reliability of its data and the nature of the discrepancies with Pinnacle's claimed durations. Sentinel monitors Lumos's production SaaS environment through two complementary mechanisms:
Synthetic Transaction Checks. Sentinel deploys automated synthetic transactions that simulate typical end-user interactions with the Lumos platform. These synthetic checks execute predefined API calls against Lumos's primary production endpoints, measuring both availability (whether the endpoint returns a successful HTTP 200 response within the configured timeout window) and performance (the response time in milliseconds). The synthetic checks are configured with a timeout window of 30 seconds — meaning that if the primary API endpoint does not return a successful response within 30 seconds, the check is recorded as a failure for that polling interval.
Real-User Monitoring (RUM) Agents. In addition to synthetic checks, Sentinel deploys lightweight JavaScript-based RUM agents within the Lumos platform's front-end code. These agents capture actual end-user page load times, API response times, and error rates as experienced by real users accessing the platform in production. RUM data provides supplementary visibility into user-experienced performance but is secondary to the synthetic checks for purposes of availability measurement.
Polling Frequency and Node Distribution. Sentinel's synthetic transaction checks are executed at a polling frequency of every 60 seconds (i.e., one check per minute) from each of six geographically distributed monitoring nodes. The six nodes are located as follows:
1. US-East — Northern Virginia, United States
2. US-West — Oregon, United States
3. US-Central — Iowa, United States
4. EU-West — Dublin, Ireland
5. APAC-East — Tokyo, Japan
6. APAC-South — Sydney, Australia
This geographic distribution ensures that Sentinel's monitoring captures availability from a diverse set of network paths and access points, reducing the risk that localized network issues, ISP outages, or routing anomalies at any single location could distort the overall availability picture.
Outage Definition. Under Sentinel's standard monitoring protocol, an "outage minute" is recorded only when all six nodes simultaneously report service unavailability — i.e., when the primary API endpoint fails to return a successful HTTP 200 response within the 30-second timeout window from every monitoring node during a given one-minute polling interval. This is a deliberately conservative definition that minimizes false positives. If even one node reports the service as available during a polling interval, that interval is not counted as an outage minute.
Status Classifications. Sentinel distinguishes among three service-status classifications:
• Full Outage: Complete service unavailability as confirmed by all six monitoring nodes. This corresponds to the contractual definition of "Downtime" under Exhibit C, Section 1.1.
• Degraded Performance: The platform is accessible and functional (i.e., it returns successful HTTP 200 responses), but response times exceed contractual performance thresholds. Typical symptoms include elevated API response latency, slow page loads, and extended query execution times. Under the MSA, degraded performance triggers separate P1 incident response-time SLAs (acknowledgment within 15 minutes, resolution or workaround within 2 hours) but does not constitute "Downtime" for purposes of the uptime percentage calculation.
• Partial Outage: A subset of platform features or API endpoints is unavailable while the core platform remains accessible. Sentinel logs partial outages separately and does not count them as full-outage minutes unless the core platform functionality is wholly unavailable.
This tripartite classification is directly relevant to the discrepancies identified in this analysis because, as discussed below, Pinnacle appears to have treated degraded-performance periods and partial outages as equivalent to full outages, thereby inflating its claimed downtime durations.
Contractual Alignment. Exhibit C, Section 1.1 of the MSA defines "Downtime" as any period during which the Lumos platform is "wholly unavailable" to the customer, exclusive of scheduled maintenance windows (which are governed by Section 2.2 and require 72 hours' advance notice). This definition aligns precisely with Sentinel's "full outage" classification. Periods of degraded performance — even severe degraded performance — do not satisfy the "wholly unavailable" standard and therefore do not count toward the uptime percentage calculation under the SLA.
B. Pinnacle's Measurement Methodology (as Inferred from Demand Letter and Supporting Exhibits)
Pinnacle's May 1, 2023 demand letter does not describe in detail the monitoring tools, measurement protocols, or data sources used to derive its claimed outage durations. Based on our review of the demand letter and its supporting exhibits, we infer the following about Pinnacle's methodology:
First, Pinnacle appears to have measured downtime based on its own internal user-experience reports and help-desk ticket timestamps. The demand letter references "user-reported service disruptions" and attaches summaries of internal help-desk tickets opened by Pinnacle employees during each incident. Help-desk ticket timestamps — recording when users first reported problems and when they reported that service had been restored — appear to serve as Pinnacle's primary data points for calculating outage start and end times.
Second, Pinnacle's methodology appears to include periods of degraded performance (slow response times and elevated latency) and partial outages (individual feature unavailability) within its definition of "downtime." This is evident from the demand letter's own descriptions of the incidents, which frequently reference "severely degraded performance" and "unacceptable response times" alongside periods of complete unavailability, without distinguishing between the two for purposes of the uptime calculation. This conflation systematically inflates Pinnacle's claimed durations.
Third, Pinnacle's measurements do not appear to distinguish between downtime attributable to the Lumos platform and downtime attributable to Pinnacle's own infrastructure or third-party service providers. This is particularly relevant to Incident INC-5033, where — as discussed below — a significant portion of the claimed downtime was caused by a configuration change implemented by Pinnacle's own IaaS provider, Brindoval Cloud Infrastructure LLC. Under Exhibit C, Section 2.3 ("Exclusions from Uptime Calculation"), such third-party-caused downtime is expressly excluded from the uptime calculation.
Fourth, Pinnacle has not produced its raw monitoring data or described its measurement tools in its demand letter. The absence of this information makes it impossible to independently verify Pinnacle's claimed durations or to assess the reliability and precision of Pinnacle's measurement methodology. As discussed in the Recommendations section below, we should seek production of this data in any discovery or mediation exchange.
C. Reconciliation Approach
For each of the four incidents, this memorandum presents a side-by-side comparison of the following data points:
1. Sentinel's recorded full-outage duration — the total minutes during which Sentinel recorded a full outage (all six monitoring nodes reporting unavailability) during the incident window;
2. Pinnacle's claimed duration — the outage duration stated in Pinnacle's demand letter and supporting exhibits;
3. The resulting uptime percentage under each party's figures — calculated using total minutes in the relevant calendar month as the denominator; and
4. The corresponding SLA credit tier — determined by reference to the tiered credit structure in Exhibit C, Section 3.2.
Uptime percentages are calculated using the following denominators for each relevant calendar month:
• October 2022: 31 days × 24 hours × 60 minutes = 44,640 total minutes
• November 2022: 30 days × 24 hours × 60 minutes = 43,200 total minutes
• January 2023: 31 days × 24 hours × 60 minutes = 44,640 total minutes
• March 2023: 31 days × 24 hours × 60 minutes = 44,640 total minutes
The uptime formula applied throughout this memorandum is:
Uptime % = [(Total Month Minutes − Full Outage Minutes) / Total Month Minutes] × 100
None of the four affected months had any scheduled maintenance windows that would need to be excluded from the denominator under Exhibit C, Section 2.2. Accordingly, the full calendar-month minute totals are used without adjustment.
IV. Incident-by-Incident Analysis
A. Incident INC-4471 (October 12–13, 2022)
1. Pinnacle's Claimed Data. Pinnacle's demand letter asserts that Incident INC-4471 caused a service outage lasting 7 hours and 42 minutes (462 minutes), beginning at approximately 11:18 PM EDT on October 12, 2022 and concluding at approximately 7:00 AM EDT on October 13, 2022. Based on this claimed duration, Pinnacle calculates the October 2022 monthly uptime as follows:
Uptime = (44,640 − 462) / 44,640 × 100 = 98.97%
Pinnacle's demand letter states a claimed uptime of 98.93% for October 2022, which differs slightly from the arithmetic result of 98.97% and may reflect rounding or a slightly different minute count. Regardless, Pinnacle places October 2022 uptime below the 99.00% threshold and claims the maximum SLA credit tier of 30% of the monthly fee, yielding a claimed credit of $36,000.
2. Sentinel's Recorded Data. Sentinel's telemetry data for October 2022 records the INC-4471 incident as a full outage lasting 4 hours and 11 minutes (251 minutes). Sentinel's incident log shows the full outage commencing at 11:18 PM EDT on October 12, 2022 — consistent with Pinnacle's reported start time — and full service restoration occurring at 3:29 AM EDT on October 13, 2022. All six Sentinel monitoring nodes confirmed service availability by 3:29 AM EDT.
Based on Sentinel's recorded duration, the October 2022 monthly uptime is calculated as follows:
Uptime = (44,640 − 251) / 44,640 × 100 = 99.44%
A monthly uptime of 99.44% falls within the 99.00%–99.49% credit tier under Exhibit C, Section 3.2, yielding an SLA credit of 20% of the monthly fee, or $24,000. This is $12,000 less than Pinnacle's claimed $36,000 credit for this incident.
3. Discrepancy Analysis. The discrepancy between Pinnacle's claimed duration and Sentinel's recorded duration for INC-4471 is 3 hours and 31 minutes (211 minutes). This is a significant discrepancy that materially affects the applicable credit tier, moving the October 2022 uptime from below 99.00% (Pinnacle's calculation) to the 99.00%–99.49% range (Sentinel's calculation) and reducing the credit from $36,000 to $24,000.
The source of the discrepancy can be identified with reasonable confidence from Sentinel's detailed telemetry logs. Sentinel's data shows that full service was restored at 3:29 AM EDT on October 13, 2022, approximately 3 hours and 31 minutes before the 7:00 AM EDT timestamp that Pinnacle cites as the end of the outage. During the intervening 211-minute window (3:29 AM to 7:00 AM EDT), Sentinel's monitoring nodes recorded the Lumos platform as available — the primary API endpoint was returning successful HTTP 200 responses — but Sentinel's degraded-performance alerts were active throughout this period. Specifically, Sentinel's response-time monitoring shows that API response latency during this window ranged between 3 seconds and 8 seconds, well above the normal baseline of less than 500 milliseconds but still within the range of a functioning, accessible platform.
This pattern is consistent with a post-outage recovery period during which the platform was back online and functional but operating at reduced performance levels as backend systems (caches, connection pools, query optimizers) re-warmed following the outage. Such degraded-performance periods are common following significant outages and are a well-understood phenomenon in production SaaS environments.
Under Exhibit C, Section 1.1 of the MSA, "Downtime" is defined as periods during which the Lumos platform is "wholly unavailable" to the customer. The 211-minute degraded-performance period following the INC-4471 outage does not meet this definition. The platform was accessible, API calls were succeeding, and users could perform core functions — albeit with slower-than-normal response times. Degraded performance may trigger separate P1 incident response-time SLAs under the MSA, but it does not constitute "Downtime" for purposes of the monthly uptime percentage calculation.
Accordingly, the inclusion of this 211-minute degraded-performance period in Pinnacle's claimed outage duration is inconsistent with the contractual definition of "Downtime" and results in an overstated credit claim.
Timeliness Issue. In addition to the duration discrepancy, we note a significant procedural issue with Pinnacle's credit request for INC-4471. Under Exhibit C, Section 3.5, Pinnacle was required to submit its written credit request within 30 calendar days following the end of the affected calendar month (October 2022). The 30-day deadline expired on November 30, 2022. However, Pinnacle did not submit its credit request for INC-4471 until December 14, 2022 — 44 days after the end of October 2022 and 14 days past the contractual deadline. Under Section 3.5, failure to submit a timely credit request constitutes a waiver of the applicable credit. This timeliness defense is addressed in detail in the Contractual Limitations Memorandum but is noted here for completeness as it has the potential to eliminate the INC-4471 credit entirely.
4. Conclusion. Based on Sentinel's independently recorded telemetry data, the correct SLA credit for Incident INC-4471 is $24,000 (20% of the monthly fee), assuming the credit request is deemed timely — a proposition that Lumos disputes. This represents a $12,000 reduction from Pinnacle's claimed credit of $36,000. If the timeliness defense succeeds, the credit for this incident would be $0.
B. Incident INC-4602 (November 28, 2022)
1. Pinnacle's Claimed Data. Pinnacle's demand letter asserts that Incident INC-4602 caused a service outage lasting 3 hours and 18 minutes (198 minutes) on November 28, 2022. Based on this claimed duration, Pinnacle calculates the November 2022 monthly uptime as follows:
Uptime = (43,200 − 198) / 43,200 × 100 = 99.54%
Pinnacle places November 2022 uptime within the 99.50%–99.89% credit tier and claims a credit of 10% of the monthly fee, yielding a claimed credit of $12,000.
2. Sentinel's Recorded Data. Sentinel's telemetry data for November 2022 records the INC-4602 incident as a full outage lasting 1 hour and 47 minutes (107 minutes). Sentinel's incident log shows the full outage commencing at 2:14 PM EST on November 28, 2022 and full service restoration occurring at 4:01 PM EST on the same day. All six monitoring nodes confirmed platform availability by 4:01 PM EST.
Based on Sentinel's recorded duration, the November 2022 monthly uptime is calculated as follows:
Uptime = (43,200 − 107) / 43,200 × 100 = 99.75%
A monthly uptime of 99.75% yields an SLA credit of 5% of the monthly fee under the applicable tier, resulting in a credit of $6,000. This is $6,000 less than Pinnacle's claimed $12,000 credit for this incident.
3. Discrepancy Analysis. The discrepancy between Pinnacle's claimed duration and Sentinel's recorded duration for INC-4602 is 1 hour and 31 minutes (91 minutes). While this is the smallest discrepancy in absolute terms among the four incidents, it is proportionally significant — Pinnacle's claimed duration is approximately 85% longer than the actual full-outage duration recorded by Sentinel.
The pattern here mirrors that observed in INC-4471. Sentinel's telemetry data shows that following full service restoration at 4:01 PM EST, the platform entered a degraded-performance state lasting approximately 90 minutes. During this period, Sentinel's response-time monitoring recorded elevated API response latency ranging between 2 seconds and 5 seconds, compared to the normal baseline of less than 500 milliseconds. However, the platform was fully accessible throughout this period — synthetic transaction checks from all six nodes returned successful HTTP 200 responses, and RUM data confirmed that end users were able to access core platform functionality.
Once again, under Exhibit C, Section 1.1, this degraded-performance period does not satisfy the "wholly unavailable" standard required to constitute "Downtime" for purposes of the uptime percentage calculation. The inclusion of this 91-minute degraded-performance tail in Pinnacle's claimed outage duration inflates the claim beyond the contractually defined measurement.
We also note that Pinnacle's credit request for INC-4602 was submitted on December 22, 2022, which is within the 30-calendar-day deadline following the end of November 2022 (deadline: December 30, 2022). There is accordingly no timeliness defense available for this incident.
4. Conclusion. Based on Sentinel's independently recorded telemetry data, the correct SLA credit for Incident INC-4602 is $6,000 (5% of the monthly fee). This represents a $6,000 reduction from Pinnacle's claimed credit of $12,000.
C. Incident INC-4815 (January 9–10, 2023)
1. Pinnacle's Claimed Data. Pinnacle's demand letter asserts that Incident INC-4815 caused a service outage lasting 11 hours and 5 minutes (665 minutes), beginning on the evening of January 9, 2023 and extending into January 10, 2023. Based on this claimed duration, Pinnacle calculates the January 2023 monthly uptime as follows:
Uptime = (44,640 − 665) / 44,640 × 100 = 98.51%
Pinnacle's demand letter states a claimed uptime of 98.47% for January 2023. The minor difference from the arithmetic result likely reflects Pinnacle's rounding or a slightly different minute count. In either case, Pinnacle places January 2023 uptime below the 99.00% threshold and claims the maximum SLA credit tier of 30% of the monthly fee, yielding a claimed credit of $36,000.
2. Sentinel's Recorded Data. Sentinel's telemetry data for January 2023 records the INC-4815 incident as a full outage lasting 6 hours and 22 minutes (382 minutes). Sentinel's data reveals that the incident comprised two distinct outage windows:
• Primary Outage Window: Commencing at 9:47 PM EST on January 9, 2023 and ending at 3:22 AM EST on January 10, 2023 (approximately 5 hours and 35 minutes).
• Secondary Disruption: Following initial restoration at 3:22 AM EST, the platform operated normally for approximately 18 minutes before experiencing a brief secondary disruption from 3:40 AM EST to 4:27 AM EST (approximately 47 minutes), caused by a residual issue in the database replication layer that had not been fully resolved during the initial incident response.
The combined full-outage time across both windows totals 6 hours and 22 minutes (382 minutes). Based on this recorded duration, the January 2023 monthly uptime is calculated as follows:
Uptime = (44,640 − 382) / 44,640 × 100 = 99.14%
A monthly uptime of 99.14% falls within the 99.00%–99.49% credit tier under Exhibit C, Section 3.2, yielding an SLA credit of 20% of the monthly fee, or $24,000. This is $12,000 less than Pinnacle's claimed $36,000 credit for this incident.
3. Discrepancy Analysis. The discrepancy between Pinnacle's claimed duration and Sentinel's recorded duration for INC-4815 is 4 hours and 43 minutes (283 minutes). This substantial discrepancy moves the January 2023 uptime from below 99.00% (Pinnacle's calculation) to the 99.00%–99.49% range (Sentinel's calculation), resulting in a one-tier reduction in the applicable credit.
Sentinel's detailed telemetry data indicates that the 283-minute discrepancy is attributable to two factors:
Degraded Performance Periods. Consistent with the pattern observed in INC-4471 and INC-4602, Pinnacle's claimed duration appears to include degraded-performance periods both between the two outage windows and following final service restoration. Sentinel's response-time monitoring shows elevated latency during these windows, but the platform remained accessible and functional. Under Exhibit C, Section 1.1, these periods do not constitute "Downtime."
Customer-Side Connectivity Issues. Sentinel's per-node telemetry data reveals that during a portion of the period Pinnacle claims as downtime, the Lumos platform was accessible from all six Sentinel monitoring nodes but may have been intermittently inaccessible from Pinnacle's specific network environment. This pattern is consistent with connectivity issues on Pinnacle's side of the network path — potentially involving Pinnacle's own corporate network, firewall configuration, or VPN infrastructure — rather than unavailability of the Lumos platform itself. Exhibit C, Section 2.3 ("Exclusions from Uptime Calculation") expressly excludes from the uptime calculation any downtime "attributable to Customer's infrastructure, Customer's third-party service providers, or any services not provided by [Lumos]." To the extent that a portion of the claimed INC-4815 downtime was caused by Pinnacle-side connectivity issues, that time is excluded under Section 2.3.
Failure to Activate DR Failover. We also note that Pinnacle had the contractual right and technical ability to activate failover to Lumos's designated disaster-recovery environment in the US-West-2 region during this incident. Under the MSA's Business Continuity provisions (Exhibit D, Section 4.2), Lumos maintains a hot-standby disaster-recovery environment in a geographically separate Meridian Technologies region (US-West-2, Oregon), and Pinnacle's technical team has been provided with documented failover procedures and credentials. Pinnacle did not activate this failover during INC-4815. Had Pinnacle done so, the effective downtime experienced by Pinnacle's end users would have been substantially shorter — likely limited to the failover activation time (typically 10–15 minutes per the documented procedure). While this is primarily a mitigation defense (addressed in separate memoranda), it also explains part of the measurement discrepancy: Pinnacle continued to measure downtime against the primary production environment without accounting for the availability of the DR environment.
4. Conclusion. Based on Sentinel's independently recorded telemetry data, the correct SLA credit for Incident INC-4815 is $24,000 (20% of the monthly fee). This represents a $12,000 reduction from Pinnacle's claimed credit of $36,000.
D. Incident INC-5033 (March 3–5, 2023)
1. Pinnacle's Claimed Data. Pinnacle's demand letter asserts that Incident INC-5033 caused a service outage lasting 26 hours and 31 minutes (1,591 minutes), beginning on March 3, 2023 and extending through March 5, 2023. This is by far the longest and most consequential of the four claimed incidents, and it forms the foundation of Pinnacle's most significant consequential damages claims.
Based on this claimed duration, Pinnacle calculates the March 2023 monthly uptime as approximately:
Uptime = (44,640 − 1,591) / 44,640 × 100 ≈ 96.44%
Pinnacle's demand letter states a claimed uptime of 96.32% for March 2023. The discrepancy between the arithmetic result (approximately 96.44%) and Pinnacle's stated figure (96.32%) may be attributable to rounding, a different minute-count methodology, or the use of a slightly different denominator. Regardless of the precise figure, Pinnacle places March 2023 uptime well below the 99.00% threshold and claims the maximum SLA credit tier of 30% of the monthly fee, yielding a claimed credit of $36,000.
2. Sentinel's Recorded Data. Sentinel's telemetry data for March 2023 records the INC-5033 incident as a full outage lasting 14 hours and 8 minutes (848 minutes). This is substantially less than Pinnacle's claimed 26 hours and 31 minutes, representing a discrepancy of more than 12 hours.
Sentinel's incident log shows the full outage commencing at 1:36 AM EST on March 3, 2023 and total service restoration occurring at 3:44 PM EST on March 3, 2023, with the full-outage minutes during that window totaling 848 minutes when accounting for brief intervals of partial restoration that occurred during the incident response.
Based on Sentinel's recorded duration, the March 2023 monthly uptime is calculated as follows:
Uptime = (44,640 − 848) / 44,640 × 100 ≈ 98.10%
Sentinel's formal monthly availability report for March 2023 states an uptime of 98.04%, which is slightly lower than the strict arithmetic result of 98.10%. This minor discrepancy likely reflects sub-minute partial outage intervals or Sentinel's application of its standard rounding methodology to the raw per-minute data. For purposes of this analysis, we use Sentinel's reported figure of 98.04%.
A monthly uptime of 98.04% falls below the 99.00% threshold, placing it in the maximum credit tier of 30% of the monthly fee, or $36,000. Notably, both parties' calculations result in the same credit tier for this incident — the disagreement relates to the magnitude of the downtime and the resulting uptime percentage, not to the applicable credit amount. However, the dramatically different uptime percentages (Pinnacle's 96.32% vs. Sentinel's 98.04%) are highly relevant to the broader dispute because Pinnacle's consequential damages claims rely in significant part on the severity and duration of the INC-5033 outage as characterized in its demand letter.
3. Discrepancy Analysis. The discrepancy between Pinnacle's claimed duration and Sentinel's recorded duration for INC-5033 is 12 hours and 23 minutes (743 minutes) — by far the largest discrepancy among the four incidents, both in absolute terms and as a proportion of the claimed duration. Pinnacle's claimed duration is approximately 88% longer than the full-outage duration recorded by Sentinel.
This discrepancy has a distinct and critically important causation element that distinguishes it from the other three incidents. Specifically, the discrepancy is primarily attributable to a configuration change implemented by Pinnacle's own infrastructure-as-a-service provider, Brindoval Cloud Infrastructure LLC.
Root-Cause Analysis. Sentinel's detailed root-cause analysis, corroborated by Lumos's internal incident post-mortem report (prepared by Thomas Kwan, VP of Engineering / SRE, dated March 12, 2023), indicates that the INC-5033 incident involved two overlapping but distinct causes:
(a) Lumos-Side Database Failure (14 hours 8 minutes). The genuine Lumos-side component of the INC-5033 incident was a cascading failure in Lumos's database replication layer, triggered by an unexpected surge in write operations that overwhelmed the primary database cluster's replication capacity. This failure caused the Lumos platform to become wholly unavailable to all customers — not just Pinnacle — for a period of 14 hours and 8 minutes. Lumos acknowledges this outage and does not dispute that it constitutes "Downtime" under Exhibit C, Section 1.1.
(b) Brindoval-Caused Routing Disruption (approximately 12+ hours). During the same general timeframe, Brindoval Cloud Infrastructure LLC implemented a network configuration change in its cloud environment that disrupted BGP (Border Gateway Protocol) routing between Pinnacle's Brindoval-hosted cloud environment and Lumos's production servers hosted on a separate cloud infrastructure. This routing disruption caused the Lumos platform to be inaccessible specifically from Pinnacle's network environment for a period extending well beyond the resolution of the Lumos-side database failure.
Sentinel's Multi-Node Data Confirms the Brindoval Causation. The most compelling evidence for the Brindoval causation theory comes from Sentinel's per-node telemetry data. Sentinel's six monitoring nodes are located in diverse geographic and network environments and access the Lumos platform through independent network paths. During the period that Pinnacle claims as continued downtime (i.e., the approximately 12 hours following Lumos's restoration of service at 3:44 PM EST on March 3, 2023), Sentinel's monitoring data shows the following:
• All six Sentinel monitoring nodes — including nodes in US-East, US-West, US-Central, EU-West, APAC-East, and APAC-South — recorded the Lumos platform as fully available and responsive following restoration at 3:44 PM EST on March 3, 2023.
• No Sentinel monitoring node recorded any full-outage minutes after 3:44 PM EST on March 3, 2023 through the end of the claimed outage window on March 5, 2023.
• Sentinel's RUM data confirms that other Lumos customers (accessing the platform from non-Brindoval environments) experienced normal service during this same period.
This data strongly supports the conclusion that the Lumos platform was restored and available to the broader customer base by 3:44 PM EST on March 3, 2023, and that Pinnacle's continued inability to access the platform after that time was caused by the Brindoval routing disruption — not by any ongoing unavailability of the Lumos platform itself.
Contractual Exclusion Under §2.3. Exhibit C, Section 2.3 ("Exclusions from Uptime Calculation") expressly provides that the following categories of downtime are excluded from the monthly uptime calculation:
> "Unavailability attributable to Customer's infrastructure, Customer's third-party service providers, or any services not provided by Provider; connectivity or network issues beyond Provider's network demarcation point; or Force Majeure events as defined in Section 14.1 of the Agreement."
Brindoval Cloud Infrastructure LLC is Pinnacle's third-party infrastructure-as-a-service provider. The Brindoval-caused routing disruption falls squarely within the Section 2.3 exclusion as downtime "attributable to Customer's third-party service providers." Accordingly, the approximately 12 hours of Brindoval-caused inaccessibility should be excluded from the uptime calculation, and only the 14 hours and 8 minutes of genuine Lumos-side downtime should be counted.
Failure to Activate DR Failover. As with INC-4815, Pinnacle did not activate the contractual DR failover to Lumos's US-West-2 disaster-recovery environment during INC-5033. This is particularly significant for the INC-5033 incident because the DR environment — hosted in a different Meridian Technologies region with a different network path — may well have been accessible from Pinnacle's environment even during the Brindoval routing disruption (since the routing disruption specifically affected the path between Brindoval and Lumos's primary production environment). Pinnacle's failure to activate this failover both exacerbated the impact of the incident on Pinnacle's operations and contributed to the inflation of Pinnacle's claimed downtime duration.
4. Conclusion. Based on Sentinel's independently recorded telemetry data, the correct SLA credit for Incident INC-5033 is $36,000 (30% of the monthly fee). Both parties' calculations fall within the same credit tier (below 99.00%), so the credit amount is identical regardless of which party's figures are used.
However, the dramatic discrepancy in uptime percentages (Pinnacle's 96.32% vs. Sentinel's 98.04%) is highly significant for several reasons beyond the immediate credit calculation. First, it demonstrates that Pinnacle's characterization of the severity and duration of the INC-5033 incident is materially overstated, undermining the foundation of Pinnacle's consequential damages claims. Second, the Brindoval causation theory, supported by Sentinel's multi-node data, provides a strong basis for arguing under Exhibit C, Section 2.3 that a substantial portion of the claimed downtime should be excluded from the uptime calculation entirely — which could potentially eliminate or substantially reduce even the $36,000 credit. This third-party causation argument is preserved for further briefing and development as the dispute progresses.
V. Summary Comparison Table
The following table summarizes the incident-by-incident comparison between Pinnacle's claimed outage data and Sentinel's independently recorded telemetry:
Net Difference in SLA Credits: $120,000 (Pinnacle's claim) − $90,000 (Lumos's calculation) = $30,000 overstatement by Pinnacle.
The $90,000 figure calculated using Sentinel's data represents a maximum figure that does not account for two additional defenses:
(a) Timeliness Defense — INC-4471. Pinnacle's credit request for INC-4471 was submitted on December 14, 2022, which is 44 days after the end of October 2022 and 14 days past the 30-calendar-day deadline prescribed by Exhibit C, Section 3.5. If this defense is sustained, the $24,000 credit for INC-4471 is eliminated.
(b) Third-Party Causation Defense — INC-5033. As detailed in Section IV.D above, the predominant portion of the claimed INC-5033 downtime (approximately 12 hours of the 26 hours 31 minutes claimed, and a significant portion of even the 14 hours 8 minutes recorded by Sentinel to the extent the Brindoval disruption overlapped with the Lumos-side failure) is attributable to a configuration change by Pinnacle's own cloud provider, Brindoval Cloud Infrastructure LLC. Under Exhibit C, Section 2.3, such third-party-caused downtime is excluded from the uptime calculation. If this defense is sustained, the $36,000 credit for INC-5033 could be eliminated or substantially reduced.
Minimum Exposure Scenario. If both the timeliness defense on INC-4471 and the third-party causation defense on INC-5033 are successful, Lumos's total SLA credit exposure across all four incidents would be limited to $30,000, comprising only:
• INC-4602: $6,000
• INC-4815: $24,000
• Total: $30,000
This represents a 75% reduction from Pinnacle's claimed $120,000 in SLA credits.
VI. Key Observations on Measurement Methodology Differences
The systematic nature of the discrepancies between Pinnacle's claimed durations and Sentinel's recorded durations warrants several overarching observations regarding the parties' respective measurement methodologies. These observations are relevant not only to the SLA credit dispute but also to the broader credibility of Pinnacle's damages claims.
A. Definition of "Downtime" Under Exhibit C, §1.1
The MSA establishes a precise, contractual definition of "Downtime" in Exhibit C, Section 1.1, which governs the uptime percentage calculation. Under this definition, "Downtime" means periods during which the Lumos platform is "wholly unavailable" to the customer. Degraded performance — including slow response times, elevated latency, extended query execution times, and similar performance impairments — does not constitute "Downtime" for purposes of the uptime calculation, even when the degraded performance is severe.
This distinction is critically important because degraded performance triggers a separate remedial framework under the MSA. Specifically, degraded performance constitutes a Priority 1 ("P1") incident that triggers response-time SLAs requiring Lumos to acknowledge the incident within 15 minutes and to provide a resolution or workaround within 2 hours. The P1 response-time SLAs are governed by Exhibit C, Section 4.1 and carry their own remedial provisions. The uptime-based SLA credit structure in Section 3.2 is distinct from and in addition to the P1 response-time framework, and the two should not be conflated.
Pinnacle's measurements appear to systematically conflate full outages with degraded-performance periods, treating any period during which platform performance was impaired — regardless of whether the platform was actually unavailable — as "Downtime" for purposes of the uptime calculation. This conflation is evident across all four incidents and accounts for a significant portion of the aggregate 22-hour-and-8-minute discrepancy between Pinnacle's claimed durations and Sentinel's recorded durations. In INC-4471, the additional 211 minutes correspond to a degraded-performance tail. In INC-4602, the additional 91 minutes correspond to a similar degraded-performance tail. In INC-4815, the additional 283 minutes include both degraded-performance periods and customer-side connectivity issues. In INC-5033, the majority of the additional 743 minutes is attributable to third-party infrastructure issues, though degraded-performance periods likely account for a portion as well.
B. Third-Party Infrastructure Exclusion (§2.3)
Exhibit C, Section 2.3 establishes a clear exclusion from the uptime calculation for any downtime attributable to customer infrastructure, customer third-party service providers, or services not provided by Lumos. This exclusion reflects the fundamental principle that Lumos can only be held accountable for the availability of its own platform and infrastructure; it cannot be responsible for disruptions caused by the customer's own systems, network configuration, or third-party providers.
This exclusion is most directly relevant to Incident INC-5033, where the evidence strongly supports the conclusion that a Brindoval Cloud Infrastructure LLC configuration change disrupted network routing between Pinnacle's environment and Lumos's production servers, causing the Lumos platform to be inaccessible specifically from Pinnacle's network for approximately 12 hours after Lumos had restored service to its broader customer base. Sentinel's multi-node telemetry data confirms that the platform was accessible from all six geographically distributed monitoring nodes during this period, demonstrating that the unavailability was specific to Pinnacle's network path — not a platform-wide outage.
Pinnacle's measurements do not appear to distinguish between Lumos-caused downtime and Brindoval-caused downtime. Pinnacle's demand letter and supporting exhibits present the INC-5033 outage as a single, continuous 26-hour-31-minute disruption attributable entirely to Lumos, without acknowledging or accounting for the Brindoval routing disruption that was the predominant cause of the extended inaccessibility from Pinnacle's environment.
This failure to disaggregate Lumos-caused and Brindoval-caused downtime is not merely a methodological deficiency — it is inconsistent with the express terms of the SLA. If Pinnacle intends to maintain its claim that the full 26 hours and 31 minutes constitutes "Downtime" attributable to Lumos, it bears the burden of demonstrating that the Section 2.3 exclusion does not apply, which will require Pinnacle to explain why its own third-party provider's configuration change should be treated as Lumos-caused downtime.
C. Monitoring Data Provenance and Reliability
The relative reliability and credibility of the parties' respective data sources is a critical consideration in evaluating the competing outage-duration claims.
Sentinel's Data. Sentinel Uptime Services Inc. is an independent third-party vendor retained by Lumos for the specific purpose of monitoring platform availability. Sentinel has no financial interest in the outcome of this dispute — its monitoring contract with Lumos is a fixed-fee engagement that does not vary based on uptime results. Sentinel's data is generated automatically at fixed one-minute intervals using standardized monitoring protocols, stored in Sentinel's own infrastructure (separate from Lumos's systems), and contemporaneously logged with tamper-evident audit trails that prevent after-the-fact modification. Sentinel's methodology — six-node consensus-based outage detection with a 30-second timeout window — is conservative, well-documented, and industry-standard.
Pinnacle's Data. By contrast, Pinnacle's claimed durations appear to be derived from internal user reports and help-desk ticketing systems. These data sources are inherently less precise and less reliable than automated monitoring telemetry for several reasons. First, help-desk ticket timestamps depend on human judgment about when to open and close tickets, introducing subjectivity and imprecision into the measurement of outage start and end times. Second, user-experience reports are influenced by factors other than platform availability, including local network conditions, browser configuration, VPN connectivity, and individual user perception of performance. Third, Pinnacle has not produced its raw monitoring data, has not identified the specific tools or protocols used to measure availability, and has not described any quality-assurance measures applied to its duration calculations.
The superiority of Sentinel's data as an objective, independent, automated record of platform availability is a significant strength for Lumos's defense. In any mediation or litigation proceeding, Sentinel's data is likely to be viewed as substantially more credible than Pinnacle's internally generated help-desk records.
D. Disaster Recovery Failover (US-West-2) — Mitigation Failure
For both Incident INC-4815 and Incident INC-5033, Pinnacle had the contractual right and documented technical ability to activate failover to Lumos's designated disaster-recovery environment in the US-West-2 region (Oregon). The DR environment is maintained as a hot-standby replica of the production environment, with documented failover procedures and pre-provisioned credentials provided to Pinnacle's technical operations team. The documented failover activation time is typically 10 to 15 minutes.
Pinnacle did not activate this failover capability for either incident. Had Pinnacle done so, the effective downtime experienced by Pinnacle's end users would have been substantially reduced. In the case of INC-5033, the DR failover may have been particularly effective because the US-West-2 environment — hosted in a separate Meridian Technologies region with an independent network path — may not have been affected by the Brindoval-caused routing disruption that prevented access to the primary production environment.
While Pinnacle's failure to activate the DR failover is primarily relevant as a mitigation defense (which is addressed in separate memoranda being prepared by the engagement team), it also contributes to the measurement discrepancy at issue in this memorandum. Pinnacle's measurement of downtime was conducted against the primary production environment only, without acknowledging or accounting for the availability of the contractually provided DR environment. A proper assessment of the "downtime" experienced by Pinnacle should consider the totality of the service infrastructure made available to Pinnacle under the MSA, including the DR environment.
VII. Impact on Lumos's Overall Exposure Analysis
This uptime data analysis has significant implications for Lumos's overall exposure in the pending dispute with Pinnacle. Pinnacle's total demand, as set forth in its May 1, 2023 demand letter, is $2,870,000, comprising the following components:
SLA Credit Component. As demonstrated in this memorandum, the SLA credit component of Pinnacle's demand is overstated by at least $30,000. Sentinel's independently recorded telemetry data supports total SLA credits of $90,000, not $120,000. If the timeliness defense on INC-4471 and the third-party causation defense on INC-5033 are both successful, SLA credit exposure drops further to $30,000 — a 75% reduction from Pinnacle's claimed amount.
Consequential Damages and Additional Claims ($2,750,000). The consequential damages, remediation costs, and reputational harm claims — totaling $2,750,000 — are subject to several independent contractual defenses that are addressed in separate memoranda but are summarized here for completeness:
• Mutual Waiver of Consequential Damages (§11.3). Section 11.3 of the MSA contains a mutual waiver of indirect, incidental, special, consequential, and lost-profits damages. This waiver bars Pinnacle's $1,950,000 consequential damages claim and its $460,000 reputational harm claim in their entirety.
• Aggregate Liability Cap (§11.2). Section 11.2 of the MSA limits each party's aggregate liability under the Agreement to an amount equal to the total fees paid or payable during the twelve-month period immediately preceding the claim, yielding a cap of $1,440,000. Even if the consequential damages waiver were not applicable (which we do not concede), Pinnacle's total demand of $2,870,000 far exceeds this contractual ceiling.
• SLA Credit Cap (§3.4). Exhibit C, Section 3.4 provides that maximum SLA credits in any rolling twelve-month period shall not exceed 30% of the annual subscription fee, or $432,000. This cap provides an additional constraint on Lumos's credit exposure independent of the per-incident analysis.
• Exclusive Remedy (§3.6). Exhibit C, Section 3.6 provides that SLA credits constitute the customer's sole and exclusive remedy for any failure by Lumos to meet the uptime commitment. This provision, if enforced, would bar all of Pinnacle's claims beyond the SLA credit amount.
Overall Assessment. The Sentinel data materially strengthens Lumos's defense position across the entire dispute. By demonstrating that Pinnacle's claimed outage durations are systematically overstated — by a cumulative total of more than 22 hours — the data undermines not only Pinnacle's SLA credit calculations but also the factual predicate for its consequential damages claims, which are premised on the severity and duration of the outages as characterized in the demand letter. If the actual outages were materially shorter than Pinnacle claims (as Sentinel's data shows), then the downstream business impacts that Pinnacle attributes to those outages are necessarily overstated as well.
VIII. Recommendations
Based on the foregoing analysis, I recommend the following action items for the engagement team's consideration:
1. Preserve All Sentinel Data. Ensure that all raw telemetry exports, incident logs, availability reports, and associated metadata from Sentinel Uptime Services Inc. for the period September 2022 through April 2023 are fully preserved under the litigation hold issued on May 15, 2023. The litigation hold was communicated to Adriana Voss (General Counsel, Lumos), Thomas Kwan (VP of Engineering / SRE, Lumos), and Rachel Dominguez (Director of IT Operations, Lumos). Confirm with Lumos's legal team that Sentinel has been notified of the preservation obligation and that Sentinel's standard data-retention policies will not result in deletion or overwriting of the relevant data during the pendency of this dispute. Given the criticality of this data, we should request that Lumos obtain a written confirmation from Sentinel that the data has been placed on preservation hold.
2. Obtain a Declaration or Certification from Brenda Hale. Contact Brenda Hale, Director of Client Engineering at Sentinel Uptime Services Inc., and arrange for the preparation of a sworn declaration or formal certification confirming: (a) Sentinel's monitoring methodology, including polling frequency, node distribution, outage-detection criteria, and status classification definitions; (b) the integrity and authenticity of the data produced for this engagement, including confirmation that the data has not been altered or modified since its original recording; (c) the independence of Sentinel's monitoring infrastructure from Lumos's own systems; and (d) Sentinel's data retention and audit trail practices. This declaration should be prepared in a form suitable for submission in mediation, arbitration, or litigation proceedings. We should coordinate with Sentinel's legal department to ensure the declaration is appropriately reviewed before execution.
3. Request Pinnacle's Monitoring Data. In any discovery exchange, mediation information request, or pre-litigation correspondence, demand that Pinnacle produce: (a) the raw monitoring data and system logs underlying its claimed outage durations for all four incidents; (b) documentation of the monitoring tools, measurement protocols, and methodologies used by Pinnacle to determine outage start and end times; (c) all internal help-desk tickets, user-experience reports, and incident reports relating to the four incidents; and (d) any communications with Brindoval Cloud Infrastructure LLC regarding the March 3–5, 2023 routing disruption. Exposing Pinnacle's methodological deficiencies — particularly its apparent conflation of full outages with degraded performance — will be essential to establishing that Pinnacle's claimed durations are unreliable and contractually unfounded.
4. Request Brindoval Cloud Infrastructure LLC Records. Obtain or, if necessary, subpoena Brindoval Cloud Infrastructure LLC's change management logs, incident reports, network configuration change records, and customer notifications for the March 3–5, 2023 period. These records are essential to substantiating the third-party causation defense for INC-5033. Brindoval's own documentation of the BGP routing change that disrupted connectivity between Pinnacle's environment and Lumos's production servers would provide powerful corroboration of the Sentinel telemetry data showing that the Lumos platform was accessible from non-Pinnacle environments during the disputed period. We should also investigate whether Pinnacle received any notification or incident report from

ATTORNEY-CLIENT PRIVILEGED AND CONFIDENTIAL — ATTORNEY WORK PRODUCT

MEMORANDUM

Record

Parties

Dates

Amounts