1007-00008 · Vantage Mobility Systems Corp · Memoranda

use-it-or-lose-it-compliance-memo.docx DOCUMENT IP / Technology

24 / 35 ← → ✕

PRIVILEGED AND CONFIDENTIAL — ATTORNEY-CLIENT COMMUNICATION ATTORNEY WORK PRODUCT

MEMORANDUM

TO: Bernard Crawford, Responsible Partner, Calderwood & Harkness LLP

FROM: Gabrielle Moss, Lead Associate, Calderwood & Harkness LLP

DATE: August 7, 2023

RE: Vantage Mobility Systems Corp. — Analysis of Section 4.3 "Use-It-or-Lose-It" Clause: Compliance Options and Tolling Arguments

MATTER NO.: C&H Matter No. 1007-00008

Right-click to update Table of Contents

I. Executive Summary

This memorandum addresses a critical contractual compliance issue facing our client, Vantage Mobility Systems Corp. ("VMS" or "Vantage"), arising under Section 4.3 of the Master Embedded Software License and Services Agreement dated June 21, 2022 (the "MESLSA"), between VMS and Meridian Code Technologies, Inc. ("MeridianCode"). Section 4.3 of the MESLSA contains what is colloquially referred to as a "Use-It-or-Lose-It" clause, which requires VMS to "commence integration testing on at least 2 platforms within 18 months of the Effective Date." Because the Effective Date of the MESLSA is June 21, 2022, the eighteen-month compliance deadline falls on December 21, 2023.

The issue has been brought into sharp relief by VMS's suspension of all integration work on March 22, 2023, following the VMS Board of Directors' March 14, 2023 resolution to rescope Project Argonaut from five designated vehicle platform configurations down to two — Argonaut-A and Argonaut-C only. VMS thereafter provided timely dormancy notice to MeridianCode on July 14, 2023, which was six days before the 120-day trigger date of July 20, 2023 (calculated from the March 22, 2023 suspension date). MeridianCode acknowledged Dormancy Status on August 3, 2023.

This memorandum evaluates three primary questions:

1. Whether Dormancy Status under Section 9.4 tolls the Section 4.3 deadline. We conclude that VMS has a strong, though not dispositive, argument that Section 9.4's tolling of "all milestone deadlines" encompasses the Section 4.3 commencement deadline. However, the contractual language is not free from ambiguity, and MeridianCode can be expected to advance a colorable counter-argument that the Section 4.3 deadline is a "license utilization" condition, not a "milestone deadline."

2. Whether VMS has already achieved substantial compliance with Section 4.3 through its completed milestones on Argonaut-A and Argonaut-C. We conclude that Argonaut-A's completed Milestone 3 (alpha integration testing passed on February 28, 2023) constitutes clear compliance with the Section 4.3 commencement requirement for at least one platform. The case for Argonaut-C — which reached only Milestone 2 (source-code customization delivered on January 15, 2023) — is reasonable but vulnerable to a strict textual interpretation of "commence integration testing."

3. What alternative compliance strategies are available to VMS. We identify four options, ranging from a passive reliance on tolling and substantial compliance arguments to a proactive strategy of addressing the Section 4.3 deadline expressly in the proposed Amendment No. 1 to the MESLSA, which this firm is currently preparing for circulation to MeridianCode's counsel, Redstone Whitaker LLP.

Summary of Conclusions: VMS has strong arguments that (a) Section 9.4 dormancy tolls the Section 4.3 deadline, and (b) VMS has already substantially complied with Section 4.3 with respect to at least one platform (Argonaut-A) and arguably two (Argonaut-C). However, the ambiguities in the contract language create meaningful risk if MeridianCode disputes either position, particularly before the three-arbitrator panel at the Midwest Arbitration Institute ("MAI"). Proactive measures — specifically, incorporating a Section 4.3 resolution into the Draft Amendment No. 1 negotiations — are strongly recommended to eliminate this risk.

II. Factual Background

A. The MESLSA and Project Argonaut

VMS and MeridianCode executed the MESLSA on June 21, 2022. The agreement governs VMS's license to integrate and deploy MeridianCode's proprietary embedded real-time operating system, ATLAS-RT™, into VMS's next-generation adaptive vehicle platforms under the umbrella program internally designated as "Project Argonaut."

The key commercial and structural terms of the MESLSA are as follows:

• Total Deal Value: $20,000,000 over the term of the agreement, comprising upfront license fees, annual maintenance fees, integration services fees, and a runtime royalty structure.

• Licensed Product: ATLAS-RT™ embedded real-time operating system, Version 4.2, as subsequently updated to Version 4.2.3 through MeridianCode's standard patch and release cycle. ATLAS-RT is a proprietary RTOS designed for safety-critical embedded applications in the automotive, aerospace, and industrial automation sectors. MeridianCode holds eighteen registered U.S. patents covering core elements of the ATLAS-RT kernel architecture, task scheduling algorithms, and fault-tolerance mechanisms.

• License Scope: The MESLSA grants VMS a perpetual license to use ATLAS-RT, subject to a five-year initial term expiring June 20, 2027. The license encompasses integration into up to five designated vehicle platform configurations under Project Argonaut, internally designated as Argonaut-A, Argonaut-B, Argonaut-C, Argonaut-D, and Argonaut-E. Each platform configuration is separately identified in Statement of Work No. 1 ("SOW No. 1"), which is incorporated by reference into the MESLSA as Exhibit B.

• Project Argonaut Objective: Project Argonaut was conceived as a multi-year engineering initiative to develop a unified embedded-software architecture for Vantage's next-generation adaptive vehicle platforms. The project's central objective is integrating ATLAS-RT as the core RTOS layer across multiple vehicle configurations, thereby enabling a common software foundation for Vantage's fleet of adaptive mobility vehicles. At the time of execution, VMS projected integration across five distinct platform configurations, serving both internal combustion engine ("ICE") and electric vehicle ("EV") drivetrains.

• Governing Law: The MESLSA is governed by the laws of the State of Michigan, without regard to conflict-of-laws principles.

• Dispute Resolution: The MESLSA mandates binding arbitration under the rules of the Midwest Arbitration Institute ("MAI"), with the arbitration seated in Detroit, Michigan. For disputes exceeding $1,000,000 in claimed damages, the MESLSA provides for a three-arbitrator panel. Given the financial magnitude of the issues at stake — VMS has already paid $12,320,000 under the MESLSA — any arbitration proceeding would almost certainly invoke the three-arbitrator panel requirement.

B. Project Argonaut Rescoping

On March 14, 2023, the VMS Board of Directors adopted a formal resolution to rescope Project Argonaut from five vehicle platform configurations to two. Under the revised project scope, only Argonaut-A and Argonaut-C would proceed to full integration and deployment. Platforms Argonaut-B, Argonaut-D, and Argonaut-E were deferred indefinitely. Additionally, the Board resolved to defer all electrification-related integration activities — originally planned for Argonaut-D and Argonaut-E — to a contemplated "Phase II" of Project Argonaut, for which no firm date has been established.

The rescoping decision was driven by a confluence of factors:

• Supply-Chain Delays: Persistent disruptions in semiconductor procurement, particularly affecting the specialized automotive-grade microcontroller units ("MCUs") required for Argonaut-B and the EV platforms, made it impracticable to proceed with integration on those platforms within the originally contemplated timeline.

• Capital Expenditure Reduction: Kestrel Capital Partners, LP — VMS's majority private equity sponsor — issued a portfolio-wide capital expenditure reduction directive in February 2023, mandating that all Ashgrove Equity Partners portfolio companies reduce projected 2023–2024 capital expenditures by not less than 20%. This directive required VMS to prioritize integration spending on the platforms with the highest near-term commercial return.

• Strategic Reprioritization: VMS's management team, in consultation with Ashgrove Equity Partners, made the strategic determination to prioritize ICE-platform fleet vehicles (served by Argonaut-A and Argonaut-C) over EV platforms in the near term, reflecting a reassessment of market demand and fleet customer ordering patterns.

Following the Board resolution, VMS's Chief Technology Officer, Dennis J. Whitfield, directed the cessation of all ATLAS-RT integration activities on March 22, 2023. All engineering teams assigned to Project Argonaut were redeployed to other VMS programs or placed on temporary assignment to non-Argonaut projects.

C. Integration Status at Time of Suspension

At the time integration work was suspended on March 22, 2023, the five Argonaut platforms had reached the following stages of development under the SOW No. 1 milestone framework:

• Argonaut-A: Milestone 3 of 5 completed. Alpha integration testing was conducted and passed on February 28, 2023. This milestone involved integrating the customized ATLAS-RT build into the Argonaut-A hardware platform, executing the defined test suite, and verifying that the RTOS met the specified performance and fault-tolerance requirements for the Argonaut-A configuration. Argonaut-A was the most advanced of the five platforms and was on track for Milestone 4 (beta testing and validation) before the suspension.

• Argonaut-B: Milestone 1 only. The requirements specification for Argonaut-B had been approved on November 30, 2022, but no code integration work had begun. The Argonaut-B platform was designated for a light-duty commercial fleet vehicle and was dependent on the semiconductor components subject to the supply-chain disruptions referenced above.

• Argonaut-C: Milestone 2 of 5 completed. Source-code customization for the Argonaut-C platform was delivered by MeridianCode on January 15, 2023. This deliverable involved tailoring the ATLAS-RT codebase to the specific hardware abstraction layer, peripheral driver interfaces, and safety requirements of the Argonaut-C vehicle platform. No formal integration testing (Milestone 3) had commenced on Argonaut-C at the time of suspension.

• Argonaut-D and Argonaut-E: Not commenced. These platforms — both designated for EV drivetrains — had not progressed beyond initial scoping discussions. No formal milestone activities were initiated.

VMS's engineering teams had invested approximately 14,200 engineering hours across all Argonaut platforms through the date of suspension. This figure includes both VMS internal engineering effort and embedded MeridianCode engineer time provided under the SOW No. 1 integration services engagement.

Integration services fees paid by VMS through Milestone 3 completion totaled $1,920,000 of the total $3,200,000 integration services fee contemplated by SOW No. 1.

D. Dormancy Status

Following the March 22, 2023 suspension of integration work, VMS monitored the 120-day dormancy trigger window under Section 9.4 of the MESLSA. Section 9.4 provides that if the licensee "ceases all material integration and deployment activities for a period of one hundred twenty (120) consecutive days," the licensee must either resume activities or provide written notice to invoke Dormancy Status. The 120-day period, calculated from March 22, 2023, expired on July 20, 2023.

VMS sent its formal dormancy notice to MeridianCode on July 14, 2023 — six calendar days before the July 20, 2023 trigger date. The notice was delivered via overnight courier and confirmed electronic delivery to MeridianCode's designated notice address as specified in Section 14.2 of the MESLSA, with a copy to Redstone Whitaker LLP.

MeridianCode acknowledged receipt of VMS's dormancy notice and confirmed VMS's entry into Dormancy Status by written correspondence dated August 3, 2023. MeridianCode's acknowledgment was transmitted through Redstone Whitaker LLP.

Under Section 9.4 of the MESLSA, Dormancy Status has two principal effects: (1) it reduces MeridianCode's support obligations to a critical-security-patch-only level, suspending all other maintenance, technical support, and professional services obligations; and (2) it "toll[s] all milestone deadlines" for the duration of the dormancy period.

Dormancy under Section 9.4 is subject to a twelve-month cap. Because MeridianCode acknowledged Dormancy Status on August 3, 2023, the twelve-month dormancy period will expire on August 3, 2024, at which point the MESLSA requires the parties to either renegotiate the terms of the agreement or proceed to termination.

E. Financial Context

The financial stakes underlying the Section 4.3 compliance question are substantial. As of the date of dormancy, VMS has paid a total of $12,320,000 to MeridianCode under the MESLSA, comprising the following components:

The total remaining contractual commitment under the MESLSA, absent amendment, is $7,680,000, broken down as follows:

Critically, under certain termination provisions of the MESLSA — including Section 9.1 (Termination for Convenience) if triggered before the 24-month anniversary — VMS faces forfeiture of the entire $12,320,000 in prepaid fees. This forfeiture exposure is the subject of a separate memorandum being prepared by this team and reinforces the importance of maintaining VMS's compliance posture under all operative provisions of the MESLSA, including Section 4.3.

III. Section 4.3 — Text and Operative Requirements

A. Full Text of Section 4.3

The operative language of Section 4.3 of the MESLSA reads as follows:

Section 4.3 — Minimum Utilization Requirement. Licensee shall commence integration testing on at least two (2) of the Designated Vehicle Platform Configurations identified in SOW No. 1 within eighteen (18) months of the Effective Date (the "Minimum Utilization Deadline"). In the event that Licensee fails to satisfy the Minimum Utilization Deadline, Licensor shall have the right, exercisable upon not less than thirty (30) days' prior written notice to Licensee, to: (a) reduce the scope of the License Grant under Section 2.1 to include only those Designated Vehicle Platform Configurations on which Licensee has commenced integration testing as of the Minimum Utilization Deadline; (b) terminate any unused platform allocations under the License Grant, with corresponding reduction in Licensor's support and maintenance obligations; and/or (c) require Licensee to enter into good-faith renegotiation of the Fee Schedule set forth in Exhibit A to reflect the reduced scope of the License Grant. For the avoidance of doubt, Licensor's exercise of any remedy under this Section 4.3 shall not constitute a termination of this Agreement, and shall not affect Licensee's obligations with respect to fees already paid or accrued.

The clause is denominated as a "Minimum Utilization Requirement" and is located within Article IV of the MESLSA, which is titled "License Grant — Conditions and Restrictions." This placement is significant to the interpretive analysis below, as it situates Section 4.3 among the conditions governing VMS's license rights rather than among the milestone-based performance obligations set forth in SOW No. 1.

The core operative requirement is that VMS must "commence integration testing" on at least two of the five Designated Vehicle Platform Configurations within eighteen months of the Effective Date — that is, by December 21, 2023. The threshold is commencement, not completion. The clause does not require that integration testing be passed, validated, or advanced to any particular milestone; it requires only that integration testing be "commenced."

The consequences of non-compliance are structured as permissive remedies available to MeridianCode, not as automatic termination triggers. Upon timely notice, MeridianCode may narrow the license scope, terminate unused platform allocations, and/or require renegotiation of the fee structure. Importantly, the clause expressly provides that exercise of these remedies "shall not constitute a termination of this Agreement," meaning the MESLSA itself would survive even if MeridianCode invoked its Section 4.3 remedies. However, fee renegotiation in the wake of a Section 4.3 non-compliance finding would almost certainly strengthen MeridianCode's hand in the broader commercial negotiations now underway.

B. Key Defined Terms

Several defined terms within the MESLSA and SOW No. 1 bear directly on the interpretation of Section 4.3:

"Commence integration testing." This phrase is not independently defined in the MESLSA's definitions article (Article I) or in the glossary appended to SOW No. 1. The absence of a standalone definition means the phrase must be interpreted by reference to its ordinary meaning in context, informed by the milestone framework established in SOW No. 1. As discussed in Part V below, the SOW No. 1 milestone framework defines five sequential milestones, with Milestone 3 specifically denominated "Alpha Integration Testing." The most natural reading of "commence integration testing" is that it refers to the initiation of Milestone 3 activities — that is, the beginning of the formal integration testing phase as defined in the SOW. However, a broader reading is also tenable, as discussed below.

"Designated Vehicle Platform Configurations." This term is defined in Section 1.14 of the MESLSA as "the vehicle platform configurations identified in SOW No. 1 as the approved platforms for integration of the Licensed Software." SOW No. 1 identifies five such configurations: Argonaut-A, Argonaut-B, Argonaut-C, Argonaut-D, and Argonaut-E. Each platform is described in detail in Appendix 1 to SOW No. 1, which specifies the hardware architecture, target ECU specifications, operating environment requirements, and safety integrity level for each configuration.

It bears emphasis that the MESLSA requires commencement of integration testing on at least two platforms, not completion. The threshold established by Section 4.3 is one of initiation, not achievement. This distinction is important to the compliance analysis that follows, as it lowers the bar that VMS must clear. VMS does not need to have passed integration testing on two platforms; it needs only to have started it.

C. Relationship to Other Provisions

Section 4.3 does not exist in contractual isolation. Its interpretation is informed by, and interacts with, several other provisions of the MESLSA:

Section 9.4 (Dormancy). As discussed in detail in Part IV below, Section 9.4 provides that entry into Dormancy Status "shall toll all milestone deadlines for the duration of the Dormancy Period." The pivotal interpretive question is whether the Section 4.3 Minimum Utilization Deadline constitutes a "milestone deadline" within the scope of this tolling provision. If it does, the December 21, 2023 deadline is suspended for the duration of VMS's dormancy, effectively extending VMS's compliance window by up to twelve months.

Section 9.1 (Termination for Convenience). Section 9.1 permits either party to terminate the MESLSA for convenience upon ninety days' written notice, subject to certain conditions. Critically, Section 9.1(c) provides that if termination for convenience occurs prior to the twenty-four-month anniversary of the Effective Date (i.e., before June 21, 2024), all fees previously paid by the licensee are forfeited and non-refundable. This provision creates a powerful financial incentive for VMS to maintain the MESLSA in good standing through at least June 21, 2024, and underscores the importance of avoiding any Section 4.3 non-compliance event that could strengthen MeridianCode's leverage to force an early termination or disadvantageous renegotiation.

SOW No. 1 — Milestone Framework. SOW No. 1 establishes a five-milestone framework for each Designated Vehicle Platform Configuration:

Each milestone has defined deliverables, acceptance criteria, and associated fee installments. The milestones are sequential — each milestone is a prerequisite to the next. The SOW expressly provides that "no milestone shall be deemed commenced until the immediately preceding milestone has been accepted by Licensee in accordance with the Acceptance Procedures set forth in Appendix 2." This language is relevant to the question of whether Argonaut-C's completion of Milestone 2 can be characterized as "commencing" Milestone 3 activities, a question addressed in Part V.C below.

IV. Analysis: Does Dormancy Status Under Section 9.4 Toll the Section 4.3 Deadline?

A. The Tolling Language of Section 9.4

The threshold question is whether the Section 4.3 Minimum Utilization Deadline is tolled during VMS's period of Dormancy Status under Section 9.4. Resolution of this question turns on the interpretation of Section 9.4's tolling clause, which provides in relevant part:

"Upon entry into Dormancy Status, all milestone deadlines set forth in any Statement of Work or this Agreement shall be tolled for the duration of the Dormancy Period. Licensor's support obligations during the Dormancy Period shall be limited to the provision of critical security patches as described in Section 7.3(c)."

The central interpretive question is whether the phrase "all milestone deadlines set forth in any Statement of Work or this Agreement" encompasses the Section 4.3 Minimum Utilization Deadline. The tolling language is capacious — it refers to "all milestone deadlines" and expressly covers deadlines "set forth in . . . this Agreement" (i.e., the MESLSA itself), not only those in a Statement of Work. However, the scope of the phrase depends on whether the Section 4.3 deadline qualifies as a "milestone deadline."

Arguments Favoring Tolling (VMS Position). VMS has several strong arguments that the Section 4.3 deadline falls within the tolling provision:

First, the Section 4.3 deadline is functionally a milestone-related deadline. Section 4.3 requires VMS to "commence integration testing" — a requirement that directly corresponds to the progression of work through the milestones defined in SOW No. 1. Specifically, "integration testing" corresponds to Milestone 3 (Alpha Integration Testing) in the SOW No. 1 framework. The Section 4.3 deadline is not an abstract temporal condition unrelated to milestone performance; it is a deadline that requires VMS to have reached a particular milestone-defined stage of work product development. A deadline that requires achievement of a milestone-defined activity is, by any functional measure, a "milestone deadline."

Second, the purpose of the dormancy tolling provision supports tolling. The evident purpose of the Section 9.4 tolling provision is to protect the licensee from adverse contractual consequences during a period of authorized inactivity. Dormancy is a contractual right, not a breach. If Section 4.3 were to remain operative during dormancy — running its eighteen-month clock even as VMS exercises its contractual right to suspend activities — the result would be to penalize VMS for invoking a right the MESLSA expressly grants. Such an interpretation would render the dormancy tolling provision a dead letter with respect to one of the most consequential deadlines in the agreement, undermining the commercial purpose of the dormancy mechanism.

Third, Michigan contract interpretation principles favor VMS's reading. Michigan courts apply the principle of contra proferentem, which provides that ambiguous contract terms are construed against the party that drafted the agreement. Klapp v. United Insurance Group Agency, Inc., 468 Mich. 459, 470 (2003). MeridianCode drafted the MESLSA, including both Section 4.3 and Section 9.4. If the tolling language is deemed ambiguous as to whether it encompasses the Section 4.3 deadline, that ambiguity should be resolved in VMS's favor.

Fourth, the alternative reading creates an internal inconsistency. If the Section 4.3 deadline is not tolled by dormancy, a licensee could properly invoke dormancy under Section 9.4, have "all milestone deadlines" tolled, and yet simultaneously face loss of license scope under Section 4.3 for failing to meet a deadline that is inextricably linked to milestone performance. This reading would create an internal tension within the MESLSA that Michigan courts would seek to avoid. See Coates v. Bastian Bros., Inc., 276 Mich. App. 498, 508 (2007) (contracts should be interpreted to give effect to all provisions and avoid internal contradictions).

Arguments Against Tolling (Anticipated MeridianCode Position). MeridianCode can be expected to advance several counter-arguments:

First, Section 4.3 is structurally distinct from the milestone provisions. Section 4.3 is titled "Minimum Utilization Requirement" and is located in Article IV ("License Grant — Conditions and Restrictions"), not in Article VI or SOW No. 1 where the milestone framework is established. MeridianCode may argue that "milestone deadlines" is a term of art referring only to the specific payment and deliverable milestones enumerated in SOW No. 1 (Milestones 1 through 5 for each platform), not to the separate utilization condition in Section 4.3. Under this reading, the tolling provision suspends the dates by which specific SOW deliverables must be completed and accepted, but does not suspend the broader license-scope condition in Section 4.3.

Second, Section 4.3 is a condition to maintaining full license scope, not a performance milestone. MeridianCode may draw a distinction between "milestone deadlines" (which relate to the sequential performance of integration work under SOW No. 1) and "license utilization conditions" (which relate to the licensee's obligation to make productive use of the license grant). Under this framing, Section 4.3 is a protective mechanism ensuring that MeridianCode's proprietary technology is not warehoused by a licensee that licenses broadly but integrates narrowly, and the dormancy tolling provision was not intended to suspend this distinct category of obligation.

Third, the expressio unius argument. If the parties had intended Section 4.3 to be tolled by dormancy, they could have said so expressly. Section 9.4 uses the phrase "all milestone deadlines" rather than "all deadlines" or "all time-based obligations." MeridianCode may argue that the use of the modifier "milestone" was deliberate and reflects an intentional limitation on the scope of the tolling provision. Under the expressio unius est exclusio alterius canon, the inclusion of "milestone deadlines" implies the exclusion of non-milestone deadlines such as the Section 4.3 Minimum Utilization Deadline.

Assessment. VMS's tolling argument is the stronger of the two positions, but it is not free from doubt. The contractual language is genuinely ambiguous — the phrase "all milestone deadlines" is capacious enough to encompass the Section 4.3 deadline, but MeridianCode's structural and textual arguments have facial plausibility. The strength of VMS's position is bolstered by the contra proferentem principle and the internal consistency canon, both of which favor VMS. However, if the matter proceeds to arbitration before a three-arbitrator MAI panel, the outcome is not assured. In our assessment, VMS's tolling argument has a moderate-to-strong probability of success, but the risk of an adverse finding is sufficient to warrant proactive measures rather than passive reliance on the tolling argument alone.

B. Implications of the Dormancy Effective Date

Assuming the Section 4.3 deadline is tolled, the next question is the mechanics of tolling: from what date does tolling commence, and how is the adjusted deadline calculated?

There are two plausible dates from which tolling could be measured:

Option 1: Tolling from the Acknowledged Dormancy Date (August 3, 2023). Under this approach, tolling commences on the date MeridianCode formally acknowledged VMS's entry into Dormancy Status. This date has the virtue of contractual certainty — it is the date on which dormancy was officially confirmed by both parties. If tolling commenced on August 3, 2023, and the twelve-month dormancy period runs through August 3, 2024, the Section 4.3 deadline would be extended by the duration of the dormancy. Because the original deadline is December 21, 2023, and approximately four months and eighteen days remain between August 3, 2023 and the original deadline, the tolled deadline would be approximately December 21, 2024 — i.e., the original deadline plus twelve months of dormancy tolling. The precise calculation would depend on whether the tolling formula is additive (adding the dormancy duration to the remaining time) or suspensive (freezing the clock as of the dormancy date and restarting it upon reactivation).

Option 2: Tolling from the Date of Work Suspension (March 22, 2023). Under this approach, tolling would be measured from the date on which VMS actually ceased all integration activities, on the theory that this is the event that triggered the dormancy mechanics and the date from which VMS's inability to make progress toward the Section 4.3 deadline became operative. If tolling is measured from March 22, 2023, VMS would gain additional time reaching back to the suspension date, effectively freezing the Section 4.3 clock as of March 22, 2023. Under this calculation, VMS would have approximately nine months of additional time remaining on the Section 4.3 clock upon reactivation (the eighteen-month period minus the nine months that elapsed between the June 21, 2022 Effective Date and the March 22, 2023 suspension date).

VMS should advocate for tolling commencing as of March 22, 2023, the date on which integration work was actually suspended. This position is supported by the commercial reality that VMS's inability to progress toward the Section 4.3 deadline began on the suspension date, not on the later date of formal dormancy acknowledgment. The intervening period between March 22, 2023 and August 3, 2023 — during which VMS was processing the dormancy notice and awaiting MeridianCode's response — should not count against VMS's compliance window, as VMS was not performing integration work during this period and had no ability to advance toward the Section 4.3 requirement.

C. Michigan Law on Contractual Tolling and Deadline Interpretation

Michigan applies the "plain meaning" rule for contract interpretation: where the terms of a contract are clear and unambiguous, the court will enforce the contract as written and will not look beyond the four corners of the agreement. Rory v. Continental Insurance Co., 473 Mich. 457, 468 (2005). However, where the terms of a contract are ambiguous — that is, reasonably susceptible to more than one interpretation — Michigan courts will consider extrinsic evidence and applicable canons of construction to determine the parties' intent. Shay v. Aldrich, 487 Mich. 648, 667 (2010).

As discussed above, the critical phrase — "all milestone deadlines set forth in any Statement of Work or this Agreement" — is reasonably susceptible to both VMS's interpretation (encompassing the Section 4.3 deadline) and MeridianCode's interpretation (limited to SOW-defined milestone dates). This ambiguity opens the door to extrinsic evidence and interpretive canons, both of which generally favor VMS.

Michigan courts have addressed analogous tolling questions in the context of commercial contracts involving suspension of performance. In Great Lakes Fabricators, Inc. v. Consolidated Controls Corp., No. 298475, 2012 WL 893271 (Mich. Ct. App. Mar. 15, 2012), the Michigan Court of Appeals held that a force majeure clause tolling "all performance deadlines" encompassed not only delivery deadlines but also acceptance-testing deadlines, notwithstanding the defendant's argument that the acceptance deadlines were separate conditions rather than "performance" obligations. The court reasoned that a narrow reading of the tolling provision would undermine the clause's evident purpose of protecting the performing party during a period of excused non-performance. While this case is unpublished and therefore not binding precedent, it is persuasive authority for VMS's position.

Michigan courts also apply the principle that contracts should be construed to give effect to all provisions, avoiding interpretations that render any clause superfluous or inoperative. Klapp, 468 Mich. at 468. VMS can argue that reading Section 4.3 as untolled during dormancy would effectively render Section 9.4's tolling provision meaningless in the one scenario where tolling matters most — a licensee that has suspended work and entered dormancy precisely because it is unable to meet upcoming deadlines.

Finally, the contra proferentem principle weighs in VMS's favor. MeridianCode drafted both Section 4.3 and Section 9.4. If MeridianCode intended the Section 4.3 deadline to survive dormancy unaffected, it had every opportunity to say so. The failure to carve Section 4.3 out from the tolling provision — or, conversely, the failure to expressly include it — creates the ambiguity, and that ambiguity should be resolved against the drafter.

V. Analysis: Has VMS Already Achieved Substantial Compliance with Section 4.3?

A. Defining "Commence Integration Testing"

Even if the Section 4.3 deadline is not tolled, VMS may have already achieved compliance — or at least substantial compliance — through its completed milestones on Argonaut-A and Argonaut-C. This analysis turns on the meaning of "commence integration testing" in the context of the SOW No. 1 milestone framework.

As noted above, SOW No. 1 defines five sequential milestones for each Designated Vehicle Platform Configuration:

The phrase "commence integration testing" most naturally refers to the initiation of the integration testing phase. In the SOW No. 1 framework, the formal integration testing phase begins at Milestone 3 — Alpha Integration Testing. Milestone 3 is specifically defined as the stage at which the customized ATLAS-RT build is integrated into the target hardware platform and subjected to a defined suite of integration tests. The use of the word "commence" (rather than "complete" or "pass") establishes a low threshold: VMS need only have begun the integration testing process, not finished it.

The question is whether activities preceding Milestone 3 — particularly the Milestone 2 source-code customization phase — can be characterized as "commencing integration testing" within the meaning of Section 4.3.

B. Argonaut-A: Milestone 3 Completed

Argonaut-A presents no compliance question. VMS's engineering team, in coordination with MeridianCode's embedded engineers, completed Milestone 3 — Alpha Integration Testing — for the Argonaut-A platform on February 28, 2023. The alpha integration test suite was executed, all critical and high-severity defects were resolved, and MeridianCode delivered a signed Milestone 3 acceptance certificate on March 2, 2023.

Argonaut-A's Milestone 3 completion not only "commenced" integration testing but completed it through the alpha testing phase. This clearly exceeds the Section 4.3 requirement. Moreover, Milestone 3 was completed approximately ten months before the December 21, 2023 deadline and approximately three weeks before the suspension of integration work on March 22, 2023. There is no plausible argument that VMS has not "commenced integration testing" on the Argonaut-A platform.

Accordingly, VMS has unambiguous compliance with the Section 4.3 requirement for at least one Designated Vehicle Platform Configuration.

C. Argonaut-C: Milestone 2 Completed

The compliance question for the second platform is more nuanced. Argonaut-C reached Milestone 2 — source-code customization delivered — on January 15, 2023. MeridianCode delivered the customized ATLAS-RT build for the Argonaut-C hardware configuration, including the platform-specific hardware abstraction layer, peripheral driver interfaces, and safety-critical module configurations. VMS's engineering team accepted the Milestone 2 deliverable on January 22, 2023, and MeridianCode issued the corresponding Milestone 2 acceptance certificate.

However, no Milestone 3 activities — that is, no formal Alpha Integration Testing — had commenced on Argonaut-C at the time work was suspended on March 22, 2023. The question, therefore, is whether completion of Milestone 2 (source-code customization) constitutes "commencing integration testing" within the meaning of Section 4.3.

Arguments That Milestone 2 Satisfies Section 4.3. VMS can advance several arguments that Argonaut-C's Milestone 2 completion satisfies the Section 4.3 commencement requirement:

First, source-code customization is a prerequisite to and integral part of the integration process. Milestone 2 is not a standalone preparatory activity divorced from integration; it is the immediate precursor to integration testing and involves the substantive work of integrating ATLAS-RT code into VMS's platform architecture. The Milestone 2 deliverable is a customized software build tailored to the specific hardware platform — this is integration activity by any practical measure, even if the formal testing sub-phase (Milestone 3) had not yet begun.

Second, "commence" establishes a low threshold. The word "commence" means "to begin" or "to initiate." It does not require that a specific milestone have been formally reached. Initiating the integration process — by customizing the ATLAS-RT source code for the Argonaut-C platform — arguably constitutes commencing the integration testing process, even if the formal testing activities defined in Milestone 3 had not yet started. The customization work performed under Milestone 2 involved integrating the ATLAS-RT code with VMS's platform-specific drivers and configurations, which is substantively integration work.

Third, VMS's internal engineering records support this characterization. VMS's engineering logs and project management records would show that the Argonaut-C Milestone 2 work involved significant integration-related activities, including hardware-software interface configuration, driver integration, and preliminary functional verification. These activities, while categorized under Milestone 2 for project management and billing purposes, are substantively indistinguishable from the early stages of integration testing.

Arguments That Milestone 2 Does Not Satisfy Section 4.3 (Anticipated MeridianCode Position). MeridianCode can be expected to advance the following counter-arguments:

First, "integration testing" is not "integration." Section 4.3 specifically requires commencement of "integration testing," not "integration" generally. Source-code customization is a development and preparation activity — it prepares the codebase for testing but is not itself testing. The milestones in SOW No. 1 draw a clear distinction between customization (Milestone 2) and testing (Milestone 3), and the contract should be interpreted in accordance with this taxonomy.

Second, the milestones create a defined sequential framework. SOW No. 1 expressly provides that "no milestone shall be deemed commenced until the immediately preceding milestone has been accepted." Under this language, Milestone 3 had not "commenced" for Argonaut-C because, while Milestone 2 had been accepted, no Milestone 3 work had been initiated. MeridianCode will argue that the SOW framework gives precise meaning to the phrase "commence integration testing" and that Argonaut-C had not crossed that threshold.

Third, VMS's interpretation would render Section 4.3 meaningless. If Milestone 2 completion constitutes "commencement" of integration testing, then by similar logic, Milestone 1 (requirements specification) could also be argued to constitute commencement of the integration process — it is, after all, the first step toward integration. If any milestone activity satisfies Section 4.3, the provision imposes no meaningful obligation and is effectively a nullity. Michigan courts would disfavor an interpretation that renders a contract provision superfluous. Klapp, 468 Mich. at 468.

Assessment. VMS has a reasonable argument that Argonaut-C's Milestone 2 completion constitutes commencement of integration testing, but this argument is vulnerable to a strict textual interpretation. The strength of VMS's position on this point is moderate. If Section 4.3 is interpreted strictly — requiring at least the initiation of Milestone 3 activities — then Argonaut-C has not yet reached the requisite threshold, and VMS has complied with Section 4.3 on only one platform (Argonaut-A), not the required two. If interpreted more broadly — treating the commencement of the integration process (including source-code customization) as sufficient — then both Argonaut-A and Argonaut-C are in compliance.

We note that this interpretive question would likely be resolved by reference to the specific language of the SOW No. 1 milestone framework and any extrinsic evidence of the parties' intent (e.g., negotiation history, contemporaneous correspondence). If VMS can point to any pre-execution communications in which the parties discussed the Section 4.3 requirement in terms broader than strict Milestone 3 commencement, such evidence would be valuable.

D. Substantial Compliance Doctrine

Even if Argonaut-C's Milestone 2 completion does not literally satisfy the "commence integration testing" requirement, VMS may invoke the doctrine of substantial compliance under Michigan law.

Under Michigan law, the doctrine of substantial compliance may excuse minor or technical deviations from contractual requirements where the essential purpose of the obligation has been fulfilled and the non-compliant party has acted in good faith. See McCarty v. Mercury Metalcraft Co., 372 Mich. 567, 574 (1964); Omnicom of Michigan v. Giannetti Investment Co., 221 Mich. App. 341, 348 (1997). The doctrine is applied on a case-by-case basis, with courts considering the nature of the deviation, the extent of the obligor's performance, and whether the obligee has suffered material prejudice.

Several factors support a substantial compliance finding in VMS's favor:

• Magnitude of VMS's Investment: VMS has invested approximately 14,200 engineering hours and $1,920,000 in integration services fees across the Argonaut platforms, demonstrating a substantial and good-faith commitment to the integration program.

• Preservation of the Two Most Advanced Platforms: VMS's rescoping decision preserved Argonaut-A and Argonaut-C — the two platforms with the most advanced integration progress — showing continued commitment to deploying the ATLAS-RT technology on the platforms most likely to proceed to production.

• Good-Faith Engagement: VMS's suspension of integration work was driven by legitimate business considerations (supply-chain disruption, capital constraints, strategic reprioritization), not by an intent to warehouse MeridianCode's technology or circumvent the utilization requirement. VMS timely invoked the dormancy provision and has maintained its support obligations throughout.

• Near-Compliance on Argonaut-C: Argonaut-C is one milestone short of unambiguous compliance. The gap between Milestone 2 (source-code customization) and Milestone 3 (alpha integration testing) is incremental, not fundamental. Argonaut-C had already received the customized ATLAS-RT build and was positioned to commence formal testing when work was suspended.

Against these factors, MeridianCode may contend that the Section 4.3 deadline is a bright-line condition, not subject to substantial compliance analysis. MeridianCode's argument would be that the Minimum Utilization Requirement was specifically negotiated as a hard deadline with defined consequences, and that permitting substantial compliance would effectively rewrite the provision. Michigan courts have recognized that the substantial compliance doctrine is not available to excuse non-performance of conditions where the contract establishes clear, date-certain requirements and provides for specific remedies in the event of breach. See Forge v. Smith, 458 Mich. 198, 208 (1998) (distinguishing conditions precedent, which must be strictly satisfied, from covenants, which may be subject to substantial performance analysis).

The viability of the substantial compliance argument therefore depends on whether the arbitrators characterize Section 4.3 as a condition precedent to maintaining full license scope (favoring strict compliance) or as a covenant or performance obligation (favoring substantial compliance analysis). Given the language of Section 4.3 — which provides for permissive remedies rather than automatic forfeiture — VMS has a reasonable basis for arguing that the clause is more akin to a covenant than a strict condition, but this is a close question.

VI. Compliance Options and Strategic Recommendations

Based on the foregoing analysis, we have identified four compliance strategies available to VMS, each carrying distinct advantages and risks. We present them in ascending order of proactive engagement.

A. Option 1: Rely on Tolling and Substantial Compliance Arguments (Passive Approach)

Under this option, VMS would take no affirmative steps to address the Section 4.3 deadline. Instead, VMS would rely on its legal arguments that (a) the Section 4.3 deadline is tolled during dormancy under Section 9.4, and (b) VMS has already substantially complied through its completion of Milestone 3 on Argonaut-A and Milestone 2 on Argonaut-C. If MeridianCode later invokes Section 4.3, VMS would respond by asserting its tolling and compliance positions.

Advantages:

• No additional expenditure of engineering resources or fees.

• Preserves VMS's negotiating flexibility by not raising the Section 4.3 issue affirmatively.

• Consistent with VMS's existing dormancy posture and avoids signaling concern about Section 4.3 compliance.

Risks:

• If MeridianCode challenges VMS's compliance and the MAI arbitrators reject both the tolling argument and the substantial compliance argument, VMS could face a loss of license scope for three platform allocations (Argonaut-B, D, and E) and a forced renegotiation of the fee structure. While the practical impact of losing the Argonaut-B, D, and E allocations may be limited — given that those platforms have already been rescoped out of Project Argonaut — the renegotiation leverage this would hand to MeridianCode is significant.

• Financial exposure: MeridianCode could use a Section 4.3 non-compliance finding to demand concessions in the broader dormancy extension and fee restructuring negotiations, potentially increasing VMS's total cost of maintaining the MESLSA.

• Failure to create a contemporaneous record of VMS's position could be perceived by the arbitrators as suggesting that VMS did not, in fact, believe it had complied with Section 4.3.

B. Option 2: Proactive Written Confirmation from MeridianCode (Negotiated Approach)

Under this option, VMS would seek written acknowledgment from MeridianCode — through correspondence between this firm and Redstone Whitaker LLP — that (a) Dormancy Status under Section 9.4 tolls the Section 4.3 deadline, and/or (b) VMS's existing milestone completion on Argonaut-A and Argonaut-C constitutes compliance with Section 4.3.

This acknowledgment could take the form of a standalone letter agreement or side letter, or it could be incorporated into the ongoing negotiations for the proposed Amendment No. 1 to the MESLSA. We understand that Amendment No. 1 is expected to address a range of issues, including revised platform allocations, dormancy extension, and fee restructuring — making it a natural vehicle for resolving the Section 4.3 issue.

Advantages:

• Eliminates ambiguity and provides clear contractual protection on the Section 4.3 issue.

• Creates a binding written record of MeridianCode's acknowledgment that can be relied upon in any subsequent dispute.

• Can be paired with other elements of the dormancy extension and fee restructuring discussions, allowing VMS to resolve multiple issues in a single negotiation.

Risks:

• Raising the Section 4.3 issue explicitly with MeridianCode may invite attention to a provision that MeridianCode has not yet focused on. If MeridianCode's counsel at Redstone Whitaker has not independently identified the Section 4.3 compliance question, proactively raising it could create a negotiating problem that does not yet exist.

• MeridianCode may demand concessions in exchange for providing the requested acknowledgment — e.g., accelerated fee payments, enhanced reporting obligations, or other consideration.

• The negotiation process takes time, and there is no guarantee that an agreement can be reached before the December 21, 2023 deadline (if tolling is unavailable).

C. Option 3: Targeted Reactivation of Argonaut-C to Reach Milestone 3 (Partial Reactivation)

Under this option, VMS would temporarily reactivate limited integration work on the Argonaut-C platform, with the specific objective of advancing Argonaut-C from Milestone 2 (source-code customization) to Milestone 3 (alpha integration testing). Achieving Milestone 3 on Argonaut-C would eliminate the interpretive ambiguity regarding the second platform and provide VMS with unambiguous compliance on two platforms — Argonaut-A and Argonaut-C — regardless of the outcome of the tolling analysis.

Implementation of this option would require coordination with Dennis J. Whitfield (CTO) and Lena Petrova (Director, Software Integration Engineering) to assess the engineering resources, timeline, and budget required to progress Argonaut-C to Milestone 3. Based on preliminary estimates, the progression from Milestone 2 to Milestone 3 for a single platform could potentially be achieved in sixty to ninety days with dedicated engineering resources, assuming the Milestone 2 deliverable (customized source code) remains current and does not require substantial rework due to the passage of time or changes in the Argonaut-C hardware specification.

Advantages:

• Eliminates the "commenced integration testing" ambiguity for the second platform and provides VMS with maximum compliance flexibility regardless of the tolling interpretation.

• Demonstrates VMS's good faith and continued commitment to the ATLAS-RT integration program.

• Provides a concrete, verifiable compliance achievement that would be difficult for MeridianCode to challenge.

Risks:

• Dormancy Inconsistency: Partial reactivation of integration work on Argonaut-C may be inconsistent with VMS's Dormancy Status under Section 9.4. Section 9.4 defines dormancy as a state in which the licensee "ceases all material integration and deployment activities." Resuming integration work on Argonaut-C — even on a limited, targeted basis — could be argued by MeridianCode to constitute a resumption of "material integration activities" sufficient to terminate the dormancy period. If dormancy terminates, VMS would lose the tolling protection for all other milestone deadlines, MeridianCode's full support obligations would resume (along with VMS's corresponding payment obligations), and the twelve-month dormancy clock would stop running — potentially triggering the dormancy cap renegotiation provisions prematurely.

• Additional Engineering Costs: Reactivation of Argonaut-C would require allocation of engineering resources that are currently deployed on other VMS programs. The incremental cost of a sixty-to-ninety-day Milestone 3 effort has not been estimated but would include both internal VMS engineering costs and any required MeridianCode professional services support.

• Year 2 Maintenance Fee Trigger: If VMS resumes integration work, MeridianCode may argue that the Year 2 Maintenance Fee obligation — currently in dispute — is triggered, on the theory that VMS is resuming active use of the ATLAS-RT platform and requires full maintenance support. This could expose VMS to a $2,400,000 maintenance fee demand that is currently being contested.

• Ashgrove Equity Partners Approval: Given the Kestrel Capital Partners portfolio-wide capital expenditure reduction directive, reactivation of Argonaut-C integration work may require approval from VMS's Board and/or Ashgrove Equity Partners. Obtaining such approval may be time-consuming and is not assured.

D. Option 4: Include Section 4.3 Resolution in Proposed Amendment No. 1 (Preferred Approach)

Under this option — which we recommend as the primary strategy — VMS would address the Section 4.3 deadline expressly in Draft Amendment No. 1 to the MESLSA, which this firm is currently preparing for circulation to Redstone Whitaker LLP. This approach would resolve the Section 4.3 issue comprehensively, as part of the broader package of amendments being negotiated in connection with the dormancy extension and fee restructuring.

We propose that Draft Amendment No. 1 include the following Section 4.3-related terms:

(i) Tolling Confirmation. Confirm, for the avoidance of doubt, that Dormancy Status under Section 9.4 tolls the Section 4.3 Minimum Utilization Deadline for the duration of the Dormancy Period, with tolling measured from the date on which integration work was suspended (March 22, 2023).

(ii) Platform Reduction. Reduce the number of Designated Vehicle Platform Configurations under the License Grant from five to two (Argonaut-A and Argonaut-C), consistent with the rescoped Project Argonaut. Conforming revisions to be made to the number of platforms referenced in Section 4.3 (from "at least two (2)" to "at least two (2) of the remaining Designated Vehicle Platform Configurations").

(iii) Deadline Reset. Reset the eighteen-month commencement deadline to run from the date of reactivation (i.e., the date on which VMS exits Dormancy Status and resumes integration activities), rather than from the original Effective Date.

(iv) Milestone 3 Confirmation. Confirm that Argonaut-A's Milestone 3 completion (alpha integration testing passed on February 28, 2023) satisfies the Section 4.3 commencement requirement for one Designated Vehicle Platform Configuration.

Advantages:

• Provides a comprehensive, negotiated solution that eliminates all ambiguity regarding Section 4.3 compliance.

• Aligns the Section 4.3 resolution with VMS's broader negotiation strategy, which already encompasses dormancy extension, fee restructuring, and platform scope adjustments.

• Avoids the piecemeal approach of addressing Section 4.3 in isolation, which could result in inconsistent positions or concessions that undermine VMS's broader negotiating posture.

• Provides contractual certainty through a written amendment, reducing the risk of subsequent arbitration on the Section 4.3 issue.

Risks:

• Dependent on successful negotiation with MeridianCode and Redstone Whitaker LLP. If the Amendment No. 1 negotiations fail or stall, VMS would need to fall back to Options 1, 2, or 3.

• Including Section 4.3 in the amendment package may introduce additional complexity into negotiations that are already addressing multiple contentious issues.

• MeridianCode may seek to extract concessions on other points (e.g., accelerated royalty payments, enhanced audit rights, or narrower termination protections) in exchange for agreeing to the Section 4.3 provisions.

Notwithstanding these risks, Option 4 represents the most strategically sound approach and is our recommended path forward. It provides maximum protection for VMS's interests while minimizing the risk of unintended consequences that could arise from the partial reactivation approach (Option 3) or the passive approach (Option 1).

VII. Interaction with Other Critical Deadlines

The Section 4.3 compliance question does not exist in isolation. Several other critical deadlines under the MESLSA interact with the Section 4.3 timeline and must be considered in developing VMS's compliance strategy.

A. June 21, 2024 — 24-Month Anniversary (Fee Forfeiture Cutoff)

Under Section 9.1(c) of the MESLSA, termination for convenience prior to the twenty-four-month anniversary of the Effective Date — i.e., prior to June 21, 2024 — triggers forfeiture of all fees previously paid by VMS. As of the date of dormancy, VMS has paid $12,320,000 in aggregate fees. Forfeiture of this amount would represent a catastrophic financial outcome for VMS and must be avoided.

The interplay between the Section 4.3 deadline (December 21, 2023) and the fee forfeiture cutoff (June 21, 2024) creates a six-month window of heightened risk. If MeridianCode invokes its Section 4.3 remedies on or shortly after December 21, 2023 — demanding fee renegotiation and license scope reduction — the resulting negotiations could destabilize the MESLSA relationship during the period when VMS is most vulnerable to fee forfeiture. If MeridianCode were to engineer a termination scenario — for example, by demanding renegotiation terms so onerous that VMS is forced to terminate — VMS could face forfeiture of the entire $12,320,000 if termination occurs before June 21, 2024.

VMS must avoid any sequence of events that could lead to termination before the fee forfeiture cutoff. This consideration reinforces the importance of resolving the Section 4.3 issue proactively, before the December 21, 2023 deadline arrives, rather than waiting for MeridianCode to assert its remedies.

B. August 3, 2024 — 12-Month Dormancy Cap

The dormancy period, which commenced with MeridianCode's acknowledgment on August 3, 2023, is subject to a twelve-month cap under Section 9.4. The dormancy period will therefore expire on August 3, 2024, at which point Section 9.4 requires the parties to either (a) agree to a reactivation plan with revised milestone schedules and fee terms, or (b) proceed to termination of the MESLSA on terms specified in Section 9.4(d).

If the Section 4.3 issue is not resolved before August 3, 2024, VMS will face the simultaneous convergence of two adverse contractual events: (1) an unresolved Section 4.3 non-compliance argument, which MeridianCode can use as leverage, and (2) the mandatory dormancy expiration, which forces renegotiation under time pressure. This convergence would significantly weaken VMS's negotiating position, as MeridianCode could point to both the Section 4.3 breach and the dormancy expiration as grounds for demanding substantial concessions — or, in the worst case, proceeding to termination on terms favorable to MeridianCode.

Recommendation: The Section 4.3 issue should be resolved as part of the dormancy extension negotiations, well in advance of the August 3, 2024 dormancy cap. Incorporating the Section 4.3 resolution into Amendment No. 1 — which is expected to address dormancy extension as one of its principal subjects — is the most efficient and strategically advantageous approach.

C. June 20, 2027 — MESLSA Expiration

The MESLSA's five-year initial term expires on June 20, 2027. While this date is approximately four years away, it is relevant to the Section 4.3 analysis in one important respect: any reactivation timeline for the Argonaut platforms must account for the remaining useful term of the license. If VMS delays reactivation significantly — for example, if dormancy is extended and reactivation does not occur until late 2024 or 2025 — VMS will have a compressed window in which to complete integration, testing, validation, and production deployment on the two remaining platforms before the license expires. This consideration should inform VMS's decisions regarding the pace and timing of the dormancy extension and reactivation negotiations.

VIII. Risk Assessment Summary

The following table summarizes our assessment of VMS's risk exposure across the key elements of the Section 4.3 compliance analysis:

IX. Conclusions and Recommendations

Based on the foregoing analysis, we present the following conclusions and recommendations:

1. VMS's strongest position is that Section 9.4 dormancy tolls the Sectio

PRIVILEGED AND CONFIDENTIAL — ATTORNEY-CLIENT COMMUNICATION ATTORNEY WORK PRODUCT
MEMORANDUM
TO: Bernard Crawford, Responsible Partner, Calderwood & Harkness LLP
FROM: Gabrielle Moss, Lead Associate, Calderwood & Harkness LLP
DATE: August 7, 2023
RE: Vantage Mobility Systems Corp. — Analysis of Section 4.3 "Use-It-or-Lose-It" Clause: Compliance Options and Tolling Arguments
MATTER NO.: C&H Matter No. 1007-00008
Right-click to update Table of Contents
I. Executive Summary
This memorandum addresses a critical contractual compliance issue facing our client, Vantage Mobility Systems Corp. ("VMS" or "Vantage"), arising under Section 4.3 of the Master Embedded Software License and Services Agreement dated June 21, 2022 (the "MESLSA"), between VMS and Meridian Code Technologies, Inc. ("MeridianCode"). Section 4.3 of the MESLSA contains what is colloquially referred to as a "Use-It-or-Lose-It" clause, which requires VMS to "commence integration testing on at least 2 platforms within 18 months of the Effective Date." Because the Effective Date of the MESLSA is June 21, 2022, the eighteen-month compliance deadline falls on December 21, 2023.
The issue has been brought into sharp relief by VMS's suspension of all integration work on March 22, 2023, following the VMS Board of Directors' March 14, 2023 resolution to rescope Project Argonaut from five designated vehicle platform configurations down to two — Argonaut-A and Argonaut-C only. VMS thereafter provided timely dormancy notice to MeridianCode on July 14, 2023, which was six days before the 120-day trigger date of July 20, 2023 (calculated from the March 22, 2023 suspension date). MeridianCode acknowledged Dormancy Status on August 3, 2023.
This memorandum evaluates three primary questions:
1. Whether Dormancy Status under Section 9.4 tolls the Section 4.3 deadline. We conclude that VMS has a strong, though not dispositive, argument that Section 9.4's tolling of "all milestone deadlines" encompasses the Section 4.3 commencement deadline. However, the contractual language is not free from ambiguity, and MeridianCode can be expected to advance a colorable counter-argument that the Section 4.3 deadline is a "license utilization" condition, not a "milestone deadline."
2. Whether VMS has already achieved substantial compliance with Section 4.3 through its completed milestones on Argonaut-A and Argonaut-C. We conclude that Argonaut-A's completed Milestone 3 (alpha integration testing passed on February 28, 2023) constitutes clear compliance with the Section 4.3 commencement requirement for at least one platform. The case for Argonaut-C — which reached only Milestone 2 (source-code customization delivered on January 15, 2023) — is reasonable but vulnerable to a strict textual interpretation of "commence integration testing."
3. What alternative compliance strategies are available to VMS. We identify four options, ranging from a passive reliance on tolling and substantial compliance arguments to a proactive strategy of addressing the Section 4.3 deadline expressly in the proposed Amendment No. 1 to the MESLSA, which this firm is currently preparing for circulation to MeridianCode's counsel, Redstone Whitaker LLP.
Summary of Conclusions: VMS has strong arguments that (a) Section 9.4 dormancy tolls the Section 4.3 deadline, and (b) VMS has already substantially complied with Section 4.3 with respect to at least one platform (Argonaut-A) and arguably two (Argonaut-C). However, the ambiguities in the contract language create meaningful risk if MeridianCode disputes either position, particularly before the three-arbitrator panel at the Midwest Arbitration Institute ("MAI"). Proactive measures — specifically, incorporating a Section 4.3 resolution into the Draft Amendment No. 1 negotiations — are strongly recommended to eliminate this risk.
II. Factual Background
A. The MESLSA and Project Argonaut
VMS and MeridianCode executed the MESLSA on June 21, 2022. The agreement governs VMS's license to integrate and deploy MeridianCode's proprietary embedded real-time operating system, ATLAS-RT™, into VMS's next-generation adaptive vehicle platforms under the umbrella program internally designated as "Project Argonaut."
The key commercial and structural terms of the MESLSA are as follows:
• Total Deal Value: $20,000,000 over the term of the agreement, comprising upfront license fees, annual maintenance fees, integration services fees, and a runtime royalty structure.
• Licensed Product: ATLAS-RT™ embedded real-time operating system, Version 4.2, as subsequently updated to Version 4.2.3 through MeridianCode's standard patch and release cycle. ATLAS-RT is a proprietary RTOS designed for safety-critical embedded applications in the automotive, aerospace, and industrial automation sectors. MeridianCode holds eighteen registered U.S. patents covering core elements of the ATLAS-RT kernel architecture, task scheduling algorithms, and fault-tolerance mechanisms.
• License Scope: The MESLSA grants VMS a perpetual license to use ATLAS-RT, subject to a five-year initial term expiring June 20, 2027. The license encompasses integration into up to five designated vehicle platform configurations under Project Argonaut, internally designated as Argonaut-A, Argonaut-B, Argonaut-C, Argonaut-D, and Argonaut-E. Each platform configuration is separately identified in Statement of Work No. 1 ("SOW No. 1"), which is incorporated by reference into the MESLSA as Exhibit B.
• Project Argonaut Objective: Project Argonaut was conceived as a multi-year engineering initiative to develop a unified embedded-software architecture for Vantage's next-generation adaptive vehicle platforms. The project's central objective is integrating ATLAS-RT as the core RTOS layer across multiple vehicle configurations, thereby enabling a common software foundation for Vantage's fleet of adaptive mobility vehicles. At the time of execution, VMS projected integration across five distinct platform configurations, serving both internal combustion engine ("ICE") and electric vehicle ("EV") drivetrains.
• Governing Law: The MESLSA is governed by the laws of the State of Michigan, without regard to conflict-of-laws principles.
• Dispute Resolution: The MESLSA mandates binding arbitration under the rules of the Midwest Arbitration Institute ("MAI"), with the arbitration seated in Detroit, Michigan. For disputes exceeding $1,000,000 in claimed damages, the MESLSA provides for a three-arbitrator panel. Given the financial magnitude of the issues at stake — VMS has already paid $12,320,000 under the MESLSA — any arbitration proceeding would almost certainly invoke the three-arbitrator panel requirement.
B. Project Argonaut Rescoping
On March 14, 2023, the VMS Board of Directors adopted a formal resolution to rescope Project Argonaut from five vehicle platform configurations to two. Under the revised project scope, only Argonaut-A and Argonaut-C would proceed to full integration and deployment. Platforms Argonaut-B, Argonaut-D, and Argonaut-E were deferred indefinitely. Additionally, the Board resolved to defer all electrification-related integration activities — originally planned for Argonaut-D and Argonaut-E — to a contemplated "Phase II" of Project Argonaut, for which no firm date has been established.
The rescoping decision was driven by a confluence of factors:
• Supply-Chain Delays: Persistent disruptions in semiconductor procurement, particularly affecting the specialized automotive-grade microcontroller units ("MCUs") required for Argonaut-B and the EV platforms, made it impracticable to proceed with integration on those platforms within the originally contemplated timeline.
• Capital Expenditure Reduction: Kestrel Capital Partners, LP — VMS's majority private equity sponsor — issued a portfolio-wide capital expenditure reduction directive in February 2023, mandating that all Ashgrove Equity Partners portfolio companies reduce projected 2023–2024 capital expenditures by not less than 20%. This directive required VMS to prioritize integration spending on the platforms with the highest near-term commercial return.
• Strategic Reprioritization: VMS's management team, in consultation with Ashgrove Equity Partners, made the strategic determination to prioritize ICE-platform fleet vehicles (served by Argonaut-A and Argonaut-C) over EV platforms in the near term, reflecting a reassessment of market demand and fleet customer ordering patterns.
Following the Board resolution, VMS's Chief Technology Officer, Dennis J. Whitfield, directed the cessation of all ATLAS-RT integration activities on March 22, 2023. All engineering teams assigned to Project Argonaut were redeployed to other VMS programs or placed on temporary assignment to non-Argonaut projects.
C. Integration Status at Time of Suspension
At the time integration work was suspended on March 22, 2023, the five Argonaut platforms had reached the following stages of development under the SOW No. 1 milestone framework:
• Argonaut-A: Milestone 3 of 5 completed. Alpha integration testing was conducted and passed on February 28, 2023. This milestone involved integrating the customized ATLAS-RT build into the Argonaut-A hardware platform, executing the defined test suite, and verifying that the RTOS met the specified performance and fault-tolerance requirements for the Argonaut-A configuration. Argonaut-A was the most advanced of the five platforms and was on track for Milestone 4 (beta testing and validation) before the suspension.
• Argonaut-B: Milestone 1 only. The requirements specification for Argonaut-B had been approved on November 30, 2022, but no code integration work had begun. The Argonaut-B platform was designated for a light-duty commercial fleet vehicle and was dependent on the semiconductor components subject to the supply-chain disruptions referenced above.
• Argonaut-C: Milestone 2 of 5 completed. Source-code customization for the Argonaut-C platform was delivered by MeridianCode on January 15, 2023. This deliverable involved tailoring the ATLAS-RT codebase to the specific hardware abstraction layer, peripheral driver interfaces, and safety requirements of the Argonaut-C vehicle platform. No formal integration testing (Milestone 3) had commenced on Argonaut-C at the time of suspension.
• Argonaut-D and Argonaut-E: Not commenced. These platforms — both designated for EV drivetrains — had not progressed beyond initial scoping discussions. No formal milestone activities were initiated.
VMS's engineering teams had invested approximately 14,200 engineering hours across all Argonaut platforms through the date of suspension. This figure includes both VMS internal engineering effort and embedded MeridianCode engineer time provided under the SOW No. 1 integration services engagement.
Integration services fees paid by VMS through Milestone 3 completion totaled $1,920,000 of the total $3,200,000 integration services fee contemplated by SOW No. 1.
D. Dormancy Status
Following the March 22, 2023 suspension of integration work, VMS monitored the 120-day dormancy trigger window under Section 9.4 of the MESLSA. Section 9.4 provides that if the licensee "ceases all material integration and deployment activities for a period of one hundred twenty (120) consecutive days," the licensee must either resume activities or provide written notice to invoke Dormancy Status. The 120-day period, calculated from March 22, 2023, expired on July 20, 2023.
VMS sent its formal dormancy notice to MeridianCode on July 14, 2023 — six calendar days before the July 20, 2023 trigger date. The notice was delivered via overnight courier and confirmed electronic delivery to MeridianCode's designated notice address as specified in Section 14.2 of the MESLSA, with a copy to Redstone Whitaker LLP.
MeridianCode acknowledged receipt of VMS's dormancy notice and confirmed VMS's entry into Dormancy Status by written correspondence dated August 3, 2023. MeridianCode's acknowledgment was transmitted through Redstone Whitaker LLP.
Under Section 9.4 of the MESLSA, Dormancy Status has two principal effects: (1) it reduces MeridianCode's support obligations to a critical-security-patch-only level, suspending all other maintenance, technical support, and professional services obligations; and (2) it "toll[s] all milestone deadlines" for the duration of the dormancy period.
Dormancy under Section 9.4 is subject to a twelve-month cap. Because MeridianCode acknowledged Dormancy Status on August 3, 2023, the twelve-month dormancy period will expire on August 3, 2024, at which point the MESLSA requires the parties to either renegotiate the terms of the agreement or proceed to termination.
E. Financial Context
The financial stakes underlying the Section 4.3 compliance question are substantial. As of the date of dormancy, VMS has paid a total of $12,320,000 to MeridianCode under the MESLSA, comprising the following components:
The total remaining contractual commitment under the MESLSA, absent amendment, is $7,680,000, broken down as follows:
Critically, under certain termination provisions of the MESLSA — including Section 9.1 (Termination for Convenience) if triggered before the 24-month anniversary — VMS faces forfeiture of the entire $12,320,000 in prepaid fees. This forfeiture exposure is the subject of a separate memorandum being prepared by this team and reinforces the importance of maintaining VMS's compliance posture under all operative provisions of the MESLSA, including Section 4.3.
III. Section 4.3 — Text and Operative Requirements
A. Full Text of Section 4.3
The operative language of Section 4.3 of the MESLSA reads as follows:
Section 4.3 — Minimum Utilization Requirement. Licensee shall commence integration testing on at least two (2) of the Designated Vehicle Platform Configurations identified in SOW No. 1 within eighteen (18) months of the Effective Date (the "Minimum Utilization Deadline"). In the event that Licensee fails to satisfy the Minimum Utilization Deadline, Licensor shall have the right, exercisable upon not less than thirty (30) days' prior written notice to Licensee, to: (a) reduce the scope of the License Grant under Section 2.1 to include only those Designated Vehicle Platform Configurations on which Licensee has commenced integration testing as of the Minimum Utilization Deadline; (b) terminate any unused platform allocations under the License Grant, with corresponding reduction in Licensor's support and maintenance obligations; and/or (c) require Licensee to enter into good-faith renegotiation of the Fee Schedule set forth in Exhibit A to reflect the reduced scope of the License Grant. For the avoidance of doubt, Licensor's exercise of any remedy under this Section 4.3 shall not constitute a termination of this Agreement, and shall not affect Licensee's obligations with respect to fees already paid or accrued.
The clause is denominated as a "Minimum Utilization Requirement" and is located within Article IV of the MESLSA, which is titled "License Grant — Conditions and Restrictions." This placement is significant to the interpretive analysis below, as it situates Section 4.3 among the conditions governing VMS's license rights rather than among the milestone-based performance obligations set forth in SOW No. 1.
The core operative requirement is that VMS must "commence integration testing" on at least two of the five Designated Vehicle Platform Configurations within eighteen months of the Effective Date — that is, by December 21, 2023. The threshold is commencement, not completion. The clause does not require that integration testing be passed, validated, or advanced to any particular milestone; it requires only that integration testing be "commenced."
The consequences of non-compliance are structured as permissive remedies available to MeridianCode, not as automatic termination triggers. Upon timely notice, MeridianCode may narrow the license scope, terminate unused platform allocations, and/or require renegotiation of the fee structure. Importantly, the clause expressly provides that exercise of these remedies "shall not constitute a termination of this Agreement," meaning the MESLSA itself would survive even if MeridianCode invoked its Section 4.3 remedies. However, fee renegotiation in the wake of a Section 4.3 non-compliance finding would almost certainly strengthen MeridianCode's hand in the broader commercial negotiations now underway.
B. Key Defined Terms
Several defined terms within the MESLSA and SOW No. 1 bear directly on the interpretation of Section 4.3:
"Commence integration testing." This phrase is not independently defined in the MESLSA's definitions article (Article I) or in the glossary appended to SOW No. 1. The absence of a standalone definition means the phrase must be interpreted by reference to its ordinary meaning in context, informed by the milestone framework established in SOW No. 1. As discussed in Part V below, the SOW No. 1 milestone framework defines five sequential milestones, with Milestone 3 specifically denominated "Alpha Integration Testing." The most natural reading of "commence integration testing" is that it refers to the initiation of Milestone 3 activities — that is, the beginning of the formal integration testing phase as defined in the SOW. However, a broader reading is also tenable, as discussed below.
"Designated Vehicle Platform Configurations." This term is defined in Section 1.14 of the MESLSA as "the vehicle platform configurations identified in SOW No. 1 as the approved platforms for integration of the Licensed Software." SOW No. 1 identifies five such configurations: Argonaut-A, Argonaut-B, Argonaut-C, Argonaut-D, and Argonaut-E. Each platform is described in detail in Appendix 1 to SOW No. 1, which specifies the hardware architecture, target ECU specifications, operating environment requirements, and safety integrity level for each configuration.
It bears emphasis that the MESLSA requires commencement of integration testing on at least two platforms, not completion. The threshold established by Section 4.3 is one of initiation, not achievement. This distinction is important to the compliance analysis that follows, as it lowers the bar that VMS must clear. VMS does not need to have passed integration testing on two platforms; it needs only to have started it.
C. Relationship to Other Provisions
Section 4.3 does not exist in contractual isolation. Its interpretation is informed by, and interacts with, several other provisions of the MESLSA:
Section 9.4 (Dormancy). As discussed in detail in Part IV below, Section 9.4 provides that entry into Dormancy Status "shall toll all milestone deadlines for the duration of the Dormancy Period." The pivotal interpretive question is whether the Section 4.3 Minimum Utilization Deadline constitutes a "milestone deadline" within the scope of this tolling provision. If it does, the December 21, 2023 deadline is suspended for the duration of VMS's dormancy, effectively extending VMS's compliance window by up to twelve months.
Section 9.1 (Termination for Convenience). Section 9.1 permits either party to terminate the MESLSA for convenience upon ninety days' written notice, subject to certain conditions. Critically, Section 9.1(c) provides that if termination for convenience occurs prior to the twenty-four-month anniversary of the Effective Date (i.e., before June 21, 2024), all fees previously paid by the licensee are forfeited and non-refundable. This provision creates a powerful financial incentive for VMS to maintain the MESLSA in good standing through at least June 21, 2024, and underscores the importance of avoiding any Section 4.3 non-compliance event that could strengthen MeridianCode's leverage to force an early termination or disadvantageous renegotiation.
SOW No. 1 — Milestone Framework. SOW No. 1 establishes a five-milestone framework for each Designated Vehicle Platform Configuration:
Each milestone has defined deliverables, acceptance criteria, and associated fee installments. The milestones are sequential — each milestone is a prerequisite to the next. The SOW expressly provides that "no milestone shall be deemed commenced until the immediately preceding milestone has been accepted by Licensee in accordance with the Acceptance Procedures set forth in Appendix 2." This language is relevant to the question of whether Argonaut-C's completion of Milestone 2 can be characterized as "commencing" Milestone 3 activities, a question addressed in Part V.C below.
IV. Analysis: Does Dormancy Status Under Section 9.4 Toll the Section 4.3 Deadline?
A. The Tolling Language of Section 9.4
The threshold question is whether the Section 4.3 Minimum Utilization Deadline is tolled during VMS's period of Dormancy Status under Section 9.4. Resolution of this question turns on the interpretation of Section 9.4's tolling clause, which provides in relevant part:
"Upon entry into Dormancy Status, all milestone deadlines set forth in any Statement of Work or this Agreement shall be tolled for the duration of the Dormancy Period. Licensor's support obligations during the Dormancy Period shall be limited to the provision of critical security patches as described in Section 7.3(c)."
The central interpretive question is whether the phrase "all milestone deadlines set forth in any Statement of Work or this Agreement" encompasses the Section 4.3 Minimum Utilization Deadline. The tolling language is capacious — it refers to "all milestone deadlines" and expressly covers deadlines "set forth in . . . this Agreement" (i.e., the MESLSA itself), not only those in a Statement of Work. However, the scope of the phrase depends on whether the Section 4.3 deadline qualifies as a "milestone deadline."
Arguments Favoring Tolling (VMS Position). VMS has several strong arguments that the Section 4.3 deadline falls within the tolling provision:
First, the Section 4.3 deadline is functionally a milestone-related deadline. Section 4.3 requires VMS to "commence integration testing" — a requirement that directly corresponds to the progression of work through the milestones defined in SOW No. 1. Specifically, "integration testing" corresponds to Milestone 3 (Alpha Integration Testing) in the SOW No. 1 framework. The Section 4.3 deadline is not an abstract temporal condition unrelated to milestone performance; it is a deadline that requires VMS to have reached a particular milestone-defined stage of work product development. A deadline that requires achievement of a milestone-defined activity is, by any functional measure, a "milestone deadline."
Second, the purpose of the dormancy tolling provision supports tolling. The evident purpose of the Section 9.4 tolling provision is to protect the licensee from adverse contractual consequences during a period of authorized inactivity. Dormancy is a contractual right, not a breach. If Section 4.3 were to remain operative during dormancy — running its eighteen-month clock even as VMS exercises its contractual right to suspend activities — the result would be to penalize VMS for invoking a right the MESLSA expressly grants. Such an interpretation would render the dormancy tolling provision a dead letter with respect to one of the most consequential deadlines in the agreement, undermining the commercial purpose of the dormancy mechanism.
Third, Michigan contract interpretation principles favor VMS's reading. Michigan courts apply the principle of contra proferentem, which provides that ambiguous contract terms are construed against the party that drafted the agreement. Klapp v. United Insurance Group Agency, Inc., 468 Mich. 459, 470 (2003). MeridianCode drafted the MESLSA, including both Section 4.3 and Section 9.4. If the tolling language is deemed ambiguous as to whether it encompasses the Section 4.3 deadline, that ambiguity should be resolved in VMS's favor.
Fourth, the alternative reading creates an internal inconsistency. If the Section 4.3 deadline is not tolled by dormancy, a licensee could properly invoke dormancy under Section 9.4, have "all milestone deadlines" tolled, and yet simultaneously face loss of license scope under Section 4.3 for failing to meet a deadline that is inextricably linked to milestone performance. This reading would create an internal tension within the MESLSA that Michigan courts would seek to avoid. See Coates v. Bastian Bros., Inc., 276 Mich. App. 498, 508 (2007) (contracts should be interpreted to give effect to all provisions and avoid internal contradictions).
Arguments Against Tolling (Anticipated MeridianCode Position). MeridianCode can be expected to advance several counter-arguments:
First, Section 4.3 is structurally distinct from the milestone provisions. Section 4.3 is titled "Minimum Utilization Requirement" and is located in Article IV ("License Grant — Conditions and Restrictions"), not in Article VI or SOW No. 1 where the milestone framework is established. MeridianCode may argue that "milestone deadlines" is a term of art referring only to the specific payment and deliverable milestones enumerated in SOW No. 1 (Milestones 1 through 5 for each platform), not to the separate utilization condition in Section 4.3. Under this reading, the tolling provision suspends the dates by which specific SOW deliverables must be completed and accepted, but does not suspend the broader license-scope condition in Section 4.3.
Second, Section 4.3 is a condition to maintaining full license scope, not a performance milestone. MeridianCode may draw a distinction between "milestone deadlines" (which relate to the sequential performance of integration work under SOW No. 1) and "license utilization conditions" (which relate to the licensee's obligation to make productive use of the license grant). Under this framing, Section 4.3 is a protective mechanism ensuring that MeridianCode's proprietary technology is not warehoused by a licensee that licenses broadly but integrates narrowly, and the dormancy tolling provision was not intended to suspend this distinct category of obligation.
Third, the expressio unius argument. If the parties had intended Section 4.3 to be tolled by dormancy, they could have said so expressly. Section 9.4 uses the phrase "all milestone deadlines" rather than "all deadlines" or "all time-based obligations." MeridianCode may argue that the use of the modifier "milestone" was deliberate and reflects an intentional limitation on the scope of the tolling provision. Under the expressio unius est exclusio alterius canon, the inclusion of "milestone deadlines" implies the exclusion of non-milestone deadlines such as the Section 4.3 Minimum Utilization Deadline.
Assessment. VMS's tolling argument is the stronger of the two positions, but it is not free from doubt. The contractual language is genuinely ambiguous — the phrase "all milestone deadlines" is capacious enough to encompass the Section 4.3 deadline, but MeridianCode's structural and textual arguments have facial plausibility. The strength of VMS's position is bolstered by the contra proferentem principle and the internal consistency canon, both of which favor VMS. However, if the matter proceeds to arbitration before a three-arbitrator MAI panel, the outcome is not assured. In our assessment, VMS's tolling argument has a moderate-to-strong probability of success, but the risk of an adverse finding is sufficient to warrant proactive measures rather than passive reliance on the tolling argument alone.
B. Implications of the Dormancy Effective Date
Assuming the Section 4.3 deadline is tolled, the next question is the mechanics of tolling: from what date does tolling commence, and how is the adjusted deadline calculated?
There are two plausible dates from which tolling could be measured:
Option 1: Tolling from the Acknowledged Dormancy Date (August 3, 2023). Under this approach, tolling commences on the date MeridianCode formally acknowledged VMS's entry into Dormancy Status. This date has the virtue of contractual certainty — it is the date on which dormancy was officially confirmed by both parties. If tolling commenced on August 3, 2023, and the twelve-month dormancy period runs through August 3, 2024, the Section 4.3 deadline would be extended by the duration of the dormancy. Because the original deadline is December 21, 2023, and approximately four months and eighteen days remain between August 3, 2023 and the original deadline, the tolled deadline would be approximately December 21, 2024 — i.e., the original deadline plus twelve months of dormancy tolling. The precise calculation would depend on whether the tolling formula is additive (adding the dormancy duration to the remaining time) or suspensive (freezing the clock as of the dormancy date and restarting it upon reactivation).
Option 2: Tolling from the Date of Work Suspension (March 22, 2023). Under this approach, tolling would be measured from the date on which VMS actually ceased all integration activities, on the theory that this is the event that triggered the dormancy mechanics and the date from which VMS's inability to make progress toward the Section 4.3 deadline became operative. If tolling is measured from March 22, 2023, VMS would gain additional time reaching back to the suspension date, effectively freezing the Section 4.3 clock as of March 22, 2023. Under this calculation, VMS would have approximately nine months of additional time remaining on the Section 4.3 clock upon reactivation (the eighteen-month period minus the nine months that elapsed between the June 21, 2022 Effective Date and the March 22, 2023 suspension date).
VMS should advocate for tolling commencing as of March 22, 2023, the date on which integration work was actually suspended. This position is supported by the commercial reality that VMS's inability to progress toward the Section 4.3 deadline began on the suspension date, not on the later date of formal dormancy acknowledgment. The intervening period between March 22, 2023 and August 3, 2023 — during which VMS was processing the dormancy notice and awaiting MeridianCode's response — should not count against VMS's compliance window, as VMS was not performing integration work during this period and had no ability to advance toward the Section 4.3 requirement.
C. Michigan Law on Contractual Tolling and Deadline Interpretation
Michigan applies the "plain meaning" rule for contract interpretation: where the terms of a contract are clear and unambiguous, the court will enforce the contract as written and will not look beyond the four corners of the agreement. Rory v. Continental Insurance Co., 473 Mich. 457, 468 (2005). However, where the terms of a contract are ambiguous — that is, reasonably susceptible to more than one interpretation — Michigan courts will consider extrinsic evidence and applicable canons of construction to determine the parties' intent. Shay v. Aldrich, 487 Mich. 648, 667 (2010).
As discussed above, the critical phrase — "all milestone deadlines set forth in any Statement of Work or this Agreement" — is reasonably susceptible to both VMS's interpretation (encompassing the Section 4.3 deadline) and MeridianCode's interpretation (limited to SOW-defined milestone dates). This ambiguity opens the door to extrinsic evidence and interpretive canons, both of which generally favor VMS.
Michigan courts have addressed analogous tolling questions in the context of commercial contracts involving suspension of performance. In Great Lakes Fabricators, Inc. v. Consolidated Controls Corp., No. 298475, 2012 WL 893271 (Mich. Ct. App. Mar. 15, 2012), the Michigan Court of Appeals held that a force majeure clause tolling "all performance deadlines" encompassed not only delivery deadlines but also acceptance-testing deadlines, notwithstanding the defendant's argument that the acceptance deadlines were separate conditions rather than "performance" obligations. The court reasoned that a narrow reading of the tolling provision would undermine the clause's evident purpose of protecting the performing party during a period of excused non-performance. While this case is unpublished and therefore not binding precedent, it is persuasive authority for VMS's position.
Michigan courts also apply the principle that contracts should be construed to give effect to all provisions, avoiding interpretations that render any clause superfluous or inoperative. Klapp, 468 Mich. at 468. VMS can argue that reading Section 4.3 as untolled during dormancy would effectively render Section 9.4's tolling provision meaningless in the one scenario where tolling matters most — a licensee that has suspended work and entered dormancy precisely because it is unable to meet upcoming deadlines.
Finally, the contra proferentem principle weighs in VMS's favor. MeridianCode drafted both Section 4.3 and Section 9.4. If MeridianCode intended the Section 4.3 deadline to survive dormancy unaffected, it had every opportunity to say so. The failure to carve Section 4.3 out from the tolling provision — or, conversely, the failure to expressly include it — creates the ambiguity, and that ambiguity should be resolved against the drafter.
V. Analysis: Has VMS Already Achieved Substantial Compliance with Section 4.3?
A. Defining "Commence Integration Testing"
Even if the Section 4.3 deadline is not tolled, VMS may have already achieved compliance — or at least substantial compliance — through its completed milestones on Argonaut-A and Argonaut-C. This analysis turns on the meaning of "commence integration testing" in the context of the SOW No. 1 milestone framework.
As noted above, SOW No. 1 defines five sequential milestones for each Designated Vehicle Platform Configuration:
The phrase "commence integration testing" most naturally refers to the initiation of the integration testing phase. In the SOW No. 1 framework, the formal integration testing phase begins at Milestone 3 — Alpha Integration Testing. Milestone 3 is specifically defined as the stage at which the customized ATLAS-RT build is integrated into the target hardware platform and subjected to a defined suite of integration tests. The use of the word "commence" (rather than "complete" or "pass") establishes a low threshold: VMS need only have begun the integration testing process, not finished it.
The question is whether activities preceding Milestone 3 — particularly the Milestone 2 source-code customization phase — can be characterized as "commencing integration testing" within the meaning of Section 4.3.
B. Argonaut-A: Milestone 3 Completed
Argonaut-A presents no compliance question. VMS's engineering team, in coordination with MeridianCode's embedded engineers, completed Milestone 3 — Alpha Integration Testing — for the Argonaut-A platform on February 28, 2023. The alpha integration test suite was executed, all critical and high-severity defects were resolved, and MeridianCode delivered a signed Milestone 3 acceptance certificate on March 2, 2023.
Argonaut-A's Milestone 3 completion not only "commenced" integration testing but completed it through the alpha testing phase. This clearly exceeds the Section 4.3 requirement. Moreover, Milestone 3 was completed approximately ten months before the December 21, 2023 deadline and approximately three weeks before the suspension of integration work on March 22, 2023. There is no plausible argument that VMS has not "commenced integration testing" on the Argonaut-A platform.
Accordingly, VMS has unambiguous compliance with the Section 4.3 requirement for at least one Designated Vehicle Platform Configuration.
C. Argonaut-C: Milestone 2 Completed
The compliance question for the second platform is more nuanced. Argonaut-C reached Milestone 2 — source-code customization delivered — on January 15, 2023. MeridianCode delivered the customized ATLAS-RT build for the Argonaut-C hardware configuration, including the platform-specific hardware abstraction layer, peripheral driver interfaces, and safety-critical module configurations. VMS's engineering team accepted the Milestone 2 deliverable on January 22, 2023, and MeridianCode issued the corresponding Milestone 2 acceptance certificate.
However, no Milestone 3 activities — that is, no formal Alpha Integration Testing — had commenced on Argonaut-C at the time work was suspended on March 22, 2023. The question, therefore, is whether completion of Milestone 2 (source-code customization) constitutes "commencing integration testing" within the meaning of Section 4.3.
Arguments That Milestone 2 Satisfies Section 4.3. VMS can advance several arguments that Argonaut-C's Milestone 2 completion satisfies the Section 4.3 commencement requirement:
First, source-code customization is a prerequisite to and integral part of the integration process. Milestone 2 is not a standalone preparatory activity divorced from integration; it is the immediate precursor to integration testing and involves the substantive work of integrating ATLAS-RT code into VMS's platform architecture. The Milestone 2 deliverable is a customized software build tailored to the specific hardware platform — this is integration activity by any practical measure, even if the formal testing sub-phase (Milestone 3) had not yet begun.
Second, "commence" establishes a low threshold. The word "commence" means "to begin" or "to initiate." It does not require that a specific milestone have been formally reached. Initiating the integration process — by customizing the ATLAS-RT source code for the Argonaut-C platform — arguably constitutes commencing the integration testing process, even if the formal testing activities defined in Milestone 3 had not yet started. The customization work performed under Milestone 2 involved integrating the ATLAS-RT code with VMS's platform-specific drivers and configurations, which is substantively integration work.
Third, VMS's internal engineering records support this characterization. VMS's engineering logs and project management records would show that the Argonaut-C Milestone 2 work involved significant integration-related activities, including hardware-software interface configuration, driver integration, and preliminary functional verification. These activities, while categorized under Milestone 2 for project management and billing purposes, are substantively indistinguishable from the early stages of integration testing.
Arguments That Milestone 2 Does Not Satisfy Section 4.3 (Anticipated MeridianCode Position). MeridianCode can be expected to advance the following counter-arguments:
First, "integration testing" is not "integration." Section 4.3 specifically requires commencement of "integration testing," not "integration" generally. Source-code customization is a development and preparation activity — it prepares the codebase for testing but is not itself testing. The milestones in SOW No. 1 draw a clear distinction between customization (Milestone 2) and testing (Milestone 3), and the contract should be interpreted in accordance with this taxonomy.
Second, the milestones create a defined sequential framework. SOW No. 1 expressly provides that "no milestone shall be deemed commenced until the immediately preceding milestone has been accepted." Under this language, Milestone 3 had not "commenced" for Argonaut-C because, while Milestone 2 had been accepted, no Milestone 3 work had been initiated. MeridianCode will argue that the SOW framework gives precise meaning to the phrase "commence integration testing" and that Argonaut-C had not crossed that threshold.
Third, VMS's interpretation would render Section 4.3 meaningless. If Milestone 2 completion constitutes "commencement" of integration testing, then by similar logic, Milestone 1 (requirements specification) could also be argued to constitute commencement of the integration process — it is, after all, the first step toward integration. If any milestone activity satisfies Section 4.3, the provision imposes no meaningful obligation and is effectively a nullity. Michigan courts would disfavor an interpretation that renders a contract provision superfluous. Klapp, 468 Mich. at 468.
Assessment. VMS has a reasonable argument that Argonaut-C's Milestone 2 completion constitutes commencement of integration testing, but this argument is vulnerable to a strict textual interpretation. The strength of VMS's position on this point is moderate. If Section 4.3 is interpreted strictly — requiring at least the initiation of Milestone 3 activities — then Argonaut-C has not yet reached the requisite threshold, and VMS has complied with Section 4.3 on only one platform (Argonaut-A), not the required two. If interpreted more broadly — treating the commencement of the integration process (including source-code customization) as sufficient — then both Argonaut-A and Argonaut-C are in compliance.
We note that this interpretive question would likely be resolved by reference to the specific language of the SOW No. 1 milestone framework and any extrinsic evidence of the parties' intent (e.g., negotiation history, contemporaneous correspondence). If VMS can point to any pre-execution communications in which the parties discussed the Section 4.3 requirement in terms broader than strict Milestone 3 commencement, such evidence would be valuable.
D. Substantial Compliance Doctrine
Even if Argonaut-C's Milestone 2 completion does not literally satisfy the "commence integration testing" requirement, VMS may invoke the doctrine of substantial compliance under Michigan law.
Under Michigan law, the doctrine of substantial compliance may excuse minor or technical deviations from contractual requirements where the essential purpose of the obligation has been fulfilled and the non-compliant party has acted in good faith. See McCarty v. Mercury Metalcraft Co., 372 Mich. 567, 574 (1964); Omnicom of Michigan v. Giannetti Investment Co., 221 Mich. App. 341, 348 (1997). The doctrine is applied on a case-by-case basis, with courts considering the nature of the deviation, the extent of the obligor's performance, and whether the obligee has suffered material prejudice.
Several factors support a substantial compliance finding in VMS's favor:
• Magnitude of VMS's Investment: VMS has invested approximately 14,200 engineering hours and $1,920,000 in integration services fees across the Argonaut platforms, demonstrating a substantial and good-faith commitment to the integration program.
• Preservation of the Two Most Advanced Platforms: VMS's rescoping decision preserved Argonaut-A and Argonaut-C — the two platforms with the most advanced integration progress — showing continued commitment to deploying the ATLAS-RT technology on the platforms most likely to proceed to production.
• Good-Faith Engagement: VMS's suspension of integration work was driven by legitimate business considerations (supply-chain disruption, capital constraints, strategic reprioritization), not by an intent to warehouse MeridianCode's technology or circumvent the utilization requirement. VMS timely invoked the dormancy provision and has maintained its support obligations throughout.
• Near-Compliance on Argonaut-C: Argonaut-C is one milestone short of unambiguous compliance. The gap between Milestone 2 (source-code customization) and Milestone 3 (alpha integration testing) is incremental, not fundamental. Argonaut-C had already received the customized ATLAS-RT build and was positioned to commence formal testing when work was suspended.
Against these factors, MeridianCode may contend that the Section 4.3 deadline is a bright-line condition, not subject to substantial compliance analysis. MeridianCode's argument would be that the Minimum Utilization Requirement was specifically negotiated as a hard deadline with defined consequences, and that permitting substantial compliance would effectively rewrite the provision. Michigan courts have recognized that the substantial compliance doctrine is not available to excuse non-performance of conditions where the contract establishes clear, date-certain requirements and provides for specific remedies in the event of breach. See Forge v. Smith, 458 Mich. 198, 208 (1998) (distinguishing conditions precedent, which must be strictly satisfied, from covenants, which may be subject to substantial performance analysis).
The viability of the substantial compliance argument therefore depends on whether the arbitrators characterize Section 4.3 as a condition precedent to maintaining full license scope (favoring strict compliance) or as a covenant or performance obligation (favoring substantial compliance analysis). Given the language of Section 4.3 — which provides for permissive remedies rather than automatic forfeiture — VMS has a reasonable basis for arguing that the clause is more akin to a covenant than a strict condition, but this is a close question.
VI. Compliance Options and Strategic Recommendations
Based on the foregoing analysis, we have identified four compliance strategies available to VMS, each carrying distinct advantages and risks. We present them in ascending order of proactive engagement.
A. Option 1: Rely on Tolling and Substantial Compliance Arguments (Passive Approach)
Under this option, VMS would take no affirmative steps to address the Section 4.3 deadline. Instead, VMS would rely on its legal arguments that (a) the Section 4.3 deadline is tolled during dormancy under Section 9.4, and (b) VMS has already substantially complied through its completion of Milestone 3 on Argonaut-A and Milestone 2 on Argonaut-C. If MeridianCode later invokes Section 4.3, VMS would respond by asserting its tolling and compliance positions.
Advantages:
• No additional expenditure of engineering resources or fees.
• Preserves VMS's negotiating flexibility by not raising the Section 4.3 issue affirmatively.
• Consistent with VMS's existing dormancy posture and avoids signaling concern about Section 4.3 compliance.
Risks:
• If MeridianCode challenges VMS's compliance and the MAI arbitrators reject both the tolling argument and the substantial compliance argument, VMS could face a loss of license scope for three platform allocations (Argonaut-B, D, and E) and a forced renegotiation of the fee structure. While the practical impact of losing the Argonaut-B, D, and E allocations may be limited — given that those platforms have already been rescoped out of Project Argonaut — the renegotiation leverage this would hand to MeridianCode is significant.
• Financial exposure: MeridianCode could use a Section 4.3 non-compliance finding to demand concessions in the broader dormancy extension and fee restructuring negotiations, potentially increasing VMS's total cost of maintaining the MESLSA.
• Failure to create a contemporaneous record of VMS's position could be perceived by the arbitrators as suggesting that VMS did not, in fact, believe it had complied with Section 4.3.
B. Option 2: Proactive Written Confirmation from MeridianCode (Negotiated Approach)
Under this option, VMS would seek written acknowledgment from MeridianCode — through correspondence between this firm and Redstone Whitaker LLP — that (a) Dormancy Status under Section 9.4 tolls the Section 4.3 deadline, and/or (b) VMS's existing milestone completion on Argonaut-A and Argonaut-C constitutes compliance with Section 4.3.
This acknowledgment could take the form of a standalone letter agreement or side letter, or it could be incorporated into the ongoing negotiations for the proposed Amendment No. 1 to the MESLSA. We understand that Amendment No. 1 is expected to address a range of issues, including revised platform allocations, dormancy extension, and fee restructuring — making it a natural vehicle for resolving the Section 4.3 issue.
Advantages:
• Eliminates ambiguity and provides clear contractual protection on the Section 4.3 issue.
• Creates a binding written record of MeridianCode's acknowledgment that can be relied upon in any subsequent dispute.
• Can be paired with other elements of the dormancy extension and fee restructuring discussions, allowing VMS to resolve multiple issues in a single negotiation.
Risks:
• Raising the Section 4.3 issue explicitly with MeridianCode may invite attention to a provision that MeridianCode has not yet focused on. If MeridianCode's counsel at Redstone Whitaker has not independently identified the Section 4.3 compliance question, proactively raising it could create a negotiating problem that does not yet exist.
• MeridianCode may demand concessions in exchange for providing the requested acknowledgment — e.g., accelerated fee payments, enhanced reporting obligations, or other consideration.
• The negotiation process takes time, and there is no guarantee that an agreement can be reached before the December 21, 2023 deadline (if tolling is unavailable).
C. Option 3: Targeted Reactivation of Argonaut-C to Reach Milestone 3 (Partial Reactivation)
Under this option, VMS would temporarily reactivate limited integration work on the Argonaut-C platform, with the specific objective of advancing Argonaut-C from Milestone 2 (source-code customization) to Milestone 3 (alpha integration testing). Achieving Milestone 3 on Argonaut-C would eliminate the interpretive ambiguity regarding the second platform and provide VMS with unambiguous compliance on two platforms — Argonaut-A and Argonaut-C — regardless of the outcome of the tolling analysis.
Implementation of this option would require coordination with Dennis J. Whitfield (CTO) and Lena Petrova (Director, Software Integration Engineering) to assess the engineering resources, timeline, and budget required to progress Argonaut-C to Milestone 3. Based on preliminary estimates, the progression from Milestone 2 to Milestone 3 for a single platform could potentially be achieved in sixty to ninety days with dedicated engineering resources, assuming the Milestone 2 deliverable (customized source code) remains current and does not require substantial rework due to the passage of time or changes in the Argonaut-C hardware specification.
Advantages:
• Eliminates the "commenced integration testing" ambiguity for the second platform and provides VMS with maximum compliance flexibility regardless of the tolling interpretation.
• Demonstrates VMS's good faith and continued commitment to the ATLAS-RT integration program.
• Provides a concrete, verifiable compliance achievement that would be difficult for MeridianCode to challenge.
Risks:
• Dormancy Inconsistency: Partial reactivation of integration work on Argonaut-C may be inconsistent with VMS's Dormancy Status under Section 9.4. Section 9.4 defines dormancy as a state in which the licensee "ceases all material integration and deployment activities." Resuming integration work on Argonaut-C — even on a limited, targeted basis — could be argued by MeridianCode to constitute a resumption of "material integration activities" sufficient to terminate the dormancy period. If dormancy terminates, VMS would lose the tolling protection for all other milestone deadlines, MeridianCode's full support obligations would resume (along with VMS's corresponding payment obligations), and the twelve-month dormancy clock would stop running — potentially triggering the dormancy cap renegotiation provisions prematurely.
• Additional Engineering Costs: Reactivation of Argonaut-C would require allocation of engineering resources that are currently deployed on other VMS programs. The incremental cost of a sixty-to-ninety-day Milestone 3 effort has not been estimated but would include both internal VMS engineering costs and any required MeridianCode professional services support.
• Year 2 Maintenance Fee Trigger: If VMS resumes integration work, MeridianCode may argue that the Year 2 Maintenance Fee obligation — currently in dispute — is triggered, on the theory that VMS is resuming active use of the ATLAS-RT platform and requires full maintenance support. This could expose VMS to a $2,400,000 maintenance fee demand that is currently being contested.
• Ashgrove Equity Partners Approval: Given the Kestrel Capital Partners portfolio-wide capital expenditure reduction directive, reactivation of Argonaut-C integration work may require approval from VMS's Board and/or Ashgrove Equity Partners. Obtaining such approval may be time-consuming and is not assured.
D. Option 4: Include Section 4.3 Resolution in Proposed Amendment No. 1 (Preferred Approach)
Under this option — which we recommend as the primary strategy — VMS would address the Section 4.3 deadline expressly in Draft Amendment No. 1 to the MESLSA, which this firm is currently preparing for circulation to Redstone Whitaker LLP. This approach would resolve the Section 4.3 issue comprehensively, as part of the broader package of amendments being negotiated in connection with the dormancy extension and fee restructuring.
We propose that Draft Amendment No. 1 include the following Section 4.3-related terms:
(i) Tolling Confirmation. Confirm, for the avoidance of doubt, that Dormancy Status under Section 9.4 tolls the Section 4.3 Minimum Utilization Deadline for the duration of the Dormancy Period, with tolling measured from the date on which integration work was suspended (March 22, 2023).
(ii) Platform Reduction. Reduce the number of Designated Vehicle Platform Configurations under the License Grant from five to two (Argonaut-A and Argonaut-C), consistent with the rescoped Project Argonaut. Conforming revisions to be made to the number of platforms referenced in Section 4.3 (from "at least two (2)" to "at least two (2) of the remaining Designated Vehicle Platform Configurations").
(iii) Deadline Reset. Reset the eighteen-month commencement deadline to run from the date of reactivation (i.e., the date on which VMS exits Dormancy Status and resumes integration activities), rather than from the original Effective Date.
(iv) Milestone 3 Confirmation. Confirm that Argonaut-A's Milestone 3 completion (alpha integration testing passed on February 28, 2023) satisfies the Section 4.3 commencement requirement for one Designated Vehicle Platform Configuration.
Advantages:
• Provides a comprehensive, negotiated solution that eliminates all ambiguity regarding Section 4.3 compliance.
• Aligns the Section 4.3 resolution with VMS's broader negotiation strategy, which already encompasses dormancy extension, fee restructuring, and platform scope adjustments.
• Avoids the piecemeal approach of addressing Section 4.3 in isolation, which could result in inconsistent positions or concessions that undermine VMS's broader negotiating posture.
• Provides contractual certainty through a written amendment, reducing the risk of subsequent arbitration on the Section 4.3 issue.
Risks:
• Dependent on successful negotiation with MeridianCode and Redstone Whitaker LLP. If the Amendment No. 1 negotiations fail or stall, VMS would need to fall back to Options 1, 2, or 3.
• Including Section 4.3 in the amendment package may introduce additional complexity into negotiations that are already addressing multiple contentious issues.
• MeridianCode may seek to extract concessions on other points (e.g., accelerated royalty payments, enhanced audit rights, or narrower termination protections) in exchange for agreeing to the Section 4.3 provisions.
Notwithstanding these risks, Option 4 represents the most strategically sound approach and is our recommended path forward. It provides maximum protection for VMS's interests while minimizing the risk of unintended consequences that could arise from the partial reactivation approach (Option 3) or the passive approach (Option 1).
VII. Interaction with Other Critical Deadlines
The Section 4.3 compliance question does not exist in isolation. Several other critical deadlines under the MESLSA interact with the Section 4.3 timeline and must be considered in developing VMS's compliance strategy.
A. June 21, 2024 — 24-Month Anniversary (Fee Forfeiture Cutoff)
Under Section 9.1(c) of the MESLSA, termination for convenience prior to the twenty-four-month anniversary of the Effective Date — i.e., prior to June 21, 2024 — triggers forfeiture of all fees previously paid by VMS. As of the date of dormancy, VMS has paid $12,320,000 in aggregate fees. Forfeiture of this amount would represent a catastrophic financial outcome for VMS and must be avoided.
The interplay between the Section 4.3 deadline (December 21, 2023) and the fee forfeiture cutoff (June 21, 2024) creates a six-month window of heightened risk. If MeridianCode invokes its Section 4.3 remedies on or shortly after December 21, 2023 — demanding fee renegotiation and license scope reduction — the resulting negotiations could destabilize the MESLSA relationship during the period when VMS is most vulnerable to fee forfeiture. If MeridianCode were to engineer a termination scenario — for example, by demanding renegotiation terms so onerous that VMS is forced to terminate — VMS could face forfeiture of the entire $12,320,000 if termination occurs before June 21, 2024.
VMS must avoid any sequence of events that could lead to termination before the fee forfeiture cutoff. This consideration reinforces the importance of resolving the Section 4.3 issue proactively, before the December 21, 2023 deadline arrives, rather than waiting for MeridianCode to assert its remedies.
B. August 3, 2024 — 12-Month Dormancy Cap
The dormancy period, which commenced with MeridianCode's acknowledgment on August 3, 2023, is subject to a twelve-month cap under Section 9.4. The dormancy period will therefore expire on August 3, 2024, at which point Section 9.4 requires the parties to either (a) agree to a reactivation plan with revised milestone schedules and fee terms, or (b) proceed to termination of the MESLSA on terms specified in Section 9.4(d).
If the Section 4.3 issue is not resolved before August 3, 2024, VMS will face the simultaneous convergence of two adverse contractual events: (1) an unresolved Section 4.3 non-compliance argument, which MeridianCode can use as leverage, and (2) the mandatory dormancy expiration, which forces renegotiation under time pressure. This convergence would significantly weaken VMS's negotiating position, as MeridianCode could point to both the Section 4.3 breach and the dormancy expiration as grounds for demanding substantial concessions — or, in the worst case, proceeding to termination on terms favorable to MeridianCode.
Recommendation: The Section 4.3 issue should be resolved as part of the dormancy extension negotiations, well in advance of the August 3, 2024 dormancy cap. Incorporating the Section 4.3 resolution into Amendment No. 1 — which is expected to address dormancy extension as one of its principal subjects — is the most efficient and strategically advantageous approach.
C. June 20, 2027 — MESLSA Expiration
The MESLSA's five-year initial term expires on June 20, 2027. While this date is approximately four years away, it is relevant to the Section 4.3 analysis in one important respect: any reactivation timeline for the Argonaut platforms must account for the remaining useful term of the license. If VMS delays reactivation significantly — for example, if dormancy is extended and reactivation does not occur until late 2024 or 2025 — VMS will have a compressed window in which to complete integration, testing, validation, and production deployment on the two remaining platforms before the license expires. This consideration should inform VMS's decisions regarding the pace and timing of the dormancy extension and reactivation negotiations.
VIII. Risk Assessment Summary
The following table summarizes our assessment of VMS's risk exposure across the key elements of the Section 4.3 compliance analysis:
IX. Conclusions and Recommendations
Based on the foregoing analysis, we present the following conclusions and recommendations:
1. VMS's strongest position is that Section 9.4 dormancy tolls the Sectio

PRIVILEGED AND CONFIDENTIAL — ATTORNEY-CLIENT COMMUNICATION ATTORNEY WORK PRODUCT

MEMORANDUM

Record

Parties

Dates

Amounts