Refuse the 9.10-as-of-today letter for KT - give them 9.6 LTS now with its real support window and a required migration, and correct the numbers publicly when they turn out to be wrong

September 2, 2026 at 11:57 PMstrategyhigh

Situation

Arthur Tyde pulled Peter and Ramesh Srinivasan into an early-morning call on 9/2 over a roughly 1.x million dollar KT deal. The Korea AE had drafted a letter, largely AI-written, committing CIQ to deliver RLC 9.10 LTS as of today. RLC 9.10 does not exist - it is a November-December release - and KT cannot move to 10 because their ISV and telco software is certified on 9. Peter refused the letter shape and reframed the question first: why do they want early access, what do they want to do with it, what are they trying to accomplish. He then constructed the alternative himself - ship 9.6, which is the actual LTS build (9.8 is not), now, and extend support on 9.6 toward the 9.10 LTS window - and committed to verify feasibility with Nathan Blackham before anyone signed. He noted CIQ has done nothing on 9.10 builds yet, so early access to 9.10 does not exist to give. Later the same day in the group DM with Arthur, the Korea AE and Ramesh, Peter worked the actual support windows: 9.6 support is 4 years, 9.10 is not 10 years but 8, so the gap cannot be bridged - we can give them 9.6 now but they would need to migrate to 9.10 within 4 years. He posted the correction against himself unprompted: And I was wrong - 9.10 is 8 years, not 10. But still the same overall problem.

Reasoning

The letter as drafted would have forked a release on paper. Peter would not let a sales document create an engineering commitment that does not exist, and Ramesh named the same constraint - any letter must not bind us into something we cannot deliver or should not be delivering. But he did not stop at no: he found the commitment CIQ can actually keep and offered it, because the deal is real and the customer need is real. The public self-correction on the support window matters more than the number - a commitment letter is only worth the accuracy of the numbers underneath it, and he would rather be visibly wrong in the group DM than let a wrong number reach a customer contract.

Additional Context

KT is behind on a compliance audit and needs a secure supported Linux on thousands of machines inside the current budget cycle. The Korea AE needed signatures from Arthur, Peter and Bjorn before 11:30 KST. Peter had a hard deadline of about 90 minutes to verify with Nathan.

Observed Evidence

Fathom transcript of the 9/2 09:43 impromptu call with Arthur Tyde and Ramesh Srinivasan; group DM messages 9/2 18:21-18:33 UTC; DM to Nathan Blackham asking whether the two are different kernels.

Matching Patterns

40%
Decide on the Precedent, Not the Case(what any customer letter may commit to, release-forking precedent)

Confidence Breakdown

35/35
Evidence
24/30
Pattern
20/20
Source
15/15
Corroboration

Reasoning Depth Analysis

Org Signal:Sales cannot write commitments into a letter that engineering has to discover later. It also signals that the CTO will personally do the arithmetic on a support window rather than delegate the risk.
Who Affected:Nathan Blackham, who owns whether extended 9.6 support is deliverable; the Korea AE, who has to renegotiate the letter; Bjorn Hovland, a required signatory; KT, who now get a migration obligation they did not ask for.
Precedent:Establishes the answer shape for every future early-access ask: name what actually exists, state its real support window, and put the migration obligation in writing rather than papering over the gap.
Consequences:Real. A letter goes back for rewrite, KT gets 9.6 rather than 9.10, and a migration requirement lands inside a deal that was being sold as a 10-year commitment.
Timing:Driven entirely by the AEs same-day signature deadline in Korea Standard Time - which is precisely why the temptation to sign an inaccurate letter existed.

Source

reflection

AI Confidence

94%

Related Context

🎥
Impromptu Zoom Meeting - 9/2 09:43

fathom

I want to be clear. What we are saying is we will give them 9.6 now, and we will support 9.6 for the lifetime of 9.10 LTS. ... I do not think 9.8 is an LTS build for us. So I need to support the LTS version, because that is going to get me the closest to a 9.10 LTS.

💬
mpdm-pnelson--atyde--ally.cho--ramesh

slack

9.6 support is 4 years. 9.10 is 10 years. So we cannot bridge that gap... We can give them 9.6 now, but they would need to migrate to 9.10 in the next 4 years.

💬
mpdm-pnelson--atyde--ally.cho--ramesh

slack

And I was wrong - 9.10 is 8 years... not 10. But still the same overall problem.

Outcome

No outcome recorded yet.

Decision ID: f62b7530-af03-4adb-b4a5-4cc31631d550