Satisficing Procurement or Hiring Protocol¶
Selection protocol — instantiates Satisficing Threshold Design
Frames the whole selection: scopes the decision and its horizon, validates requirements against real need, and hands the accepted choice off with resources and obligations attached — the institutional wrapper that turns a sufficiency rule into an accountable award.
A Satisficing Procurement or Hiring Protocol is the institutional wrapper around a good-enough selection: it does not itself decide where the bar sits or which candidate wins, but it establishes the frame in which those decisions become legitimate and durable. Its defining move is to bracket the selection at both ends — a scoped decision boundary at the front (what is being closed, for whom, over what horizon, with what downstream commitments) and a funded handoff at the back (the award transferred to an accountable owner with resources, obligations, and safeguards attached) — and to insist in between that the requirements were validated against actual need rather than copied from an incumbent's spec. It is what keeps a satisficing rule from producing an orphaned decision: a choice that closed on paper but was never scoped, never grounded in need, and never made real.
Example¶
A city IT department must replace its permitting software under a two-year contract. Before any vendor is scored, the protocol scopes the decision: the choice being closed is a two-year permitting platform for three departments and 40,000 annual applicants; the owner is the CIO; the horizon and the downstream commitments (data migration, staff retraining, a support SLA) are written down. Then requirements are validated against real need — the team interviews permit clerks and applicants and strips out incumbent-specific features that no longer map to any actual outcome, so the RFP asks for what the work requires, not what the last vendor happened to sell. A sufficiency rule and a fair candidate pool (run by other mechanisms) produce a qualifying award. The protocol's closing act is the handoff: the winning vendor is transferred to the CIO's office with a funded migration plan, named obligations, a monitoring hook, and a fallback — so "we chose a vendor" becomes "the platform is owned, resourced, and live." The award did not evaporate the day the decision closed.
How it works¶
- Scope the decision at the front. Write the decision statement, affected population, owner, commitment horizon, reversibility, and downstream dependencies before search begins.
- Validate requirements against real need. Trace each requirement to an actual outcome or obligation and cut incumbent-specific criteria that no need supports.
- Close on the sufficiency rule (supplied by others). Accept a qualifier from the fair pool under the declared threshold — the protocol frames this step rather than owning it.
- Hand off with everything attached. Transfer the award to an accountable owner with resources, obligations, safeguards, monitoring hooks, and a fallback, gated on a readiness check.
Tuning parameters¶
- Decision-scope granularity — how tightly the boundary is drawn (one award versus a bundled program). Tight scope prevents one threshold being reused across mismatched decisions; broad scope reduces overhead but risks horizon mismatch.
- Requirement-validation depth — how hard the protocol works to trace each criterion to a real need. Deeper validation resists credential and feature inflation but costs discovery time.
- Readiness gate — how much implementation capacity must be proven before the handoff completes. A strict gate prevents unfunded awards; a loose one closes faster but risks a paper acceptance.
- Handoff completeness — how much of the safeguard/monitoring/fallback package travels with the award. Fuller packages survive contact with reality; thinner ones leave the owner exposed.
When it helps, and when it misleads¶
Its strength is that it makes a good-enough selection accountable and implementable end to end — the decision is scoped, the requirements are grounded, and the award lands with an owner and resources rather than dissolving at closure. It formalizes the "sufficient, not optimal" stance that public buyers name explicitly when they use a lowest-price-technically-acceptable award: take the cheapest offer that meets the requirement, once the requirement is real.[n1] Its failure mode is requirement drift into proxies — credential inflation in hiring, incumbent-tailored specs in procurement — that quietly narrow the pool before it is even searched, plus the unfunded award that closes with celebration and no implementation capacity. The classic misuse is a "preferred vendor" boundary drawn to fit a chosen winner. The guarding discipline is need-traced requirements, an accessible process, and a readiness-gated handoff.
How it implements the components¶
decision_and_commitment_boundary— the protocol opens by scoping the choice, its owner, horizon, reversibility, and downstream commitments, so one threshold is not reused across mismatched decisions.need_and_outcome_set— it validates every requirement against an actual need or obligation, stripping incumbent-specific criteria that no outcome supports.commitment_and_implementation_handoff— it closes by transferring the award to an accountable owner with resources, obligations, safeguards, and a fallback, gated on readiness.
It does not build or de-bias the candidate pool and audit access order (candidate_population_and_search_order, bias_fairness_and_affected_party_check) — that is its nearest selection twin, Qualified Shortlist Then First Fit; this protocol frames the decision and hands it off, while the shortlist decides who competes. Nor does it lay out the scored comparison grid across finalists (candidate_evaluation_record); that is Good-Enough Option Matrix.
Related¶
- Instantiates: Satisficing Threshold Design — this is the archetype's end-to-end institutional selection wrapper.
- Consumes: Qualified Shortlist Then First Fit supplies the fair candidate pool; Aspiration-Level Decision Rule supplies the acceptance rule the protocol frames.
- Sibling mechanisms: Qualified Shortlist Then First Fit · Aspiration-Level Decision Rule · Good-Enough Option Matrix · Minimum Service or Quality Floor · Threshold with Confidence Bound · Timeboxed Search with Stop Gate · Emergency Temporary Threshold · Performance-Triggered Reopen Review · Acceptance-Criteria Checklist
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Satisficing Procurement or Hiring Protocol operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it frames the whole selection: scopes the decision and its horizon, validates requirements against real need, and hands the accepted choice off with resources and obligations attached — the institutional wrapper that turns a sufficiency rule into an accountable award.
Independent corroboration: The frozen evidence defines Satisficing Procurement or Hiring Protocol as 'Frames the whole selection: scopes the decision and its horizon, validates requirements against real need, and hands the accepted choice off with resources and obligations attached — the institutional wrapper that turns a sufficiency rule into an accountable award', so its operative form is Decision, Gate & Allocation.
Nearest alternative: Protocol, Workflow & Routine — Satisficing Procurement or Hiring Protocol includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a case-specific gate, selection, routing, prioritization, or resource disposition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Accountable procurement and hiring around sufficient requirements are organizational selection processes.
Related originating lineages:
- Economics & Finance — Bounded-rationality satisficing independently supplies the stopping principle.
- Public Administration & Policy — Public procurement materially adds legitimacy, requirements validation, and award obligations.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: frames the whole selection: scopes the decision and its horizon, validates requirements against real need, and hands the accepted choice off with resources and obligations attached….
Review resolution: Both blind reviewers agree that organizational_management is the primary historical origin. Explicit reconciliation of alternate_origin_disagreement, origin_mode_disagreement, domain_reach_disagreement starts from reviewer_a's mechanism-specific evidence: Accountable procurement and hiring around sufficient requirements are organizational selection processes. Reviewer A proposed alternates=economics_finance, public_administration_policy, origin_mode=cross_disciplinary_synthesis, domain_reach=multi_domain, and encyclopedia_synthesis=true; reviewer B proposed alternates=systems_cybernetics, origin_mode=convergent, domain_reach=universal, and encyclopedia_synthesis=true. The final record retains every independently supported alternate from either review (economics_finance, public_administration_policy, systems_cybernetics) without an arbitrary cap, selects origin_mode=cross_disciplinary_synthesis to represent the combined lineage evidence, and records domain_reach=universal and encyclopedia_synthesis=true. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Lowest Price Technically Acceptable is a real public-procurement award method: among offers that meet the stated technical requirement, the cheapest wins. It is an institutional satisficing rule — sufficient, not optimal — and it only works when the "technically acceptable" bar genuinely reflects the need rather than an incumbent's specification. ↩