Keedian — Scoring Criteria Reference

Impact (X axis)

Impact is calculated, not assigned. For each profile, country, and mode:

implementation_revenue_USD = sites × impl_addressable_pct × impl_avg_ticket_USD
subscription_revenue_USD   = sites × sub_addressable_pct  × ARPU_monthly_USD × 12 × horizon_years
total_impact_USD           = combination depending on selected mode

The 1–10 axis is derived via the selected normalization:

Method	What it does	When to use
`quantile`	Rank-based: spreads profiles uniformly across 1–10.	Default. Best for visual separation when profiles vary by orders of magnitude.
`log`	log₁₀ scaling. Preserves "how much bigger" without crushing small profiles.	When you want a sense of magnitude in the axis, not just order.
`linear`	Raw scaling vs the max.	Avoid unless your profiles are within one order of magnitude. Outliers crush everything.

Feasibility (Y axis)

Feasibility is a weighted composite of five 1–10 inputs. Default weights:

Input	Weight	What 1 means	What 10 means	Notes
Need perception	0.30	Profile not aware of / not open to buying.	Profile actively shopping for this.	The biggest single driver. Initial values came from XLSX Attractiveness Score × 2.
HW gap	0.25	No hardware development needed — our existing kit covers it.	Major hardware development needed before we can serve.	Inverted in scoring: high gap → low feasibility.
Similar clients exist	0.20	No references. Cold start.	Multiple referenceable customers in this profile.	Sales motion accelerator. Strong for Grocery (Chedraui), Cstore (7-Eleven), Foodservice (Outback).
BMS penetration effect	0.10	No existing BMS in this profile.	High BMS penetration.	Sign depends on mode — see below.
Sustainment upside	0.15	No legacy BMS to upgrade.	Large installed base of aging BMS that needs replacement.	Captures the recurring upgrade / sustainment opportunity beyond the new install.

Weights must sum to 1.0. The UI enforces this. Edit in Parameters.

BMS penetration — why the sign depends on mode

The same BMS penetration value can be a tailwind or a headwind depending on what you're selling:

Mode	Sign	Reasoning
`subscription_only`	positive	If the market is already instrumented, our recurring service can plug in fast. High BMS → easier service entry.
`implementation_only`	negative	If the market is already instrumented, there's less room to sell a new implementation. High BMS → smaller addressable.
`full`	mixed	The two effects partially cancel. Weighted by the impl/sub revenue split inside the profile.

Quadrants

Quadrant	What it means	Suggested action
Go now (high impact, high feasibility)	Big market we can address with current capabilities.	Prioritize go-to-market motion. Build playbooks. Allocate sellers.
Build to win (high impact, low feasibility)	Big market we can't fully address yet.	Invest in the missing capability (HW, references, productization).
Quick wins (low impact, high feasibility)	We can win here, but the market is small.	Pursue only if the references unlock bigger markets, or if cost-to-serve is very low.
Park (low impact, low feasibility)	Small and hard.	Deprioritize. Revisit when capabilities change.

The quadrant divider is the median of the visible data when quadrant_thresholds.mode is median (default). Switch to manual in scoring.yml to use fixed thresholds.

Modes (revenue filter)

Mode	What's counted in Impact	When to use
`full`	Implementation + subscription over the configured horizon (default 3 years).	Default. Strategic ranking.
`subscription_only`	Recurring revenue only. Implementation is ignored.	When evaluating recurring-revenue priority.
`implementation_only`	One-shot implementation revenue only. Subscription is ignored.	When evaluating immediate cash-impact priority.

Axis fit and quadrant thresholds

By default, the matrix axes zoom into the actual data range (with a small padding) so profiles aren't bunched into a corner. The quadrant divider is the median of the visible data. Both behaviors are configurable in scoring.yml under display.axis_fit and display.quadrant_thresholds.

Validation status

Every profile YAML carries a validation_status block listing which sections are still preliminary vs validated. When you've reviewed a profile's data and approve it, remove the preliminary: true flag at the top of the YAML and update the validation_status entries.