Overview
Matching strategies control how Experio identifies duplicate or related entities across different data sources. When the same person, project, or organization appears in multiple documents, matching strategies determine whether they should be merged into a single entity or kept separate. Navigate to Model & Define > Matching Strategies.Strategy Types
Default Strategy
The default strategy applies to all entity types unless overridden. It defines the baseline matching behavior for your entire knowledge graph.Entity-Specific Strategies
Create custom strategies for specific entity types that need different matching rules. For example, person names may need fuzzy matching, while project codes need exact matching.Configuration Sections
Each matching strategy has four configuration areas:1. Matching Methods
Enable and weight different matching algorithms:
Each enabled method has a weight slider (0 to 1) that controls its relative importance in the overall match score.
2. Filters
Apply additional constraints to matching: Temporal Filter:- Max Distance (Days) — Maximum time difference between entities (default: 1825 / 5 years)
- Penalty Per Year — Score reduction per year of difference (default: 0.1)
- Date Attribute Names — Which entity attributes contain dates
- Parent Entity Types — Limit matching to entities with specific parent types
- Relationship Types — Consider only entities connected by specific relationships
3. Normalization
Preprocessing steps applied before matching:4. Thresholds
Define confidence levels that determine how matches are handled:
Matches below the Human Review threshold are treated as distinct entities.
Creating Entity-Specific Strategies
- Click Create New Strategy
- Select the entity type this strategy applies to
- Configure matching methods, filters, normalization, and thresholds
- Save the strategy
Resetting to Defaults
Each strategy section can be reset to default values using the Reset option. This is useful if experimental changes produce poor results.Asking the copilot
The Admin Copilot has a page pack for this page. Open it with the Copilot button or ⌘J. It knows the saved ontology, the other knowledge-model pages and the files you attach in the chat (see The knowledge-model copilot). It reads every strategy, including one you have open with unsaved edits, and can explain them, check them, and propose changes as a card. A card changes one strategy:
A card never changes a strategy’s entity type, and an edit card never deletes a strategy: a delete is
a card of its own, which you confirm (see
Re-validating, reviewing and deleting a strategy).
When a strategy’s entity type is gone from the ontology, the fix is a new strategy for the right type,
which a card can stage; you then delete the old one, or ask the copilot to propose that delete.
A new strategy starts from the page’s defaults (Exact 1, Fuzzy 0.8, Vector 0.7; thresholds
0.90 / 0.70 / 0.50; both filters off), and the card lists only what it changes from them.
A strategy belongs to an entity type, not to an artifact type. When you ask for a strategy for an
artifact type, the copilot reads the entity types its documents become and makes the card for the one
that fits what you want to match. It says which one it chose, and that the strategy applies to every
node of that entity type, whatever document it came from. It asks which one only when several fit
equally. A strategy affects only entity types set to Create or Match or Match Only (see
Artifact Types): when none of the artifact type’s entity types is, the
copilot tells you so and makes no card.
A card that changes the temporal filter and leaves it on fills any value left empty with the page’s
default, as the page’s switch does (the card names each one): 1825 days, 0.1 per year, and no date
attributes.
Every card is checked on the server before you see it, without saving anything. The page’s Save doesn’t
check the values, so the copilot does:
- each threshold is between 0 and 1, and they are in order: Human Review ≤ LLM Disambiguation ≤ Auto-Match;
- every enabled method has a weight between 0 and 1;
- the date attributes, parent entity types and relationship types a filter names are in the saved ontology. A name the ontology lacks points the copilot to the ontology change first; for a saved strategy, the change is kept (no card yet) and proposed after you save the ontology;
- when the change leaves no method enabled, the temporal filter on with no date attribute, or the relationship filter on with nothing to filter on, the card carries a warning you acknowledge before Apply.
- For a new strategy: Save first creates the strategy for its entity type (with the page’s defaults,
and
nameas its required attribute), then saves the card’s values. - Save rewrites the normalization rules from the page’s five switches, so any other saved normalization key is dropped.
- Save adds
relationship_filterto the enabled strategies, or takes it off, to follow the relationship filter switch.
Applying a card
- Every card for a saved strategy is checked against that strategy as saved, even one made on this page. It is refused once the strategy has been saved again since the card was made (This matching strategy was saved since this was proposed — ask the copilot again.), or once the ontology has (The ontology was saved since this was proposed — ask the copilot again.).
- Apply opens that strategy in edit mode with the card’s values (Applied to the strategy — nothing is saved until you click Save); a weight or threshold of 0 shows as 0. Click Save Changes to keep them. If the strategy is open with unsaved edits, Apply asks first, because the card replaces them.
- A card that stages a new strategy adds it to the page marked New — not saved yet. Create Strategy creates it and saves the card’s values. While a new strategy is staged, the copilot makes no new-strategy card: it asks you to click Create Strategy or Cancel on the staged one first. Apply on a new-strategy card made earlier asks before it replaces the staged one.
- Undo on the card puts the strategy back as it was (or closes it), until you edit on top of the applied change.
Re-validating, reviewing and deleting a strategy
Ask the copilot to re-validate a strategy, mark it reviewed or delete it, and it makes a page-action card for this page, from any knowledge-model page. On this page, Apply opens a confirmation, and only your own click on its confirm button performs the action (see Page-action cards). A strategy is named after its entity type, as for the other cards.- Re-validate is offered when the strategy’s status is not valid, and Mark reviewed when it is stale or pending review. A strategy a re-check would leave as it is gets no card.
- Delete strategy is destructive. The confirmation lists what goes and what changes, from the strategies as saved now: the strategy’s own settings go with it, and from the next ingestion on its entity type is matched with the next strategy in line (a strategy for that type bound to no artifact type, else the global default, else the matcher’s built-in values). Nodes already in the graph are not re-matched. For a strategy bound to no artifact type, the confirmation also names the bound strategies of the same type that keep their own, and says when ingestion does not use the strategy today, so that matching does not change. It also says whether this page can create the strategy again: it creates strategies bound to no artifact type only.
- The global default strategy gets no delete card.
- While a strategy is open with unsaved edits, a delete card for it is refused: save or discard the edits first, as the page’s own Delete is hidden while you edit.
- After you confirm a delete, the list refreshes and the strategy is gone. The card is refused if the strategy was saved or its status changed since it was made, and, for a review card, if the ontology was saved since.