BiasLens is designed to help organisations distinguish what their evidence demonstrates, what represents a credible risk, what remains emerging, and what has not been established.
This note explains the public methodology principles behind BiasLens. It is not legal advice, a conformity assessment, or a substitute for formal sector-specific or jurisdiction-specific review.
BiasLens assesses a defined AI-enabled system, workflow or decision process. The assessment boundary includes the purpose of the system, the decision context, available evidence, affected groups, controls, oversight and material unknowns.
Architectural principle: systems, not people. BiasLens is not designed as employee monitoring, productivity surveillance or individual scoring.
The BiasLens bias taxonomy is grounded in Friedman and Nissenbaum’s peer-reviewed, vendor-independent academic work on bias in computer systems. BiasLens uses the categories preexisting bias, technical bias and emergent bias as a transparent foundation for examining where bias pathways may arise.
BiasLens also uses the operational term Bias Drift for material change over time. That term is BiasLens terminology aligned to the problem of emergent bias; it is not presented as wording from the 1996 paper.
A serious potential harm does not automatically mean the available evidence is strong. BiasLens keeps those concepts separate so that concern is not mistaken for proof.
“Not sure” is kept distinct from “No”. Missing documentation, unclear vendor claims and unknown affected-group evidence remain visible as uncertainty rather than being converted into reassurance.
This is deliberate: a known unknown is a governance question that can be assigned, investigated and tracked.
BiasLens may use outcome comparisons and fairness measures where the underlying data is appropriate. A disparity or disparate-impact ratio is treated as a signal for investigation, not a determination of causation or unlawful discrimination.
The determination ladder is: outcome difference → evidence; possible concern → finding; cause → requires investigation; unlawful discrimination → legal determination.
BiasLens applies conservative minimum-sample guardrails to reduce false certainty and privacy risk. Current product methodology uses approximately 30+ observations for more reliable interpretation, treats smaller samples as indicative, and avoids reporting very small groups where privacy or statistical validity is compromised.
These are platform methodology thresholds, not statutory thresholds or legal safe harbours.
BiasLens is designed as a rule-based, traceable assessment engine. Where a classification is generated, the intended evidence trail records the triggering rule, rationale, framework reference where applicable, confidence or evidence status, limitations and recommended next action.
Traceability improves reviewability; it does not guarantee that every regulator, court or external reviewer will accept a conclusion.
BiasLens treats accessibility as an evidence question. A demonstration of one keyboard or screen-reader pathway is not the same as comprehensive accessibility testing, validation or WCAG conformance.
Assessments should distinguish implemented features from independently tested evidence and formal conformance claims.
A BiasLens engagement starts with one system. Evidence is inventoried, claims and unknowns are separated, possible bias pathways are examined, fairness analysis is used only where appropriate, and findings are documented with limitations and next actions.
