Misdiagnoses en escalatiecriteria

Wanneer “no power” een verkeerde conclusie wordt

Je krijgt een Apple Silicon MacBook binnen met de klacht: “Hij doet helemaal niets.” De klant heeft al “alles geprobeerd”: andere oplader, andere kamer, soms een dock, soms direct in het stopcontact. Op de werkbank zie jij óók weinig: geen chime, geen laadindicatie, geen beeld, geen trackpad-haptics. Dit is precies het soort case waar beginnende techs onbewust tijd verliezen: niet door een gebrek aan inzet, maar door een te snelle label (“logic board dood”, “poort stuk”, “batterij kapot”) zonder hard bewijs.

In deze fase van je diagnose draait het minder om nóg een extra test en meer om kwaliteit van je conclusie. Kun jij met gegevens onderbouwen wat je wél weet, wat je niet weet, en wat daarom de juiste vervolgstap is? Dat is het verschil tussen een snelle juiste route en een escalatie die voelt als gokken.

Deze les gaat daarom over twee dingen die je werk direct verbeteren: misdiagnoses herkennen (en voorkomen) en escalatiecriteria scherp formuleren. Je gebruikt daarbij dezelfde discipline uit eerdere lessen: bekend-goede power, variabelen minimaliseren, patronen noteren, en mechanische invloeden niet “als fix” verwarren met bewijs.

Kernbegrippen: wat is een misdiagnose, en wat is goede escalatie?

Misdiagnose betekent hier niet “je had ongelijk”—maar: je trekt een conclusie die niet logisch volgt uit je metingen. Bij no-power op Apple Silicon is dat extra riskant, omdat power-management streng is: een minieme instabiliteit (handshake reset, contactverlies, protectiegedrag) kan zich presenteren als “compleet dood”. Als je dan de verkeerde oorzaak kiest, ga je óf onnodig demonteren, óf juist te lang extern variëren.

Escalatiecriteria zijn de expliciete voorwaarden waaronder je stopt met laag-risico troubleshooting en overgaat naar een volgende laag: diepere inspectie, componentgerichte isolatie, of doorzetten naar een gespecialiseerde route. Goede escalatiecriteria zijn observatie-gedreven: ze verwijzen naar reproduceerbare symptomen (bijv. “alle bekend-goede adapters/cables op alle poorten: 0 indicatie”) en naar risicofactoren (bijv. vloeistofverdenking, mechanische instabiliteit).

Een handige manier om het te onthouden:

• Diagnose = “Wat weet ik zeker op basis van tests?”

• Hypothese = “Wat zou dit kunnen zijn?”

• Escalatiebesluit = “Welke volgende stap is gerechtvaardigd, gezien bewijs en risico?”

Je intakevragen en je testopzet zijn hierbij geen formaliteit, maar je “meetapparatuur” in brede zin. Neutrale vragen over docks, kabelrouting, haken aan de kabel, of mogelijke vloeistofmomenten maken vaak het verschil tussen een solide casus en een verhaal vol aannames.

De 3 meest voorkomende misdiagnoses (en hoe je ze voorkomt)

1) “Het is de logic board” (terwijl je alleen ‘geen teken van leven’ hebt)

Geen indicatoren betekent: je hebt nog geen onderscheid gemaakt tussen geen power-in, instabiele power-in, protectiegedrag, of interne distributieproblemen. Beginnende techs maken hier vaak een sprong: “Als hij niets doet op mijn lader, is het intern.” Maar Apple Silicon kan ook “niets doen” bij een input die nét niet goed genoeg is voor stabiele onderhandeling, of bij een contact dat 1–2 keer per minuut wegvalt.

De beste preventie is je baseline scherp houden: bekend-goede adapter + bekend-goede kabel, direct in de Mac, zonder dock/monitor, en met consistente omstandigheden. Je let niet alleen op of er reactie is, maar ook op herhaalbaarheid en conditie-afhankelijkheid. Eén teken van leven is geen vrijspraak; het is een datapunt dat je juist moet proberen te reproduceren.

Wanneer wordt “logic board” wél waarschijnlijker? Als je systematisch hebt uitgesloten dat power-in faalt: meerdere poorten, meerdere bekend-goede combinaties, gecontroleerde kabelrouting (geen zijbelasting), en nog steeds 0 indicatie. Zelfs dan blijft je rapportage bij voorkeur beschrijvend: “Geen enkele power-respons onder gecontroleerde bekend-goede inputcondities” is sterker dan “board dood”, en helpt de juiste vervolgstappen te rechtvaardigen.

2) “Het is PD/handshake” (terwijl het mechanisch contactkwaliteit is)

Je zag in de vorige les hoe mechanische issues zich vermommen als “handshake gedoe”. Een instabiel CC-contact of een plug/poort met speling kan ervoor zorgen dat de onderhandeling telkens reset. Voor jou ziet dat eruit als: soms wel, soms niet, afhankelijk van hoek, druk, of kabelroute. De misdiagnose ontstaat wanneer je de wisselende respons meteen mentaal parkeert bij “USB‑C is lastig” of “dock probleem”, en vervolgens eindeloos accessoires gaat roteren.

De preventie is één simpele regel: als mechanische variabelen (stress/hoek/speling) het symptoom sturen, behandel het als mechanisch totdat het tegendeel bewezen is. Dat betekent: je test met een stabiele opstelling (Mac vlak, kabel ontspannen), en je verandert alleen één fysieke factor tegelijk. Als de Mac alleen reageert wanneer jij de plug “helpt”, dan heb je geen handshake-bewijs; je hebt bewijs van contactgevoeligheid.

Belangrijk: “wiebelen” is geen methode, maar een valkuil. Je gebruikt minimale beïnvloeding alleen om een patroon vast te leggen—niet om een tijdelijk werkende toestand te normaliseren. Als jouw aanraking de enige manier is om leven te krijgen, is dat juist een escalatie-indicator: verder forceren kan micro-arcing of extra slijtage veroorzaken, en je verliest zuivere data.

3) “Het is de batterij / diepe ontlading” (terwijl de input instabiel is)

Een Mac die pas na lange tijd op de lader reageert, triggert snel het verhaal “diepe ontlading”. Soms klopt dat, maar vaak is het een verkapte observatie van instabiele input: de Mac komt nooit lang genoeg in een stabiele laadmodus omdat de verbinding telkens onderbreekt. Dan krijg je precies het verwarrende gedrag: lange wachttijden, incidentele tekenen van leven, en daarna weer niets.

De preventie is het combineren van twee technieken uit eerdere lessen: tijd noteren én beweging als oorzaak-gevolg herkennen. Je noteert “tijd tot eerste teken van leven” per gecontroleerde conditie (poort, kabeloriëntatie, kabelrouting). Als een minieme beweging de respons “reset”, wijst dat eerder op contactverlies dan op een batterij die rustig aan het herstellen is.

Daarnaast helpt het om je taal streng te houden: “reageert pas na X minuten” is een feit; “batterij is dood” is een interpretatie. Door feiten boven interpretaties te zetten, kun je later veel sneller verantwoorden waarom je wél of niet escalatie inzet.

Escalatiecriteria die verdedigbaar zijn (en die misdiagnoses stoppen)

Niet elk no-power geval hoeft meteen “omhoog” in complexiteit, maar te lang blijven hangen in variëren is ook een risico. Hieronder staan escalatiecriteria die passen bij de workflow uit deze sectie: eerst extern uitsluiten met bekend-goed, dan patroononderzoek (intermittent/vloeistof), dan mechanische lens, en pas daarna zwaardere stappen.

Een nuttige escalatie-habit is: schrijf één regel die altijd waar is op basis van jouw metingen, bijvoorbeeld: “Met bekend-goede 96W adapter + bekend-goede kabel direct in poort X/Y/Z: geen enkele indicator, ook niet na 10 minuten; gedrag verandert niet door kabelrouting.” Die ene regel voorkomt dat je later alsnog in het moeras van interpretaties wordt getrokken.

[[flowchart-placeholder]]

Twee cases: van twijfel naar heldere escalatie

Case 1: “Hij laadt alleen als je de kabel omhoog houdt” → mechanisch bewijs, geen ‘PD-probleem’

Je start met de strakke baseline: bekend-goede adapter en kabel, direct aangesloten, Mac vlak op tafel, kabel ontspannen zonder zijtrek. Je observeert: geen reactie. Daarna verander je één variabele: je ondersteunt de kabel heel licht zodat er geen trekkracht op de poort staat. Nu zie je wél een teken van leven, maar zodra je de ondersteuning weghaalt valt het weg.

Stap voor stap vertaal je dit naar bewijs:

1. De powerbron blijft identiek; de variabele is mechanische stress.
2. Het effect is reproduceerbaar (je kunt het 3–5 keer herhalen).
3. Het symptoom volgt de fysieke conditie, dus “handshake” is hoogstens een gevolg; de kern is contactkwaliteit.

De impact is dat je stopt met eindeloos kabels/chargers rouleren (ruis) en je voorkomt schade door forceren. De beperking blijft: zonder verdere inspectie weet je niet of het de poort zelf is, de plug, of intern (I/O-flex/connectorpad). Je escalatie is dus niet “poort stuk”, maar: “mechanisch beïnvloedbare power-in; instabiel contact; verder testen zonder druk is niet betrouwbaar.” Dat is precies het soort escalatie dat een team kan overnemen zonder opnieuw vanaf nul te beginnen.

Case 2: “Op kantoor via monitor dood, thuis soms wel” → geen ‘dock schuld’, maar kabelspanning als trigger

De eerste verleiding is het dock/monitorverhaal: “PD passthrough is slecht.” Je doet daarom wat in deze sectie consequent terugkomt: je maakt de setup schoon. Bekend-goede adapter, bekend-goede kabel, direct in de Mac. Op de werkbank lijkt het probleem “weg” als de kabel recht naar beneden hangt, maar komt terug wanneer je de kabel routeert alsof hij langs een monitorarm naar achteren trekt.

Je maakt het bewijs hard door controle:

1. Zelfde poort, kabel, adapter; alleen de kabelrouting verandert.
2. Met zijtrek: geen reactie. Zonder zijtrek: wel consistent(er) teken van leven.
3. Je concludeert niet “dock kapot”, maar: de kantooropstelling vergroot mechanische stress en maakt een marginaal contact zichtbaar.

De winst hiervan is organisatorisch groot: je voorkomt onjuiste advisering (“koop andere monitor”), je voorkomt terugkomers (“thuis doet-ie het wel”), en je documenteert een reproduceerbare trigger die anderen kunnen verifiëren. De beperking: ook hier blijft componentniveau (poort vs. intern) open, maar je escalatie is zuiver: “contactgevoelig onder belasting; risico op verergering; vervolgroute gericht op fysieke verbindingen.”

Een korte checklist voor jezelf: stop met gokken, start met criteria

Je hoeft niet elke case “op te lossen” in deze fase; je moet hem juist positioneren. Als je merkt dat je brein een label wil plakken, pauzeer dan en vraag jezelf:

• Heb ik bekend-goede power en kabel echt onder controlecondities getest (direct, geen dock, stabiele kabel)?

• Is het gedrag reproduceerbaar, of ben ik achter toeval aan het jagen?

• Stuurt beweging/hoek/stress het symptoom? Dan is dat je hoofdspoor.

• Heb ik één zin die mijn escalatie rechtvaardigt op basis van feiten, niet op gevoel?

Als je die vragen eerlijk kunt beantwoorden, wordt “escaleren” geen zwaktebod maar professioneel vakmanschap: je beschermt het apparaat, je beschermt je tijd, en je beschermt de kwaliteit van je diagnose.

Een checklist die je kunt vertrouwen

• Begin elke conclusie met observeerbare feiten (0 respons, tijd tot respons, reproduceerbaarheid) en voeg interpretaties pas daarna toe.

• Zie mechanische beïnvloedbaarheid als sterk bewijs: als stress/hoek het symptoom stuurt, is “PD/handshake” vaak een gevolg, niet de oorzaak.

• Gebruik escalatiecriteria om schade en tijdverlies te voorkomen: instabiliteit onder minimale beweging, vloeistofverdenking, of herhaald 0-respons onder bekend-goede condities zijn signalen om niet eindeloos te blijven variëren.

• Documenteer zo dat een andere tech jouw setup kan herhalen: poort, kabel, adapter, routing, en exacte respons.

Met deze aanpak maak je van “no power” een beheersbare categorie: niet door sneller te gokken, maar door sneller te onderbouwen.