The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
Meaning is constructed by receivers using their own mental models rather than transmitted intact from senders, because information contains no inherent meaning—meaning emerges from the interaction between information and context.
When confusion or disagreement persists despite shared facts, externalize all mental models spatially (whiteboard, diagram, parallel columns) before continuing verbal discussion, because visual comparison reveals structural misalignment that sequential verbal exchange cannot surface.
When someone challenges one part of your compound plan and you defend the whole thing, treat this as a diagnostic signal that you're still operating on fused ideas rather than independent assumptions.
For every high-stakes term in your reasoning (quality, success, productive, fair), write an operational definition specifying observable conditions that must be true for the term to apply, then store that definition as a canonical reference atom in your knowledge system.
When two people or two parts of your own thinking use the same term with persistent conflict, pause the debate and conduct a definition audit: have each party write their operational definition independently, then compare—if definitions diverge, the conflict is definitional not factual and should be resolved at the definition level.
During conversations where power dynamics make visible note-taking signal service role rather than equal participation, defer capture until immediately after the conversation ends—step outside within 2 minutes and externalize the three most important points while still in short-term memory.
When defending peak attention hours against meeting requests, offer alternative times outside your blocked window rather than explaining or justifying the block itself.
When giving feedback in code reviews or technical discussions, state observable facts (nesting levels, exit paths, line numbers) before applying evaluative labels to enable problem-solving rather than defensiveness.
In blameless postmortems, frame questions as 'what was the system state at [time]' and 'what information was available' rather than 'who caused this' to shift from evaluation to observation and enable information sharing.
When your commitment-to-capacity ratio exceeds 0.85, respond to new requests with explicit counter-offers stating either a later start date or a specific trade-off rather than accepting or declining without alternatives.
Design capacity signals with neutral, operational framing (traffic light status, numerical availability) rather than emotional or complaint-based language, delivering them before requests arrive rather than as request-time justifications.
When utilization exceeds 85% and a high-stakes request arrives, respond with the trade-off question format: 'If I add this, which of my current commitments should I deprioritize?' directed to the requester with decision authority.
When receiving critical feedback, insert a physical pause (close laptop, stand up, or wait 90 seconds) before responding to allow prefrontal cortex engagement rather than amygdala-driven reaction.
In emotionally charged messages, draft your reactive response first in a private document, then wait 10 minutes before composing the actual message, using the comparison between versions as data about emotional distortion.
When using AI to draft difficult communications, compare your reactive draft against the AI-generated neutral version to measure where emotions are distorting your message, rather than sending the AI version directly.
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.
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.
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 a judgment forms during an interaction, immediately convert it into a genuine question by replacing the evaluative conclusion with an inquiry about constraints, context, or reasoning ('Why would anyone write it this way?' becomes 'What constraints or context led to this approach?'), because questions activate exploratory cognition while conclusions activate confirmatory cognition.
In code reviews or technical evaluations, frame feedback requests as requests for reasoning rather than requests for justification—ask 'What was your reasoning?' instead of 'Why did you do it this way?'—because the first activates analytical explanation while the second activates defensive explanation.
When using AI to practice observation skills, provide it with your written accounts of charged situations and explicitly request separation of observational statements from evaluative statements, using the AI's output as immediate feedback on which judgments you embedded without noticing.
Frame feedback requests as specific behavioral questions ('What do I consistently do that I probably don't realize?') rather than character evaluations to keep feedback at task level instead of identity level.