The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
Begin every team standup with the current constraint metric before individual updates to keep collective attention focused on the binding bottleneck.
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.
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.
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.
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 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.
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.
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.
For each agent-task pair in collaborative work, assign an explicit role type (Responsible, Accountable, Consulted, Informed) and verify that every task has exactly one Accountable party.
When attempting to shift a shared team schema, create low-cost experiments where the team uses the new schema on one real decision, rather than presenting the new framework in slides or documents.
Before attempting to change a shared team schema, map what the current schema supports—which decisions it enables, what coordination it simplifies, and what would break if it disappeared—to understand its load-bearing function.
Scale your timeline expectations for schema change with group size—weeks for pairs, quarters for 50-person orgs, years for industries—and measure progress in behavioral change rather than stated agreement.