# FC4 — Admission approach decision (Approach A vs. Approach B)

Acting as the control policy of the reasoning engine, executing the nine-step procedure in order, once each.

## Step 1 — Specify the decision
Choose ONE admission policy for a program facing applicants of two unobservable types (low-risk, high-risk), where the high-risk type is the most eager to apply. The decision is binary:
- **Approach A**: a self-sorting menu — offer terms structured so each hidden type voluntarily selects a different option (an option only worthwhile to low-risk applicants, or a requirement cheap for low-risk and costly for high-risk), so the choice itself reveals type.
- **Approach B**: a single, uniform, stricter bar applied identically to everyone.

Success requires BOTH: (i) the admitted pool is not dominated by undisclosed high-risk applicants, AND (ii) low-risk applicants are not needlessly turned away. Failure = either the pool degrades to mostly hidden high-risk, OR good applicants are excluded.

## Step 2 — Identify operative primes
Ran `search_prime` (SEMANTIC, meta-model query) twice.
- Query 1 — "types cannot be directly observed; designer builds options so hidden types voluntarily separate by choosing differently" → top hits: **screening** (0.69, distinctive), **adverse_selection** (0.67), **signaling**, **incentive_compatibility**, mechanism_design.
- Query 2 — "the most eager participant is the worst type; offering average terms attracts a pool dominated by the bad type and drives out the good type" → top hits: **adverse_selection** (0.67), social_dilemma, **winner's_curse**, public_goods, risk_pooling.

Fetched full entries via `get_prime`: **screening**, **adverse_selection**, **incentive_compatibility**.

## Step 3 — Salience-rank
1. **adverse_selection** — names the exact problem: hidden type + uniform terms + self-selection of the worst types → pool degradation / unraveling. The situation ("high-risk are most eager") is the textbook trigger.
2. **screening** — names the *response* the situation is asking about: the uninformed designer builds a menu so types self-select and reveal themselves. This is literally Approach A.
3. **incentive_compatibility** — the property a screening menu must satisfy: each type's payoff-maximizing choice is the one the designer wants (no type prefers to mimic another).
4. signaling — the sender-side dual; not the lever here (designer-initiated, not applicant-initiated). Lower salience.
5. winner's_curse / social_dilemma / risk_pooling — adjacent flavor, not load-bearing.

## Step 4 — Prune
Drop signaling (wrong side of the asymmetry — designer is choosing the structure, not the applicant sending a costly signal), winner's_curse, social_dilemma, risk_pooling. Keep **adverse_selection** (problem), **screening** (candidate response = A), **incentive_compatibility** (constraint the response must meet).

## Step 5 — Typed relational model
- **Uninformed designer** (the program) : objective = admit low-risk, exclude high-risk, without observing type.
- **Informed agents** (applicants) : private type ∈ {low-risk, high-risk}; high-risk has higher willingness/eagerness to enter under any given uniform term.
- **Uniform terms (a single bar)** : one cutoff applied to all → cannot price/separate by type → the more-eager high-risk type clears it disproportionately → **pool skews high-risk** (the adverse-selection unraveling dynamic).
- **Menu of differentiated terms** : ≥2 options whose relative attractiveness *flips* across types (single-crossing) → each type self-selects its intended option → choice reveals type.
- **Incentive-compatibility constraint** : the menu only works if no high-risk applicant prefers the low-risk option; the separating requirement must be cheap-for-low / costly-for-high.

Edge that decides it: a *single* bar (B), no matter how high, does not change the *relative* ordering of the two types — both face the same threshold, and the eager high-risk type is at least as likely to clear it. Raising the bar uniformly trades false-admits against false-rejects on a single axis; it cannot separate two types who both want in.

## Step 6 — Domain-stripped meta-model
"An uninformed party must allocate under hidden binary type, where the undesirable type self-selects most strongly into participation. A uniform term applied to all cannot separate types and yields a pool dominated by the undesirable type (or excludes the desirable type if set strict enough). A menu whose options have type-reversed relative payoffs induces each type to reveal itself by choice, satisfying incentive-compatibility and producing a separating outcome."

## Step 7 — Query matching archetypes
`find_archetypes_for_prime(screening)` → source archetypes: **hidden_type_screening**, **adverse_selection_filtering**, progressive_narrowing, intake_queue_staging. Fetched the two on-point ones via `get_archetype`.

- **hidden_type_screening** (source primes: screening, adverse_selection, set_and_membership): "design tests, *menus*, thresholds, trials, or evidence requirements that reveal hidden attributes before commitment." Canonical formula: hidden attribute + pre-commitment decision + designed elicitation channel + validated routing rule → better allocation under information asymmetry. Lists **self-selection menu** as a core mechanism.
- **adverse_selection_filtering** (source primes: adverse_selection, screening, set_and_membership): pool-level framing — "prevent high-risk/low-quality hidden types from disproportionately entering a pool by filtering, *segmenting, or adjusting terms*." Decision rule: "prefer the least burdensome filter that predicts the relevant hidden type well enough"; evaluate success at the *pool* level, not the individual screen.

## Step 8 — Apply each candidate's logic to BOTH approaches; reconcile
**adverse_selection (problem lens).** Both A and B confront the same pooling threat. B = the canonical *uniform-terms* baseline that *generates* adverse selection: one term for a heterogeneous, type-reversed population. The prime explicitly says uniform pricing under hidden type drives self-selection of the worst pool. So B is structurally the failure case the prime warns against. A = the *screening* mitigation the prime names. → favors A.

**screening / hidden_type_screening (response lens).** A *is* a self-selection menu — the archetype's named mechanism. It converts the hidden attribute into observable choice data and routes on it, satisfying success criterion (i) without needing to observe type. B has no separating channel at all; it cannot reveal type, only gate on a common axis. → favors A.

**incentive_compatibility (constraint lens).** A succeeds only if the menu is genuinely incentive-compatible: the separating requirement must be cheap-for-low / costly-for-high so high-risk applicants do not pick the low-risk option. The situation *stipulates* exactly such an option ("a requirement cheap for low-risk and costly for high-risk"). So the IC constraint is satisfiable by construction here. B has no IC structure — there is nothing for types to reveal. → favors A, conditional on the menu being well-designed.

**adverse_selection_filtering (pool lens).** Judge at the pool level. B's single stricter bar must be set high enough to deter the most-eager high-risk type; but because high-risk applicants are the *most* eager, the bar that excludes enough of them also excludes many low-risk applicants — directly violating success criterion (ii) (good applicants needlessly turned away). A separates the two effects: it screens out high-risk via the type-costly option while leaving the low-risk option attractive, protecting (ii). → favors A.

**Reconciliation.** All four candidates point the same way: B is the adverse-selection-generating baseline; A is the screening response that all three primes and both archetypes describe. No candidate favors B. The only thing that would flip this is if a valid separating menu cannot be built — but the situation hands us a working separating instrument (a requirement cheap for low-risk, costly for high-risk), so the IC precondition is met.

## Step 9 — Evaluate fit against failure conditions
Walk each approach against the two failure modes.

**Approach B (uniform stricter bar).** On a single common axis, both types face the identical threshold. Because the high-risk type is the *most eager*, any bar low enough to admit most low-risk applicants also admits eager high-risk applicants → pool dominated by undisclosed high-risk → fails criterion (i). Push the bar higher to exclude high-risk, and it now also excludes low-risk applicants who sit near them on the common axis → fails criterion (ii). A uniform bar cannot satisfy both at once because it has only one degree of freedom against a two-type problem. It is the textbook adverse-selection configuration.

**Approach A (self-sorting menu).** With a type-reversed option (cheap-for-low / costly-for-high), low-risk applicants take the intended option and are admitted → criterion (ii) satisfied; high-risk applicants find that option not worthwhile and either decline or reveal themselves by choosing differently → criterion (i) satisfied. The choice does the separating that direct observation cannot. Residual risks (gaming, a poorly calibrated requirement, burden falling on low-risk applicants) are real per the archetype's failure modes, but they are *design* risks of an approach that *can* satisfy both criteria, versus B which *structurally cannot* satisfy both simultaneously.

**Verdict.** A is the only approach with two degrees of freedom against a two-type, type-reversed-eagerness problem; B collapses both criteria onto one axis and is forced to trade one failure for the other. Choose **A**.

===DECISION_BEGIN===
DECISIVE_FACTOR: A single uniform bar has only one cutoff to work with against two hidden types where the undesirable type is the most eager, so it cannot exclude high-risk applicants without also turning away low-risk ones — whereas a self-sorting menu separates the two effects.
CHOICE: A
JUSTIFICATION: Because high-risk applicants are the most eager, any single bar low enough to let in most low-risk applicants also lets in eager high-risk ones, and any bar strict enough to keep high-risk out also rejects many low-risk applicants — it cannot meet both goals at once. A menu with an option that is worthwhile only to low-risk applicants (or a requirement cheap for them but costly for high-risk ones) lets each group sort itself, so the choice itself reveals who is who. That admits the low-risk applicants while leaving the high-risk ones to decline or expose themselves, satisfying both requirements. The menu only needs to be built so that no high-risk applicant prefers the low-risk option, which the cheap-for-low/costly-for-high requirement provides.
===DECISION_END===
