Fairness monitoring

Selection parity, proxy strength and vulnerable-group handling

The claim under test is that this system cannot discriminate because it uses no protected characteristic. That is not something to assert; it is something to instrument. The mechanism worth worrying about is not a feature — it is the objective function. Expected value is uplift × ARPU × horizon × margin − cost, and ARPU is a term in it. Wherever income tracks geography or age, an expected-value rule inherits that correlation without anyone writing it down, and it will never appear in a feature-importance chart.

I expected this page to show a regressive result. It does not, and that is worth stating plainly. The hypothesis was that lower-ARPU groups would be systematically under-contacted because their margin at risk is smaller. In this base the effect is real but dominated: risk varies far more across groups than ARPU does, and expected value tracks risk. Prepaid subscribers carry the lowest ARPU (€8.47) and receive the highest contact rate (15.1%), because they churn at 12.7% against 3.2% for postpaid. A monitor that only reported the direction I predicted would have been useless.

Settlement type within screen

Group	Subscribers	Contacted	Observed risk	Raw ratio	Need-adjusted	Mean ARPU
rural	2,476	5.94%	4.89%	0.95	0.97	€19.01
town	2,883	5.86%	4.68%	0.94	1.00	€22.17
urban	6,297	6.24%	5.15%	1.00	0.97	€23.72

Market within screen

Group	Subscribers	Contacted	Observed risk	Raw ratio	Need-adjusted	Mean ARPU
EE	2,573	5.71%	4.90%	0.87	0.88	€22.31
LT	4,569	5.80%	5.03%	0.88	0.87	€22.32
LV	4,514	6.58%	4.96%	1.00	1.00	€22.37

Product class flagged

Group	Subscribers	Contacted	Observed risk	Raw ratio	Need-adjusted	Mean ARPU
business	1,371	0.51%	1.75%	0.03	0.22	€49.60
consumer_postpaid	7,876	4.29%	3.17%	0.28	1.00	€21.83
prepaid	2,409	15.11%	12.70%	1.00	0.88	€8.47

The gate — what happens when a check fails

A monitor that reports and never blocks is a dashboard, and a dashboard constrains nothing. The regulation asks what the operator does when a check fails. The gate is part of PolicyConfig, so it is inside the policy fingerprint: turning it off changes the recorded policy version, which makes “the gate was on” verifiable rather than remembered. Every firing is written to the same append-only log as the decisions it constrains.

Mode	What it does	Contacts	Net margin	Cost of the gate
off	monitor only	709	€-2,762	€0
block	BLOCKED — campaign not released	0	€0	€-2,762
rebalance	REBALANCED — +19 contacts to clear the 80% need-adjusted floor	728	€-2,964	€202

Rebalance adds contacts rather than removing them. The under-served group is brought up to the floor; the best-served group is untouched. Cutting the top group would satisfy the ratio by making everyone worse off — it would pass the check and help nobody, which is the standard way parity metrics get gamed.

This base cannot show the real tension, and pretending otherwise would be the easy mistake. Blocking appears to save €2,762 — but only because the offer is unaffordable at any targeting quality (see retention economics), so stopping the campaign stops a loss. Rebalancing costs €202 on 19 added contacts, which is a real but small number precisely because each marginal contact is barely worth making. On a profitable offer the ordering would reverse and the gate would have teeth. The mechanism is demonstrated; the trade-off is not.

Why a raw ratio is a screen, not a verdict

Product class fails the four-fifths screen hard — business sits at 0.03 of the best-served group. Adjusting for observed baseline risk moves it to 0.22, and the reason is mundane: business churns at 1.75% against 12.70% for prepaid. Unequal treatment of unequal need is not automatically unfair, and a monitor that cannot say so generates false alarms on exactly the groups it should be protecting. The residual 0.22 is still worth a human answering — it is a question the screen surfaces, not a conclusion it reaches.

Proxy strength — can any model feature reconstruct geography?

Each figure is the cross-validated AUC of a model trying to predict settlement type from that single model feature. 0.50 is chance.

Model feature	AUC vs settlement
`arpu_eur`	0.551
`tenure_months`	0.511
`contract_months_remaining`	0.509
`app_logins_3m`	0.503
`competitor_pressure`	0.503
`mnp_enquiry_60d`	0.502
`usage_trend_3m`	0.502
`care_unresolved_6m`	0.501

Strongest is arpu_eur at 0.551 — barely above chance, so no feature here meaningfully reconstructs where someone lives. That is a real negative result rather than an absence of testing. It would not stay true if postcode, handset model or cell-site features were added, which is the point of running it every cycle rather than once.

Vulnerable-pattern handling

Subscribers matching the low-engagement, long-tenure pattern	92
Contact rate within that group	10.87%
Contact rate elsewhere	6.04%
Share suppressed by conduct rules	14.13%

This is a proxy for the voice-first senior profile, which the persona library flags for exclusion from offer optimisation. The group is contacted more, not less — consistent with genuinely higher risk, but it is the case that most deserves a human decision rather than an automated one, and the agent panel that would capture that decision (§12.4) is not built.

What this page does not do

No protected characteristic is actually held. Settlement type is a crude stand-in. Age, gender and income are not in the estate, so the checks that matter most under the AI Act cannot be run here — only demonstrated in form.

No intersectional analysis. Single-attribute parity misses the combinations where disparities usually concentrate.

No threshold is enforced. The monitor reports; nothing blocks a campaign on a failed screen. Wiring it into the policy engine as a gate is the obvious next step and is deliberately not claimed.

Monitoring is not compliance. These are the instruments that make the question answerable. The answer still requires someone accountable to look.