The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
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.
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.
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.
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.