Why can't I catch the fault that only acts up when I'm gone?

You have learned to read the faults that show themselves. This one does not. It waits for you to leave, then acts. You call it intermittent, as if it were choosing to hide from you. It is not. Here is what you control: not the moment, but what waits to catch it. You cannot stand watch forever. So stop trying. Build something that stands watch instead. Notice the flattering thought behind this: that skill or patience alone would catch it. That is vanity, not diagnosis. The fix is not more of you. It is a trap that works without you.

◆ How this problem reads on the two dials

GuidanceKnowledge

More coaching

Some to learn

1:1 with AureliusWith others (a Pod)

Mostly you & the coach

A little with peers

The problem is less about missing facts than about changing what you do, so guidance leads while a little instrumentation knowledge makes the action concrete.

How the two dials adapt to you →

What’s really going on

You will not be there when it happens — accept that first. Stop chasing the moment; build the thing that watches in your place. Set logs and triggers before you leave, so evidence waits for you. The fault does not answer to your presence. Neither should your method.

🔒 What you’ll build togetherUnlock by starting

A moveStop trying to witness the fault yourself — build a log that runs when you cannot.

A moveSet a trigger that records state only when the fault condition fires, not constant noise.

A moveBefore you leave, ask: what evidence will exist here without me? If none, add it now.

A moveLeave instrumentation running across days, not hours — the fault does not obey your visit.

A moveWhen the log finally catches it, trust the data over your memory of past visits.

What changes unlock by starting

You stop needing to be present to catch the fault.
You build evidence trails that work without you.
You lose the habit of blaming the fault, or yourself, for its timing.
Diagnosis speeds up because data accumulates even when you are gone.

One object, two jobs: a public answer to a real problem, and — the moment you start the chat — Aurelius’s live plan for your version of it.