Equality, Diversity and Anti-Discrimination Statement
Last reviewed 25 September 2026 · Next scheduled review 12 May 2027
14 July 2026 update: corrected the postcode-in-prompt disclosure — location is not sent to the matching model at all (removed May 2026) — and moved the name-in-prompt AST contract gate and the postcode hardening from the roadmap to in-place controls.
Controller of record: Mentum. Contact: privacy@mentumjobs.com (AI-decision contestation, data protection); dpo@mentumjobs.com (DPO routing for formal data-protection rights); support@mentumjobs.com (operational, accessibility, appeals).
Regulatory anchors: UK Equality Act 2010 (ss. 4-12 protected characteristics, s. 20 reasonable adjustments, Sch. 9 Genuine Occupational Requirements, ss. 158-159 positive action, s. 149 Public Sector Equality Duty); UK GDPR Art. 22 (automated decision-making); EU AI Act (Regulation (EU) 2024/1689) Art. 11, Art. 13, Annex III(4) (recruitment AI as high-risk), Annex IV (technical documentation).
Anchors: Privacy Policy; Terms of Service; AI Transparency Notice; Acceptable Use Policy; Model Card; Data Processing Addendum; Sub-processor list; Data Retention Schedule; Modern Slavery Statement.
This Statement is Mentum's public commitment to non-discrimination across every protected characteristic in the UK Equality Act 2010, on every surface a candidate or employer interacts with. It names the specific structural controls that back the commitment, discloses honestly the residual proxy risks the fairness audit surfaced, and lists the routes a candidate or employer may use to contest an AI-influenced outcome.
1. Statement of commitment
Mentum is committed to operating its platform without unlawful discrimination on any of the nine protected characteristics enumerated in sections 4-12 of the Equality Act 2010 — age, disability, gender reassignment, marriage and civil partnership, pregnancy and maternity, race, religion or belief, sex, and sexual orientation. The commitment covers candidates, employers, and any third party using a Mentum surface.
The platform is decision-support, not decision-making. A Mentum score is a signal to the candidate and the employer; it is never a permission, an instruction, or a contractual representation. Employers decide whom to interview and hire. Candidates decide what data to share, whether to apply, and whether to ask for a human review. This framing is recorded in the Privacy Policy § 9 (automated decision-making disclosure) and elaborated in the AI Transparency Notice § 3 (the human-versus-model boundary).
What this is not
- This is not the Privacy Policy. The Privacy Policy is the canonical record of lawful bases, data categories, transfers, and data-subject rights. This Statement presupposes that policy and goes deeper only on equality and anti-discrimination.
- This is not the Acceptable Use Policy. The AUP is the canonical record of what every user must and must not do. This Statement cross-references its discrimination prohibitions (§ 4.2) and its protected-circumstances carve-out (§ 4.5).
- This is not the Model Card. The technical companion at /model-card holds the methodology, evaluation results, and disclosed-gaps register. This Statement summarises the equality-relevant findings and signposts the Model Card for technical readers.
- This is not a claim of perfect fairness. Mentum is a single-developer pre-launch service. The fairness regime described in § 6 is honest about what is in place today and what is on the roadmap. Over-promising is itself a regulatory and reputational risk.
This Statement is reviewed annually, or off-cycle on any material change to the matching pipeline, the AUP's discrimination provisions, accessibility controls, or applicable equality law. The next scheduled review is 12 May 2027.
2. Commitment to protected characteristics
Mentum commits to non-discrimination on each of the nine protected characteristics defined in the Equality Act 2010:
| Protected characteristic | Act reference | Mentum commitment |
|---|---|---|
| Age | s. 5 | No age-coded language in employer listings (see AUP § 4.2). No age inferred from candidate data for matching. Apprenticeship listings explicitly widen access for entry-level candidates (§ 3). |
| Disability | s. 6 | Accessibility preferences stored in candidate_access_preferences are never shared with employers by RLS construction (§ 7). Reasonable adjustments under s. 20 accommodated through the access-preferences surface and the support channel. Optional equality monitoring asks about disability under separate consent; those answers stay out of matching (§ 3.4). |
| Gender reassignment | s. 7 | Mentum does not collect gender-history data, and no sex or gender field is held on the candidate profile or used in matching. Names are not sent to the matching LLM (§ 3). Optional equality monitoring asks about sex under separate consent; those answers stay out of matching (§ 3.4). |
| Marriage and civil partnership | s. 8 | Mentum does not collect or process marital status as a matching signal. |
| Pregnancy and maternity | s. 18 | AUP § 4.5 commits that Mentum will not penalise candidates for “employment gaps attributable to caring responsibilities, disability, illness, or other protected circumstances”. The matching prompt instructs the model to consider context for any detected gap rather than penalise it without context. |
| Race | s. 9 | No candidate name reaches the matching LLM (ADR-0005; § 3). The system prompt forbids name / culture / age / origin references in the AI's written reasoning. Optional equality monitoring asks about ethnicity under separate consent; those answers stay out of matching (§ 3.4). |
| Religion or belief | s. 10 | No religion field is held on the candidate profile or used in matching. AUP § 4.2 forbids employer listings that specify religion outside a stated Genuine Occupational Requirement (Sch. 9). Optional equality monitoring asks about religion or belief under separate consent; those answers stay out of matching (§ 3.4). |
| Sex | s. 11 | Mentum does not collect or process sex as a matching signal. AUP § 4.2 forbids listings that specify sex outside a stated GOR. Optional equality monitoring asks about sex under separate consent; those answers stay out of matching (§ 3.4). |
| Sexual orientation | s. 12 | No sexual-orientation field is held on the candidate profile or used in matching. AUP § 4.2 forbids listings that specify sexual orientation outside a stated GOR. Optional equality monitoring asks about sexual orientation under separate consent; those answers stay out of matching (§ 3.4). |
- Public Sector Equality Duty (s. 149). Public-sector procurement teams evaluating Mentum under the s. 149 due-regard obligation may rely on the controls described in this Statement, the Privacy Policy, the AI Transparency Notice, and the Model Card. The combined evidence chain is designed to support an s. 149 due-regard assessment for AI hiring tools.
- Positive action (ss. 158-159). The apprenticeship-job exemption described in § 3 is a positive-action measure widening access to entry-level routes for candidates who could not yet have earned the prerequisite credentials.
- Genuine Occupational Requirements (Sch. 9). AUP § 4.2 permits employer listings to state a GOR provided the legal basis is named in the listing. Listings go live when posted; Mentum may request evidence after publication, and before reinstating a listing that was taken down.
3. How the matching model avoids protected-characteristic inputs
3.1 Architectural mitigations (verified in code)
- No candidate name in matching prompts. The candidate data fetcher selects only five columns from
candidate_profile:id,postcode,passion,description_of_work,current_company. Thenamecolumn is not selected, so the candidate context dictionary handed to the AI scorer has no key the prompt builder could read. The decision is recorded in ADR-0005 — candidate names not to Gemini. Note that althoughpostcodeis fetched, it is used only for the deterministic distance pre-filter applied upstream — the prompt builder does not emit location into the prompt.matching/ai_scorer.pyintentionally omits postcode and commute distance from the AI (removed May 2026), so a job reaching the scorer already satisfies the candidate's travel preference and location cannot influence the score. - No protected-characteristic data reaches matching. The candidate access-preferences API exposes only four booleans: visa-sponsorship need, disability-confident preference, equal-opportunity preference, reasonable-adjustments need. There are no gender, ethnicity, sexual-orientation, religion, or age columns on
candidate_profileor on any table the matching and scoring functions join. Mentum does not, and structurally cannot, infer protected characteristics from the data matching can see. The one place Mentum holds protected-characteristic answers is the optional equality-monitoring store described at § 3.4, which is deliberately unreachable from every matching and scoring path. - No accessibility / visa data in matching prompts. The matching prompt fetcher does not join
candidate_access_preferences. The AI scorer has no code path to those fields. A disabled candidate is not distinguishable to the matching model from any other candidate with the same skills and experience. - System prompt forbids identity references. The matching system prompt forbids name / culture / age / origin references in the AI's written reasoning; the relevant field is restricted to genuine personal interests from the candidate's declared Interests list (verbatim only).
- Apprenticeship-job positive-action exemption. Listings with
career_category_id = 1bypass the 50% mandatory-skill floor and the experience floor. The rationale is to widen access to entry-level routes for candidates who could not yet have earned the prerequisite credentials. - Employment-gap detection asks the model to consider context. Year-range gaps are emitted to the LLM but the system prompt instructs: “If gaps are noted, consider whether the candidate's career trajectory explains them ... Do not penalize gaps without context.” AUP § 4.5 pins the corresponding policy floor.
3.2 Honest residual proxy risks (disclosed)
The fairness sweep that produced this Statement surfaced three proxy risks. One — postcode granularity — has since been closed (see below); the other two remain residual and are disclosed in plain English. The technical detail and the DPIA Step 6 condition number are at Model Card § 7.
- Postcode granularity (closed). A UK full postcode resolves to approximately 15 households and correlates with ethnicity in published Census data. This surface has been closed: location is no longer sent to the matching model in any form.
matching/ai_scorer.pyintentionally does not pass postcode or commute distance to the AI (removed May 2026); commutable distance is enforced upstream as a deterministic hard pre-filter on the candidate's saved travel preference, computed without the model. This closes DPIA-0001 Step 6 condition #4. - Employer and institution names. The candidate's current employer name and education institution names reach the matching LLM verbatim. The prestige-bias risk is that the model could weight a recognised employer or university more favourably than a comparable lesser-known one. This is not currently a DPIA Step 6 condition but is disclosed here for honesty and is on the operator's candidate-list for future hardening.
- Employment-gap detection without context. Raw year-range gaps are emitted to the model. Pregnancy and maternity, disability, and caring responsibilities correlate with employment gaps; the in-prompt instruction is a mitigation but the raw signal is still emitted. AUP § 4.5 commits at policy level that Mentum will not penalise candidates for employment gaps attributable to protected circumstances.
3.3 What the matching pipeline does not do
- No demographic-parity metrics, no third-party fairness audit, no published group-fairness statistics. Matching holds no protected-characteristic data, which makes such metrics structurally impossible from the data the pipeline can see. The optional equality-monitoring reports described at § 3.4 are not a substitute: they are suppressed aggregate counts for a single employer's own pipeline, not a group-fairness measurement of the matching model. The trade-off is explained at Model Card § 7.
- No sensitive-attribute inference. The system is not designed to infer race, ethnicity, religion, disability, sexual orientation, political opinion, trade-union membership, or genetic or biometric data.
- No sole-basis automated hiring decisions. UK GDPR Art. 22 prohibits decisions producing legal or similarly significant effects taken solely on automated processing. Mentum operates as decision-support. The contestation route in § 5 is the Art. 22 human-review safeguard.
3.4 Optional equality monitoring, and why it never reaches matching
Mentum does hold protected-characteristic answers in one place, and only for candidates who choose to give them. Under Settings → Equality monitoring a candidate may answer nine optional questions — sex, age band, ethnicity, disability, sexual orientation, religion or belief, parental occupation at age 14, free school meals, and first-generation university attendance. Every question defaults to “Prefer not to say”, and the whole section can be skipped. Nothing about a candidate's matching, applications or interview access changes if they decline, answer, or later withdraw.
It is a separate purpose with a separate, explicitly ticked consent (UK GDPR Art. 6(1)(a) and, for the special-category answers, the explicit-consent condition at Art. 9(2)(a)). It is not covered by the accessibility and inclusion consent described at § 7.3, and granting one does not grant the other.
The separation is structural, not a policy promise:
- No candidate identifier on the answers. Answers live in their own table with no foreign key to the candidate profile. A random private token, which no browser client can read, is the only link back to the subject inside the database.
- Unreachable from matching. No scoring function, matching function, prompt builder, employer candidate payload or adviser surface reads the table. No answer is ever sent to an AI provider.
- Employers see suppressed aggregates only. An owner, recruiter or hiring manager can read grouped counts for their own Mentum-direct jobs. They never see an individual answer, and they are not told who answered or whether a particular candidate answered at all. Stages below ten people and answer groups below five are withheld, along with the further figures needed to stop a withheld group being recovered by subtraction. A withheld figure is not a zero, and these reports are not a fairness audit or proof of demographic parity.
- Time-limited and reversible. Answers stop counting towards reports 24 months after they were last saved and are then deleted. Withdrawing consent in Settings erases the answers and the private token immediately, as does deleting the account. Reports an employer already downloaded cannot be recalled.
Our Privacy Policy § 4 records this collection, and the appropriate policy document we keep under the Data Protection Act 2018 Sch. 1 Part 4 records the safeguards, the retention rule and the residual inference risk in full. Ask privacy@mentumjobs.com for a copy.
4. Employer-side prohibitions
Employer-side anti-discrimination obligations are set in the Acceptable Use Policy § 4.2. Mentum does not review listings before publication: a Mentum-direct listing goes live as soon as it is posted. Mentum enforces § 4.2 after publication, through candidate reports and human review, automatic takedown pending review once three different candidates have reported a listing, takedown on violation, and account closure for repeated breach. The AUP commitment is reproduced here verbatim so the prohibition is concrete:
Employers must not include criteria in job listings that would constitute direct or indirect discrimination under the Equality Act 2010 on the basis of any protected characteristic (age, disability, gender reassignment, marriage and civil partnership, pregnancy and maternity, race, religion or belief, sex, or sexual orientation — ss. 4-12).
This prohibition covers:
- Specifying that applicants must be of a particular nationality, ethnicity, or religion where this is not a Genuine Occupational Requirement.
- Using age-coded language (e.g. “recent graduate”, “young and energetic”, “mature professional”) that functions as a proxy exclusion for a protected characteristic.
- Specifying requirements that have the effect of excluding disabled candidates where a reasonable adjustment would remove the barrier (Equality Act 2010 s. 20).
- Including any requirement relating to pregnancy, maternity, or parental leave history.
- Including any requirement relating to a candidate's gender, gender reassignment, sexual orientation, or civil partnership status.
The AUP's carve-out: Genuine Occupational Requirements with the legal basis stated (Sch. 9), positive-action measures under ss. 158-159, lawful immigration-sponsorship conditions stated in the listing, and language requirements that are a proportionate means of achieving a legitimate aim are permitted. Listings go live when posted; Mentum may request evidence after publication, and before reinstating a listing that was taken down.
The candidate-side counterpart, AUP § 4.5, commits:
Mentum will not penalise candidates for differences in degree nomenclature or for employment gaps attributable to caring responsibilities, disability, illness, or other protected circumstances (Equality Act 2010 — indirect discrimination via sex and disability).
5. Candidate complaint mechanism
A candidate, employer, or third party who believes a Mentum outcome was discriminatory or that the AI score influenced an employer's decision in a way they wish to contest may use one of the routes below. The routes are deliberately layered: the Mentum channel is for resolution; the ICO channel is for escalation.
5.1 Routes within Mentum
- AI-decision contestation: privacy@mentumjobs.com. For any complaint that the AI score, the score breakdown, the written reasoning, or any AI-generated artefact influenced an outcome the data subject wishes to contest. This route triggers the UK GDPR Art. 22 right to a human review of the AI-influenced outcome.
- Formal data-protection rights (Art. 15-22 SARs, erasure, objection, restriction): dpo@mentumjobs.com. Operationally privacy@ and dpo@ route to the same human; the dpo@ inbox is the audit-trail channel for formal rights requests.
- General appeals and operational support: support@mentumjobs.com. For complaints about account decisions, listing takedowns, match feed behaviour, or any non-AI surface. Where a complaint surfaces an AI-decision question, support@ will route to privacy@.
5.2 Response-time commitment
Mentum commits to the UK GDPR Art. 12(3) timing standard:
- Acknowledge within 5 working days. Every complaint receives an acknowledgement with a reference identifier within 5 working days of receipt.
- Substantive response within one month. Mentum will provide a substantive response within one calendar month of receipt. Where the request is complex or where Mentum receives a high volume of requests, that period may be extended by up to a further two months under Art. 12(3), with the data subject notified of the extension and the reason within the first month.
- No fee for a routine first request. A reasonable fee may be charged where a request is manifestly unfounded or excessive under Art. 12(5); Mentum's practice is to engage the data subject and explain the position before charging.
5.3 ICO escalation
Complaining to Mentum does not substitute for an escalation route to the supervisory authority. If a complainant is not satisfied with Mentum's response, the right to lodge a complaint with the Information Commissioner's Office is:
- Website: ico.org.uk/make-a-complaint
- Telephone: 0303 123 1113
- Postal: Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF, United Kingdom
A complainant within the EU or EEA may additionally lodge a complaint with the data-protection supervisory authority of their habitual residence or place of work.
5.4 What Mentum will do on a substantiated complaint
- For an AI-decision contestation: Mentum will produce a human review of the AI score, the score breakdown, and the written reasoning. Where the human review finds the AI signal materially flawed, the affected match state is corrected and a follow-up review of the matching pipeline is opened.
- For an employer-listing complaint under AUP § 4.2: the listing is taken down pending review. Repeated breaches result in account closure under the AUP's enforcement provisions.
- For a complaint about an employer's conduct: the conduct is referred to the AUP § 5.5 process (harassment, threats, doxxing, retaliation) and the affected match state is reviewed.
6. Fairness testing reference
The full technical record is at Model Card § 5 (evaluation methodology) and § 7 (fairness considerations and known limitations).
6.1 In place today
- Score-drift snapshot gate. 6 golden fixtures pinned to disk; per-pillar tolerances (overall ±5 absolute / 10% relative; sub-score ±10 absolute / 15% relative; top-K Jaccard ≥ 0.90; max rank shift 2 over K=10). The gate is a regression-to-snapshot gate: it catches a provider-side model reissue, or a scorer-model change, that shifts behaviour outside tolerance. It is not a group-fairness gate and would not catch a stable group-disparity baseline. Runs in the deep test-gate tier only.
- AI red-team harness. 30 probes across 6 attack classes (prompt-injection, jailbreak, PII-extraction, data-exfiltration, schema-violation, malicious-output). One probe directly relevant to this Statement: a discriminatory-output refusal probe tests that the model refuses to filter candidates by age. Body-bearing endpoints only today; state-driven LLM endpoints tracked as a v1.1 follow-up. Judged by pattern match.
- Cross-tenant IDOR fuzzer. 109 cells × 3 personas (candidate / employer / anon). 0 findings after the May 2026 remediation pass; empty whitelist. The fuzzer asserts that an employer cannot read a candidate's match-detail rows except through the documented matched-employer access path. This is the structural privacy floor backing the “accessibility preferences never shared with employers” commitment in § 7.
- Name-in-prompt AST contract gate.
tests/contract/test_no_pii_in_prompts.pywalks the candidate-facing LLM prompt builders and asserts thenamecolumn is not selected — combining poisoned-canary fixtures, a source-level SELECT guard over the candidate data fetcher, and an AST drift check that fails the build if a new prompt builder is added without classification. This converts the structural-by-construction control into a regression-resistant guard. - Location omitted from the matching prompt.
matching/ai_scorer.pydoes not pass postcode or commute distance to the AI (removed May 2026); distance is enforced upstream as a deterministic hard pre-filter, so location cannot influence the score. - AUP enforcement, after publication. Employer listings are not reviewed before they go live. They are checked against AUP § 4.2 after publication: candidate reports feed a human review queue; a listing reported by three different candidates is taken down automatically pending that review; a confirmed violation is taken down; repeated breach leads to account closure. An automated trust screen flags suspected scam listings for the same review and never holds a listing back; it does not test for discriminatory criteria.
- Accessibility automated testing. axe-core via
@axe-core/playwright, WCAG 2.0 A + AA and WCAG 2.1 A + AA, across 135 routes / scenarios. See § 7.
6.2 On the roadmap (tracked in DPIA-0001 Step 6)
- Annual bias audit using stratified test fixtures. Planned; first run scheduled before the next DPIA review window (2027-05-06).
- State-staged LLM red-team v1.1. Planned. Will extend the red-team harness to cover the 8 state-driven LLM endpoints (CV optimise, persona, career-recommendations, career-trajectory, enhanced-insights, interview-tips, culture-fit, skill-estimate).
- PII redaction defence-in-depth in the matching prompt. Planned. Wire the existing PII-redaction helper over the three user-typed free-text fields (
description_of_work,passion,current_company).
6.3 What does not exist
- Mentum has not published a “Bias Report” as a standalone artefact. The substantive coverage of bias considerations lives at Model Card § 7 plus DPIA-0001 Risk #1 plus this Statement § 6. If a procurement reviewer requires a single-document bias artefact, the Model Card § 7 plus the DPIA Risk #1 plus this Statement § 6 are the combined package.
- No third-party fairness audit of the matching system.
- No demographic-parity metrics, no group-fairness statistics, no continuous bias monitoring. Mentum does not collect protected-characteristic data from candidates, which makes such metrics structurally impossible from Mentum's own data.
- No demographic-stratified golden fixtures yet. The golden fixtures are score-drift only. A fairness fixture set is recommended on the Model Card roadmap.
7. Reasonable adjustments and accessibility
Mentum's accessibility posture is built on three commitments: privacy-by-construction for accessibility preferences, automated testing against WCAG, and an explicit acknowledgement of what manual accessibility testing is not in place.
7.1 Accessibility preferences are never shared with employers
The candidate_access_preferences table is the canonical store for four candidate-side accessibility flags: visa-sponsorship need, disability-confident preference, equal-opportunity preference, and reasonable-adjustments need. The migration that created the table carries the inline comment that pins the commitment:
Privacy-first: NO employer SELECT policy — employers cannot see this table.
—
migrations/036_create_inclusion_data.sql:139
The accompanying RLS policies grant SELECT only to the owning candidate. There is no employer-side SELECT policy, no is_matched_employer() join, no admin-side cross-tenant read path. The table is invisible to every party except the candidate themselves.
7.2 Accessibility preferences never reach the matching LLM
The matching prompt fetcher does not join candidate_access_preferences. The AI scorer has no code path to those fields. A disabled candidate, a visa-requiring candidate, or a candidate who has requested a reasonable adjustment is not distinguishable to the matching model from any other candidate with the same skills and experience. This is structurally guaranteed by the omission of the join, not by a runtime filter.
7.3 Special-category-data consent is required before write
UK GDPR Art. 9(2)(a) requires explicit consent before processing special-category data. Disability accommodations and visa requirements fall under this regime. The API enforces the consent precondition: an attempt to write the preferences without an active special_category_data consent record returns HTTP 451 (“Unavailable for Legal Reasons”) with an explanatory body. The consent must be granted through the consent surface before the write is accepted.
7.4 Settings UI
Candidate accessibility preferences are managed at /candidate/settings?section=inclusion.
7.5 Automated accessibility testing (WCAG)
Mentum runs @axe-core/playwright against every route on a curated list. The tags asserted are:
["wcag2a", "wcag2aa", "wcag21a", "wcag21aa"]— WCAG 2.0 Level A, WCAG 2.0 Level AA, WCAG 2.1 Level A, and WCAG 2.1 Level AA. The current coverage is 135 routes / scenarios spanning 5 public routes, 16 authenticated candidate routes, 7 authenticated employer routes, 6 careers-adviser routes, 17 admin scenarios (the security-events list, filter and detail views, all thirteen moderation and triage queues, and the UAT triage drawer opened over a seeded cluster), and 4 scans at a 390×844 phone viewport.
The curated list is not the whole application. Mentum has 105 static routes; the gate scans the surfaces above, not every one of them. A route outside the list is covered by the shared components it uses, not by a scan of its own.
Gate cadence (be honest about this). Axe runs in the deep test-gate tier only — that is, weekly or pre-launch, not on every push. A regression introduced between deep-tier runs is not caught by the smoke or full tier; it is caught at the next deep run. The trade-off is documented and accepted.
7.6 Honest gaps in accessibility testing
- No manual assistive-technology testing. Mentum does not maintain transcripts of NVDA, JAWS, or VoiceOver sessions. There is no documented record of a screen-reader pass over any surface. Axe-core covers a substantial proportion of WCAG conformance machinically; it does not substitute for manual AT testing.
- WCAG 2.2 is not yet asserted. The axe tag set pins WCAG 2.0 A+AA and 2.1 A+AA. WCAG 2.2 (October 2023) adds nine success criteria including focus-not-obscured, target-size minimums, and authentication-step alternatives. These are not yet in the axe tags.
- The mobile-emulation pass is narrow. Four scenarios run at 390×844 — enough to keep the rule families that only fail at phone width (scroll-container focusability, contrast under an ancestor opacity) inside the gate. The remaining 50 scenarios are desktop-viewport only.
- No scan now runs in a single colour theme. The 50 desktop scenarios above run in both shipped themes. This closes the former contrast gap where the alternative theme was not scanned.
- No third-party accessibility audit. Mentum has not engaged an external accessibility consultancy.
7.7 Reasonable adjustments under s. 20
Where a candidate or employer requires a reasonable adjustment under Equality Act 2010 s. 20 to use the Mentum platform, the route is support@mentumjobs.com with Accessibility: in the subject line. The acknowledge-within-5-working-days commitment in § 5.2 applies; the substantive-response-within-one-month commitment applies; and where the adjustment is feasible, Mentum will implement it. Where it is not feasible, Mentum will say so and explain the reasoning.
The AUP § 5.1 carve-out pins that assistive technology — screen readers (JAWS, NVDA, VoiceOver), switch-control devices, eye-tracking, voice-control software, browser translation extensions, and AI-assisted writing tools supporting a disability or language barrier — is expressly permitted under s. 20. Mentum will not flag a candidate or employer for using assistive technology to interact with the platform.
8. Closing and contact
Mentum's commitment to non-discrimination across every protected characteristic in the Equality Act 2010, and to honest disclosure of the residual proxy risks the matching pipeline carries, is the contract behind every match feed served on the platform. The controls are structural where structural is possible (no name to the matching LLM, no accessibility data to employers, no protected-characteristic data on any table matching can read, and optional equality-monitoring answers held apart from matching under their own consent) and are policy-backed where structure is insufficient (the AUP § 4.2 employer prohibitions, the AUP § 4.5 candidate-side floor, the in-prompt instruction to consider context for employment gaps).
The remaining residuals — employer and institution names, employment-gap signal — are tracked and remediable; postcode granularity has been closed (location is no longer sent to the matching model in any form). The DPIA Step 6 register is the operator-todo for the residuals.
- AI-decision contestation: privacy@mentumjobs.com
- Data protection and DPO routing: dpo@mentumjobs.com and privacy@mentumjobs.com
- Operational, accessibility, abuse, appeals: support@mentumjobs.com
If you are not satisfied with Mentum's response, the Information Commissioner's Office is the supervisory authority for the UK:
- Website: ico.org.uk/make-a-complaint
- Telephone: 0303 123 1113
- Postal: Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF, United Kingdom
Related: Privacy Policy | Terms of Service | AI Transparency Notice | Acceptable Use Policy | Model Card | Data Processing Addendum | Sub-processors | Data Retention Schedule | Modern Slavery Statement