Simplification Audit

batch: First Iteration/Batch 27/Wave 2

aliases:
oversimplification audit
simplification review
omission audit
abstraction audit
edge-case simplification review

source_primes: abstraction approximation uncertainty

related_primes: representation completeness boundary_critique parsimony minimalism constraint hypothesis_testing

slug: abstraction

slug: approximation

slug: uncertainty

slug: representation

slug: completeness

slug: parsimony

slug: minimalism

slug: constraint

components:
Simplified Artifact
Simplification Intent
Preserved Function or Invariant
Omitted Detail List
Omission Relevance Criterion
Edge-Case Test
Distortion Check
Decision Consequence Threshold
Exception Rule
Revision Path
Comparison Baseline
Stakeholder or Use-Case Probe
Audit Cadence or Trigger
Audit Owner
Residual Simplification Risk

mechanisms:
Simplification Review
Omission Checklist
Edge-Case Testing
Assumption Audit
Model Simplification Audit
Approximation Validation
Stakeholder Review
Red-Team Review
Sensitivity Check
Backtest Against Full Cases

essence_one_line: Review whether a simplified model, process, representation, or solution has removed details that are actually necessary.

compression_statement: When simplification improves usability, speed, or tractability but may hide important variation, constraints, or cases, audit what was removed and decide whether to preserve the simplification, add exceptions, revise it, or escalate to a richer representation.

core_intuition: Simplification is useful because it removes detail. The danger is that some removed detail may later become decision-critical. This archetype creates a governance pass over simplification: it asks what was omitted, where the simplified artifact breaks, and what must be restored, qualified, or routed around without abandoning simplification entirely.

canonical_formula: simplified artifact + omission inventory + edge-case/distortion tests + consequence threshold + exception or revision path -> safer simplification without uncontrolled complexity creep

structural_problem: A simplified representation, model, process, policy, or solution is being used as if its omissions are harmless, even though the omitted details may affect validity, fairness, safety, interpretation, or operational reliability.

trigger_conditions: A model, process, policy, summary, dashboard, requirement set, or design has been simplified for speed, usability, cost, or tractability.

trigger_conditions: The simplification removed variables, cases, caveats, steps, dependencies, stakeholders, or context that may matter in some uses.

trigger_conditions: Users or decision-makers are treating the simplified artifact as complete enough for decisions beyond its original scope.

trigger_conditions: Incidents, complaints, edge cases, subgroup failures, confusing interpretations, or model errors suggest that simplification may be hiding a real constraint.

trigger_conditions: The system needs to preserve useful simplicity while preventing simplification-induced harm.

symptoms: A simple rule or model works for common cases but fails awkwardly at boundaries or exceptions.

symptoms: Summaries or dashboards omit caveats and cause decision-makers to over-trust a compact representation.

symptoms: A streamlined process is faster but loses checks that previously caught rare or high-impact issues.

symptoms: A simplified policy is easy to apply but excludes unusual, disadvantaged, or complex cases.

symptoms: Teams debate whether to add complexity back, but lack a disciplined way to decide which omitted details matter.

symptoms: The simplified artifact drifts into new contexts without revalidation.

root_tension: The system needs simplification to remain usable, but the same omission that makes the artifact useful can also make it wrong, unfair, unsafe, or misleading in cases that matter.

anti_signatures: The artifact has not been simplified; the issue is general incompleteness rather than simplification-induced omission.

anti_signatures: The task is to create a simplification from raw complexity, which is closer to Essential Structure Extraction, Task-Relevant Compression, Parsimony Filter, or Minimum Sufficient Solution.

anti_signatures: The only problem is ordinary implementation quality, with no meaningful omitted detail, edge case, or distortion caused by simplification.

anti_signatures: The review is a generic audit for compliance or accuracy rather than a targeted audit of what simplification removed.

anti_signatures: The needed response is to add all detail back indiscriminately, which destroys the intended value of simplification.

structural_intervention: Identify the simplified artifact and its intended preserved function, inventory omitted details, test likely edge cases and distortions, judge which omissions are decision-critical, and choose a revision, caveat, exception, escalation, or revalidation path.

action_logic: Name the simplified artifact and the simplification intent so the audit has a defined target.

action_logic: State the function, invariant, outcome, or user value the simplification must preserve.

action_logic: Inventory what was omitted, compressed, standardized, rounded, abstracted away, or assumed away.

action_logic: Screen omissions for relevance to decisions, affected parties, safety margins, validity, fairness, and maintainability.

action_logic: Run edge-case tests, stakeholder probes, comparisons to richer baselines, sensitivity checks, or backtests to see where simplification distorts outcomes.

action_logic: Define consequence thresholds that determine when an omission is acceptable, when a caveat is enough, and when revision or escalation is required.

action_logic: Create exception rules and revision paths that preserve common-case simplicity while handling cases the simplification cannot safely cover.

action_logic: Document residual simplification risk and set re-audit triggers for context drift, incidents, scale changes, or new uses.

decision_rules: Audit simplifications after use expands, context changes, incidents occur, or edge cases accumulate.

decision_rules: Do not treat every omitted detail as a defect; judge omissions by their effect on the preserved function and consequences of error.

decision_rules: Preserve the simplification when omitted details remain irrelevant to the intended use.

decision_rules: Add caveats when omitted details matter for interpretation but not routine action.

decision_rules: Add exception routes when omitted details matter in identifiable cases but not common cases.

decision_rules: Revise or replace the simplified artifact when omissions systematically distort important decisions or outcomes.

decision_rules: Escalate to a richer representation when stakes, uncertainty, or boundary conditions exceed the simplification’s validity domain.

target_invariants: The simplified artifact remains tied to its intended use and validity conditions.

target_invariants: Omitted details are made visible enough to inspect, not silently assumed harmless.

target_invariants: Common-case usability is preserved unless omitted detail becomes decision-critical.

target_invariants: Edge cases and affected groups receive explicit treatment rather than accidental exclusion.

target_invariants: Audit findings lead to a revision, caveat, exception, escalation, or documented residual risk.

target_invariants: The audit does not become a blanket demand to restore all complexity.

expected_outcomes: Safer, more valid use of simplified models, processes, policies, summaries, and solutions.

expected_outcomes: Earlier detection of oversimplification, omitted-case harm, misleading summaries, and hidden assumptions.

expected_outcomes: Better distinction between harmless detail removal and harmful loss of information or function.

expected_outcomes: More targeted exceptions and revisions instead of uncontrolled complexity creep.

expected_outcomes: Clearer documentation of simplification limits, residual risks, and re-audit triggers.

expected_outcomes: Improved trust in simplification because its limits are actively governed.

prose_essence:
Simplification Audit reviews a simplified artifact after it has been created or adopted. Its question is not “how can we make this simpler?” but “what did simplification remove, and does any of that removed detail now matter for validity, fairness, safety, meaning, or operation?”

The archetype preserves the value of simplification while preventing hidden omission. A good audit does not restore all complexity. It identifies which omissions are harmless, which need caveats, which need exception routes, and which require revising or replacing the simplified artifact.

prose_when_to_use:
Use Simplification Audit when a simplified model, process, policy, interface, summary, dashboard, rubric, checklist, or solution is already being used and there is reason to suspect that omitted detail may matter. The trigger may be edge-case failure, stakeholder complaint, context drift, new use, higher stakes, subgroup harm, incident patterns, or user overconfidence in a compact representation.

Do not use it as the first step in making something simple. If the work is initial abstraction, compression, parsimony, approximation, or minimum-scope design, use those upstream archetypes. Simplification Audit is the downstream governance pass that asks whether the simplification still deserves trust.

prose_structural_problem:
A simplified artifact gains usefulness by removing detail. That same removal can later become a hidden source of error. A dashboard hides caveats, a triage rule omits rare cases, a model drops variables, a policy removes context, or a process eliminates a step that had been silently protecting quality.

The structural problem is not complexity itself. The problem is unexamined omission after simplification. The system treats the simplified artifact as complete enough even though its omitted cases, assumptions, dependencies, or constraints may now affect decisions and outcomes.

prose_intervention_logic:
The intervention begins by naming the simplified artifact and its intended preserved function. Reviewers then inventory omitted details: variables, cases, stakeholders, caveats, steps, assumptions, dependencies, context, exceptions, or boundary conditions that were removed for simplicity.

Next, the audit tests whether omissions matter. It uses edge-case testing, stakeholder probes, comparison to richer baselines, sensitivity checks, backtesting, red-team review, or model review. The audit then chooses a response: leave the simplification intact, add a caveat, add an exception route, revise the artifact, escalate high-stakes cases to richer analysis, or retire the simplification for the affected use.

prose_key_components:
- **Simplified Artifact** (`simplified_artifact`): Identifies the simplified model, policy, process, representation, scope, interface, summary, or solution being audited. The audit needs a concrete simplification target. It should name what was simplified and for which intended use, rather than auditing generic simplicity.
- **Simplification Intent** (`simplification_intent`): States why the simplification was made: speed, usability, communication, cost reduction, tractability, delivery, standardization, or cognitive load reduction. This prevents the audit from treating every omitted detail as a defect. The omitted detail matters only if it undermines the purpose or creates unacceptable harm.
- **Preserved Function or Invariant** (`preserved_function_or_invariant`): Defines what the simplified artifact must still preserve for the task to remain valid, fair, usable, safe, or decision-supporting. Examples include predictive validity, eligibility fairness, safety margin, causal relation, service coverage, interface meaning, or operational reliability.
- **Omitted Detail List** (`omitted_detail_list`): Catalogs the cases, variables, dependencies, constraints, stakeholders, exceptions, assumptions, or context that were removed or compressed away. This component is central: without an explicit inventory of what simplification removed, the audit cannot test whether the removal was safe.
- **Omission Relevance Criterion** (`omission_relevance_criterion`): Decides which omitted details are still irrelevant and which might affect decisions, outcomes, equity, safety, interpretation, or maintainability. The criterion should be tied to consequences. Some omitted details can remain omitted; others require exception handling or revision.
- **Edge-Case Test** (`edge_case_test`): Tests the simplified artifact against boundary cases, excluded cases, rare cases, adversarial cases, subgroup cases, or high-consequence cases. Edge-case testing distinguishes this archetype from a generic completeness review. The focus is on cases that simplification is likely to erase or mis-handle.
- **Distortion Check** (`distortion_check`): Assesses whether the simplification changes meaning, hides dependencies, shifts incentives, erases important variation, or misleads decisions. A simplification can be factually compact yet still distort a user’s interpretation or action. This check looks for harmful representational effects.
- **Decision Consequence Threshold** (`decision_consequence_threshold`): Sets the level of stakes or error consequence at which the simplified artifact must be revised, qualified, escalated, or replaced by a richer version. A lightweight simplification may be acceptable for low-stakes screening but unacceptable for irreversible, high-impact, or rights-affecting decisions.
- **Exception Rule** (`exception_rule`): Defines when omitted or edge cases should bypass the simplified route and receive a richer analysis, human review, special handling, or explicit caveat. Exception rules preserve simplification for common cases while preventing omitted cases from being invisibly forced through an inadequate simplification.
- **Revision Path** (`revision_path`): Specifies how the simplified artifact is corrected: revise the model, add a caveat, expand scope, restore a variable, create a variant, or add an escalation path. The audit should end in an action. A list of flaws without a revision path becomes criticism rather than a solution archetype.

Optional components include Comparison Baseline (`comparison_baseline`), Stakeholder or Use-Case Probe (`stakeholder_or_use_case_probe`), Audit Cadence or Trigger (`audit_cadence_or_trigger`), Audit Owner (`audit_owner`), Residual Simplification Risk (`residual_simplification_risk`). These become important when the simplified artifact changes over time, affects multiple stakeholders, or requires accountable ownership.

prose_common_mechanisms:
- **Simplification Review** (`simplification_review`, review_workflow): Runs a structured review of what a simplified artifact preserved, omitted, distorted, and now requires as caveats, exceptions, or revisions. This is a mechanism under the archetype. It implements the audit but does not define the whole archetype by itself.
- **Omission Checklist** (`omission_checklist`, checklist): Prompts reviewers to identify removed variables, stakeholders, dependencies, assumptions, constraints, cases, failure states, and boundary conditions. Useful for making omissions explicit. It should not become a generic completeness checklist detached from simplification decisions.
- **Edge-Case Testing** (`edge_case_testing`, test_procedure): Applies the simplified artifact to boundary, rare, adversarial, subgroup, or high-stakes cases to see where it breaks or misleads. Implements the edge-case test component. It can be manual, empirical, simulated, or scenario-based.
- **Assumption Audit** (`assumption_audit`, audit_method): Surfaces assumptions introduced by simplification and checks whether those assumptions still hold in the target context. A reusable mechanism across many archetypes; here it is specifically aimed at assumptions caused by simplification.
- **Model Simplification Audit** (`model_simplification_audit`, model_review): Compares a simplified model, surrogate, scoring rule, or approximation against richer evidence, edge cases, residuals, and known validity limits. Can support the model-specific variant. It should be coupled with revision or escalation rules rather than merely reporting model limitations.
- **Approximation Validation** (`approximation_validation`, validation_check): Checks whether a simplified approximation remains within acceptable error or validity bounds for the decision it supports. This overlaps with Bounded Approximation, but here it functions as an audit mechanism after simplification has already occurred.
- **Stakeholder Review** (`stakeholder_review`, participatory_review): Asks affected users, operators, maintainers, or stakeholders whether the simplification omits cases or constraints they consider important. Especially useful when omission harms are visible to affected parties but not to designers of the simplification.
- **Red-Team Review** (`red_team_review`, adversarial_review): Challenges the simplified artifact by searching for ways it can mislead, exclude, be gamed, or fail outside its convenient assumptions. Useful when simplification is high-stakes, politically attractive, or likely to be overtrusted.
- **Sensitivity Check** (`sensitivity_check`, analysis_method): Varies omitted or simplified variables to test whether conclusions change materially when simplifying assumptions are relaxed. Helps determine whether an omission is harmless or decision-critical.
- **Backtest Against Full Cases** (`backtest_against_full_cases`, retrospective_test): Compares the simplified artifact against historical or fully documented cases to identify missed exceptions, distortions, and systematic failure patterns. Works best when a richer baseline or case record is available.

These mechanisms implement the archetype; they are not the archetype itself. An edge-case test, checklist, model audit, or stakeholder review only becomes Simplification Audit when it is tied to an omission inventory, relevance criteria, consequence thresholds, and a path for revision, caveat, exception, or escalation.

prose_failure_modes:
Common failure modes include audit as complexity creep, checklist theater, average-case blindness, caveat dumping, false security from a one-time audit, and unbounded exception growth. The mitigations are relevance criteria, consequence thresholds, edge-case tests, stakeholder probes, explicit revision paths, re-audit triggers, and residual-risk documentation.

A particularly common failure is treating an audit as a reason to distrust all simplification. That is the wrong lesson. The archetype exists because simplification is valuable enough to protect, but risky enough to govern.

prose_neighbor_distinctions:
- **Essential Structure Extraction** (`essential_structure_extraction`): Essential Structure Extraction creates a task-relevant abstraction by stripping incidental detail; Simplification Audit inspects an existing simplification to see whether removed detail has become necessary.
- **Task-Relevant Compression** (`task_relevant_compression`): Task-Relevant Compression designs compact representations; Simplification Audit checks whether compactness removed information that users now need.
- **Bounded Approximation** (`bounded_approximation`): Bounded Approximation authorizes a simplified estimate by setting error bounds; Simplification Audit reviews whether a simplification still respects its validity domain and whether omitted details have become consequential.
- **Parsimony Filter** (`parsimony_filter`): Parsimony Filter removes unsupported assumptions or features before adoption; Simplification Audit later tests whether removed assumptions, variables, or steps should be restored or handled as exceptions.
- **Minimum Sufficient Solution** (`minimum_sufficient_solution`): Minimum Sufficient Solution finds the smallest solution that meets the core requirement; Simplification Audit examines whether that minimum has become insufficient in edge cases, new contexts, or higher-stakes use.
- **Uncertainty Explicitness** (`uncertainty_explicitness`): Uncertainty Explicitness makes unknowns and confidence visible; Simplification Audit asks whether simplification has hidden or erased uncertainty, then decides whether to revise, caveat, or escalate.
- **Completeness Audit** (`completeness_audit`): Completeness Audit searches for missing cases, states, stakeholders, or paths in general. Simplification Audit is narrower: the missing material was removed by a simplification and must be judged against the simplification’s intended function.
- **Boundary Critique Audit** (`boundary_critique_audit`): Boundary Critique Audit interrogates inclusion and exclusion boundaries broadly. Simplification Audit focuses on simplification-induced omissions, though boundary critique can be one mechanism for finding them.
- **False Convergence Prevention** (`false_convergence_prevention`): False Convergence Prevention prevents apparent agreement or stability from being mistaken for real convergence. Simplification Audit addresses omitted detail and distortion created by simplified artifacts, even when there is no apparent convergence problem.

The core boundary is simple: upstream archetypes create or justify simplification; Simplification Audit reviews whether a simplification has become unsafe, invalid, unfair, misleading, or insufficient because of what it removed.

prose_cross_domain_examples:
- **public policy**: A benefits agency audits a simplified eligibility rule and discovers that unusual household structures are wrongly excluded, so it adds an exception route and clearer documentation rather than abandoning the rule.
- **healthcare operations**: A clinic reviews a simplified triage checklist after rare urgent cases are missed, then restores two warning signs and creates an escalation rule for ambiguous symptoms.
- **machine-learning governance**: A screening model is audited for omitted context after average accuracy looks good but subgroup failures emerge; the team adds validity limits, human review triggers, and retraining requirements.
- **software deployment**: A simplified release checklist is audited after incidents reveal that removed verification steps caught rare configuration errors; the team adds a conditional check for high-risk deployments.
- **executive reporting**: A dashboard metric is reviewed because executives treat it as a complete measure of service quality; the team adds uncertainty, missing-case flags, and a companion drill-down path.
- **education**: A simplified grading rubric is audited against student work that falls outside standard categories, leading to a clarified exception rule and examples for boundary cases.
- **supply-chain planning**: A simplified demand model is tested against disruptions and seasonal anomalies, revealing that the omitted supplier lead-time variable matters above a certain order volume.

prose_non_examples:
- **Creating a simple diagram from a complex system for the first time.** That is closer to Essential Structure Extraction or Task-Relevant Compression unless the task is to audit omitted details after the diagram is in use.
- **Choosing the simplest model that fits evidence before deployment.** That is Parsimony Filter or model selection. Simplification Audit is the later review of whether the chosen simplification omitted something important.
- **Running a generic compliance audit with no connection to simplification.** The trigger is not simplification-induced omission, so the archetype is not the right fit.
- **Adding every possible caveat to a summary.** This defeats the simplification rather than auditing which omissions are decision-critical.
- **Using a full-fidelity analysis because simplification is unacceptable.** The archetype governs safe simplification; if simplification is not allowed, there is nothing to audit as a simplification.

prose_tradeoffs:
Simplification Audit trades speed against assurance. More review catches more omitted risk but slows the use of simple artifacts. It trades rule clarity against exception handling: more exceptions protect boundary cases but make the system harder to explain and maintain. It trades communication simplicity against caveat accuracy: adding context can prevent distortion but can also make a summary unreadable.

The best implementation does not maximize detail. It restores only the detail needed to preserve the artifact’s function, validity, fairness, or safety.

prose_invariants_to_preserve:
The simplified artifact must remain tied to its intended use. The audit must make omitted detail visible enough to inspect. Harmless omissions should remain omitted. Decision-critical omissions should trigger caveats, exceptions, revisions, or escalation. The audit must preserve useful simplicity rather than collapsing into uncontrolled complexity restoration.

Another invariant is actionability: material audit findings must connect to a response. A report that merely lists possible omissions but changes nothing is not a full implementation of the archetype.

prose_target_outcomes:
The target outcomes are safer simplification, clearer validity limits, reduced oversimplification harm, better handling of edge cases, improved fairness and reliability in simplified systems, and less uncontrolled complexity creep. The archetype helps a system keep the benefits of simple artifacts while governing where they break.

It also improves trust. Users can rely on simplification more confidently when they know its omissions have been inspected, its exceptions are explicit, and its remaining risks are documented.

prose_parameter_dimensions:
Important tuning dimensions include audit depth, frequency, edge-case severity threshold, acceptable residual risk, breadth of stakeholder sampling, sensitivity-test range, consequence threshold, exception volume, documentation burden, and revision cost.

A shallow audit preserves speed but may miss harmful omission. A deep audit improves safety and fairness but can undermine the usability that justified simplification. Sensitive exception rules catch more edge cases but can create exception overload. Strict consequence thresholds protect high-stakes uses but may force richer analysis more often.

prose_variants_and_near_names:
Recognized variants:

- **Model Simplification Audit** (`model_simplification_audit`): Audits whether a simplified model, surrogate, scoring rule, or approximation has omitted variables, cases, or validity limits that matter for use. It remains a variant because It uses the same omission inventory, edge-case test, distortion check, exception rule, and revision path.
- **Process Simplification Audit** (`process_simplification_audit`): Audits whether a streamlined process has removed checks, handoffs, context, or exceptions that are still needed for quality, fairness, safety, or reliability. It remains a variant because It still catalogs omissions, tests cases, checks distortion or harm, and defines exceptions or revisions.
- **Communication Simplification Audit** (`communication_simplification_audit`): Audits whether a summary, dashboard, label, diagram, or brief has become misleading by removing uncertainty, caveats, context, or minority cases. It remains a variant because It uses omitted detail inventory, distortion checks, consequence thresholds, and revision paths for simplified representations.
- **Policy Simplification Audit** (`policy_simplification_audit`): Audits whether a simplified rule or policy has erased exceptions, equity concerns, implementation constraints, or affected-party cases that still require treatment. It remains a variant because It still tests omitted details and edge cases and then adds exceptions, caveats, or revisions.

Aliases and near names:

- **Oversimplification audit** (alias): Common near name emphasizing the failure mode rather than the intervention form.
- **Simplification review** (alias): Plain-language alias for the same audit logic.
- **Omission audit** (near_name): Useful retrieval term, but too broad unless tied to details omitted by simplification.
- **Abstraction audit** (near_name): Near name when the simplified artifact is an abstraction; keep parent name broader because approximation, compression, and process simplification can also be audited.
- **Edge-case review** (near_name): A common mechanism or emphasis under the archetype, not a full synonym by itself.
- **Model audit** (related_mechanism_or_domain_variant): A model audit may implement this archetype when it specifically tests simplification-induced omissions; model audit is broader in other contexts.

Collapsed candidates include model audit, assumption audit, edge-case testing, and omission checklist when they function as mechanisms under this archetype. Boundary Critique Audit and Completeness Audit remain important neighboring candidates rather than collapsed Batch 027 outputs.

raw_bundle_path: solution_archetypes/_Batches/First Iteration/Batch 27/Wave 2/simplification_audit_solution_archetype_output_bundle.zip

Model Simplification Audit

distinctive_feature: The simplified artifact is an analytical or predictive model rather than a policy, process, or communication representation.

distinct_from_parent: The parent applies to any simplified artifact; this variant focuses on model validity, omitted variables, and approximation boundaries.

still_same_parent_because: It uses the same omission inventory, edge-case test, distortion check, exception rule, and revision path.

use_when: A simplified model is being used for decision support, estimation, prioritization, forecasting, screening, or explanation.

use_when: The model is easier to use than a richer representation but may hide assumptions, subgroup differences, residual error, or boundary conditions.

use_when: The consequences of model error are high enough that omissions must be tested rather than accepted as convenience.

example_domains:
risk scoring
operations modeling
public policy analysis
scientific modeling
software reliability

domain: risk scoring

example: Auditing a simplified eligibility model against rare but important cases before it is used for denial decisions.

domain: operations

example: Testing a simplified capacity model against peak-load and maintenance scenarios that were omitted from the original estimate.

failure_modes: treating model accuracy averages as enough

failure_modes: documenting caveats without changing use

failure_modes: failing to define escalation when validity limits are reached

Process Simplification Audit

distinctive_feature: The simplified artifact is a workflow, operating procedure, service path, or administrative process.

distinct_from_parent: The parent audits all forms of simplification; this variant focuses on lost process functions and hidden step value.

still_same_parent_because: It still catalogs omissions, tests cases, checks distortion or harm, and defines exceptions or revisions.

source_primes: minimalism parsimony constraint

use_when: A process has been shortened, automated, standardized, or simplified for speed and ease of use.

use_when: Dropped steps may have carried hidden functions such as error detection, accountability, context capture, or exception routing.

use_when: The simplified process now handles varied cases that may not fit its common-case path.

example_domains:
healthcare workflows
customer support
compliance review
software deployment
public service intake

domain: healthcare

example: Auditing a streamlined intake process to see whether it lost red flags for urgent or unusual cases.

domain: software operations

example: Reviewing a simplified deployment checklist after incidents reveal that removed verification steps had been catching rare errors.

failure_modes: failing to identify which removed steps were protective

Communication Simplification Audit

distinctive_feature: The simplified artifact is a communication representation rather than a model or process.

distinct_from_parent: The parent audits simplification broadly; this variant emphasizes audience interpretation and representational distortion.

source_primes: compression representation uncertainty

use_when: Information was summarized or visualized for readability, speed, or decision-maker attention.

use_when: The compact representation may hide uncertainty, causal caveats, subgroup differences, time limits, or operational constraints.

use_when: Users are likely to treat the simplified communication as complete or certain.

example_domains:
executive reporting
public communication
data dashboards
education
design documentation

domain: public communication

example: Checking whether a simple risk label hides the uncertainty and exceptions needed for safe behavior.

domain: executive reporting

example: Reviewing a dashboard metric after leaders overinterpret it as a complete measure of service quality.

failure_modes: hiding caveats because they complicate the message

failure_modes: focusing on aesthetics rather than decision distortion

failure_modes: no revision path for misleading summaries

Policy Simplification Audit

distinctive_feature: The simplified artifact is a policy or rule with inclusion, exclusion, or obligation effects.

distinct_from_parent: The parent is general; this variant foregrounds fairness, eligibility, implementation burden, and exception governance.

still_same_parent_because: It still tests omitted details and edge cases and then adds exceptions, caveats, or revisions.

use_when: A policy was simplified to improve consistency, speed, compliance, or understandability.

use_when: The simplified rule may exclude rare, disadvantaged, complex, or high-need cases.

use_when: The policy affects access, eligibility, obligation, safety, or procedural fairness.

example_domains:
benefits policy
school rules
workplace policy
clinical triage
regulatory implementation

domain: benefits administration

example: Auditing a simplified eligibility rule to see whether it wrongly excludes applicants with unusual household structures.

domain: workplace policy

example: Reviewing a simplified remote-work rule for caregiving, disability, security, and role-specific exceptions.

failure_modes: using audit to justify arbitrary exceptions

failure_modes: letting fairness concerns dissolve all rule clarity

near_names:
Oversimplification audit
Simplification review
Omission audit
Abstraction audit
Edge-case review
Model audit
Abstraction Validity Review
Edge-Case Simplification Review


Site-Responsive Spatial Abstraction

type: archetype

source: generated

batch: Second Iteration/Batch 03

slug: composition

slug: perspective

slug: scale

slug: sublime

slug: ornamentation

slug: boundary

slug: iconicity

slug: resonance

slug: flow

components: Installation Constraint and Stewardship Check

mechanisms:
Site Mapping Walkthrough
Spatial Axis Diagram
Solar Shadow and Reflection Study
Light-Material Mockup
Viewer Path Storyboard
Scale Maquette or Mass Model
Negative-Space Blockout
Context Removal Probe
Site Constraint Matrix
Seasonal Variation Model
Community Reading Session
Post-Installation Site Response Review

essence_one_line: Make abstraction inseparable from place by translating content into the spatial, light, material, and temporal relations of a particular site.

compression_statement: Site-Responsive Spatial Abstraction takes a representational, emotional, historical, ecological, or conceptual target and deliberately strips away literal depiction until the target is expressed through site-specific relations: axes, thresholds, voids, shadows, reflections, paths, scale shifts, weathering, horizon, architectural enclosure, and patterns of encounter. The site is not a neutral container for an abstract object; it is part of the medium and part of the meaning. The intervention succeeds when the abstraction becomes clearer, richer, or more resonant because of the site’s actual geometry, light, materials, history, and use, and would become materially weaker or different if moved elsewhere.

core_intuition: Some abstractions cannot be completed on a canvas, plinth, page, or portable object because the relevant meaning lives in the relation between form and place. A shadow cast at a particular hour, a void aligned with a former boundary, a reflective surface facing a river, or a geometric cut through a landscape can isolate a concept more powerfully than literal depiction. The archetype works by making the site’s constraints and affordances do expressive labor.

canonical_formula: For abstraction target T and site S, derive site affordances A(S) = {geometry, light, material, path, scale, memory, environmental variation}. Select retained formal relations R(T) and map them into A(S) such that meaning M = f(R(T), A(S), viewer access, time) and M changes nontrivially when S is removed or substituted.

structural_problem: A concept, memory, process, or representational subject needs abstraction, but a portable formal treatment would detach it from the place-specific conditions that give it force. The site has geometry, light, history, material behavior, access patterns, ecological constraints, or social meanings that should shape the abstraction, yet they are being treated as background display conditions rather than as active structure.

condition: The proposed work responds to a specific building, room, landscape, memorial site, public space, or natural setting.

diagnostic_use: Signals that site conditions must be part of the abstraction rather than post-hoc installation logistics.

condition: Meaning depends on light, shadow, reflection, horizon, path, scale, threshold, weather, or season.

diagnostic_use: Calls for spatial and temporal modeling before final form selection.

condition: Literal representation would be too didactic, intrusive, reductive, or incompatible with the site.

diagnostic_use: Abstraction can preserve meaning while reducing depiction.

condition: A work could become decorative or generic if moved from one site to another without loss.

diagnostic_use: Use the context-removal test to determine whether the site is genuinely active.

condition: The site carries contested, sacred, ecological, historical, or community meaning.

diagnostic_use: Requires meaning anchors, stewardship checks, and interpretation review.

condition: The viewer’s route, bodily scale, sightline, or approach changes how the work is perceived.

diagnostic_use: Viewer access must be specified even when the work is not interactive.

symptom: The work looks plausible in renderings but feels arbitrary or generic when placed at the site.

interpretation: The site has not been structurally incorporated into the abstraction.

symptom: Lighting, weather, or circulation patterns repeatedly undermine the intended meaning.

interpretation: Environmental variation was treated as accident rather than medium.

symptom: The design explains the concept verbally but the spatial experience does not carry the concept.

interpretation: The abstraction target has not been translated into site-specific formal relations.

symptom: Stakeholders read the work as imposed, decorative, disrespectful, or placeless.

interpretation: Site memory, use, and community meanings are being ignored or overwritten.

symptom: A supposedly site-specific work could be installed anywhere with no material change in interpretation.

interpretation: The design fails the context-removal test.

symptom: Only one privileged viewpoint makes the work legible while ordinary users encounter obstruction or confusion.

interpretation: Viewer access and accessibility frames are under-specified.

root_tension: The same site constraints that make a work difficult—fixed geometry, changing light, weather, public use, historical burden, ecological limits, access restrictions—can become the source of its abstract power. The archetype balances formal reduction against contextual specificity: strip away literal depiction, but do not strip away the place that makes the abstraction meaningful.

case: The goal is to create a coherent visual identity, palette, or ornamental vocabulary across contexts.

reason: Use aesthetic_coherence_system or a later ornamentation-focused archetype; site-specific abstraction is not the core problem.

case: The main task is choosing the best representation format for a dataset, argument, or model.

reason: Use representation_fit_selection; this archetype concerns art/design form embedded in a physical site.

case: The work is primarily an image-to-concept visual metaphor that could travel between media.

reason: Use visual metaphor or metaphor_visual_artistic neighbors; site dependency is incidental.

case: The site is merely a practical constraint for hanging, mounting, permitting, or lighting a finished object.

reason: Those are installation logistics, not site-responsive spatial abstraction.

case: The central intervention is active viewer participation, manipulation, performance, or embodied co-creation.

reason: Route to Viewer Participation and Embodied Interpretation or a participatory/embodied archetype; this draft handles access and sightline, not participation as primary generator.

case: The intervention damages a fragile site, erases local meaning, or turns public access into private spectacle.

reason: Reject or redesign with stewardship, consent, and accessibility constraints.

structural_intervention: Use the site as an abstraction medium. Define the target content; analyze the site’s geometry, light, materials, movement paths, temporal variation, and meanings; strip the target to formal relations that the site can carry; map those relations into spatial, material, and light interactions; test whether meaning survives actual viewer access and temporal conditions; and revise until the work is meaningfully site-bound without becoming opaque, decorative, unsafe, or extractive.

action_logic: State the abstraction target before form-making begins.

action_logic: Inventory site affordances and constraints as potential expressive structure.

action_logic: Identify which literal details should be removed and which formal relations should remain.

action_logic: Map retained relations into axes, thresholds, voids, surfaces, light paths, viewer routes, and scale contrasts.

action_logic: Model how day/night, weather, seasons, occupancy, and maintenance will change the work.

action_logic: Check whether local memory, ecological constraints, and public access alter the meaning or permissible form.

action_logic: Prototype material-light behavior and viewer encounter rather than relying only on concept sketches.

action_logic: Run a context-removal test to determine whether the abstraction is genuinely site-responsive.

action_logic: Revise for safety, accessibility, stewardship, and interpretive clarity without flattening abstraction into literal signage.

rule: Treat site conditions as compositional inputs when they materially shape meaning.

rationale: Otherwise the work is merely installed at a site, not responsive to it.

rule: Require a traceable relation between abstraction target and site-specific formal choice.

rationale: Prevents arbitrary formalism and decorative site dressing.

rule: Do not depend on a light, weather, viewpoint, or season condition without documenting its availability and failure mode.

rationale: A site-responsive work can change over time, but predictable disappearance should be intentional.

rule: Use the context-removal test before calling a work site-specific.

rationale: The claim is only justified when relocation would materially alter meaning, perception, or function.

rule: Add accessibility and stewardship checks whenever the work occupies shared, natural, historical, or public space.

rationale: Site responsiveness must not become exclusion, hazard, or damage.

rule: Keep viewer access distinct from viewer participation unless the viewer’s action materially produces the work.

rationale: Prevents this archetype from absorbing participation-centered candidates.

target_invariants: The site is part of the work’s meaning, not only its location.

target_invariants: The abstraction target remains traceable after representational detail is stripped away.

target_invariants: Spatial and light relationships are calibrated to actual site conditions.

target_invariants: Viewer encounter conditions are considered across realistic paths and abilities.

target_invariants: Temporal variability is either intentionally used or explicitly bounded.

target_invariants: Local, historical, ecological, and access constraints are not overwritten by formal ambition.

target_invariants: Relocation would change the work’s interpretation, not merely its logistics.

expected_outcomes: Abstract form becomes more legible, resonant, or powerful because it is bound to place.

expected_outcomes: Site constraints become expressive resources rather than late-stage limitations.

expected_outcomes: Light, shadow, void, scale, and path carry content that would otherwise require literal depiction.

expected_outcomes: Public or architectural installations feel integrated rather than pasted onto a setting.

expected_outcomes: Design review can evaluate site fit using explicit criteria rather than taste alone.

expected_outcomes: Documentation clarifies why the work belongs where it is.

Architectural Light Abstraction

short_definition: Uses an architectural site’s apertures, surfaces, volumes, and artificial or natural light to make abstract meaning spatially perceptible.

distinctive_feature: Architecture and light are treated as compositional media rather than as display setting.

distinct_from_parent: The parent includes natural landscapes and public sites; this variant focuses on architectural enclosure and light.

still_same_parent_because: The abstraction remains site-bound and spatial-light calibrated.

use_when: The site is a building, room, atrium, facade, chapel, gallery, passage, or constructed interior.

use_when: Light path, surface, shadow, enclosure, and viewer route determine the work’s meaning.

use_when: The intervention would not work as a freestanding object detached from the architecture.

example_domains:
site-specific installation
gallery design
sacred architecture
public interiors

domain: gallery installation

example: A transparent plane aligns with window light so a concept appears only as a moving shadow across the floor.

failure_modes:
lighting treated as decoration
dependence on unavailable daylight
gallery constraints ignored

Landform Geometric Abstraction

short_definition: Converts landscape, terrain, horizon, path, ecological process, or human presence into geometric, volumetric, or void-based land-form relations.

distinctive_feature: Terrain and horizon become the abstraction’s medium.

distinct_from_parent: The parent includes interiors and public spaces; this variant emphasizes land art and landscape-scale geometry.

still_same_parent_because: The core move remains reducing content into site-specific spatial relations.

use_when: The site is a landscape, earthwork, garden, park, shoreline, field, or other open natural/built environment.

use_when: Scale, horizon, weather, approach, terrain, and ecological disturbance are structurally important.

use_when: The work must be evaluated as a modification of land, not only as an image or object.

example_domains:
land art
landscape architecture
memorial landscapes
environmental art

domain: land art

example: Human passage is abstracted into a cut, mound, and sightline that only resolves at the horizon.

failure_modes:
site damage
romanticized landscape extraction
scale overwhelms legibility

Temporal Shadow Abstraction

short_definition: Uses changing shadows, reflections, illuminations, or occlusions to abstract time, process, memory, or transformation at a site.

distinctive_feature: Time is encoded through site-specific light behavior.

distinct_from_parent: The parent may be static; this variant depends on temporal activation.

still_same_parent_because: The temporal behavior remains anchored to the site and abstraction target.

use_when: The intended abstraction only appears through temporal change.

use_when: Sun, artificial light sequence, weather, or viewer movement changes the perceived relation.

use_when: A static photograph cannot capture the main structure of the work.

example_domains:
light art
memorial design
urban installations
ritual spaces

domain: memorial installation

example: A shadow aligns with a threshold only on an anniversary date, abstracting loss into temporal absence.

failure_modes: temporal event too rare to be experienced

Site Memory Spatial Encoding

short_definition: Translates a site’s historical, cultural, ecological, or social memory into abstract spatial markers, absences, alignments, or material traces.

distinctive_feature: The site’s memory is abstracted into spatial relation rather than narrated directly.

distinct_from_parent: The parent includes purely formal and environmental site response; this variant emphasizes memory and interpretive responsibility.

still_same_parent_because: Memory is expressed through site-bound spatial abstraction.

use_when: The work responds to memory or meaning already attached to the site.

use_when: Literal depiction would be reductive, contested, or inappropriate.

use_when: The design must make absence, trace, continuity, rupture, or remembrance spatially legible.

example_domains:
memorials
heritage sites
public art
museum installations

domain: public memorial

example: A former boundary is abstracted into an unoccupied linear void that visitors cross without a figurative monument.

failure_modes: local meaning flattened into design trope

short_definition: Makes the abstraction resolve, fragment, distort, or change according to the viewer’s position and sightline within the site.

distinctive_feature: The viewer’s frame of reference controls legibility.

distinct_from_parent: The parent can involve fixed spatial relationships; this variant focuses on perspective-conditioned resolution.

still_same_parent_because: The work still uses the site’s spatial frame as the abstraction medium.

use_when: Meaning depends on where the viewer stands or moves, but the viewer does not materially alter the work.

use_when: Sightlines, occlusion, parallax, scale, and bodily orientation are the main perceptual variables.

use_when: The design needs to distinguish position-dependent perception from active participation.

example_domains:
installation art
anamorphic sculpture
exhibition design

domain: installation art

example: Fragmented planes align into a single abstract relation only from a threshold in the building.

failure_modes: confusing viewpoint calibration with interactive participation

failure_modes: excluding users who cannot access the resolving viewpoint


Situational Attribution Check

batch: First Iteration/Batch 40

related_primes: causality confounding psychological_safety procedural_fairness accountability essentialism

slug: causality

slug: confounding

slug: accountability

slug: essentialism

components:
Observed Behavior
Trait Attribution
Situational Factor Map
Constraint Context Review
Explanatory Weighting
Accountability Boundary
Response Adjustment
Impact or Standard Reference
Actor Perspective Record
Comparison Case Reference
Context Learning Record

mechanisms:
Context Reconstruction Interview
Behavior-Context Mapping Template
Just Culture Review
Incident Timeline Review
Performance Context Review
Root-Cause Analysis
Constraint and Incentive Checklist
Actor Perspective Interview
Empathy Mapping
Policy Exception Review

essence_one_line: Check situational causes before explaining behavior as a stable trait or personal failing.

compression_statement: When an actor's behavior is being explained as character, competence, motivation, or intent, reconstruct the constraints, incentives, information, tools, norms, and system conditions around the behavior before assigning blame, support, redesign, escalation, or responsibility.

core_intuition: Observers usually see behavior more clearly than they see the situation that produced it. This archetype slows the jump from behavior to character by making the missing situation visible, while still preserving a boundary for standards, harms, and responsibility.

canonical_formula: observed behavior + trait explanation pressure -> situational factor reconstruction + explanatory comparison + accountable response adjustment

structural_problem: A person or group explains another actor's behavior primarily through stable traits, motives, competence, or character while underweighting constraints, incentives, information asymmetries, role conditions, tools, norms, and system design that may have shaped the behavior.

condition: A behavior has visible consequences.

explanation: The behavior may be an error, delay, conflict move, noncompliance event, missed standard, poor decision, absence of action, or surprising choice.

condition: A trait explanation arrives quickly.

explanation: Observers reach for labels such as careless, lazy, incompetent, selfish, uncommitted, disrespectful, reckless, irrational, or bad-faith before context is examined.

condition: The observer lacks full access to the actor's situation.

explanation: Missing information often concerns workload, incentives, constraints, role ambiguity, tools, timing, social pressure, training, competing obligations, or prior history.

condition: The response will matter.

explanation: The explanation may shape discipline, feedback, design changes, support, conflict escalation, policy enforcement, hiring, promotion, training, or safety investments.

condition: The environment plausibly shaped available choices.

explanation: The actor may have faced a constrained choice set, ambiguous cues, conflicting instructions, poorly designed procedures, or incentives that made the observed behavior more likely.

condition: Group or status dynamics make blame easy.

explanation: Power differences, outsider status, stereotypes, time pressure, or organizational politics can make a person-centered explanation feel simpler than a situational one.

symptom: Character labels replace behavioral description.

explanation: The discussion uses labels before stating what was actually observed, when it happened, and what standard or impact is at issue.

symptom: Context appears only after blame is assigned.

explanation: Constraints and system conditions are treated as excuses rather than evidence to consider in causal explanation.

symptom: Repeated behavior is treated as proof of disposition.

explanation: Frequency may matter, but repeated exposure to the same constraint can also produce repeated behavior.

symptom: The observer explains their own similar behavior situationally.

explanation: The actor's behavior is attributed to character while the observer's comparable behavior is attributed to workload, pressure, confusion, or bad circumstances.

symptom: Response options narrow prematurely.

explanation: Discipline, exclusion, escalation, or moral judgment is chosen before support, redesign, clarification, training, or system repair is considered.

symptom: The same behavior clusters in a role, site, tool, process, or time period.

explanation: Patterning around context suggests the cause may not be an isolated person trait.

symptom: People stop reporting errors or constraints.

explanation: A blame-heavy explanation climate hides the context that would make prevention possible.

root_tension: Responsibility requires taking behavior seriously, but fair and effective response requires explaining behavior in the choice environment where it occurred. The tension is between the need to uphold standards and the need to avoid turning partial information into a dispositional story.

condition: The behavior and context are already well established.

explanation: If the evidence already shows repeated, informed, unconstrained violation of a known standard, the main need may be accountability, enforcement, or boundary setting rather than attribution checking.

condition: The main problem is unclear system causality without person-centered blame.

explanation: If no trait explanation is driving the response, whole-system diagnosis, causal mechanism mapping, or root-cause analysis may be more direct.

condition: The issue is assigning an owner for future action.

explanation: If a group sees a problem but no one acts, responsibility_assignment_for_action is the closer archetype.

condition: The central need is group dissent or consensus pressure.

explanation: If people are suppressing doubts to preserve harmony, dissent_protection_protocol addresses the process failure more directly.

condition: The response must be immediate for safety.

explanation: Emergency containment can precede attribution checking; the check should follow once immediate risk is controlled.

condition: The process is being used to excuse harm without repair.

explanation: Contextual explanation is not a substitute for acknowledging impact, making repair, or preventing recurrence.

structural_intervention: Separate the observable behavior from the observer's trait explanation, reconstruct relevant situational factors, compare trait and context explanations against evidence, then adjust the response so it fits both accountability and the conditions that shaped the behavior.

description: State the observable action, inaction, outcome, timing, and affected standard before using character or motive language.

description: Surface the person-centered story explicitly so it can be examined rather than silently governing the response.

description: List constraints, incentives, information access, role clarity, workload, tools, procedures, norms, social pressure, dependencies, and environmental conditions.

description: Seek evidence from the actor, witnesses, records, process data, timing, artifacts, and comparable cases without treating any single perspective as decisive.

description: Ask which explanation best accounts for the behavior, which evidence is missing, and whether multiple causes are likely.

description: Distinguish explaining a behavior from excusing it; keep standards, harm, intention, knowledge, choice, and recurrence risk visible.

description: Choose among feedback, clarification, support, training, process redesign, resource changes, repair, discipline, escalation, or monitoring based on the revised explanation.

description: Capture context factors that should change future design, policy, onboarding, review, or incident prevention.

rule: Do not use trait labels until the behavior has been described.

rationale: Behavioral specificity prevents labels from replacing evidence.

rule: Treat first explanations as hypotheses, not verdicts.

rationale: The first explanation is often the most cognitively available, not the most causally complete.

rule: Require at least one situational explanation before final response selection.

rationale: A credible alternative explanation can reveal support, redesign, or prevention actions that blame alone would miss.

rule: Do not let context erase impact.

rationale: Context can explain why behavior occurred while still requiring repair, boundary setting, or accountability.

rule: Escalate if context factors recur across actors or sites.

rationale: Repeated behavior in the same conditions indicates a design or governance problem, not only individual variation.

rule: Increase evidence standards as consequences become more serious.

rationale: High-stakes discipline, exclusion, legal action, or safety consequences require stronger attribution evidence.

rule: Update the system, not only the story.

rationale: The intervention succeeds when better explanation changes the response, prevention path, or operating environment.

invariant: Behavior remains observable and specific.

why_it_matters: The check should not drift into vague speculation about motives or personality.

invariant: Situational evidence is considered before final judgment.

why_it_matters: The point is to interrupt premature trait explanation, not merely soften language after the fact.

invariant: Accountability and impact remain visible.

why_it_matters: Contextual explanation should not become excuse-making or harm minimization.

invariant: Response matches causal structure.

why_it_matters: Training, discipline, redesign, support, repair, or escalation should fit what plausibly produced the behavior.

invariant: Systemic patterns are escalated when found.

why_it_matters: If multiple people behave similarly under the same conditions, the context must become an object of design or governance.

invariant: Affected parties are not erased by empathy for the actor.

why_it_matters: Fair attribution must consider both the actor's situation and the impact on others.

outcome: Fairer behavioral explanations

description: Observers become less likely to convert partial evidence into stable character judgments.

outcome: Better response selection

description: The chosen response is more likely to include the right mix of accountability, support, redesign, clarification, repair, or escalation.

outcome: Improved incident learning

description: Errors and failures reveal system conditions that can be changed, rather than disappearing into individual blame.

outcome: Reduced conflict escalation

description: People can respond to behavior without immediately hardening into hostile motive stories.

outcome: Higher procedural legitimacy

description: Actors and affected parties can see that judgments considered evidence, context, standards, and impact.

outcome: Reusable context knowledge

description: Repeated constraints, incentives, or process failures become design inputs rather than private excuses.

prose_essence:
Situational Attribution Check is the intervention pattern for moments when behavior is visible but context is not. It prevents an observer from turning a missed deadline, sharp comment, error, policy breach, silence, refusal, or poor result into a stable story about someone's character before the situation has been reconstructed.

The archetype is not a call to assume everyone is blameless. It is a disciplined pause between observation and judgment. The pause asks: what exactly happened, what trait story are we about to believe, what conditions might have shaped the behavior, and how should the response change once the explanation is more complete?

prose_when_to_use:
Use this archetype when a behavior is about to trigger feedback, blame, discipline, escalation, exclusion, policy enforcement, conflict response, safety review, or performance judgment. It is especially valuable when the observer has only partial access to workload, tools, incentives, role clarity, history, social pressure, time constraints, or information available to the actor.

It is also useful when the same behavior appears across multiple people in the same role, site, process, time period, or tool environment. Repetition under shared conditions often indicates a context that produces behavior rather than a collection of identical personal failings.

prose_structural_problem:
The structural problem is a mismatch between what observers can easily see and what they need to know. Observers see the behavior: someone missed a commitment, broke a rule, made an error, acted defensively, failed to speak up, or produced poor work. They often do not see the constraints, incentives, ambiguity, information gaps, tools, dependencies, or pressures surrounding that behavior.

Because the situation is less visible than the behavior, the mind supplies a trait explanation. The person was careless. The team was lazy. The customer was irrational. The subordinate was disrespectful. The operator was incompetent. Once that explanation hardens, response options narrow toward blame, punishment, avoidance, or moral judgment, and the system loses the chance to learn what actually made the behavior likely.

prose_intervention_logic:
The intervention starts by separating observation from interpretation. First describe the behavior in concrete terms. Then name the initial trait attribution explicitly. This makes the assumption reviewable: “We are interpreting this as carelessness” is easier to examine than an unstated atmosphere of blame.

Next, reconstruct the situation. What did the actor know at the time? What alternatives were available? What incentives, constraints, norms, tools, workload, dependencies, history, or environmental factors shaped the choice? Which factors are supported by evidence, which are speculation, and which would actually change the response if true?

Finally, compare explanations and adjust the response. The answer may still include accountability, direct feedback, repair, monitoring, or discipline. It may also include training, role clarification, resource changes, process redesign, policy revision, or conflict repair. The archetype succeeds when better explanation produces a better response.

prose_key_components:
### Observed Behavior

The observed behavior is the anchor. It states what happened before labels appear. “The report was submitted three days late after two reminders” is usable; “she is unreliable” is already an attribution. A good observed-behavior record includes timing, action or inaction, relevant standard, affected parties, and evidence source.

### Trait Attribution

The trait attribution is the initial person-centered story. It should be recorded, not suppressed, because hidden attributions still shape responses. Naming the story makes it testable: is this really laziness, incompetence, disrespect, bad faith, recklessness, or lack of motivation, or is that story filling a gap left by missing context?

### Situational Factor Map

The situational factor map makes the invisible environment visible. It includes constraints, incentives, role clarity, workload, tools, procedures, information access, dependencies, social norms, history, timing, and environmental conditions. The goal is not to list every possible excuse; it is to identify plausible conditions that could have shaped the behavior.

### Constraint Context Review

The constraint context review tests which context factors have explanatory power. A heavy workload may matter if it directly crowded out the task. A vague policy may matter if the actor reasonably misunderstood it. A poor tool may matter if it made the error predictable. This component turns context from a sympathy list into causal evidence.

### Explanatory Weighting

Explanatory weighting compares trait, situation, interaction, and uncertainty. Many real cases are mixed. A person may have made a bad choice under badly designed conditions. A system may have created predictable error while an actor still needs coaching. This component prevents both simplistic blame and simplistic excuse.

### Accountability Boundary

The accountability boundary keeps standards and impact visible. Explaining a behavior is not the same as excusing it. The check should still ask who was harmed, what standard applied, what the actor knew, what choices were feasible, whether repair is needed, and what recurrence risk remains.

### Response Adjustment

Response adjustment is where the archetype becomes a solution rather than an interpretation exercise. If the explanation changes, the response should change. That may mean process redesign instead of discipline, coaching plus role clarification, accountability plus tool repair, or conflict repair plus a clearer norm.

prose_common_mechanisms:
Context reconstruction interviews implement the archetype by asking actors and observers what was known, constrained, pressured, or misunderstood at the time. They work best when the interviewer is not merely collecting excuses but testing explanations.

Behavior-context mapping templates implement the archetype as an artifact. They separate the behavior, initial attribution, context factors, evidence, impact, and response options. A template is useful because it keeps the reviewer from skipping directly from behavior to judgment.

Just culture reviews implement an incident-centered variant. They are valuable when safety, error reporting, or operational learning matters, but they are not the archetype itself. They are one mechanism for balancing system contribution and accountability.

Incident timeline reviews implement the archetype by reconstructing the sequence of cues, handoffs, pressures, and decisions. A timeline can reveal that the actor's behavior was the final visible point in a chain of contextual conditions.

Performance context reviews implement the archetype inside evaluation. They check expectations, role clarity, workload, resources, feedback history, and constraints before a performance judgment is finalized.

Root-cause analysis can support the incident variant, but it is broader than this archetype. Root-cause analysis asks what caused an outcome; Situational Attribution Check specifically asks whether a person-centered explanation of behavior is being accepted too early.

Empathy mapping can support the conflict variant, but it must not replace evidence, standards, impact, or accountability. Empathy is a mechanism for perspective-taking, not a license to ignore harm.

prose_failure_modes:
A common failure mode is excuse drift. The reviewer discovers context and concludes that no accountability is appropriate. The mitigation is to keep the accountability boundary explicit.

Another failure mode is blame laundering. The organization performs a context check but keeps the original blame response. The mitigation is to document how context evidence changed, or did not change, the response.

A third failure mode is context theater. Reviewers list generic factors like workload or communication without evidence. The mitigation is to ask which factor changed available choices and what evidence supports that claim.

A fourth failure mode is over-systemization. All behavior is treated as system-produced, and individual choice disappears. The mitigation is explanatory weighting: context, choice, competence, intent, knowledge, and recurrence can all matter.

A fifth failure mode is selective use. Powerful actors receive context-sensitive explanation while less powerful actors receive character judgment. The mitigation is consistent criteria and review across status groups.

prose_neighbor_distinctions:
Whole System Diagnosis is broader. It maps system causes generally. Situational Attribution Check starts from a specific behavior and a risk of trait-centered explanation.

Psychological Safety Enablement is about creating a climate where people can speak up. Situational Attribution Check can benefit from psychological safety, but it is a specific decision discipline for interpreting behavior.

Conflict Resolution aims to resolve or transform disagreement. Situational Attribution Check may support conflict resolution, but only by correcting the causal story about behavior before response.

Competence Calibration Feedback aligns self-assessed skill with performance evidence. Situational Attribution Check examines the observer's explanation of someone else's behavior.

Responsibility Assignment for Action prevents diffusion of responsibility by assigning an owner. Situational Attribution Check asks whether observed behavior is being misexplained as character rather than situation.

Agency / Structure Attribution Balance is a neighboring macro-explanation pattern. It concerns how outcomes are explained across individual agency and structural conditions. Situational Attribution Check is narrower: behavior-centered and response-oriented.

prose_cross_domain_examples:
In performance management, the archetype changes a missed-deadline response from “unreliable employee” to a mixed response: clarify priority conflicts, repair the missed handoff, and give direct feedback about notification expectations.

In incident analysis, the archetype changes a medication-labeling error from “careless nurse” to a prevention path involving label redesign, interruption reduction, staffing review, and appropriate individual coaching.

In policy enforcement, the archetype changes a rule breach from “bad intent” to a response that distinguishes unclear notice, infeasible compliance, repeated disregard, and rule-design failure.

In customer service, the archetype changes “irrational customers” into a service-design diagnosis: confusing bills, unresolved tickets, high perceived risk, and channel delays may be producing the behavior.

In education, the archetype changes “unmotivated student” into a more useful explanation that may involve instructions, access, schedule, confidence, prior preparation, or support gaps.

prose_non_examples:
“Assume positive intent” is not this archetype. It replaces one default attribution with another and may ignore impact.

A generic empathy exercise is not this archetype. Empathy can help, but the archetype requires behavior specificity, evidence, explanatory comparison, accountability, and response adjustment.

A root-cause analysis with no person-centered blame risk is not this archetype. It may be good analysis, but it does not specifically correct trait-over-context attribution.

A disciplinary decision after clear evidence of informed, intentional, unconstrained misconduct is not primarily this archetype. Context may still inform prevention, but accountability is the center.

A bias checklist used after the response is already decided is not this archetype. The check must operate before interpretation hardens.

prose_tradeoffs:
The archetype trades speed for accuracy. A quick trait judgment is cognitively efficient, but often wrong or incomplete.

It trades simplicity for nuance. The resulting explanation may be mixed: a person made a poor choice, and the system made that poor choice more likely.

It trades emotional closure for learning. Blame can feel satisfying because it locates the problem in a person. Context reconstruction may reveal a harder, more distributed problem.

It also trades privacy against relevance. Some context is important; too much inquiry can become invasive. The check should gather only what is relevant to explanation, response, and prevention.

prose_invariants_to_preserve:
The behavior must remain specific and observable. The process should not replace one vague label with another.

Situational evidence must be considered before final judgment. A retrospective note that “context matters” does not interrupt attribution if the response was already chosen.

Impact and standards must remain visible. The archetype corrects explanation; it does not minimize harm.

The response must fit the revised explanation. If context points to process design, role ambiguity, or poor tools, the response should include design or governance changes, not only individual admonishment.

Repeated contextual patterns must be escalated. If many actors behave similarly under the same conditions, the context itself becomes a design problem.

prose_target_outcomes:
The primary outcome is fairer interpretation of behavior. The observer becomes less likely to treat partial information as proof of character.

A second outcome is better response selection. Instead of choosing only blame, the decision maker can choose a more accurate mix of feedback, repair, support, training, redesign, clarification, discipline, or escalation.

A third outcome is learning. Incidents, conflicts, and performance misses reveal constraints and system conditions that can be changed.

A fourth outcome is legitimacy. People are more likely to accept difficult feedback or consequences when they can see that evidence, context, impact, and standards were all considered.

prose_parameter_dimensions:
The first tuning dimension is stakes. Low-stakes feedback may need only a short behavior-context check. Discipline, exclusion, safety review, or policy enforcement requires stronger evidence, more perspectives, and clearer documentation.

The second dimension is time pressure. In emergencies, containment comes first and attribution review follows. In ordinary evaluation, the check should occur before the response hardens.

The third dimension is evidence depth. Some cases need only actor perspective and a quick scan of constraints. Others need records, timelines, comparison cases, process data, affected-party accounts, or independent review.

The fourth dimension is accountability strictness. Context should be considered without erasing standards. Domains with safety, legal, compliance, or trust obligations need explicit boundaries between explanation, repair, discipline, and prevention.

The fifth dimension is privacy. Context review should gather information relevant to the behavior and response decision, not personal detail merely because it is available.

prose_variants_and_near_names:
Performance Context Attribution Check applies in evaluation and supervision. It keeps role clarity, workload, tools, and expectations visible before a performance judgment is finalized.

Incident Attribution Reconstruction applies in safety, operations, compliance, and post-incident review. It asks whether an apparent individual error is better explained as a system-supported failure, a mixed case, or a genuinely reckless action.

Conflict Attribution Repair applies when interpersonal stories have hardened into hostile trait explanations. It uses context reconstruction to make the next response fairer without forcing reconciliation or excusing impact.

Policy Enforcement Context Check applies when apparent noncompliance may reflect unclear notice, access barriers, rule design, inconsistent enforcement, or contradictory incentives.

Near names include attribution error check, trait/context rebalancing, behavior-context check, context reconstruction, behavior-context mapping, just-culture review, and actor/observer correction. Most of these are aliases or mechanisms rather than standalone archetypes.

Performance Context Attribution Check

short_definition: Checks work conditions, role clarity, resources, incentives, workload, and information access before interpreting poor performance as a fixed trait or lack of care.

distinctive_feature: The behavior being explained is evaluated against a role or performance standard, so the check must preserve accountability while testing whether the context made the standard hard to meet.

distinct_from_parent: The parent applies to any behavior explanation; this variant centers on performance judgment and the fairness of evaluative response.

still_same_parent_because: The structural intervention is still a trait explanation interrupted by situational reconstruction before response selection.

use_when: A manager, reviewer, instructor, or evaluator is about to explain weak performance primarily through character, competence, attitude, or motivation.

use_when: The performer may have faced ambiguous expectations, missing resources, conflicting goals, overload, poor tools, or hidden dependencies.

use_when: The response will shape feedback, discipline, training, assignment, promotion, or support.

domain: team management

example: A missed deadline is checked against competing priorities, unclear handoffs, tool failures, and staffing before being described as laziness.

domain: education

example: Repeated late assignments are examined for access, instructions, timing, and support barriers before being interpreted as lack of motivation.

failure_modes: Context review becomes a way to avoid direct feedback or necessary accountability.

failure_modes: The reviewer asks only the actor for context and misses effects on teammates or stakeholders.

failure_modes: The explanation focuses on workload but ignores skill gaps that need coaching or role redesign.

Incident Attribution Reconstruction

short_definition: Reconstructs system conditions around an incident before assigning the cause to individual negligence, incompetence, or bad intent.

distinctive_feature: The context map must support future prevention, not only fair interpretation of the actor.

distinct_from_parent: The parent is a general attribution check; this variant is tied to incident learning, safety, prevention, and recurrence reduction.

still_same_parent_because: It still interrupts trait-centered blame by rebuilding the situation in which the behavior occurred.

use_when: An error, safety event, policy breach, outage, or operational failure is quickly being attributed to a person.

use_when: Interfaces, procedures, incentives, staffing, supervision, handoffs, or environmental conditions may have shaped the behavior.

use_when: The response could determine discipline, redesign, retraining, reporting, or prevention investment.

example_domains: safety operations healthcare incident_response compliance

example: A shipping error is traced through staffing, label design, handoff timing, exception rules, and system warnings before assigning individual fault.

example: An outage caused by a risky deployment is examined for alert fatigue, deployment pressure, rollback tools, and review coverage before blaming the engineer.

failure_modes: The review becomes so system-focused that it cannot name reckless choices or repeated standard violations.

failure_modes: The analysis searches for one root cause rather than a configuration of contributing factors.

failure_modes: Participants withhold context because the process is perceived as punishment disguised as learning.

Conflict Attribution Repair

short_definition: Uses behavior-context reconstruction to reduce hostile trait stories in interpersonal or intergroup conflict before choosing a response.

distinctive_feature: The variant must manage mutual interpretation, face threat, and conversational safety while still testing causal explanations.

distinct_from_parent: The parent can be a one-sided reasoning check; this variant is dialogic and relational.

still_same_parent_because: It still works by separating observed behavior from trait attribution and adding situational evidence before response.

use_when: A disagreement has hardened into stories about laziness, disrespect, incompetence, selfishness, bad faith, or malicious intent.

use_when: The parties have incomplete information about constraints, incentives, history, or interpretation frames.

use_when: The goal is a fairer next move, not forced harmony or avoidance of consequences.

domain: team conflict

example: A curt reply is checked against urgency, prior context, workload, and medium before being treated as disrespect.

domain: customer support

example: An angry customer is interpreted through service failure, uncertainty, and perceived risk before the response is escalated or dismissed.

failure_modes: Perspective-taking becomes pressure to excuse harmful behavior.

failure_modes: The process overfocuses on intent while ignoring impact.

failure_modes: A facilitator treats all explanations as equally plausible despite asymmetric evidence.

Policy Enforcement Context Check

short_definition: Reviews whether rule design, access, notice, incentives, enforcement history, or situational constraints shaped apparent noncompliance before selecting a policy response.

distinctive_feature: The check has to preserve rule legitimacy while testing whether the rule-context contributed to the behavior.

distinct_from_parent: The parent is general; this variant focuses on enforcement fairness and rule-system feedback.

still_same_parent_because: The core move remains the same: make the initial trait or intent attribution answerable to situational evidence before response.

use_when: A violation, noncompliance event, or rule breach is being attributed to irresponsibility or bad intent.

use_when: Affected actors may not have had clear notice, feasible alternatives, adequate support, or consistent enforcement expectations.

use_when: The response may involve discipline, exception handling, rule redesign, education, or escalation.

example: Repeated time-reporting errors are checked against tool design, training, schedule volatility, and policy clarity before discipline is selected.

failure_modes: The check becomes arbitrary exception-making and weakens predictability.

failure_modes: A rule-design failure is ignored because enforcement norms make individual blame easier.

failure_modes: Context review is applied inconsistently across groups, creating fairness harm.

near_names:
Attribution Error Check
Trait / Context Rebalancing
Context Reconstruction
Behavior-Context Mapping
Just Culture Review
Root-Cause Analysis
Actor / Observer Correction