By Michail Kolpidis
Listen to KTI Chairman’s Views — Episode 1: Provenance, iStorm and Apple on Spotify.
Please note: the podcast episode is in Greek.
The first episode of KTI Chairman’s Views begins with a real and still unresolved technical case involving a new MacBook Pro M5 Max, iStorm, Apple, and a question that extends far beyond one device: how do we preserve the complete history of a technical decision?
The case is ongoing. Apple Engineering is examining the technical evidence, while the contractual and regulatory questions are being considered separately. This article therefore does not claim that the computer is defective, determine the cause of the observed phenomenon, or reach a legal conclusion about the obligations of any party. It records what happened and explains why the sequence matters.
An observation before a conclusion
After acquiring a new MacBook Pro M5 Max from iStorm, together with the paid iSupport service, I noticed a specific mechanical sound and movement. The phenomenon appeared capable of raising a technical question, but an observation is not a diagnosis. I did not know its cause, and I did not present the machine as definitively defective.
My request was narrower: transmit the facts and the available observations to Apple so that the manufacturer could determine whether the behaviour was normal, within specification, or required further investigation.
That distinction is central. A customer can report what can be heard or seen without claiming to know what it means. The technical authority can then assess the evidence and make a determination. When those stages are kept separate, uncertainty remains manageable. When they are compressed into an unsupported conclusion, the integrity of the process weakens.
The escalation problem
According to the account presented in the episode, iStorm did not transmit the matter to Apple in the requested form and instead directed me towards telephone contact with Apple. Whether that response was compatible with the obligations attached to iSupport is a contractual question still under review. It should not be treated here as an adjudicated conclusion.
I then contacted Apple Executive Relations directly. The case was escalated to Apple Engineering for review of the technical evidence. That investigation remains open, and no final manufacturer determination has yet been communicated.
The sequence matters because escalation is not merely the act of sending a customer elsewhere. A meaningful escalation should preserve the original observation, the evidence accompanying it, the question being asked, and the authority expected to answer it. Without that continuity, each participant may be responding to a different version of the case.
What the service visits established—and what they did not
During visits to iStorm locations at Golden Hall and The Mall Athens, staff members heard the sound. They could not explain its cause. Their reactions suggested that the phenomenon did not appear normal to them and that a fault was possible, but those reactions were not a formal technical diagnosis by Apple.
I formed a provisional hypothesis that the noise might be associated with a key near or below the Enter key. That was my hypothesis, not an Apple finding. On that basis, I asked whether a limited key replacement could be considered.
The proposed service route was substantially broader: replacing a much larger assembly. Replacement of the complete MacBook Pro M5 Max was also not accepted. This created a practical dilemma before the manufacturer had classified the phenomenon.
If there was no defect, why open a brand-new, functioning computer and replace a major internal assembly without a documented technical basis? If there was a defect serious enough to justify that intervention, why was replacement of the new device not considered the more proportionate remedy?
The question is not whether every repair is wrong or every replacement is justified. It is whether the proposed intervention can be traced back to an authorised technical determination supported by evidence.
Comparison adds evidence, not certainty
To obtain a limited comparison, I acquired two additional new MacBook Pro computers. A MacBook Pro M5 Max reproduced the phenomenon. A baseline MacBook Pro M5 with upgraded RAM did not.
That comparison does not establish a general rule about MacBook Pro M5 configurations, nor does it determine the cause. The sample is too small for that. It does, however, add a relevant observation for competent engineers to evaluate. It narrows some possibilities, raises others, and becomes part of the evidence trail.
This is another reason provenance matters. Later evidence should be connected to the original report without rewriting it. The first observation, the service interactions, the comparison devices, and the manufacturer’s eventual conclusion should remain distinguishable but linked.
The provenance chain
In a reliable technical process, a case passes through a series of stages:
- Observation: someone notices a phenomenon.
- Evidence: the phenomenon is recorded or otherwise documented.
- Assessment: a competent person evaluates what the evidence may show.
- Determination: an authorised party reaches a technical conclusion.
- Escalation: the case moves to the appropriate higher authority when required.
- Manufacturer determination: the manufacturer classifies the behaviour and identifies the appropriate response.
- Intervention: an approved action is carried out.
- Closure: the outcome and its basis are recorded.
In real organisations, these stages often become disconnected. We may know that a repair was proposed but not who classified the problem. We may know that someone heard a sound but not what evidence the next person received. We may know that a case was closed but not the technical basis, authority, or sequence that produced the decision.
Provenance does not decide who is right
Provenance does not decide whether iStorm was right, whether I was right, or whether the MacBook Pro M5 Max is defective. Its role is to protect the integrity of the chain.
It allows us to ask precise questions: What was observed? What was recorded? Who evaluated it? What authority did that person have? What determination was made? When was it made? What evidence supported it? What intervention followed? Can the complete sequence still be demonstrated six months later?
This framework applies well beyond consumer electronics. The same need appears in industrial products, supply chains, certifications, laboratory results, equipment maintenance, financial events, and any process in which the route to a decision is as important as the outcome.
From disagreement to corrective action
The purpose of documenting this case is not simply to allocate blame. A real disagreement can reveal where a process loses information, authority, or continuity. If those gaps are examined, the case can produce a better and more traceable process for the future.
Apple Engineering’s review continues. The contractual and regulatory dimensions are being examined separately. When a substantive new event occurs, the history can be extended without erasing the uncertainty that existed at each earlier stage.
That is the simplest meaning of provenance: we protect not only the result, but the history of the result.