Concepts
The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types
Replace 'interrupted' and 'ignored' with camera-observable…
Replace evaluative words that smuggle judgment ('interrupted,' 'ignored,' 'slammed') with camera-observable behavior descriptions ('began speaking while I was mid-sentence,' 'has not replied since Tuesday') in feedback conversations.
Use 'how did this happen' not 'why did you do this'…
In technical postmortems, use 'how' questions ('how did the deployment occur') rather than 'why' questions ('why did you skip review') because 'how' elicits description while 'why' elicits defensive justification.
Write down your mood and expectation before high-stakes…
Before high-stakes observations (meetings, decisions, analyses), write down your current mood and strongest expectation about the outcome to make perceptual filters visible for later comparison against actual observations.
Search logs for evidence that falsifies your hypothesis…
When debugging with strong initial hypotheses about root cause, deliberately search logs for evidence that would falsify the hypothesis rather than confirm it, to counteract confirmation bias in data collection.
Enforce 5 minutes of data-only observation in incident…
During incident response, enforce a mandatory 5-minute observation period where team members only report dashboard data and log patterns before anyone proposes a causal theory.
Name the specific emotion precisely before responding…
After initial defensive emotional reaction to feedback, name the specific emotion with high granularity ('I notice frustration about the timeline comment, not the technical critique') before responding, to activate prefrontal regulation.
Make implementation intention triggers highly specific…
When using implementation intentions to create behavioral pauses, specify the triggering situation at high detail ('If I receive code review feedback challenging my approach...') rather than generically ('If I get criticism...') to increase cue detectability.
Before committing to a bug hypothesis, write
Before committing to a hypothesis about a bug's cause, write one sentence completing 'What would I expect to see if I were wrong?' then specifically search for that evidence before continuing the investigation.
High confidence is a trigger for more scrutiny, not less…
When confidence in a technical conclusion exceeds 8/10, treat that high confidence as a trigger to increase scrutiny and deliberately search for disconfirming evidence rather than reducing verification effort.
Before recurring meetings, list five things that never get…
Before any recurring meeting or code review, spend 5 minutes writing down what topics never get discussed, what people never speak, and what failure modes are never mentioned—listing at least five absences.
Describe a familiar system for 10 minutes without…
When encountering a familiar system or codebase, force yourself to describe what you observe using only concrete sensory details for 10 minutes before applying any evaluative categorization or pattern labels.
Before design reviews, write what you assume is already…
Before entering any design conversation or architecture review, write one sentence answering 'What am I assuming is already settled here?' to surface expertise-hidden assumptions that should be re-examined.
Treat a newcomer's unanswerable question as a signal…
When a newcomer to a codebase or system asks a question you cannot immediately answer about code you wrote, treat their question as a defamiliarization signal requiring investigation rather than dismissing it as lack of context.
After explaining a system, revisit every 'obviously'…
After explaining a system to someone with zero context, revisit any point where you said 'obviously' or 'of course' and document the unstated assumption those words concealed.
Use random body-scan timers to build interoceptive awareness
Set three random timers throughout your workday; when each fires, pause for 30 seconds to scan jaw, shoulders, chest, stomach, and hands for tension, rating each 1-5 and noting your current activity.
When dashboards are all-green but something feels wrong…
When a system reports all-green status but something feels wrong, immediately check for missing log streams, absent metrics, or silent services rather than trusting the presence of positive signals alone.
When your body tenses in a design review, name what…
When you feel chest tightening or jaw tension during a design review or technical discussion, write down 'I notice I want to protect [X]' before formulating your response to create separation between observation and defense.
Filter facts from stories in difficult emails before sending
Before sending difficult emails or presenting challenging conclusions, run your draft through fact-story filtering by asking which statements would survive if you had to prove them with timestamps, screenshots, or measurements, because this prevents narrative from masquerading as evidence.
Trace execution paths variable-by-variable instead…
When reviewing code or data, trace actual execution paths or data trends variable-by-variable rather than pattern-matching from function names or headline numbers, because the gap between assumed behavior and actual behavior is where critical issues hide.
After strong reactions, record facts and interpretations…
After any event producing strong reactions, spend 90 seconds recording observations in a two-column format (left: camera-recordable facts, right: interpretations) before analysis, because this separation prevents retroactive rewriting of evidence to fit conclusions.
Complete the incident timeline before writing any causal…
When drafting incident postmortems or failure analyses, complete the timeline of observable events (with timestamps and measurements) before writing any causal analysis, because mixing observation and explanation during collection produces defensive filtering.
Force AI to separate observations from interpretations…
Before prompting AI to analyze meeting transcripts or documents, explicitly request separated outputs: first section lists only observable facts without interpretation, second section offers interpretations of those observations.
Announce mode switches explicitly in team observation…
In team contexts where observation must be separated from evaluation, make the phase transition explicit through verbal announcement ('We are now switching from observation mode to evaluation mode'), because implicit transitions allow the two modes to collapse into each other despite individual intentions.
If the same judgment appears in three contexts…
When you encounter the same judgment arising across three or more different contexts, treat it as a structural cognitive habit requiring explicit examination rather than a series of independent assessments, because cross-context repetition indicates the judgment is executing from pattern-matching rather than situation-specific analysis.