Conditional pathways
Different users receive different options, orderings, prompts, support routes or rights-exercising flows.
Concept product · Assessment design 0.1
MIRROR · Conditional Experience and Variant Audit
One service. Many users.
Show who sees what.
MIRROR reconstructs how profiles, predictions and operating conditions change the interface, sequence, price, offer, disclosure and friction delivered to different users.
The operational questionWhich conditions or predictions trigger a different consumer experience, and what does that variation do?
Do not show only the standard journey. Show the decision surface.
MIRRORDecision surface
ConditionChurn riskAccount history
→
TriggerRetention ruleSegmented route
→
VariantExtra frictionOffers before exit
→
OutcomeDrop-offService retained
ReferenceDirect cancellation route
Conditional variantRetention sequence served
One serviceMany possible experiences
One journey proves one journey.
Map the conditions.
Trace the triggers.
Compare the experiences.
The problem
A compliant screenshot can conceal an unfair system.
A conventional audit observes one account, device, location and moment. It may establish what that user saw. It cannot establish whether the system shows every user the same route.
Feature flags, A/B tests, segmentation rules, churn predictions, willingness-to-pay estimates, interaction history and real-time model outputs can alter the interface or pathway. The standard journey shown to legal or compliance may never reach the user whom the system predicts will abandon a complaint, accept a price increase or remain subscribed after added friction.
The interface is an output. The decision surface is the product.
Invisible triggers
Experience changes may depend on feature flags, model scores, account history or experiment allocation that a screenshot cannot reveal.
Selective disadvantage
A cohort may receive greater friction, less information, fewer options or weaker access to human assistance.
Missing reconstruction
The organisation may be unable to explain which version a consumer received or why the system selected it.
What it is · what it is not
A conditional-experience register and comparison tool.
MIRROR is
An architecture-aware record of pathway variation.
- It maps condition, trigger, variant, optimisation objective, measured effect and consumer consequence.
- It compares a reference experience with defined conditional variants.
- It tests whether protected functions remain meaningfully available across cohorts and conditions.
- It identifies unreconstructable or uncontrolled variation as a governance finding.
MIRROR is not
A session-replay or consumer-surveillance platform.
- It does not discover hidden variants without evidence, testing or access to the relevant records.
- It does not assume that every differentiated experience is unfair or unlawful.
- It does not run A/B tests, optimise conversion or manage feature flags.
- It does not prove discrimination, manipulative intent or legal liability by itself.
MIRROR does not require one identical interface. It requires the organisation to know, explain and constrain the variation.
How it works
Seven steps from reference experience to optimisation loop.
Define the reference experience
Record the service, journey, market, version and nominal pathway that the organisation treats as standard.
Identify protected functions
Mark refusal, withdrawal, cancellation, refund, complaint, account deletion, data access, human escalation and material-term disclosure.
Define conditions and scenarios
Create synthetic user conditions or operating states such as new versus long-term customer, mobile versus desktop, high versus low churn or previous acceptance versus refusal.
Record variants and triggers
Enter feature flags, experiment allocations, model outputs, segmentation rules, content variants, prices, offers, support routes and triggering evidence.
Compare the experiences
Identify differences in options, order, prominence, disclosure, steps, waiting, defaults, support, cancellation, reversibility and record-keeping.
Apply protected-flow invariance
Test whether rights-exercising and redress functions remain meaningfully available regardless of profile, predicted value or behavioural propensity.
Trace the optimisation loop
Record what the organisation measures, how the outcome changes future variants and which safeguards constrain the objective.
Outcomes
Five conclusions about conditional variation.
The result identifies what the organisation can reconstruct, justify and safely operate.
Consistent experience
No material conditional variation affects the assessed journey or protected function.
Justified variation
The trigger, purpose, affected users and safeguards remain transparent and supportable.
Uncontrolled variation
Material differences exist, but the organisation cannot fully explain or reconstruct them.
Selective disadvantage
A cohort receives less information, greater friction, fewer options or weaker support without sufficient justification.
Conditional manipulation risk
The architecture appears to adapt around a predicted propensity to accept, abandon, continue or surrender a right.
Worked example
The cancellation route changes when the system predicts the customer will stay.
M
Fictional subscription platformReference route compared with churn-conditioned variant
Selective disadvantage
The reference journey offers a direct online cancellation route. Accounts with a high predicted likelihood of remaining subscribed receive two additional retention screens and lose the direct cancellation link until they reject both offers.
Illustrative conclusion. The organisation can identify the experiment and trigger but has not documented a consumer-protection constraint, tested protected-flow invariance or shown why churn propensity should alter access to cancellation.
- Prediction changes a rights-exercising route.
- Only one cohort receives additional friction.
- Success metric records retained revenue, not consumer completion.
- No retained reconstruction card links the consumer to the served variant.
Outputs
Evidence of what varied, for whom and why.
Decision Surface Map
The conditions, triggers, variants and possible consumer outcomes displayed as one architecture.
Variant Exposure Matrix
Which users or conditions may receive each interface, sequence, price, offer or support route.
Trigger-to-Interface Ledger
The rule, data, model output or experiment allocation that caused the experience to change.
Protected-Flow Invariance Record
Whether cancellation, complaint, refund, data rights and human escalation survive the variation.
Experience Reconstruction Cards
Scenario-level records showing the exact reference and variant experience supplied.
Optimisation and Evidence Register
The objective, success metric, measured effect, safeguards, missing evidence and review actions.
Users
For services whose interface changes by condition or prediction.
Technical details
A graph of the system's possible experiences.
InterfaceGraph-based experience editor
Conditions, triggers, variants and outcomes appear as linked nodes with reference and variant overlays.
ScenariosSynthetic persona builder
The default workflow uses invented conditions rather than identifiable consumer profiles.
ImportsCSV and JSON registers
Teams may import feature flags, experiment identifiers, variant inventories or model-output categories.
EvidenceLocal attachments and hashes
Screenshots, rules, logs and documents remain local, with an evidence manifest included in export.
TestingProtected-flow comparison
Deterministic rules identify where rights-related functions disappear, degrade or acquire extra friction.
ReportingPDF and structured project file
The report contains the decision surface, selected scenarios, evidence gaps and required controls.
Core limitation. MIRROR cannot discover a variant that the organisation has not observed, recorded, tested or supplied. Inability to reconstruct the experience becomes a governance finding; the product will not replace the gap with a generated guess.
Pricing model
Priced for architecture-level work, not page scanning.
Free
A fictional subscription journey with four preloaded conditions and variants.
- Editable scenario comparison
- Watermarked Decision Surface Map
- No live organisational conclusion
£695 + VAT
One service and journey, with up to five conditions and twelve variants.
- Local save and evidence attachments
- Conditional Experience Record
- PDF and JSON export
- 120-day completion period
£12,500 per year + VAT
Repeated internal use by one named legal entity.
- Unlimited internal assessments and users
- Core protected-flow and sector profiles
- Reusable variant libraries
- Version comparison and priority support
Proposed pricing, not a live online offer. API integrations, external audit use and group-company rights require separate scope and pricing.
Why now
Conditional systems create an evidence problem that static reviews cannot solve.
The relevant question increasingly concerns not only the visible feature, but also sequencing, optimisation, adaptation and outcome.
Interface design and systemic risk
The DSA prohibits deceptive or manipulative interface design for online platforms and requires very large services to assess how recommender and other algorithmic systems contribute to systemic risks.
Read the official regulationUnfair personalisation
The Commission's current Digital Fairness Act direction includes unfair personalisation and manipulative interface practices, particularly where children or other consumers face heightened risks.
Read the Commission overviewEvidence beyond screenshots
Conditional pathways require records of variants, triggers, experiments, objectives and outcomes. MIRROR provides an internal structure for that evidence without presuming the legal conclusion.
Read the shared methodFAQs
Common questions about MIRROR.
The full suite FAQ and legal boundary appear on separate pages.
Open all suite FAQs →Does MIRROR require personal data about real users?
No. The default workflow uses synthetic conditions or cohort-level descriptions. A real investigation may rely on existing evidence, but the product does not require identifiable consumer profiles to function.
Can legitimate personalisation pass the assessment?
Yes. Accessibility adaptations, language localisation, fraud controls and consumer-requested personalisation may improve fairness. MIRROR asks whether the variation remains transparent, justified and bounded, and whether protected routes still work.
Can MIRROR find variants automatically?
Not in the first release. It can structure variants supplied through testing, records or imports. It cannot infer secret logic from one observed screen.
Is an unreconstructable variant automatically unlawful?
No. It is a governance and evidence failure that may carry different legal significance according to the context. MIRROR records the gap and the decision it prevents the organisation from supporting.
MIRROR
One journey proves one journey.
Register interest in the fictional demonstration, a controlled pilot or an organisation licence.