The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
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.
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.
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.
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.
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.
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.
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 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.
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 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.
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 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.
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 to someone with zero context, revisit any point where you said 'obviously' or 'of course' and document the unstated assumption those words concealed.
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 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 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.
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.
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 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.
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.
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.
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.
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.