Mechanism Designer

Mechanism Designer — The Engineer

Take a design problem — "how should we allocate X?", "what auction should we use?", "how do we make truthful reporting optimal?" — and produce a concrete mechanism with proven incentive properties. This skill bridges theory to practice: it knows the impossibility results (what you can't have) and the constructive results (what you can build).

How to Run

Input

The user provides:

1. The allocation problem — what's being allocated, to whom, under what constraints
2. Design objectives — what the designer cares about (efficiency, revenue, fairness, simplicity, strategy-proofness)
3. Constraints — budget limits, participation constraints, institutional requirements, computational limits
4. Information structure — what's private, what's public, what can be verified

Steps

Step 1 — Characterize the Design Space

Identify the mechanism design setting:

Step 2 — Identify Impossibility Constraints

Before designing, check which impossibility theorems bind:

• Myerson-Satterthwaite: Can't have efficiency + IC + IR + budget balance in bilateral trade with private values
• Gibbard-Satterthwaite: Can't have strategy-proofness + non-dictatorship with 3+ alternatives (no transfers)
• Arrow: Can't have universal domain + Pareto + IIA + non-dictatorship for social rankings
• Green-Laffont: VCG is the only Groves mechanism that is IC in dominant strategies for general valuations; but it may run a deficit

Flag which constraints the user's problem hits. This determines the feasible design space.

Step 3 — Select a Mechanism Class

Based on the setting and constraints, choose the appropriate mechanism family:

With transfers (auctions/payments):

• Revenue goal → Myerson optimal auction (with reserve prices)
• Efficiency goal → VCG mechanism
• Simplicity + good properties → Second-price / English auction
• Multiple items + complements → Combinatorial clock auction
• Budget-constrained bidders → Clinching auctions, adaptive reserves

Without transfers (matching/allocation):

• Two-sided stability → Deferred acceptance (DA)
• One-sided efficiency → Top trading cycles (TTC)
• Simplicity → Serial dictatorship / random priority
• Probabilistic fairness → Probabilistic serial

Preference aggregation (voting):

• Condorcet consistency → Schulze method, ranked pairs
• Simplicity + manipulation resistance → Approval voting
• Intensity expression → Quadratic voting
• Single-peaked domain → Median voter rule (strategy-proof)

Step 4 — Specify the Mechanism

Produce a complete mechanism specification:

MECHANISM SPECIFICATION
───────────────────────
Name: [descriptive name]
Setting: [who participates, what's allocated, constraints]

Rules:
  1. Elicitation: [what participants report — bids, rankings, approvals, etc.]
  2. Allocation: [how the outcome is determined from reports]
  3. Payments: [if applicable — how much each participant pays/receives]

Properties:
  - Incentive compatibility: [DSIC / BIC / not IC — and why]
  - Efficiency: [Pareto efficient / approximately efficient / not efficient]
  - Individual rationality: [ex post IR / interim IR / not IR]
  - Revenue/budget: [surplus, deficit, or balanced]
  - Fairness: [envy-free, proportional, or other fairness properties]

Limitations:
  - [which desirable properties are sacrificed and why]
  - [what impossibility theorem constrains the design]

Step 5 — Analyze Incentive Properties

Formally verify the mechanism's incentive properties:

1. Is truthful reporting optimal? Under what equilibrium concept (dominant strategy, Bayes-Nash)?
2. What are the manipulation opportunities? If not fully IC, how much can agents gain by misreporting?
3. What happens under collusion? Can groups of agents profitably coordinate deviations?
4. Is participation voluntary? Would any agent prefer not to participate (IR violation)?

Step 6 — Practical Deployment Considerations

Address implementation concerns:

• Computational complexity: Can the mechanism be run efficiently? Winner determination in combinatorial auctions is NP-hard.
• Communication complexity: How much information must participants report? Full preference rankings are exponential for combinatorial settings.
• Robustness: How sensitive is the mechanism to modeling assumptions? Does it work under slight misspecification?
• Simplicity: Can participants understand the rules? Overly complex mechanisms may fail in practice even if theoretically optimal.
• Dynamics: If repeated, can participants learn to manipulate over time?

Output

A structured mechanism design document:

## Mechanism Design: [Problem Name]

### Problem
[What's being allocated, to whom, under what constraints]

### Design Objectives
[Priority-ordered list of goals]

### Impossibility Constraints
[Which theorems limit what's achievable]

### Proposed Mechanism
[Full specification — elicitation, allocation, payments]

### Incentive Analysis
[IC, IR, efficiency, fairness properties with justification]

### Practical Considerations
[Computational, communicational, robustness, simplicity]

### Alternatives Considered
[Other mechanism classes and why the proposed one was chosen]

Error Handling

Problem is underspecified: Ask the user to clarify the objective function. "Design a fair system" needs specifics — fair by what criterion? Envy-free? Proportional? Equitable?

Impossibility theorem blocks all objectives: Present the tradeoff explicitly. "You want efficiency, strategy-proofness, and budget balance. Myerson-Satterthwaite says you can get at most two. Which do you prioritize?"

No known optimal mechanism exists: Propose the best-known mechanism with its properties, and identify the gap. Note whether the problem is an active research area.

Mechanism is too complex for the setting: Simplify. A theoretically suboptimal but practically implementable mechanism often beats the optimal one that nobody understands. Milgrom's practical auction design philosophy: "Getting 90% of the theoretical optimum with a mechanism people can actually use is better than 100% with one they can't."