ProbeGnosis: The Knowledge You Can Only Earn
Naval Ravikant’s “productize yourself” idea is simple but powerful: figure out what you are uniquely good at, then apply leverage so that your specific knowledge can scale.
When I first encountered that idea, it did not feel new to me.
It felt familiar.
Not because I had already built something large.
Not because I understood the creator economy perfectly.
But because ProbeLem was already living on top of that idea before I knew how to explain it.
I did not create ProbeLem because I wanted to become a content creator.
I created it because there was a kind of knowledge I needed when I was starting out...
and I could not find it.
Not in the classroom.
Not in the manuals alone.
Not in clean textbook examples where everything behaves politely.
I was looking for real shipboard electrical troubleshooting knowledge. The kind that only appears when the alarm is active, the vessel is running, the diagram is incomplete, the crew is waiting, and the ETO has to decide where to place the probe.
That is the knowledge I wanted.
That is the knowledge I was forced to learn.
And that is the knowledge I am now trying to productize.
What Does ProbeGnosis Actually Mean?
Let me start from the root, because the word was coined deliberately.
Probe. To investigate. To push the test prod of a multimeter into a circuit and find what is hiding there. A troubleshooting action. A physical, deliberate act. The word that gave ProbeLem its name.
Gnosis. This is the one that needs unpacking. Gnosis is not academic knowledge. It is not secondhand knowledge. It is not information passed around until nobody remembers where it came from. Gnosis is direct, experiential knowledge. The kind that can only be acquired by doing. By being present. By living through the problem and arriving at the answer through your own hands and your own mind.
Gnosis is knowledge gained by contact. By pressure. By consequence.
Put them together and you get ProbeGnosis: the direct, experiential knowledge of electrical troubleshooting that was never written in a manual, never taught in a maritime academy, and never distilled anywhere into a form that a young ETO can actually use.
The kind of knowledge you can only earn vessel by vessel, fault by fault, across years of real shipboard work.
That is what ProbeLem is trying to document.
The Origin
Rory Vaden said something that stopped me the first time I heard it.
You are in the most powerful position to help the person you once were.
That line hit differently than any business framework I had encountered. It was not about market positioning or audience demographics. It was personal. Almost uncomfortable in how precisely it described the reason I started this brand.
I remember what it felt like to be the ETO who did not know where to start. Who stood in front of a fault he had never seen before and reached for the part that looked most likely to be broken. Who ran in circles because nobody had ever shown him there was another way.
I remember the frustration. The late nights with the drawings spread out on the workshop table, working through a problem by trial and error because there was no resource that bridged the gap between the textbook theory and the actual circuit behavior on this specific vessel, with this specific history, under these specific conditions.
That frustration is the origin of ProbeLem.
Not a content strategy. Not a monetization plan. A direct response to a problem I lived.
The electrical troubleshooting body of knowledge I wish had existed when I was starting out. That is the mission. That has always been the mission.
The Combination
Here is something I have noticed about how I think.
When I encounter a concept that I need to retain, I compress it into a word. I name it. I build a metaphor around something physical and familiar until the abstract thing has a shape I can hold.
That is not a content trick. That is genuinely how my brain works.
ProbeLem is the combination of my procedure and my personality. I learn from real faults, real measurements, and real consequences... then I coin words so the lesson can be remembered, taught, and reused.
That is how I know.
That is how I teach.
The coinages that come from this process are not marketing labels. They are cognitive tools. Names I gave things so that I could teach them. Names that carry the concept inside them, so you do not have to re-explain every time.
ProbeGnosis is one.
The Probing Loop is another.
And the Space-Time Jutsu is the one that made me realize that the naming was actually the method.
But before I get to the Space-Time Jutsu, I need to show you what it was built against.
The Doom Loop
The Doom Loop is not a character flaw. It is the default human response under pressure.
You see a symptom. You assume you already know the cause. You swap a part. The fault returns. You swap another part. The fault returns again. You blame the equipment, write it up as intermittent fault, monitor for recurrence, and sign off the job. The spare parts are gone. The vessel sails. Nothing has changed.
It runs in five beats.
Assume. Skip identification. The symptom is the problem. “The breaker is faulty.”
Swap. Go straight to replacing components. No logic test. No paper work. “If I replace this, it should work.”
Force. When the swap fails, do the same thing with more intensity. Same approach, more pressure. “It has to be this. Try again.”
Blame. When forcing fails, externalize. “The manufacturer sent a bad part.” “This vessel is cursed.” The classic: “It was working before I got here.”
Loop back to Assume. No new information was gathered at any step. You are back where you started, with fewer spare parts and the same unresolved fault.
The Doom Loop is seductive because it looks like action. You are opening panels. You are pulling fuses. You are busy. It feels like troubleshooting.
But at no point did you generate new information about the system.
I have watched experienced engineers run the Doom Loop on complicated faults... not because they lacked skill, but because pressure collapsed their process. The cadet Doom Loops because he does not know where to start. The senior ETO Doom Loops because he has seen a hundred similar faults and assumes this one is the same. The officer under time pressure Doom Loops because the bridge is waiting and there is no time to sit with a drawing.
Different people. Different reasons. Same loop. Same result.
What separates the Probing Loop from the Doom Loop is not intelligence. It is not years of experience. It is one decision, made in the first ten seconds after the alarm sounds.
Do I react... or do I identify?
That pause is the entrance to the Probing Loop.
The Probing Loop
When I thought carefully about how I actually solve electrical problems, I noticed a pattern. Not a checklist imposed from outside. A pattern that was already there, in my own process, that I had never made explicit.
Three steps. Always three steps.
1. Identify the Problem. Not the symptom. The problem. A symptom is what the alarm shows you. A problem is the actual condition causing the alarm. These are almost never the same thing, and treating them as the same is where most troubleshooting goes wrong from the first move.
2. Probe. Investigate. But investigation has two tracks.
First, the Logic Test: work the theory on paper before you touch anything. Open the electrical drawing. Understand the circuit. Spot the contradictions. Let your mind probe the system before your hands do.
Then, the Reality Test: run an experiment that can actually fail. Not a check that confirms what you already believe. A test that could prove you wrong... because that is the only test worth running.
3. Correct / Steer / Iterate. Compare the outcome to the desired result. If you are off course, adjust heading and loop again. The failed attempt is not a dead end. It is a compass reading.
You do not throw away the rudder because the ship drifted 2° off course. You correct and continue.
I call the third step Steer because troubleshooting is navigational, not surgical. You are not cutting out a bad part and replacing it with a good one. You are moving through a problem space, generating information at each step, converging on the solution.
The Probing Loop converges inward. Each iteration tightens the spiral.
I named it so I could teach it. I teach it so others do not have to rediscover it from scratch.
That is ProbeGnosis in action.
The Space-Time Jutsu: ProbeGnosis in the Engine Room
Now let me show you what happens when the Probing Loop meets a fault that had been living inside a vessel for over a year.
When I came onboard for the first time, the crew told me about a nuisance tripping issue they had been dealing with for over a year since the previous ETO installed it. A hydraulic power pack circuit breaker on the main switchboard. Every time the vessel entered split mode, it tripped. Every single time. Control circuit fuses blowing intermittently. The fault had outlasted the previous crew rotation.
I inherited a live fault with a year of wrong answers behind it.
Step 1: Identify the Problem
The Doom Loop response was obvious: “The new breaker is faulty. Order another one.”
The Probing Loop asked a different question. Not what is broken but what condition triggers the fault?
The breaker did not trip randomly. It tripped specifically and consistently when the bus-tie breaker opened to enter split mode. That specificity matters. Random tripping suggests component failure. Conditional tripping suggests a system interaction.
So the problem was not “the breaker trips.”
The problem was: something in the split mode transition causes the undervoltage trip coil to see a voltage condition that commands the breaker to open.
That is a completely different starting point.
The Doom Loop never reaches it. Because the Doom Loop never asks the question.
How UVT Coil Impedance Mismatch Caused MCCB Nuisance Tripping | #PRObed Part 1 | Marine Electrical
Step 2a: The Logic Test
Before I touched a single wire, I sat with the electrical drawings.
The undervoltage trip coils on all three hydraulic power pack circuit breakers were connected in parallel on the secondary of a control transformer. They shared a common voltage source. And in a parallel circuit, current distributes according to impedance.
I measured the DC resistance of all three coils.
The two original coils: approximately 0.6 to 0.7 megohms. High resistance. Stable loads.
The replacement coil: 3.48 kilohms.
Nearly 200 times lower impedance than the coils it was installed alongside.
But here is what the DC resistance reading alone does not tell you. These coils operate on AC supply, not DC. In an AC circuit, a coil presents impedance... not just resistance. The new coil was not just low-resistance. It was inductive dominant, with a large inrush current on energization and significant transient behavior during switching events.
Two coils. Both rated 220V AC. Both visually interchangeable. Fundamentally incompatible in the same parallel circuit.
At the instant of bus-tie breaker opening, the circuit transitions. The inductive coil generates a transient. It pulls the shared control voltage below the undervoltage trip threshold for a fraction of a second. The breaker sees undervoltage and does exactly what it was designed to do.
It trips.
The logic test had named the enemy. Not a faulty breaker. A 200-times impedance mismatch hiding in plain sight.
How We Tried (And Failed) to Fix UVT Coil Impedance Mismatch, Series Part 2 | 1st Try |Traveling ETO
Step 2b: The Reality Test, First Pass — Space Jutsu
The logical solution was spatial. If the mismatched coil was causing problems because it shared a transformer secondary with the original coils... put it on its own transformer.
I installed a new dedicated transformer, with its secondary feeding only the replacement breaker’s coil.
We entered split mode.
The breaker tripped again.
I ran the Doom Loop response through my head for exactly one second, then stopped.
What did the experiment tell me?
It told me that spatial separation of the secondaries was not enough. Both transformers shared the same 380V primary source. When the bus-tie breaker opened, the switching transient entered at the primary level and coupled through to both transformer secondaries simultaneously.
I had solved the parallel impedance mismatch. I had not solved the root mechanism.
The transient was temporal, not just spatial.
I needed to solve not only where the fault occurred... but when.
Step 3: Correct / Steer — The Time Jutsu
The fault sequence was now fully understood.
When the bus-tie breaker opens to enter split mode, two relay contacts deenergize almost simultaneously. They gate the primary supply to the control transformer. For a fraction of a second, the transformer loses its primary supply. On the secondary side, the 220V supply to all undervoltage trip coils dips. For the original high-impedance coils, this dip is stable. For the new inductive coil, the energy dynamics during the dip create a momentary undervoltage condition sufficient to trigger the trip.
The window was less than one second.
One second was all I needed.
I installed an off-delay timer relay, wired to delay the de-energization of the main bus relay by one second after the bus-tie breaker opens. One second is enough for the split mode transition to complete before the coil supply is interrupted. The timer holds the primary supply stable through the transient. The breaker sees no voltage dip. The breaker stays closed.
Space Jutsu: isolate the mismatched coil onto its own transformer secondary. Spatial problem, spatial fix.
Time Jutsu: hold the control supply stable through the switching transient with an off-delay timer. Temporal problem, temporal fix.
Neither alone was sufficient. Both together solved the fault that had run for over a year.
I called the combined solution the Space-Time Jutsu because when you name something, you own it. When you own it, you can teach it.
The case file became ProbeStudy No. 3.
Space-Time Jutsu: The Final Solution to MCCB UVT Nuisance Tripping | Part 3 | 93m Full Uncut Troubleshooting
What ProbeGnosis Actually Is
The Space-Time Jutsu is not just a clever name for a circuit modification.
It is the crystallization of a ProbeGnosis moment.
A moment where the loop of experience, analysis, failure, correction, and re-analysis produced a principle that could not have come from a textbook. No manual on marine electrical systems says: when you encounter a mismatched UVT coil impedance causing transient undervoltage tripping during bus transfer, consider a combined spatial-temporal solution. No academy teaches the Space-Time Jutsu. It does not exist in the literature because it had never needed to exist until that vessel, that retrofit, that year-long fault.
It exists now because I was there. I worked the problem through the Probing Loop. I named what I found. And I documented it.
That is ProbeGnosis.
Direct, experiential knowledge, converted into a form that survives the person who earned it. Made transmissible. Made useful to the ETO who is standing in front of a similar fault on a different vessel in a different sea, years from now, with no idea where to start.
From Abstract to Concrete: What Naval Actually Meant
Naval talks about productizing yourself. But the abstraction is intentional, because he is addressing everyone.
For ProbeLem, the abstraction has already been made concrete.
The product is not me. The product is the accumulated body of knowledge I carry from years of real shipboard work. The product is every fault I worked, every drawing I read, every incorrect theory I tested and discarded, every ProbeGnosis moment I had at 0200 in an engine room somewhere between Norway and the North Sea.
The product is the troubleshooting body of knowledge I wish had existed when I was starting out.
Today, B2B means large company to large company. Department to department. Institution to institution.
But the direction is shifting. It will shift further.
There will come a time when the most valuable exchange is brand to brand... person to person. Real people. Real experience. A mechanic with 20 years of field failures. A nurse with pattern recognition no textbook captures. A teacher who knows how confused students actually think. A seafarer who has lived inside machinery most people only see in diagrams.
An ETO who learned troubleshooting across vessels, alarms, drawings, failures, mistakes, and hard-earned corrections.
AI will not make that experience irrelevant.
AI will make that experience scalable.
But only if the person can document it. Only if the person can structure it. Only if the person can turn the raw experience into something others can use.
That is the real challenge. Not just to use AI. But to have something worth multiplying.
ProbeLem is my answer to that challenge.
The Sixth Pillar
ProbeGnosis is the sixth of ProbeLem’s seven content pillars.
And for a long time, I knew what it felt like before I could fully articulate what it was. I coined the word before I could define it precisely. I built the content before I could explain the epistemology.
That is how direct knowledge works. You experience it first. The understanding comes later. And the transmission comes last.
I am in the transmission phase now.
The Probing Loop is transmissible. The Space-Time Jutsu is transmissible. The Doom Loop, as a named pattern that can be recognized and exited, is transmissible.
These are not just content pillars. These are the instruments of the knowledge transfer.
ProbeGnosis is the epistemological layer of the entire business. The reason the case studies exist. The reason the troubleshooting frameworks get named. The reason I write all of this down.
Because somewhere, right now, there is an ETO who is standing in front of a fault he has never seen before.
And the knowledge he needs is sitting inside someone else’s experience... undocumented, dying with the career of the person who earned it.
ProbeGnosis exists to change that.
Because I never understood learning until I experienced it.
I never found clarity until I taught it.
Keep on probing!
— Lem
The full Space-Time Jutsu case — ProbeStudy No. 3 — is available on Patreon for Probe Enthusiasts who want the complete technical documentation.
https://patreon.com/ProbeLem
ProbeLem is a troubleshooting library built from real shipboard electrical work, diagnostics, and field reflection.
If this post helped, follow the blog for future case studies and leave a comment with the fault, system, or lesson you want explored next.
Comments
Post a Comment