Concepts
The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types
Meaning as Receiver Construction
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 disagreement persists despite shared facts, draw both…
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.
Defending the whole plan when one part is challenged…
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.
Write operational definitions for every high-stakes term…
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 persistent conflict uses the same words, audit…
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.
In power-dynamic conversations, defer notes — capture…
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.
Offer alternative times instead of justifying your focus…
When defending peak attention hours against meeting requests, offer alternative times outside your blocked window rather than explaining or justifying the block itself.
State observable facts before evaluative labels in code…
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.
Ask 'what was the system state' not 'who caused this'…
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.
Above 0.85 capacity, counter-offer new requests…
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.
Signal capacity proactively with operational language…
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 overloaded, ask the requester
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.
Physically pause for 90 seconds before responding…
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.
Draft the reactive version first, then wait 10 minutes…
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.
Use AI as an emotional distortion mirror, not a ghostwriter
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 '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.
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.
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.
Convert judgments into genuine questions — ask about…
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.
Ask 'what was your reasoning?' not 'why did…
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.
Use AI to catch hidden judgments in your observation writing
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.
Ask for behavioral feedback, not character evaluations
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.