Implicit Assumption Surfacing

batch: First Iteration/Batch 38

slug: metacognition

slug: representation

slug: sensemaking

slug: anchoring

slug: uncertainty

slug: causality

essence_one_line: Make hidden assumptions explicit so they can be tested, revised, documented, or deliberately preserved.

compression_statement: When decisions, designs, policies, or interpretations rely on background beliefs no one has named, surface the implicit assumptions, map where they influence action, test them against evidence and alternatives, and decide whether to update, monitor, or document them.

core_intuition: Unstated assumptions act like invisible premises. They shape what people notice, what they ignore, what options seem reasonable, and what risks feel acceptable. Surfacing them changes the decision from “we all know what this means” to “which premises are we relying on, and are they still safe to rely on?”

canonical_formula: implicit_assumption + influence_path -> evidence_test + alternative_assumption -> update_or_documentation_rule -> deliberate_decision_premises

structural_problem: A person, group, model, policy, or design process is being guided by unstated background beliefs, defaults, expectations, or category choices that influence decisions without being available for inspection, disagreement, validation, or revision.

condition: A decision feels obvious before premises have been named

signal: Participants converge quickly or say “that’s just how it works” without articulating the conditions that make the choice valid.

condition: A plan depends on uncertain facts or behavior

signal: The outcome would change if a hidden belief about users, markets, capacity, incentives, technology, or stakeholders were false.

condition: People use shared labels with different implied meanings

signal: Terms such as ready, safe, fair, high risk, easy, normal, or user-friendly hide different background assumptions.

condition: Debate focuses on conclusions instead of premises

signal: Arguments repeat because parties defend positions while leaving the assumptions behind those positions unnamed.

condition: A representation or model appears complete

signal: Model diagrams, dashboards, forecasts, policies, or personas omit assumptions about what is excluded, simplified, or held constant.

condition: Past failure included “we assumed…”

signal: Retrospectives reveal implicit beliefs that were never tested before action.

symptom: Surprise when predictable constraints appear

interpretation: A background assumption about resources, behavior, timing, authority, or context was operating unchecked.

symptom: False agreement

interpretation: Participants agree on a label or plan while relying on different implicit premises.

symptom: Repeated exceptions or edge cases are treated as anomalies

interpretation: The schema or model contains hidden default assumptions that exclude important cases.

symptom: Stakeholders challenge a decision as biased, unrealistic, or opaque

interpretation: The decision may rest on assumptions that are visible to some actors only after impact.

symptom: A plan works only under narrow conditions

interpretation: Its validity conditions were implicit rather than documented and monitored.

symptom: Evidence is interpreted selectively

interpretation: Confirmation bias or cognitive entrenchment may be protecting unexamined assumptions.

root_tension: Action requires simplifying assumptions, but when those assumptions remain unnamed they cannot be tested, owned, revised, or deliberately accepted as risk-bearing premises.

case: The assumptions are already explicit and contested

why_not: Use evidence adjudication, negotiation, decision analysis, or governance rather than initial surfacing.

case: The main issue is a user misunderstanding how a system behaves

why_not: Mental model mismatch repair is closer when expected-versus-actual system behavior is the central structure.

case: The main intervention is choosing a representation form

why_not: Representation fit selection applies when the problem is whether a map, model, table, story, or interface is the right representation.

case: The group lacks any interpretation of an ambiguous situation

why_not: Structured sensemaking may be more central when the task is creating a plausible interpretation from unclear signals.

case: The central issue is skillful tacit know-how, not hidden premises

why_not: Tacit knowledge elicitation fits when the target is embodied or expert know-how rather than assumptions beneath a decision.

structural_intervention: Elicit hidden assumptions, connect each assumption to the decision or behavior it influences, test it against evidence and plausible alternatives, mark its confidence and validity conditions, and decide whether to revise, monitor, document, or intentionally preserve it.

step: Name the decision, model, design, or conflict where hidden assumptions matter

logic: Assumptions become actionable only when tied to something they influence.

step: Elicit implicit assumptions

logic: Use prompts, counterfactuals, interviews, premortems, critiques, or stakeholder perspectives to uncover beliefs participants have not stated.

step: Map influence paths

logic: Show how each assumption affects choices, interpretations, exclusions, risk judgments, or next actions.

step: Prioritize by leverage and uncertainty

logic: Focus effort on assumptions that are both consequential and uncertain, not on every imaginable premise.

step: Test against evidence and alternatives

logic: Ask what would make the assumption true, false, incomplete, biased, or context-limited; compare at least one plausible alternative assumption.

step: Assign status and owner

logic: Mark whether the assumption is accepted, revised, rejected, monitored, or documented as a known risk.

step: Update the decision artifact or practice

logic: Reflect revised assumptions in plans, models, policies, designs, logs, or review cadence so the surfacing work changes action.

rule: Surface assumptions that change action if false

application: Do not spend equal effort on harmless premises; prioritize decision influence.

rule: Distinguish assumption from evidence

application: Do not let a plausible story count as validation just because it has been named.

rule: Name validity conditions

application: An assumption may be useful within a boundary; record when it stops applying.

rule: Use alternatives to reveal hidden defaults

application: A default assumption becomes visible when compared with a plausible contrary premise.

rule: Preserve useful assumptions deliberately

application: The goal is not to eliminate every assumption; it is to make reliance conscious and revisable.

rule: Protect dissent and low-status perspectives

application: Hidden assumptions are often easiest to see from marginalized, novice, frontline, or external viewpoints.

invariant: The surfaced item must be an assumption, not merely a conclusion.

preservation_note: It should be phrased as a premise the decision relies on.

invariant: Every assumption should have an influence path.

preservation_note: If no decision, interpretation, or action changes, the item is probably background context rather than a priority assumption.

invariant: Evidence status must remain visible.

preservation_note: A surfaced assumption should not become more authoritative merely because it is written down.

invariant: Alternatives should remain thinkable.

preservation_note: The intervention should loosen cognitive entrenchment, not replace one hidden premise with one official premise.

invariant: Context dependence must be preserved.

preservation_note: Some assumptions are valid locally but dangerous when generalized.

invariant: The output must alter a decision artifact, review cadence, or shared understanding.

preservation_note: A one-time list of assumptions is insufficient if it has no downstream effect.

outcome: More testable decisions

evidence: Critical premises are named, prioritized, and tied to evidence or monitoring signals.

outcome: Reduced false agreement

evidence: Participants can state where they share premises and where they rely on different ones.

outcome: Earlier risk detection

evidence: Plans include leading indicators for assumptions that could fail.

outcome: Better learning from failure

evidence: Retrospectives identify which assumptions were wrong, incomplete, or unmonitored.

outcome: More inclusive and robust framing

evidence: Stakeholder, edge-case, and excluded-case assumptions become visible before harm or rework.

outcome: More deliberate preservation of useful defaults

evidence: Assumptions that remain are documented with conditions and rationale rather than treated as unquestioned facts.

prose_essence:
**Implicit Assumption Surfacing** is the intervention pattern for making hidden premises inspectable before they silently govern action. It is not a generic request to “think harder.” It creates a structured chain from an implicit premise to the decision it affects, the evidence that could test it, the alternative premise that could replace it, and the rule for updating or documenting what remains.

Use this archetype when a plan, design, policy, model, or conflict depends on beliefs that are being treated as obvious but have not been stated. The point is not to eliminate assumptions. Every action relies on some simplification. The point is to make consequential assumptions visible enough that people can decide whether they are valid, risky, context-bound, biased, or worth preserving deliberately.

Strategic Assumption Surfacing

short_definition: Surfaces the hidden market, capability, timing, risk, or stakeholder assumptions beneath a strategy before the strategy is treated as settled.

distinctive_feature: The variant centers on assumptions that carry strategic risk because they determine whether a plan is viable.

distinct_from_parent: The parent can operate in any decision context; this variant focuses on high-leverage strategy premises and leading indicators.

still_same_parent_because: It still uses assumption elicitation, influence-path mapping, evidence testing, alternatives, and update/documentation rules.

condition: A strategy depends on uncertain premises

application: Name the premises that would make the plan fail if false.

condition: Stakeholders agree on a plan too quickly

application: Check whether agreement hides different background assumptions about the world.

condition: A strategic choice has delayed feedback

application: Document leading indicators and assumption owners so validity can be monitored.

role: Names the unstated strategic premise.

role: Shows which strategic decision the assumption affects.

role: Defines what evidence would support or weaken the assumption.

example_domains:
corporate strategy
product strategy
policy planning
investment governance

domain: Product strategy

example: A team names assumptions about adoption, willingness to switch, integration burden, and buyer authority before committing roadmap resources.

domain: Policy planning

example: A policy group makes explicit its assumptions about compliance behavior, enforcement capacity, and political constraints.

failure_mode: assumption inventory without prioritization

cause: The team lists every possible premise instead of the ones that drive choice.

mitigation: Rank assumptions by decision influence and uncertainty.

Design Assumption Surfacing

short_definition: Makes hidden assumptions about users, workflows, contexts, constraints, or interpretation visible before design decisions harden.

distinctive_feature: The variant treats user/context assumptions as design constraints that must be exposed and tested.

distinct_from_parent: The parent is general; this variant anchors the surfacing loop in design choices and user evidence.

still_same_parent_because: The same assumption-to-influence-to-evidence-to-update loop remains.

condition: A design decision rests on untested beliefs about users

application: Surface assumptions about user goals, literacy, constraints, incentives, and environment.

condition: Teams debate solutions before agreeing on premises

application: Separate preference conflict from different assumptions about user behavior.

condition: Feedback is ambiguous

application: Map which assumptions each usability signal supports or challenges.

role: Names the unstated belief about users or context.

role: Prevents a single imagined user model from dominating design.

role: Connects design assumptions to research or prototype evidence.

example_domains:
interface design
service design
instructional design
safety communication

domain: Interface design

example: A design team names assumptions about what users know, notice, and can recover from before choosing navigation and warnings.

domain: Service design

example: A service team surfaces assumptions about customer time, trust, accessibility, and handoff expectations.

failure_mode: persona reification

cause: Surfaced assumptions are treated as facts because they are now visible.

mitigation: Mark confidence and evidence status for each assumption.

Governance Assumption Audit

short_definition: Audits the hidden assumptions embedded in policy, oversight, rules, or governance decisions so they can be challenged and owned.

distinctive_feature: The variant emphasizes accountability for hidden normative or institutional assumptions.

distinct_from_parent: The parent can be used informally; this variant adds governance traceability, ownership, and review needs.

still_same_parent_because: It remains a structured assumption surfacing and testing loop rather than a whole governance system.

condition: A policy or rule claims neutrality

application: Ask which assumptions about actors, incentives, categories, and harms the rule embeds.

condition: Decision rights are contested

application: Surface assumptions about authority, accountability, competence, and risk ownership.

condition: A governance process excludes some cases

application: Name assumptions behind inclusion, exclusion, thresholds, and exceptions.

role: Assigns accountability for preserving, testing, or revising a governance assumption.

role: Defines conditions under which the assumption remains acceptable.

role: Specifies how the governance record changes after review.

example_domains:
risk governance
public policy
AI model governance
institutional review

domain: AI governance

example: A review board surfaces assumptions about acceptable error tradeoffs, affected groups, and monitoring capacity before approving deployment.

domain: Public policy

example: Policy reviewers name assumptions about burden, eligibility, enforcement, and unintended exclusion.

failure_mode: compliance theater

cause: The audit records assumptions without authority or cadence to revisit them.

mitigation: Assign owners, thresholds, and review triggers.

Conflict Assumption Surfacing

short_definition: Surfaces the hidden assumptions underneath disagreement so parties can tell whether they disagree about values, facts, expectations, or interpretations.

distinctive_feature: The variant uses assumption surfacing to decompose conflict rather than to optimize a single decision.

distinct_from_parent: The parent covers hidden assumptions generally; this variant focuses on assumptions beneath disagreement and mistrust.

still_same_parent_because: It still names assumptions, maps influence, tests alternatives, and decides what to update or preserve.

condition: Parties repeatedly talk past one another

application: Elicit the background assumptions that make each position seem obvious to its holder.

condition: Conflict is framed as personality or intent

application: Map the assumption chains that connect observations to accusations or demands.

condition: The same evidence supports opposite conclusions

application: Identify interpretation assumptions before debating conclusions.

role: Names the belief each side treats as obvious.

role: Shows how a different premise could make the other view coherent.

role: Maps how assumptions turn facts into conflict positions.

example_domains:
organizational conflict
stakeholder engagement
interdisciplinary work
negotiation

domain: Cross-functional conflict

example: Engineering and sales surface assumptions about customer tolerance, release risk, and credibility before arguing about launch timing.

domain: Community engagement

example: A planning group surfaces assumptions about trust, safety, and procedural fairness beneath opposing positions.

failure_mode: forced equivalence

cause: The process treats all assumptions as equally valid to reduce tension.

mitigation: Separate empathy for assumptions from evidence and accountability tests.

near_names:
Assumption Surfacing
Hidden Assumption Review
Assumption Audit
Assumption Mapping
Model Assumption Review


Implicit Bias in Knowledge Structure

type: archetype

source: generated

batch: First Iteration/Batch 38/Wave 2

slug: schema

slug: equity

slug: framing

components:
Knowledge Structure Under Review
Category Audit
Implicit Assumption Map
Excluded Case Review
Stakeholder Perspective Set
Downstream Consequence Trace
Revision Proposal
Tradeoff Note
Validation and Monitoring Indicator
Legacy Category History
Power or Authority Map
Edge Case Library
Dissent Record
Scope Statement

mechanisms:
Taxonomy Bias Audit
Inclusive Classification Review
Stakeholder Category Review
Ontology Critique Workshop
Boundary Critique Session
Excluded Case Sampling
Category Impact Assessment
Red-Team Schema Review
Category Revision Log
Bias Review Checklist

essence_one_line: Audit how hidden assumptions in categories, schemas, or mental models bias what is noticed, valued, or ignored.

compression_statement: When a knowledge structure appears neutral but quietly privileges some cases, identities, explanations, or values, inspect its categories, boundaries, defaults, examples, and excluded cases; surface the implicit assumptions they encode; revise the structure; and document the tradeoffs so the bias does not remain hidden inside the schema.

core_intuition: People do not only hold biased beliefs; they also inherit biased ways of organizing knowledge. A category system decides what counts as normal, relevant, exceptional, comparable, or invisible. Because those decisions feel like structure rather than judgment, they need a deliberate audit that treats classification choices as accountable design choices.

canonical_formula: knowledge_structure + hidden_category_assumptions + excluded_cases + consequence_trace + accountable_revision -> bias_aware_schema_governance

structural_problem: A schema, taxonomy, model, coding frame, or conceptual map encodes hidden assumptions or value judgments that shape interpretation while presenting itself as neutral structure. The bias is not merely in one decision-maker; it is embedded in how knowledge is partitioned, named, sequenced, exemplified, and connected.

condition: A category system is treated as neutral or technical

signal: People say the schema is “just how the data is organized,” even though its categories determine what can be seen or acted on.

condition: Important cases repeatedly fall into residual or exception categories

signal: The “other,” “miscellaneous,” “nonstandard,” or “edge case” category becomes large, contested, or consequential.

condition: Stakeholders contest the meaning of categories

signal: Affected groups, users, practitioners, or downstream teams report that labels misrepresent lived experience, work practice, risk, need, or identity.

condition: A knowledge structure drives decisions beyond its original purpose

signal: A taxonomy, rubric, model, or coding scheme created for one context is reused for governance, funding, ranking, eligibility, search, triage, or automation.

condition: Examples and defaults overrepresent one viewpoint

signal: Training examples, canonical cases, default pathways, or named roles mostly reflect one group, workflow, culture, scale, or institution.

condition: Misclassification has asymmetric consequences

signal: Some people, cases, risks, or explanations are harmed more when the schema ignores, compresses, or misnames them.

condition: The structure hides a value tradeoff

signal: A category choice optimizes efficiency, simplicity, comparability, or legacy continuity while obscuring costs to accuracy, dignity, access, or local meaning.

condition: Bias appears after a schema update or standardization effort

signal: A new unified structure removes local distinctions, minority terms, historical context, or alternative interpretations.

symptom: Residual-category overload

interpretation: The schema treats recurring cases as exceptions because it lacks a legitimate place for them.

symptom: Neutrality language

interpretation: The knowledge structure is defended as objective even though category choices are contested or consequence-laden.

symptom: Invisible stakeholder perspective

interpretation: The schema reflects the organizer’s view rather than the perspectives of those classified, served, studied, or governed.

symptom: Label harm

interpretation: Category names stigmatize, flatten, pathologize, or erase important distinctions.

symptom: Uneven retrieval or visibility

interpretation: Some concepts, cases, or groups are harder to find because the map or taxonomy routes attention elsewhere.

symptom: Canonical-example skew

interpretation: The examples that teach the structure imply a narrow definition of normal, expert, successful, risky, or legitimate.

symptom: Downstream decision distortion

interpretation: Eligibility, triage, search ranking, resource allocation, or diagnosis changes because the structure hides an assumption.

symptom: Assimilation pressure

interpretation: Users must translate themselves or their work into categories that fit the system rather than categories that fit reality.

root_tension: Knowledge structures must simplify. They cannot include every distinction, perspective, and exception at once. But simplification becomes hidden bias when its exclusions, assumptions, and consequences are treated as natural, technical, or value-free. The archetype preserves the usefulness of structure while making category choices inspectable, contestable, and revisable.

case: The problem is a single unnamed assumption in a decision or plan

why_not: Implicit Assumption Surfacing is the better fit when the assumption is local to a decision rather than embedded in a reusable knowledge structure.

case: The problem is an outdated schema that misclassifies new cases without a bias or exclusion pattern

why_not: Schema Update Protocol is more direct when the issue is drift, novelty, or category maintenance rather than hidden value-laden exclusion.

case: The problem is conflict between two live schemas

why_not: Schema Conflict Resolution is better when the central work is crosswalking, translating, or integrating incompatible schemas.

case: The problem is system boundary selection rather than knowledge-structure design

why_not: Boundary Critique Audit is closer when the main object is what is inside or outside a system boundary, not how a schema categorizes knowledge.

case: The problem is an overt discriminatory rule

why_not: Legal, policy, or governance remediation may be needed first. This archetype is for hidden assumptions embedded in structure, not a substitute for direct accountability.

case: The problem is only poor naming or vocabulary inconsistency

why_not: A glossary or terminology alignment mechanism may suffice if no category boundary, value judgment, or consequence pattern is at stake.

structural_intervention: Convert an apparently neutral knowledge structure into an auditable design object. The intervention identifies the structure and its purpose, examines categories and boundaries for implicit assumptions, tests excluded or distorted cases, traces downstream consequences, incorporates affected perspectives, revises the structure, and records tradeoffs and monitoring signals.

step: Identify the knowledge structure and its use

logic: Name the schema, taxonomy, model, rubric, coding frame, or map under review and specify the decisions, interpretations, or retrieval paths it influences.

step: Inventory categories, boundaries, defaults, and examples

logic: Bias often lives in what is considered normal, central, residual, comparable, or exemplary, not only in explicit rules.

step: Surface implicit assumptions

logic: Ask what the structure assumes about users, cases, priorities, expertise, legitimacy, time, scale, identity, causality, or value.

step: Test excluded, misfit, and marginal cases

logic: Use cases that are forced into residual buckets, misnamed, invisible, or harmed to reveal where the structure fails.

step: Bring in affected and alternative perspectives

logic: A structure built from only the organizer’s viewpoint will miss how categories operate for those classified or excluded.

step: Trace downstream consequences

logic: A category choice matters most when it changes retrieval, eligibility, ranking, allocation, diagnosis, accountability, or self-understanding.

step: Generate revision options

logic: Options may include splitting, merging, renaming, adding dimensions, changing defaults, preserving local categories, annotating uncertainty, or adding exceptions.

step: Choose and document tradeoffs

logic: No revision removes all tradeoffs. Record what the new structure improves, what it still excludes, and what risks require monitoring.

step: Validate in use and monitor drift

logic: A revised structure must be tested against actual cases and reviewed as new exclusions or distortions appear.

rule: Audit consequences, not intentions

application: A schema can be biased even when its designers acted in good faith. Evaluate how it structures attention and action.

rule: Treat residual cases as evidence

application: A large or consequential exception category is not noise; it is a signal that the structure may be misrepresenting reality.

rule: Separate category maintenance from bias repair

application: A category can be outdated without being biased. Bias repair requires attention to hidden assumptions, exclusions, and asymmetric effects.

rule: Require stakeholder perspective when classification affects people

application: If the structure classifies, serves, ranks, or governs people, include perspectives from those affected by the categories.

rule: Preserve useful distinctions unless simplification is justified

application: Merging categories for simplicity should be treated as a design decision with documented consequences.

rule: Document unresolved tradeoffs

application: A revised schema should not pretend to be perfectly neutral; it should make remaining choices and risks visible.

rule: Monitor the revised structure

application: Bias can reappear through new use cases, changing meanings, or downstream workarounds.

invariant: Category choices remain accountable design choices

reason: The archetype fails if categories are treated as natural facts rather than constructed tools.

invariant: Excluded and misfit cases remain visible

reason: The audit depends on evidence from cases the structure handles poorly.

invariant: Affected perspectives are not optional decoration

reason: Hidden bias is often invisible from the organizer’s viewpoint.

invariant: Revision changes the structure, not just the rhetoric

reason: A renamed category or diversity statement does not repair a biased knowledge structure by itself.

invariant: Tradeoffs are documented

reason: Every structure simplifies; responsible revision records what remains compressed or excluded.

invariant: The structure remains usable

reason: The goal is better knowledge organization, not infinite fragmentation or paralysis.

outcome: Hidden assumptions become explicit

indicator: The audit names what the structure assumes about normal cases, relevant differences, legitimate evidence, or stakeholder roles.

outcome: Excluded cases receive legitimate handling

indicator: Residual categories shrink, edge cases are represented more accurately, or alternative paths are documented.

outcome: Downstream decisions become less distorted

indicator: Retrieval, eligibility, triage, coding, or interpretation changes after structural revision.

outcome: Stakeholder trust improves

indicator: Affected users can see how their concerns changed category names, boundaries, examples, or decision pathways.

outcome: Schema governance becomes more transparent

indicator: Revision logs, tradeoff notes, and monitoring indicators are maintained.

outcome: Bias recurrence becomes easier to detect

indicator: New misfit cases trigger review rather than disappearing into exceptions.

prose_tradeoffs:
The main tradeoff is simplicity versus representational justice. A simple taxonomy is easier to teach and maintain, but it may erase consequential differences. A more nuanced taxonomy may be more accurate but harder to use.

Another tradeoff is continuity versus correction. Changing a category can disrupt historical data, search, or reporting. The answer is not to avoid revision; it is to document crosswalks, migration rules, and comparability limits.

A third tradeoff is local meaning versus global standardization. Local categories may fit lived practice. Global categories support aggregation and interoperability. The best design may preserve both through dimensions, annotations, or crosswalks.

A fourth tradeoff is visibility versus privacy. Making an excluded group visible can improve service and recognition, but it can also expose sensitive identities or vulnerabilities.

Classification Schema Bias Audit

variant_type: subtype

short_definition: Audits a classification scheme for hidden assumptions, excluded cases, and asymmetric consequences.

distinctive_feature: The classification act itself is the main carrier of bias.

distinct_from_parent: The parent can audit any knowledge structure; this variant focuses on class assignment schemes.

still_same_parent_because: It still uses category audit, excluded-case review, consequence tracing, revision, and tradeoff documentation.

use_when: a category system assigns cases, people, risks, needs, or documents to classes

use_when: classification results influence access, retrieval, interpretation, or governance

example_domains:
policy eligibility
knowledge bases
research coding
product analytics

failure_modes: treating classification as merely technical

failure_modes: renaming categories without changing boundaries

Label Harm Review

short_definition: Reviews category names and labels for stigmatizing, flattening, or misleading effects.

distinctive_feature: The bias is concentrated in the names and frames attached to categories.

distinct_from_parent: The parent reviews names, boundaries, defaults, examples, and consequences; this variant foregrounds labels and frames.

still_same_parent_because: Label repair must still check whether boundaries and consequences remain biased after names change.

source_primes: schema epistemic_justice framing

use_when: category names affect identity, legitimacy, dignity, or interpretation

use_when: labels travel into downstream decisions or public-facing systems

example_domains:
education
healthcare
archives
public services

failure_modes: polite labels masking unchanged exclusions

Research Framing Bias Audit

short_definition: Audits research constructs, coding frames, and canonical cases for hidden assumptions about what counts as evidence or explanation.

distinctive_feature: The knowledge structure is embedded in inquiry design rather than in an operational taxonomy.

distinct_from_parent: The parent is domain-general; this variant focuses on research concepts, variables, and coding schemes.

still_same_parent_because: The intervention still surfaces assumptions, tests excluded cases, revises the frame, and documents tradeoffs.

source_primes: schema framing epistemic_justice

use_when: a research frame determines what will be collected, coded, or interpreted

use_when: canonical examples or constructs reflect a narrow social or institutional viewpoint

example_domains:
social research
evaluation
policy analysis
market research

failure_modes: adding token examples without changing constructs

failure_modes: mistaking researcher convenience for conceptual validity

Default Normal Case Review

short_definition: Tests whether a knowledge structure quietly treats one case type as normal and all others as deviations.

distinctive_feature: The audit focuses on default cases and exemplar skew rather than all category choices.

distinct_from_parent: The parent audits the whole structure; this variant audits the hidden normal case embedded in defaults and examples.

still_same_parent_because: It still acts on the same structure by revising defaults, examples, category placement, and consequence records.

source_primes: schema implicit_knowledge metacognition

use_when: a default pathway, example, or central category defines what counts as normal

use_when: nondefault users or cases are treated as exceptions or add-ons

example_domains:
interface documentation
training curricula
policy templates
medical intake categories

failure_modes: turning nondefault cases into a separate appendix

failure_modes: overfitting the structure to a new single default

near_names:
Knowledge Structure Bias Audit
Schema Bias Audit
Category Bias Audit
Taxonomy Bias Audit
Inclusive Classification Review
Implicit Category Bias Review


Incentive-Compatible Rule Design

batch: First Iteration/Batch 14

slug: accountability

slug: signaling

slug: feedback

slug: equilibrium

slug: reciprocity

components:
Participant Role Map
Desired Outcome Specification
Action and Choice Set
Incentive Payoff Map
Information Structure Map
Truthfulness Condition
Verification Rule
Penalty or Reward Rule
Strategic Response Test
Failure and Gaming Monitor
Participation Constraint
Fairness Constraint
Appeal or Exception Channel
Adaptive Rule Update
Transparency Explanation

mechanisms:
Truthful Auction Mechanism
Matching Rule Design
Anti-Gaming Scoring Rule
Incentive Contract
Self-Selection Menu
Deposit, Bond, or Stake
Audit and Penalty System
Reputation-Weighted Participation
Blind or Randomized Review Rule
Mechanism Design Protocol

essence_one_line: Design rules so participants' best self-interested action produces the desired system outcome.

compression_statement: When participants can strategically exploit a system because their private incentives or information diverge from the desired outcome, incentive-compatible rule design changes rules, payoffs, information structures, verification, and consequences so honest, cooperative, compliant, or otherwise desired behavior becomes the rational best response.

core_intuition: A rule is fragile when it assumes people will act against their incentives. The archetype works by asking what a rational participant will do after seeing the rule, then redesigning the rule until the locally attractive action also supports the system's purpose. It replaces wishful compliance with a strategic fit between participant motivation and institutional intent.

canonical_formula: strategic_participants + private_incentives_or_information + exploitable_rule -> payoff_map + information_structure + verification + reward_penalty + strategic_response_test -> desired_behavior_as_best_response

structural_problem: Participants have enough autonomy, private information, or strategic choice that they can gain by acting against the system's intended outcome. The written rule, metric, contract, protocol, or policy rewards behavior that is not the behavior the system actually needs.

condition: Participants can choose among multiple actions after observing the rule.

why_it_matters: Incentive compatibility matters when actors adapt strategically rather than simply following a fixed process.

condition: The designer cannot directly command or perfectly observe the desired behavior.

why_it_matters: If behavior is fully observable and enforceable, ordinary instruction or process control may be sufficient.

condition: Participants hold private information about value, cost, risk, quality, need, effort, or intent.

why_it_matters: Private information creates opportunities for misreporting, adverse selection, hidden action, or selective disclosure.

condition: The current rule creates a profitable path to game, evade, misreport, free-ride, or optimize a proxy.

why_it_matters: The archetype is activated by a gap between the rule's formal success condition and the intended outcome.

condition: The desired behavior can be specified well enough to design and test a rule around it.

why_it_matters: If the goal is undefined, the design can only move gaming from one proxy to another.

condition: Verification, reputation, payment, access, eligibility, or other consequence channels can be adjusted.

why_it_matters: The archetype needs levers that change expected payoffs or strategic information, not just a statement of preference.

symptom: Participants comply with the letter of the rule while violating its purpose.

interpretation: The rule rewards proxy success rather than the real target.

symptom: Reporting, bidding, ranking, or eligibility systems produce suspiciously optimized claims.

interpretation: Actors have learned which disclosed information improves their payoff.

symptom: Honest participants are disadvantaged compared with strategic manipulators.

interpretation: The mechanism punishes the behavior it claims to want.

symptom: Enforcement effort rises, but gaming returns in new forms.

interpretation: The system is policing symptoms instead of redesigning the strategic equilibrium.

symptom: A performance metric improves while underlying value, quality, safety, or fairness gets worse.

interpretation: Participants are optimizing the metric rather than the mission.

symptom: Participants hide risk, inflate value, understate cost, or misclassify themselves because disclosure would hurt them.

interpretation: Truthful revelation is not incentive-compatible.

symptom: Only naive, altruistic, or low-power actors follow the intended behavior.

interpretation: The rule is not robust to rational self-interest or unequal strategic capacity.

root_tension: The system needs participants to act, reveal, contribute, comply, or allocate in a particular way, but each participant evaluates the rule through their own incentives, information, constraints, and opportunities for strategic advantage.

case: The main problem is lack of skill, knowledge, or capacity rather than strategic response.

why_not: Training, capability building, simplification, or resource provision may be more appropriate than incentive-compatible rule design.

case: The desired outcome is morally or politically contested and cannot be reduced to a shared rule objective.

why_not: Legitimacy, deliberation, or governance design should precede incentive alignment.

case: Actors have no meaningful choice or strategic information.

why_not: There is no best-response problem to redesign.

case: The intervention is just raising a reward or penalty without testing how participants will adapt.

why_not: That may be payoff restructuring, enforcement, or punishment, but not full incentive-compatible rule design.

case: The rule would manipulate vulnerable actors or coerce behavior without transparency or consent.

why_not: Ethical constraints may rule out the intervention even when it would be strategically effective.

structural_intervention: Redesign the rule environment so the participant's expected best response lines up with the desired system behavior. This includes mapping incentives, modeling strategic choices, restructuring payoffs, shaping information, defining verification, preserving participation, and testing for gaming before and after deployment.

step: Define the system purpose and desired participant behavior.

logic: A rule cannot be incentive-compatible with an undefined or proxy-only outcome.

step: Identify participants, roles, options, private information, and current payoffs.

logic: Strategic behavior depends on what each actor can choose, knows, values, and expects.

step: Map the current best responses and gaming paths.

logic: The rule's real effect is revealed by what rational participants are rewarded for doing, not by what the rule text says.

step: Redesign payoffs, access, eligibility, information disclosure, or verification so desired behavior dominates exploitative alternatives.

logic: The core move is to make the intended behavior locally rational.

step: Add proportional monitoring, audit, appeal, and exception handling.

logic: Verification and due process keep the rule credible without turning it into surveillance or arbitrary enforcement.

step: Stress-test with adversarial scenarios and diverse participant constraints.

logic: A design that works only for cooperative or privileged actors is not robust.

step: Monitor equilibrium drift and update the rule when participants learn new strategies.

logic: Incentive-compatible design is often adaptive because actors respond to the design over time.

rule: Start from the participant's expected best response, not the designer's intended behavior.

reason: Incentive compatibility is a strategic property of the whole rule environment.

rule: Prefer designs where honest or cooperative behavior is easier than exploitative behavior.

reason: Reducing friction for desired behavior can be more durable than escalating punishment.

rule: Do not reward a proxy unless the proxy remains coupled to the real target under optimization.

reason: Rewarded proxies invite gaming when they diverge from the underlying purpose.

rule: Check participation constraints and exit options.

reason: A rule can be internally incentive-compatible yet fail because legitimate participants opt out.

rule: Treat penalties and surveillance as proportional tools, not default solutions.

reason: Excessive enforcement can create concealment, inequity, or legitimacy failure.

rule: Reassess after deployment because participants learn the mechanism.

reason: Strategic adaptation can turn yesterday's robust rule into today's exploitable loophole.

target_invariants: Desired behavior remains connected to the system's real purpose, not just to a measurable proxy.

target_invariants: Honest, cooperative, or compliant participants are not placed at a systematic disadvantage.

target_invariants: Rules remain legible enough that participants can understand what is expected and why.

target_invariants: Penalties, rewards, and verification are proportional to stakes and risk.

target_invariants: Participation remains viable for legitimate actors with different resources, constraints, or risk exposure.

target_invariants: The design preserves procedural fairness, appeal paths, and appropriate exceptions.

target_invariants: Monitoring detects gaming without normalizing unnecessary surveillance or coercion.

expected_outcomes: Reduced gaming, misreporting, loophole exploitation, and proxy optimization.

expected_outcomes: Higher rates of truthful disclosure, cooperative contribution, compliant behavior, or efficient allocation.

expected_outcomes: Lower dependence on constant manual enforcement because desired behavior is built into the payoff structure.

expected_outcomes: More predictable outcomes under self-interested participant behavior.

expected_outcomes: Improved legitimacy when participants see that honest behavior is not punished.

expected_outcomes: Better resilience to strategic adaptation because rules are tested against likely best responses.

prose_essence:
Incentive-compatible rule design is the pattern of making the desired behavior the participant's best response. It is used when people can strategically adapt to a rule, exploit a metric, hide information, or gain by doing something other than what the system needs.

The core question is not “What do we want people to do?” but “Given these rules, what will a rational participant have reason to do?” A good design narrows the gap between institutional intent and participant self-interest. It does not assume virtue, perfect monitoring, or unlimited enforcement capacity; it changes the rule environment so honest, cooperative, compliant, truthful, or efficient behavior is the path that makes sense.

prose_when_to_use:
Use this archetype when participants have meaningful choice, private information, and incentives that can diverge from the intended outcome. It is especially useful when a system is being gamed, when metrics improve but real outcomes deteriorate, when honest participants lose to strategic manipulators, or when enforcement keeps escalating without solving the strategic cause.

It is not a cure for every behavior problem. If actors lack resources, skills, legitimacy, or shared values, incentive-compatible rules may be secondary. If the desired behavior cannot be specified or verified at all, the intervention may create a new proxy to game rather than solving the problem.

prose_structural_problem:
The structural problem is strategic divergence. A participant sees a rule, metric, contract, price, audit process, ranking, or eligibility threshold and chooses the action that benefits them. If that action differs from the system's desired behavior, the system has an incentive-compatibility problem.

This often appears as loophole exploitation, misreporting, adverse selection, hidden action, proxy optimization, collusion, free-riding, or superficial compliance. The deeper issue is that the rule is not just a command; it is an environment that teaches participants what behavior pays.

prose_intervention_logic:
The intervention begins by defining the real outcome, not just the measured proxy. Then it maps participants, choices, private information, expected payoffs, verification limits, and available enforcement or reward channels. Once the current best responses are visible, the designer changes the rule so the desired action is more attractive than the exploitative alternative.

This can involve payment rules, audits, penalties, rewards, self-selection menus, ranking changes, disclosure rules, safe harbors, deposits, or random review. Those are mechanisms, not the archetype itself. The archetype is the causal logic that makes the mechanism work: desired behavior becomes rational under the rule.

prose_key_components:
**Participant Role Map** (`participant_role_map`) — Identifies the actors, roles, authorities, and strategic positions in the rule environment. Include who chooses, who benefits, who bears costs, who observes outcomes, who verifies claims, and who can exploit the rule.

**Desired Outcome Specification** (`desired_outcome_specification`) — States the real behavior or outcome the rule is meant to produce, separate from proxies or metrics. This prevents the design from optimizing an easily measurable substitute that participants can game.

**Action and Choice Set** (`action_and_choice_set`) — Lists the choices participants can actually make under the rule, including evasion and exit options. Incentive compatibility is assessed over available choices, not over the choices the designer wishes existed.

**Incentive Payoff Map** (`incentive_payoff_map`) — Maps expected benefits, costs, risks, rewards, penalties, status effects, and effort burdens for each relevant action. The map should include intangible incentives such as reputation, convenience, delay, risk avoidance, and political advantage.

**Information Structure Map** (`information_structure_map`) — Shows what each participant knows, can hide, can reveal, can infer, or can manipulate. Private information is often where misreporting, adverse selection, hidden action, and strategic signaling enter the system.

**Truthfulness Condition** (`truthfulness_condition`) — Defines when honest reporting or disclosure is a participant's best response. Not every incentive-compatible system requires truth-telling, but whenever disclosure matters this condition must be explicit.

**Verification Rule** (`verification_rule`) — Defines how claims, actions, outcomes, and compliance can be checked or cross-validated. Verification can use audits, logs, peer checks, evidence standards, random inspection, or outcome reconciliation, but it should be proportional.

**Penalty or Reward Rule** (`penalty_or_reward_rule`) — Specifies consequences that make desired behavior more attractive and exploitative behavior less attractive. Rewards and penalties should be calibrated against stakes, uncertainty, due process, and the possibility of false positives.

**Strategic Response Test** (`strategic_response_test`) — Stress-tests the rule by asking what rational, constrained, adversarial, or opportunistic participants will do. Use scenario analysis, red teaming, simulation, pilot feedback, or retrospective analysis to find failure paths before scaling.

**Failure and Gaming Monitor** (`failure_and_gaming_monitor`) — Tracks post-deployment gaming, drift, unintended consequences, and distributional effects. A mechanism that was once incentive-compatible can degrade as participants learn, coordinate, or discover loopholes.

prose_common_mechanisms:
Each mechanism below is an implementation family. None of them is automatically incentive-compatible; each must be tested against participant best responses, gaming paths, verification limits, and fairness constraints.

**Truthful Auction Mechanism** (`truthful_auction_mechanism`) — allocation_and_revelation_mechanism. Uses bidding and payment rules to reduce incentives for misrepresenting valuation or cost.

**Matching Rule Design** (`matching_rule_design`) — allocation_mechanism. Structures preferences, priorities, and assignment rules so participants cannot easily benefit by misreporting or manipulating order.

**Anti-Gaming Scoring Rule** (`anti_gaming_scoring_rule`) — metric_or_evaluation_mechanism. Scores behavior in ways that reduce gains from proxy manipulation or superficial compliance.

**Incentive Contract** (`incentive_contract`) — contractual_mechanism. Links rewards, payments, risk-sharing, or authority to outcomes or behaviors that track the desired purpose.

**Self-Selection Menu** (`self_selection_menu`) — screening_mechanism. Offers differentiated options whose tradeoffs cause different participant types to reveal themselves through choice.

**Deposit, Bond, or Stake** (`deposit_bond_or_stake`) — commitment_and_deterrence_mechanism. Requires participants to put value at risk so harmful misbehavior has an expected cost.

**Audit and Penalty System** (`audit_and_penalty_system`) — verification_and_enforcement_mechanism. Combines probabilistic inspection with consequences to make evasion unattractive without checking everything.

**Reputation-Weighted Participation** (`reputation_weighted_participation`) — trust_and_access_mechanism. Uses history or standing to shape access, influence, or scrutiny in response to repeated behavior.

**Blind or Randomized Review Rule** (`blind_or_randomized_review_rule`) — information_control_mechanism. Changes what participants or evaluators can see so strategic signaling, favoritism, or imitation becomes harder.

**Mechanism Design Protocol** (`mechanism_design_protocol`) — design_and_testing_protocol. Specifies actors, information, actions, payoffs, allocation, and enforcement, then tests whether the rule produces the intended strategic behavior.

prose_failure_modes:
Common failure modes include proxy capture, loophole mining, reward hacking, collusion, adverse sorting, punitive overcorrection, opaque mechanism distrust, and equilibrium drift. The recurring failure is designing for the participant the institution wishes it had rather than the participant who will actually respond to the rule.

A second failure is treating a mechanism as a guarantee. An auction, score, contract, penalty, subsidy, or audit is not inherently incentive-compatible. It becomes useful only when its structure makes the desired behavior a best response under realistic participant assumptions.

prose_neighbor_distinctions:
This archetype is broader than **Principal–Agent Alignment**, which focuses on delegated action by an agent for a principal. It is broader than **Moral Hazard Mitigation**, which focuses on hidden action after risk transfer. It overlaps with **Adverse Selection Filtering** when hidden types matter, but this archetype also covers scoring, compliance, contribution, allocation, and truthfulness problems.

It is close to **Mechanism Design Protocol**. For this batch, mechanism design protocol is treated as a merge-review near name or method family under the canonical parent drafted here. Human review may later decide that protocol engineering deserves its own archetype.

It also differs from **Price Signal Design**. Prices may be used as mechanisms, but price signals mainly communicate scarcity or value; incentive-compatible rule design is defined by strategic best-response alignment.

prose_cross_domain_examples:
In procurement, a buyer can combine bid rules, milestone payments, performance bonds, and audits so contractors gain less from lowballing or hiding defects. In a platform marketplace, ranking rules can be changed so sellers gain more from durable service quality than from fake reviews or keyword stuffing. In school assignment, strategy-proof matching rules can reduce the benefit of misranking preferences. In cybersecurity, a bug bounty can make responsible disclosure more attractive than silence or resale. In AI evaluation, hidden tests and contamination audits can reduce benchmark gaming.

Across these cases, the surface mechanisms differ. The abstraction is the same: redesign the rule so the participant's best response supports the intended system outcome.

prose_non_examples: A larger punishment is not automatically incentive-compatible rule design. A motivational speech is not incentive-compatible rule design if the reward structure still punishes the desired behavior. A price increase is not this archetype unless it is part of a strategic rule environment. A training program is not this archetype unless the main problem is that the rule makes bad behavior rational. A deliberation process is not this archetype when the real issue is unresolved value conflict rather than strategic misalignment.

prose_tradeoffs:
The main tradeoff is robustness versus simplicity. More strategic robustness often means more rules, tests, audits, exceptions, and governance. This can make the system harder to understand and easier to distrust.

Another tradeoff is enforcement versus autonomy. Monitoring can make a rule credible, but excessive monitoring can become surveillance. Strong incentives can align behavior, but they can also distort attention, crowd out intrinsic motivation, and make participants optimize narrow targets.

prose_invariants_to_preserve:
The design should preserve the real target outcome, not merely the metric. It should preserve a viable path for honest participants, proportional consequences, legibility, procedural fairness, and legitimate appeal. It should also preserve enough adaptability to respond when participants learn the rule and discover new strategies.

A rule that produces the desired equilibrium by coercion, opacity, or exploitation should not be treated as a successful archetype implementation. Incentive compatibility is about strategic alignment; it does not by itself prove ethical legitimacy.

prose_target_outcomes:
A successful implementation reduces gaming, misreporting, loophole exploitation, and proxy optimization. It increases truthful disclosure, cooperative contribution, compliance, efficient allocation, or other intended behavior. It also reduces the need for constant manual policing because the rule itself carries more of the alignment burden.

The best cases create a durable expectation: participants believe that honest behavior is not naive, cooperative behavior is not punished, and gaming is not the easiest path to success.

prose_parameter_dimensions:
Key tuning dimensions include reward size, penalty severity, audit probability, verification cost, transparency level, rule complexity, participant burden, appeal availability, update cadence, and tolerance for false positives or false negatives. Another important dimension is how much of the rule is public: too little transparency can undermine legitimacy, while too much detail can reveal exploitable loopholes.

The designer must also tune the strength of incentives relative to intrinsic motivation. Strong rewards can focus behavior, but they can also crowd out professional judgment, reciprocity, public spirit, or care. In high-stakes settings, proportionality and due process are design constraints, not afterthoughts.

prose_variants_and_near_names:
Important variants include truth-revealing rule design, anti-gaming rule design, self-selection menu design, contribution incentive alignment, and compliance incentive design. Near names include strategy-proof design, truthful mechanism design, game-proofing, incentive-aligned system design, and mechanism design protocol.

These variants should not be promoted automatically. They deserve promotion only when the variant has its own recurring structural problem and intervention logic that cannot be explained by the parent pattern.

Truth-Revealing Rule Design

short_definition: Design the rule so truthful disclosure is safer or more rewarding than strategic misrepresentation.

distinctive_feature: The primary design target is honest revelation rather than effort, contribution, compliance, or allocation alone.

distinct_from_parent: The parent archetype covers any rule whose desired behavior is a best response; this variant focuses specifically on making truth-telling incentive-compatible.

still_same_parent_because: Truthfulness is one incentive-compatible behavior among several; it still depends on payoff, information, verification, and strategic-response design.

use_when: Participants hold private valuations, preferences, types, costs, risks, or quality information.

use_when: The system's desired outcome depends on eliciting that information rather than merely observing behavior.

use_when: Misreporting is hard to detect after the fact or costly to punish directly.

Information Structure Map

role: Identifies who knows what and what can be elicited.

Truthfulness Condition

role: States when truthful reporting is a best response.

Verification Rule

role: Defines how claims can be checked or cross-validated.

Truthful Auction Mechanism

role: Uses payment rules that reduce gains from bid shading or misreporting.

Scoring Rule

role: Rewards forecasts or reports according to accuracy in a way that favors honest probabilities.

example_domains:
auctions
forecasting
procurement
research reporting
risk disclosure

domain: Procurement

example: A sealed process asks suppliers for capacity and cost information while structuring penalties and acceptance rules to reduce strategic lowballing.

domain: Forecasting

example: A prediction market or proper scoring rule rewards calibrated probabilities rather than confident exaggeration.

failure_modes: Truthful reporting is rewarded on paper but verification is too weak to deter profitable misreporting.

Anti-Gaming Rule Design

short_definition: Close loopholes and proxy-reward paths so optimizing the rule does not undermine the system's real purpose.

distinctive_feature: The central object is not incentives in the abstract but the gap between the written rule and the purpose it is meant to serve.

distinct_from_parent: The parent may design a new rule from scratch; this variant often hardens an existing rule against adversarial optimization.

still_same_parent_because: Gaming is a strategic best-response problem created by badly aligned rules, so the remedy is still incentive-compatible redesign.

use_when: Participants can exploit a metric, threshold, ranking, subsidy, workflow, or eligibility rule.

use_when: The system rewards observable proxies that are easier to optimize than the intended outcome.

use_when: The rule-maker can observe at least some gaming patterns and revise the rule without destroying legitimacy.

Gaming Path Map

role: Shows how actors can win the rule while violating its purpose.

Strategic Response Test

role: Stress-tests how rational actors will adapt.

Failure and Gaming Monitor

role: Detects drift after deployment.

Anti-Gaming Scoring Rule

role: Reduces reward for proxy manipulation.

Audit and Penalty System

role: Raises the expected cost of exploitative behavior.

example_domains:
platform ranking
school accountability
sales compensation
online moderation
grant evaluation

failure_modes: The anti-gaming patch creates a more complex loophole rather than aligning behavior with purpose.

Self-Selection Menu Design

short_definition: Offer differentiated options so participants reveal type or need by choosing the option that fits them best.

distinctive_feature: The rule elicits information through choice architecture rather than direct disclosure.

distinct_from_parent: The parent includes any incentive-compatible best-response design; this variant uses a menu of options as the instrument.

still_same_parent_because: The menu works only if each type's self-interested choice reveals or routes behavior in the desired way.

use_when: Participants differ in type, cost, risk, need, capability, or willingness to pay.

use_when: Directly asking for type would invite misrepresentation or require intrusive verification.

use_when: The designer can create menus whose tradeoffs make each type prefer the intended option.

Participant Type Model

role: Describes relevant differences among participant groups.

Participation Constraint

role: Ensures the menu is acceptable enough that actors engage rather than exit.

Incentive Payoff Map

role: Shows which option each type is expected to choose.

Self-Selection Menu

role: Creates options whose tradeoffs separate participant types.

Tiered Access Terms

role: Uses differentiated terms to route users by need, risk, or value.

example_domains:
insurance
education placement
benefits access
pricing tiers
service-level agreements

failure_modes: The menu sorts people by privilege or gaming ability rather than by the intended type.

Contribution Incentive Alignment

short_definition: Structure rewards, reciprocity, recognition, or access so contributing to a shared system is individually rational.

distinctive_feature: The design target is cooperative contribution rather than truthful reporting, allocation, or compliance alone.

distinct_from_parent: The parent can target any strategic behavior; this variant targets contribution incentives in shared-benefit settings.

still_same_parent_because: It still makes the desired action—contribution—the participant's best response under the rule system.

use_when: A collective or shared-resource system depends on voluntary or semi-voluntary contribution.

use_when: Participants can benefit from others' contributions while withholding their own effort.

use_when: Contribution quality can be made visible enough to reward or govern without destructive surveillance.

Contribution Rule

role: Defines expected forms and levels of contribution.

Visibility or Attribution Rule

role: Makes contribution legible enough to align recognition or reciprocity.

Fairness Constraint

role: Prevents contribution rules from punishing actors with fewer resources.

Matching Contribution

role: Amplifies individual contribution through reciprocal matching.

Reciprocity Credit

role: Connects current contribution to future access or standing.

example_domains:
open-source projects
mutual aid
knowledge bases
volunteer systems
public-goods funding

failure_modes: The incentive turns contribution into performative output and crowds out intrinsic or communal motivation.

Compliance Incentive Design

short_definition: Make compliant behavior easier, safer, or more rewarding than violation, while preserving proportionality and due process.

distinctive_feature: The desired action is rule-compliant behavior under credible, proportional governance.

distinct_from_parent: The parent covers strategic interaction broadly; this variant applies it to compliance with an existing rule regime.

still_same_parent_because: Compliance becomes incentive-compatible only when expected benefits, costs, verification, and fairness are redesigned together.

use_when: Rules are formally clear but noncompliance is the rational or easiest path.

use_when: The designer can adjust detection, penalties, defaults, procedural burden, or legitimate rewards.

use_when: The goal is not merely punishment but changing the expected payoff and friction of behavior.

Verification Rule

role: Defines detection and evidentiary thresholds.

Penalty or Reward Rule

role: Defines consequences for compliance or violation.

Appeal or Exception Channel

role: Protects legitimate edge cases.

Audit and Penalty System

role: Changes expected payoff of violation.

Default Compliance Path

role: Makes the compliant action the low-friction path.

example_domains:
regulatory compliance
cybersecurity
tax reporting
workplace safety
platform rules

failure_modes: Overly punitive incentives create fear, concealment, or adversarial compliance rather than genuine risk reduction.

near_names:
Mechanism Design Protocol
Strategy-Proof Rule Design
Truthful Mechanism Design
Game-Proofing
Incentive-Aligned System Design
Anti-Gaming Design


Inclusive Membership Union Design

batch: Batch 01

canonical_family: Algebraic & Set-Theoretic Structure

aliases:
Inclusive Merge Design
Set Union Integration
At-Least-One Membership Aggregation
Any-Source Collection Merge
Disjunctive Collection Assembly

related_primes: disjointness intersection linear_independence measure complement partition category aggregation classification completeness predicate relation boundary identity_test criteria_of_individuation span vector_space formal_system associativity commutativity invariance duality

slug: union

slug: disjointness

slug: intersection

slug: measure

slug: complement

slug: partition

slug: category

slug: aggregation

slug: classification

slug: completeness

slug: predicate

slug: relation

slug: boundary

slug: span

slug: associativity

slug: commutativity

slug: invariance

slug: duality

mechanisms:
Union Specification Sheet
Source Collection Ingestion Workflow
Canonical Identity Resolution Pass
Inclusive-OR Membership Test
Provenance Tagging Protocol
Deduplicating Union Pass
Overlap and Coverage Dashboard
Type Compatibility Checklist
Union Delta Review

essence_one_line: Pool collections by inclusive membership without losing identity, provenance, or overlap visibility.

compression_statement: Inclusive Membership Union Design is the intervention pattern of declaring source collections and a universe, normalizing member identity, applying the at-least-one membership rule, collapsing duplicates, retaining source provenance, auditing overlaps, and labeling downstream use limits so a combined collection is a controlled union rather than an ambiguous merged list.

core_intuition: Union is generous: one source is enough to include an element. That generosity is powerful for coverage, but dangerous when identity, type compatibility, provenance, and duplicate treatment are implicit. The archetype makes the inclusiveness explicit and auditable.

canonical_formula: U = ⋃ᵢ Sᵢ = {x ∈ Ω | ∃i: x ∈ Sᵢ}; with provenance P(x) = {i | x ∈ Sᵢ}.

structural_problem: Multiple collections must be combined so any-source membership counts, but the combined result becomes unreliable when universe scope, member identity, duplicates, source provenance, overlap, or type compatibility are implicit.

trigger_conditions: A decision, search, eligibility rule, dataset, catalog, or watchlist needs the inclusive set of all items appearing in any of several sources.

trigger_conditions: Source collections overlap and repeated appearances must not be counted as distinct members.

trigger_conditions: Membership in one source is sufficient, but downstream users still need to know which source supplied the member.

trigger_conditions: Sources use different identifiers, naming conventions, types, or update cadences for the same underlying elements.

trigger_conditions: A combined list is reused as if it were a validated truth set rather than an inclusive membership set.

trigger_conditions: Union size, overlap structure, or changes across versions become important evidence.

symptoms: Merged lists contain duplicates, near-duplicates, or conflicting representations of the same member.

symptoms: Union counts are inflated because overlap is treated as new membership.

symptoms: Provenance is erased, making it impossible to explain why an element is included.

symptoms: Incompatible element types are combined into one result because they share a label or field name.

symptoms: Downstream teams infer consensus or validity from any-source membership.

symptoms: A source outage is mistaken for a real reduction in union membership.

symptoms: Union, intersection, partition, aggregation, and concatenation are used interchangeably in design discussions.

root_tension: Union increases coverage by accepting membership from any source, but broader inclusion increases the need for identity resolution, source accountability, and scope control.

anti_signatures: The task is to find elements common to all collections; use shared_subset_intersection_mapping.

anti_signatures: The task is to identify everything outside a target subset; use complement_space_mapping.

anti_signatures: The task is to force categories to be non-overlapping and collectively exhaustive; use exhaustive_disjoint_partition_design.

anti_signatures: The task is to prove no shared members exist; use overlap_exclusion_design.

anti_signatures: The task is to assign additive size or probability to subsets; use additive_measure_space_design.

anti_signatures: The task is to generate reachable elements from primitives under operations; use generated_span_closure_design.

structural_intervention: Define the contributing collections, normalize their members into a common universe, apply inclusive membership, collapse duplicates by canonical identity, preserve source provenance, surface overlaps and deltas, reject incompatible sources, and attach use-scope labels to the union result.

action_logic: State why an inclusive union is needed and what downstream decision will consume it.

action_logic: Declare the universe of admissible elements and the source collections to be unioned.

action_logic: Normalize source-specific records into canonical member identities.

action_logic: Apply the inclusive rule: a member belongs if it appears in at least one admissible source collection.

action_logic: Collapse duplicates and near-duplicates according to the identity key.

action_logic: Preserve provenance for every member, including source, version, timestamp, and source membership criterion where available.

action_logic: Calculate overlap profile, union size, and source contribution deltas.

action_logic: Quarantine sources or records that violate type, universe, identity, or semantic compatibility checks.

action_logic: Label downstream uses and warn consumers against treating union membership as consensus, validation, or priority without extra evidence.

action_logic: Recompute or version the union when source membership, identity rules, or source eligibility changes.

decision_rules: If membership in any source is not sufficient, do not use union as the parent operation.

decision_rules: If element identity cannot be normalized, report an unresolved union rather than silently concatenating lists.

decision_rules: If an element appears in multiple sources, count it once for membership and separately for provenance or support.

decision_rules: If source semantics differ materially, require type-compatibility review before unioning.

decision_rules: If a source is empty or missing, distinguish true empty membership from failed observation or ingestion.

decision_rules: If downstream decisions require confidence, priority, or consensus, add a separate weighting or validation mechanism after union formation.

target_invariants: Membership is governed by at-least-one source inclusion.

target_invariants: The universe and source collections are explicit.

target_invariants: Canonical identity prevents duplicate inflation.

target_invariants: Source provenance is retained even when duplicates collapse.

target_invariants: Incompatible source types are quarantined or excluded.

target_invariants: Consumers know what union membership does and does not imply.

expected_outcomes: Inclusive coverage improves without ungoverned list sprawl.

expected_outcomes: Duplicate counts and overlap-induced inflation are reduced.

expected_outcomes: Union members remain explainable through provenance records.

expected_outcomes: Source drift, ingestion failures, and membership changes become visible.

expected_outcomes: Downstream users can distinguish “present in at least one source” from “validated,” “common,” “high priority,” or “exhaustive.”

expected_outcomes: Neighbor patterns such as intersection, complement, partition, and measure gain a clear boundary object.


Incompatible Requirement Set Resolution

batch: Batch 05

canonical_family: Formal Methods & Idealized Models

aliases:
Axiomatic Incompatibility Resolution
Inconsistent Requirement Set Resolution
Hard-Constraint Conflict Resolution
Impossibility-Aware Tradeoff Design
Guarantee-Set Reconciliation

slug: axiom

slug: consistency

slug: constraint

slug: compatibility

slug: trilemma

slug: boundedness

slug: decision

slug: prioritization

slug: preference

slug: optimization

slug: paradox

slug: closure

slug: scarcity

slug: quantifier

components:
Commitment Set
Commitment Semantics and Scope
Constraint Strength Classification
Consistency Criteria
Joint Satisfiability Model
Feasible Set
Minimal Unsatisfiable Core
Incompatibility Certificate
Protected Invariant
Relaxation Option
Constraint Priority Rule
Residual Guarantee Ledger
Tradeoff Rationale
Decision Impact Trace
Recheck Trigger
Assumption Register
Conflict Explanation Record
Exception Authority
Violation Policy
Decision Record
Uncertainty Residue

mechanisms: Weighted MaxSAT or Soft-Constraint Optimization

essence_one_line: When individually defensible commitments cannot all hold together, prove and localize the incompatibility, choose the smallest legitimate relaxation, and publish the guarantees and losses that remain.

compression_statement: Given a scoped set of axioms, requirements, guarantees, or prohibitions, normalize their semantics and strength; construct one joint satisfiability model; distinguish a genuine empty feasible set from search failure or modeling error; extract and independently verify one or more minimal unsatisfiable cores; protect non-negotiable invariants; enumerate removal, weakening, scoping, conditionalization, sequencing, assumption-change, resource-expansion, and architecture-change options; select a satisfiable resolution through an explicit authority and priority rule; then trace impacts and replace the impossible original promise with a residual guarantee ledger and recheck triggers.

core_intuition: A collection of plausible commitments can fail as a collection even when no single commitment is unreasonable and every pair looks compatible. Continuing to search for a design that satisfies an empty feasible set wastes effort and encourages hidden exceptions. The intervention separates two questions that are often blurred: first, what is mathematically or structurally impossible under the current model; second, which commitment should yield, under whose authority, with what burden, and with what remaining promise. Proof constrains the option set, but governance chooses among the surviving options.

canonical_formula: Let C = {c₁,…,cₙ} be commitments interpreted over decision space X under assumptions A and scope S. If F(C,A,S) = {x ∈ X : x satisfies every cᵢ} = ∅, find an inclusion-minimal U ⊆ C with F(U,A,S)=∅ and an incompatibility certificate π. Choose a resolution operator ρ from remove, weaken, scope, conditionalize, sequence, substitute, change A, expand X, or redesign, subject to protected invariants P, such that F(ρ(C,A,S)) ≠ ∅. Publish Δ = C − ρ(C,A,S), the residual guarantee G, decision rationale R, and recheck trigger T.

structural_problem: A system is expected to satisfy several axioms, hard requirements, guarantees, policies, or invariants that are individually plausible but have no joint realization under the same assumptions and scope. Teams continue to optimize inside an empty feasible region, satisfy different subsets in different places, or silently weaken one commitment while leaving the original all-at-once promise intact. The conflict may be global even when every pair of commitments is compatible, so local review and intuition fail to reveal the true core.

trigger_conditions: A formal proof, exhaustive finite analysis, dual certificate, or repeated validated model shows that no candidate satisfies all active commitments.

trigger_conditions: Different teams produce designs that each meet a different subset, but no integrated design survives the full requirement set.

trigger_conditions: A “pick any two,” impossibility theorem, no-free-lunch boundary, or mutually exclusive guarantee claim appears and must be checked against the actual assumptions.

trigger_conditions: Pairwise compatibility checks pass while the full set remains inconsistent or infeasible.

trigger_conditions: Hard safety, rights, legal, budget, timing, performance, or correctness constraints leave an empty feasible region.

trigger_conditions: Exceptions accumulate because implementers are resolving the same hidden incompatibility differently at local points.

trigger_conditions: The organization needs an accountable record of which promise will be changed and what remains guaranteed.

trigger_conditions: Changing one assumption, resource bound, architecture, or scope condition may restore feasibility but would materially alter the original claim.

trigger_conditions: A future-facing guarantee must be conditioned on observable competence, fault, input, or environment boundaries.

symptoms: Solver runs, design iterations, or negotiations repeatedly return no solution without a shared explanation.

symptoms: Requirements are all labeled mandatory even though implementation contains undocumented waivers.

symptoms: One document promises all properties while operational runbooks choose different properties under stress.

symptoms: A theorem is cited as a slogan, but its assumptions and quantifiers are absent from the decision record.

symptoms: Teams argue about priorities before establishing whether the commitments are actually incompatible.

symptoms: A single pair of requirements is blamed even though removing either one still leaves another unsatisfiable core.

symptoms: A local workaround shifts the violated commitment to another group, lifecycle stage, or system boundary.

symptoms: Public or contractual language preserves the original guarantee after the implementation has weakened it.

symptoms: The same conflict reappears whenever assumptions or demand conditions drift because no recheck trigger exists.

root_tension: The system wants the legitimacy and protection conferred by treating every commitment as hard, but the conjunction admits no realization. Formal analysis can establish that some sacrifice or model change is necessary, yet it cannot by itself determine which value, stakeholder, guarantee, or assumption should bear that sacrifice.

anti_signatures: The objectives are merely in tension and a feasible compromise already exists; use Pareto Frontier Navigation, Objective Weighting Governance, or ordinary optimization.

anti_signatures: The constraints have not yet been made explicit or testable; use Constraint Formulation first.

anti_signatures: Components work separately but may interfere when combined; use Composability Testing and Validation or Antagonism Screening and Separation.

anti_signatures: The contradiction is caused by ambiguous language, mismatched schemas, or collapsed levels and disappears after clarification; use Schema Conflict Resolution or Paradox Reframing.

anti_signatures: A single resource or process stage limits throughput but the requirement set is satisfiable; use Bottleneck Identification and Relief.

anti_signatures: Records or replicas have drifted into inconsistent states; use Reconciliation After Drift rather than changing the governing commitments.

anti_signatures: One axiom is unproved or controversial but the axiom set is not jointly inconsistent; use Regress Termination Rule, Knowledge-Warrant Audit, or Assumption Stress Testing.

anti_signatures: A solver timed out or a team failed to find a design; search failure alone is not an incompatibility certificate.

structural_intervention: Turn the complete commitment set into an auditable satisfiability claim, prove and localize any empty feasible region, then apply an explicitly authorized resolution operator that restores feasibility while preserving protected invariants and replacing the impossible promise with an accurate residual guarantee.

action_logic: Bound the decision instance: identify the actors, system states, time horizon, environment, resources, and behavior over which the commitments are claimed.

action_logic: Inventory every axiom, requirement, guarantee, prohibition, and derived dependency with stable identifiers, sources, owners, and wording.

action_logic: Normalize terms, units, quantifiers, temporal scope, and applicability conditions; separate model assumptions from desired commitments.

action_logic: Classify commitments by strength and mark protected invariants before any optimization or relaxation begins.

action_logic: Construct one joint satisfiability model and specify the consistency criteria, feasible set, and acceptable evidence for satisfiable and unsatisfiable results.

action_logic: Search for a satisfying realization; if none is found, distinguish resource-limited search from proof-producing unsatisfiability.

action_logic: Extract one or more minimal unsatisfiable cores and verify the incompatibility certificate independently against the real decision frame.

action_logic: Enumerate resolution operators for each core: remove, weaken, narrow scope, conditionalize, sequence, substitute, change an assumption, add a resource, alter the decision rule, or redesign the architecture.

action_logic: Reject options that violate protected invariants or merely export the conflict beyond the modeled boundary.

action_logic: Compare the remaining satisfiable options using an explicit priority, legitimacy, harm, reversibility, and distributional rule.

action_logic: Authorize and implement one resolution; update dependent requirements, proofs, interfaces, tests, contracts, policies, and operational behavior.

action_logic: Publish the residual guarantee ledger, sacrificed commitments, uncertainty residue, dissent, and out-of-scope behavior.

action_logic: Monitor recheck triggers and rerun the analysis when assumptions, commitments, technology, law, demand, or scope changes.

decision_rules: Do not force a trade-off until the incompatibility is demonstrated under a stable, reviewed model.

decision_rules: Do not treat pairwise compatibility as evidence that the whole set is satisfiable.

decision_rules: Do not treat solver timeout, numerical instability, or lack of ingenuity as proof of impossibility.

decision_rules: Prefer the smallest sufficient, most reversible relaxation that preserves protected invariants and does not shift hidden harm outside the boundary.

decision_rules: If several minimal cores exist, evaluate all materially different cores before attributing causality or choosing a sacrifice.

decision_rules: Changing theorem assumptions or applicability scope creates a conditional new guarantee; it does not refute the original impossibility result.

decision_rules: A hard-to-soft conversion requires named authority and explicit rationale; optimization weights must not silently perform governance.

decision_rules: If no authorized relaxation preserves the protected invariants, report the decision frame as unresolved or impossible rather than fabricating compliance.

decision_rules: Every chosen relaxation must be propagated to downstream tests, contracts, documentation, monitoring, and user-visible claims.

target_invariants: The incompatibility result remains tied to the exact assumptions, semantics, quantifiers, domain, and scope used to derive it.

target_invariants: Protected rights, safety floors, correctness conditions, or conservation laws are not silently converted into weighted preferences.

target_invariants: No relaxation is hidden behind implementation detail, local exception, or vague language.

target_invariants: The residual guarantee is satisfiable, testable, and no broader than the implemented behavior supports.

target_invariants: Affected stakeholders and decision authority remain traceable to the chosen sacrifice.

target_invariants: Downstream dependencies receive the revised commitment set rather than the obsolete impossible promise.

target_invariants: Uncertainty about model fidelity and proof completeness remains visible.

expected_outcomes: Futile search inside an empty feasible region stops.

expected_outcomes: The actual conflict is localized to one or more reviewable minimal cores.

expected_outcomes: Unrelated commitments are protected from indiscriminate cutting.

expected_outcomes: Trade-offs become explicit, legitimate, and comparable rather than emerging through shadow exceptions.

expected_outcomes: The implemented system and its public or contractual guarantees agree.

expected_outcomes: Out-of-scope and degraded behavior becomes observable and governed.

expected_outcomes: Future changes can be evaluated against a versioned proof, decision record, and recheck trigger.

expected_outcomes: The exactly-three trilemma case can be handled as a recognized subtype without creating a duplicate parent archetype.

prose_tradeoffs: The pattern trades accessibility against formal precision, decisive action against reversibility, broad guarantees against truthful scope, and protected values against feasible-space size. Minimal-core extraction can accelerate action but can also hide alternative cores. Optimization can compare options efficiently while laundering value judgments into weights. Resource expansion can preserve promises but create new dependency, cost, or sustainability burdens.

Trilemma Resolution

short_definition: Resolves an exactly three-property incompatibility by proving the joint guarantee impossible and choosing which property to drop, weaken, scope, sequence, or condition.

distinctive_feature: The exactly-three structure makes the option catalogue and communication surface compact enough to compare all sacrifice paths explicitly.

distinct_from_parent: The parent handles incompatibility among any number of commitments; this variant requires a three-property core and names the three drop, scope, or dissolve paths.

still_same_parent_because: It uses the same satisfiability proof, minimal-core, protected-invariant, relaxation, and residual-guarantee logic.

use_when: The conflict is naturally expressed as three desirable properties or guarantees.

use_when: The “pick any two” framing is supported by a proof or explicit model rather than repeated as a slogan.

use_when: Each of the three sacrifice paths has materially different consequences or stakeholders.

example: A team proves that its fault and timing assumptions cannot support all stated agreement, validity, and termination guarantees, then publishes which liveness guarantee is conditional.

example: A fixed budget, universal eligibility, and an unchanged per-person benefit cannot all hold under the forecast population, so the policy explicitly changes one dimension.

failure_modes: The three properties are rhetorical labels rather than formal commitments.

failure_modes: A fourth hidden requirement makes the advertised pick-any-two catalogue incomplete.

failure_modes: One property is quietly weakened while public language continues to claim all three.

Impossibility-Bounded Guarantee Scoping

short_definition: Responds to a proven impossibility boundary by narrowing the conditions under which a guarantee is claimed instead of pretending the theorem does not apply.

distinctive_feature: The primary resolution operator changes the applicability scope and publishes an out-of-scope behavior contract.

distinct_from_parent: The parent permits many resolution operators; this variant emphasizes conditional guarantees and scope detectors.

still_same_parent_because: The original commitment set remains jointly impossible, and the intervention restores satisfiability by explicitly changing one quantified claim.

use_when: A theorem rules out a universal or unconditional guarantee under stated assumptions.

use_when: A useful conditional guarantee is still possible inside a narrower fault, input, timing, distribution, or competence region.

use_when: Consumers can detect when the system has left that region and can safely defer, degrade, or switch modes.

example: A predictor withdraws its accuracy guarantee for out-of-distribution inputs and routes them to review instead of claiming universal competence.

domain: optimization

example: A method promises performance only for a declared problem class after a no-free-lunch boundary rules out universal superiority.

failure_modes: Scope is narrowed after failures but is not observable at runtime.

failure_modes: The theorem assumptions are stripped from the public claim.

failure_modes: Out-of-scope behavior is left undefined or unsafe.

name: Normative Commitment Incompatibility Resolution

short_definition: Resolves jointly impossible duties, rights, policy promises, or governance commitments through legitimate priority, exception, compensation, and review rules.

distinctive_feature: Standing, authority, due process, burden distribution, dissent, and remedy are part of the resolution rather than external implementation details.

distinct_from_parent: The parent is domain-general; this variant adds legitimacy and distributional requirements to the choice among feasible relaxations.

still_same_parent_because: It begins with the same verified joint incompatibility and ends with a satisfiable, explicitly bounded residual commitment set.

use_when: The incompatible commitments encode value judgments or obligations rather than only technical constraints.

use_when: Different groups bear the losses associated with different relaxations.

use_when: No formal proof can by itself determine which commitment should yield.

example: A program cannot simultaneously retain a fixed appropriation, universal access, and an unchanged benefit; the authorized process chooses a change and documents who bears it.

example: Conflicting confidentiality, disclosure, and appeal commitments are scoped by case type with review and remedy paths.

failure_modes: A mathematical model is used to launder a political priority choice.

failure_modes: Affected groups lack standing in the resolution process.

failure_modes: Compensation and appeal are omitted even when the sacrifice is concentrated.

near_names:
Axiomatic Incompatibility Resolution
Inconsistent Requirement Set Resolution
Hard-Constraint Conflict Resolution
Unsatisfiable-Core Resolution
Impossibility-Aware Tradeoff Design
Guarantee-Set Reconciliation