A Decision Contract fits when the answer affects delivery, migration, price, policy, governance, or scarce operating capacity. Begin with the consequence and the people who carry it.
Production slots, relied-on workflows, and commercial changes make the decision risk easiest to see.
Decision risk: A costly production slot follows an unbounded popularity signal that never states who may decide or what can block delivery.
Decision risk: The company retires a relied-on path before a supported replacement exists, while a broad vote hides the cost carried by current users.
Decision risk: A preference poll is mistaken for willingness to pay or authority to set price, so the final commercial choice cannot be explained honestly.
Each row keeps the trigger, affected group, risk, method, response, expected record, template, and relevant product state together.
Choose one production direction with players, then publish what the team will build.
A game team has one event or feature slot and several feasible options. The choice needs player evidence and a visible answer, not an endless request list.
Players who meet a stated activity or ownership rule, such as completing one event in the last 90 days.
A costly production slot follows an unbounded popularity signal that never states who may decide or what can block delivery.
Use pairwise for a small set of visual or thematic concepts. Use approval when several options can be acceptable.
Publish the chosen direction by the stated date. If the result is implementation-binding, name the platform, schedule, or safety blockers that can override it.
Northwind Arena selected Sunken Observatory, published why it led the comparisons, and later recorded the event as shipped.
Define the replacement with current users before the company retires a relied-on workflow.
A product surface has a real maintenance cost or platform limit, but removing it without a replacement would transfer that cost to users.
Users who used the affected feature during a declared recent period. Do not ask the complete customer base when most people never used it.
The company retires a relied-on path before a supported replacement exists, while a broad vote hides the cost carried by current users.
Use approval so participants can mark every replacement they can accept. This shows whether one path has broad support or several paths are required.
Publish the supported replacement and retirement sequence. Keep the old path until the promised replacement reaches the stated availability level.
Northwind Reports chose a secure download centre, shipped it, and only then started the weekly-export retirement window.
Test package clarity with affected customers and publish how the result informed the final commercial decision.
The company has several viable ways to group value. An open request for lower prices cannot tell the team which package is clearest or most usable.
Account owners or administrators who understand the current product and would be affected by the package change.
A preference poll is mistaken for willingness to pay or authority to set price, so the final commercial choice cannot be explained honestly.
Use ranked Borda to compare the complete set. Mark the result as research because the ballot informs pricing; it does not delegate the final price to users.
Publish the chosen package structure, the evidence the company used, and the date when customers will see complete terms.
Northwind Cloud chose three clear packages, explained why the ranked result beat an add-on model, and published the transition terms.
Choose a workable transition with the users who must comply, while keeping fixed legal or platform constraints explicit.
A policy must change, but the company can still choose the transition sequence, support period, or cohort order.
The users or operators who must change their behavior, defined by role or current activity.
Fixed constraints remain hidden, so participants believe the ballot can choose an outcome the company cannot legally or operationally deliver.
Use approval when several transition plans could work. Participants mark every option they can complete without unacceptable disruption.
Publish the final policy, the selected transition, the fixed constraints, and the support dates by the promised response date.
Northwind Marketplace used a staged 60-day verification transition and published office hours for the seller cohorts that needed more time.
Put comparable work against one delivery slot and publish what enters the roadmap next.
The product team has more credible work than capacity. The options are already known, but a standing board does not force a decision or response.
Users who recently used the affected workflows. Use one stable eligibility rule for every option.
Raw vote counts become promises even when scope, readiness, and contractual obligations differ across the options.
Use ranked Borda when the company needs a complete preference order across comparable work.
Publish which option gets the delivery slot, what evidence changed the choice, and what happens to the remaining options.
Northwind Studio scheduled faster first-run setup, explained the technical constraint behind the choice, and left the other options unpromised.
Turn a mature technical debate into a bounded contributor choice and a maintainer response.
An RFC has several viable implementations. Discussion has produced evidence, but repeating arguments no longer moves the project toward a decision.
Contributors who meet a declared activity rule, such as a merged change or active issue during the last year.
Discussion remains open indefinitely, or a binding result hides the compatibility test that maintainers can later use as a veto.
Use approval when maintainers need the option with the broadest acceptable support. Use ranked Borda when a complete fallback order matters.
Publish the chosen implementation, the compatibility checks, and any documented blocker that overrides an implementation-binding result.
Northwind CLI selected TOML, published the compatibility test results, and recorded the format as shipped in version 3.
Choose one programme the company can operate well and publish its start date and later outcome.
A community team has several good programme ideas but enough staff time to run only one well during the next cycle.
Members who meet the stated community rule. Use the complete community only when every member can realistically join each option.
General enthusiasm allocates scarce staff time without evidence that the declared participants can or will join the programme.
Use approval so members can mark every programme they would join. The result measures acceptable participation, not abstract popularity.
Publish the selected programme, its start date, the participation target, and what the team learned after the cycle ends.
Northwind Community opened peer mentoring circles, met its first-cycle participation target, and published the continuation decision.
Templates prefill the contract but never publish automatically.
