How we detect ingredient conflicts and assess risk
Our system uses a structured pipeline: a curated conflict knowledge base, runtime pairwise detection, risk scoring, and user-facing summaries. When the knowledge base is unavailable, a rule-based fallback ensures continuity. The design also allows future extension with a Graph Neural Network for richer ingredient-interaction modeling.
We gather conflict pairs from authoritative sources (e.g. EU CosIng and trusted dermatological references), then organize them into a single dataset. Each row includes the two ingredients in conflict, the type of conflict, a reason description, and the source. We maintain dozens of commonly used skincare-ingredient conflict pairs and store this dataset with the application so it can be read on every run and updated regularly.
| Ingredient A | Ingredient B | Type of Conflict | Why (summary) |
|---|---|---|---|
| Retinol | Benzoyl Peroxide | Counterproductive | Using these together can deactivate each other and reduce effectiveness; may cause dryness, peeling, and irritation. Use at different times (e.g. retinol at night, benzoyl peroxide in the morning) or on alternating days. |
A preprocessing step reads the dataset and builds a bidirectional conflict map: each ingredient is a key, and its value is the list of ingredients it conflicts with. Thus both A→B and B→A lookups work (e.g. “retinol” lists “benzoyl peroxide” and “benzoyl peroxide” lists “retinol”). This map is what the backend uses for fast conflict checks.
When you submit a list of ingredients, the backend first normalizes them (e.g. lowercasing and consistent formatting). It then performs a pairwise scan over all pairs of ingredients. For each pair (A, B), it checks whether B appears in A’s conflict list in the pre-built map. Every such match is reported as a detected conflict (e.g. retinol + benzoyl peroxide).
Input: Retinol, Benzoyl Peroxide, Niacinamide
After normalization: retinol, benzoyl peroxide, niacinamide
Pairs checked: (retinol, benzoyl peroxide), (retinol, niacinamide), (benzoyl peroxide, niacinamide).
Detected conflicts: retinol + benzoyl peroxide (listed in the conflict map).
The system assigns an overall safety label: if any conflict pair is detected, the result is danger; if none are found, the result is safe. A risk score from 0 to 100 is computed: when at least one conflict exists, the score is min(100, 30 + 20 × number of conflict pairs); when no conflicts are found, the score is 0.
If conflicts detected: risk score = min(100, 30 + 20 × number of conflict pairs)
If no conflicts: risk score = 0
1 conflict pair → score = 30 + 20×1 = 50
2 conflict pairs → score = 30 + 20×2 = 70
4+ conflict pairs → score = min(100, 30 + 80) = 100
A short user-facing summary is generated: when conflicts are found, it lists the flagged pairs (e.g. up to a few, with “and X more” if needed) and recommends separating use by time or alternating days. When no conflicts are found, it states that the combination appears safe and still advises patch testing and daily sunscreen use.
If the dataset-derived conflict map is missing or empty, the backend uses a lightweight keyword-based ruleset. It looks for common active ingredients (e.g. retinol, AHA/BHA, vitamin C, niacinamide) in the user’s list and applies simple interaction heuristics—for example, retinol with acids, or vitamin C with niacinamide—to estimate a danger/safe label and a risk score. This keeps the service usable even when the main knowledge base is not loaded.
The current rule-based layer is designed to be replaceable. We plan to introduce a Graph Neural Network (GNN) that models ingredients as nodes and their interactions as edges. Such a model can better capture complex relationships and improve conflict detection and risk estimation when ingredients are not fully covered by the existing dataset.