We build Agents. You build the Future.
● Public sector offer — Data qualityData matching: the probable duplicates, the criteria visible
Two business databases often describe the same members of the public with different spellings. Your agent matches those records, presents the probable correspondences with the criteria that ground them and leaves the merge to your decision. Hosted in France: the public's data stays within your administration. No merge is applied automatically — a confused identity has lasting consequences.
Updated on
Deployed in a few weeks
Data matching · hosted in France
Fictional simulation — not a client result
Match these two databases and flag the duplicates.
Correspondences established with, for each, the matching criteria used: name, date of birth, address, file reference.
The correspondences are ranked by how far the criteria agree.
No merge is applied: every pair is presented for approval.
🔗 Sourced · records from both databases, criteria shown
The correspondences are ranked by how far the criteria agree.
No merge is applied: every pair is presented for approval.
🔗 Sourced · records from both databases, criteria shown
Merge the ones that agree perfectly.
I can prepare them as a batch, with the detail of the agreeing criteria for each.
The merge itself remains your act: confusing two members of the public's identities has lasting effects on their rights.
✎ Support · batch prepared, merge decided by you
The merge itself remains your act: confusing two members of the public's identities has lasting effects on their rights.
✎ Support · batch prepared, merge decided by you
Data hosted in France · sovereign model as an option
Databases hosted in France
Hosted in FranceAI model called at its publisher, except with the Sovereign model option
Public's data protected
GDPR & AI Act: governed deploymentTraceability & human oversight
TurnkeyDesigned, installed and operated for you
Your data department decidesThe agent carries out what you have authorised
For an organisation established outside the European Union, the law of its own country applies; at its request, we put equivalent safeguards in place (human review before any action, a log of the criteria, information for the people concerned).
✦ In brief
A Blue Lemon Agent matching agent cross-checks your business databases and presents the probable correspondences with the criteria that ground them — name, date of birth, address, reference — ranked by how far they agree. No merge is applied automatically. Data hosted in France; the AI model is called at its publisher, except with the Sovereign model option. With the 100% Sovereign package, the public's data stays with you, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
100%
hosted in France in the target architecture
0
transfer outside the EU with the Sovereign model option (target architecture)
3
data quality uses ready to deploy
0
decision with a legal or significant effect taken by an agent
These figures describe our offer, not results measured at a client. How large the gain is on your number of databases matched and their size is confirmed by a pilot.
Indicative estimate, to be confirmed by a pilot on your real files (general terms of sale, article 4).
Pricing
One package, one agent
A data matching agent (cross-checking, criteria, batches to approve), installed and operated for you.
Agility
Setup + controlled subscription
5,545 € incl. VAT setup
then 380 € incl. VAT/month — you invest at installation and pay a reduced subscription. Ideal for keeping the cost under control over time.
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Hosting in France, a dedicated and isolated resource
The simplest
Serenity
All inclusive, no setup fee
685 € incl. VAT /month
all inclusive, immediate start. No upfront investment: a single subscription. Ideal for starting quickly and simply.
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Hosting in France, managed end to end
100% Sovereign
On site, you own it
8,011 € incl. VAT setup
then 495 € incl. VAT/month · + hardware from 2,989 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Included in the package: hosting and AI consumption up to the volume of your capacity tier, in documents, exchanges, tokens and storage; beyond that, re-invoiced at real cost with no margin, tracked in your client area as usage statements are issued. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices include VAT at 20%: as a public body that is not VAT-registered, you cannot reclaim it.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting for the package chosen, in France by default, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Use cases
What does the agent actually do?
One agent, several pieces of data quality work. The agent carries out by itself what you authorise it to do; no merge is applied automatically, it stays your decision.
Included in your agent
The 3 capabilities essential to this promise are included, at no extra cost.
From 380 € incl. VAT / month
Matching across databases
Cross-checks the records in your business databases and reference data.
Documented criteria
Shows the agreeing criteria and how far each pair agrees.
Batches prepared to approve
Groups the correspondences by level to speed up approval.
Controls and safeguards
These 3 controls are built into the agent: they frame what it does, whatever plan you pick. They are not chosen and are not added to your order.
Human validation, exceptions and escalation
Status, safe closure and audit trail
Explain assumptions, uncertainties and the limits of the analyses
What the agent must be connected to
This connection is required for the agent to work. It concerns your information system and is scoped during the audit.
Reconcile controlled sources with data quality and lineage
Does your need fall outside this?
Build your agent
In 30 minutes we identify the agent that will give your staff the most time back — without oversizing the project.
Demonstration
See the agent at work
5 everyday situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data. The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds. The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
Data matching · hosted in France
Fictional simulation — not a client result
Four flags this morning across your files.
· One item of equipment is listed in two files with two purchase values. The gap is €12,400, and the accounts carry the lower one.
· Two records share an address, a date of birth and two spellings of the same surname. They will not be merged — I explain why below.
· A grants file and a contracts file disagree on 9 amounts. Both were updated, on two different dates.
· 412 rows in one file have no counterpart in the other. That is not an anomaly: the two files do not cover the same thing, and nobody had written that down. morning-watch_4-flags.pdf4 flags · 1 scope to write down
⛓ Source · asset register, accounts file, grants file, contracts
· One item of equipment is listed in two files with two purchase values. The gap is €12,400, and the accounts carry the lower one.
· Two records share an address, a date of birth and two spellings of the same surname. They will not be merged — I explain why below.
· A grants file and a contracts file disagree on 9 amounts. Both were updated, on two different dates.
· 412 rows in one file have no counterpart in the other. That is not an anomaly: the two files do not cover the same thing, and nobody had written that down. morning-watch_4-flags.pdf4 flags · 1 scope to write down
⛓ Source · asset register, accounts file, grants file, contracts
The two similar records — do you merge them?
No. Never, and it is the rule that holds up everything else.
What agrees: same address, same date of birth, two close spellings of the same surname. Three strong signals.
What does not agree: two different first names, and two files opened four years apart on two unrelated schemes.
The most likely explanation, and it is ordinary: two people from the same family at the same address, born on the same day of different years — or the same day, which happens. A merge here would mix two lives into one record.
What that would cost: entitlements computed on two people's income, a medical or social history attributed to the wrong one, and a record nobody can separate again — because nothing says any more which line belonged to whom.
What I do instead: I show them side by side, with what agrees and what diverges, and an officer decides in thirty seconds with an identity document from the file. 2-records_what-agrees-and-diverges.pdf3 agreements · 2 divergences · no merge
⛓ Source · 2 records, 3 agreeing signals, 2 diverging signals
What agrees: same address, same date of birth, two close spellings of the same surname. Three strong signals.
What does not agree: two different first names, and two files opened four years apart on two unrelated schemes.
The most likely explanation, and it is ordinary: two people from the same family at the same address, born on the same day of different years — or the same day, which happens. A merge here would mix two lives into one record.
What that would cost: entitlements computed on two people's income, a medical or social history attributed to the wrong one, and a record nobody can separate again — because nothing says any more which line belonged to whom.
What I do instead: I show them side by side, with what agrees and what diverges, and an officer decides in thirty seconds with an identity document from the file. 2-records_what-agrees-and-diverges.pdf3 agreements · 2 divergences · no merge
⛓ Source · 2 records, 3 agreeing signals, 2 diverging signals
How did you spot all that? And who do you tell?
I continuously compare the files you have opened to me: what they describe in common, where they diverge, and what one holds and the other does not.
Routing follows the nature of the gap: a value gap goes to the department owning the reference file; two close records to an officer who can open an identity document, never to a dashboard; amount divergences to both departments, with both update dates; the 412 rows to the head of service, once.
With a chase: 7 days on everything, except what feeds a financial statement under way — 24 h in that case. Then a monthly summary: by type of gap and by pair of files, never by resident.
What this comparison has already produced: a €12,400 gap on one and the same asset raised with the department that owns the reference file before the accounts are closed, nine divergent amounts between grants and agreements presented with both their update dates, 412 rows explained — the two files do not cover the same scope, and that is now written down —, and two close records set side by side with what matches and what does not.
What that gives the service from tomorrow: financial statements that are true, and an officer who decides in thirty seconds on a pair of records instead of reworking two databases by hand. Merging stays their decision, and that is what protects the resident: two lives mixed into one file cannot be pulled apart again, because nothing says any longer which row belonged to whom. I hand that decision back fully worked — matching criteria, diverging criteria, level of match, and the identity document open at the right place. The day you want me to apply the merges myself above a level you set, you give me the mandate: written, bounded to that level, dated, withdrawn on a word. Residents' data never leaves the administration: I compare what you open to me, database by database, and every comparison is logged.
The next step is ready: the pairs are grouped by level of match, the safest first, so validation can move in batches. Tell me which level you want to handle first.
✎ Proposal · watch and chases to be configured — you set the thresholds
Routing follows the nature of the gap: a value gap goes to the department owning the reference file; two close records to an officer who can open an identity document, never to a dashboard; amount divergences to both departments, with both update dates; the 412 rows to the head of service, once.
With a chase: 7 days on everything, except what feeds a financial statement under way — 24 h in that case. Then a monthly summary: by type of gap and by pair of files, never by resident.
What this comparison has already produced: a €12,400 gap on one and the same asset raised with the department that owns the reference file before the accounts are closed, nine divergent amounts between grants and agreements presented with both their update dates, 412 rows explained — the two files do not cover the same scope, and that is now written down —, and two close records set side by side with what matches and what does not.
What that gives the service from tomorrow: financial statements that are true, and an officer who decides in thirty seconds on a pair of records instead of reworking two databases by hand. Merging stays their decision, and that is what protects the resident: two lives mixed into one file cannot be pulled apart again, because nothing says any longer which row belonged to whom. I hand that decision back fully worked — matching criteria, diverging criteria, level of match, and the identity document open at the right place. The day you want me to apply the merges myself above a level you set, you give me the mandate: written, bounded to that level, dated, withdrawn on a word. Residents' data never leaves the administration: I compare what you open to me, database by database, and every comparison is logged.
The next step is ready: the pairs are grouped by level of match, the safest first, so validation can move in batches. Tell me which level you want to handle first.
✎ Proposal · watch and chases to be configured — you set the thresholds
Fictional simulation — not a client result
How do you decide two rows describe the same thing?
On named signals, and I give you each one in detail.
What carries weight: a shared identifier — the safest signal, and the only one sufficient on its own; a combination of fields improbable by chance; a cross-reference, where one row cites the other.
What carries almost none: a name alone, an address alone, a date alone. Two people can share any one of those fields without being the same person.
What I produce for each match: the fields that agree, the fields that diverge — given with equal care — and what it would take to decide.
The level of agreement I produce for every pair, and it is named rather than scored: "shared identifier", "improbable combination", "cross-reference", "weak signal alone" — and the matches arrive grouped by level, ready to approve in batches. Why a name and not a percentage: "87%" does not say what is missing, and an officer who sees 87% approves; an officer who reads "two different first names" opens the file. The "shared identifier" batch is approved in one action; the pairs with a divergence are looked at one by one.
Across 18,400 rows compared: 1,240 matches proposed, 96 of them with at least one divergence — those 96 are what matters. matching_18400-rows.pdf1,240 matches · 96 with a divergence
⛓ Source · 18,400 rows, 2 files, the department's matching rules
What carries weight: a shared identifier — the safest signal, and the only one sufficient on its own; a combination of fields improbable by chance; a cross-reference, where one row cites the other.
What carries almost none: a name alone, an address alone, a date alone. Two people can share any one of those fields without being the same person.
What I produce for each match: the fields that agree, the fields that diverge — given with equal care — and what it would take to decide.
The level of agreement I produce for every pair, and it is named rather than scored: "shared identifier", "improbable combination", "cross-reference", "weak signal alone" — and the matches arrive grouped by level, ready to approve in batches. Why a name and not a percentage: "87%" does not say what is missing, and an officer who sees 87% approves; an officer who reads "two different first names" opens the file. The "shared identifier" batch is approved in one action; the pairs with a divergence are looked at one by one.
Across 18,400 rows compared: 1,240 matches proposed, 96 of them with at least one divergence — those 96 are what matters. matching_18400-rows.pdf1,240 matches · 96 with a divergence
⛓ Source · 18,400 rows, 2 files, the department's matching rules
And what do we do with the 96?
We handle them by hand, and that is very few.
What they represent: 96 cases across 18,400 rows, half of one per cent. At two minutes each, that is three hours — once, and the backlog is cleared.
What I did for those three hours: each case arrives with the document from the file that would settle it, where one exists. On 74 of the 96 it already exists: an identity document, a tax notice, a deed. The officer opens it, decides, moves on.
On the other 22 the document is not in the file, and I say so rather than proposing anyway. Those 22 need a call or a letter.
What matters in that figure: it is not that the tool finds 1,240 matches — it is that it brings the human decision down from 18,400 rows to 96 cases, 74 of which settle with a document already there. 96-cases_74-with-the-document.pdf96 cases · 74 settleable · 22 to document
✎ Support · 96 cases prepared — 74 with the document that settles it
What they represent: 96 cases across 18,400 rows, half of one per cent. At two minutes each, that is three hours — once, and the backlog is cleared.
What I did for those three hours: each case arrives with the document from the file that would settle it, where one exists. On 74 of the 96 it already exists: an identity document, a tax notice, a deed. The officer opens it, decides, moves on.
On the other 22 the document is not in the file, and I say so rather than proposing anyway. Those 22 need a call or a letter.
What matters in that figure: it is not that the tool finds 1,240 matches — it is that it brings the human decision down from 18,400 rows to 96 cases, 74 of which settle with a document already there. 96-cases_74-with-the-document.pdf96 cases · 74 settleable · 22 to document
✎ Support · 96 cases prepared — 74 with the document that settles it
Fictional simulation — not a client result
The equipment with two values — which is correct?
The one backed by a document, and there is only one.
The two values: the asset register shows €34,200, the accounts file €21,800. A gap of €12,400.
What I looked for: a purchase document attached to either. The invoice exists, it is attached to the accounting line, and it shows €34,200.
What that means: the correct value is in the asset register, and the accounting line carries the wrong one despite holding the invoice. That is the opposite of what one would expect, and precisely why the document had to be opened rather than assumed.
What gets signed, and why: correcting the accounting line. A corrected asset value changes a depreciation and a balance sheet — it belongs to the accountant, with the invoice in front of them, and it carries their name. The work itself is done: the gap is established on documentary evidence, and I hand them the depreciation recalculated over the remaining life, next to the old one.
What I prepared: both lines, the invoice, and the 6 other items in the same state that I found while checking this one. 7-items_value-gap.pdf7 items · document opened for each
⛓ Source · asset register, accounts file, attached purchase invoice
The two values: the asset register shows €34,200, the accounts file €21,800. A gap of €12,400.
What I looked for: a purchase document attached to either. The invoice exists, it is attached to the accounting line, and it shows €34,200.
What that means: the correct value is in the asset register, and the accounting line carries the wrong one despite holding the invoice. That is the opposite of what one would expect, and precisely why the document had to be opened rather than assumed.
What gets signed, and why: correcting the accounting line. A corrected asset value changes a depreciation and a balance sheet — it belongs to the accountant, with the invoice in front of them, and it carries their name. The work itself is done: the gap is established on documentary evidence, and I hand them the depreciation recalculated over the remaining life, next to the old one.
What I prepared: both lines, the invoice, and the 6 other items in the same state that I found while checking this one. 7-items_value-gap.pdf7 items · document opened for each
⛓ Source · asset register, accounts file, attached purchase invoice
And the 9 amounts that disagree between grants and contracts?
Both files are right, on two different dates.
What I looked at: the last update date of each row. The 9 divergences correspond to 9 variations signed between March and June. The contracts file took them in; the grants file stayed on the original amounts.
So it is not a keying error: it is one file that follows variations and another that never receives them. The problem is the circuit, not the data.
What that produces today: statements of grants paid are drawn up on pre-variation amounts. The cumulative gap is €47,600, running both ways.
What I propose: flagging each signed variation to the department holding the second file — and not copying the amounts across myself. A file fed by a tool without anyone knowing where the value came from is a file nobody checks any more. 9-variations_47600-eur.pdf9 variations · 2 files · cumulative gap
✎ Proposal · flagged when a variation is signed — no automatic copying
What I looked at: the last update date of each row. The 9 divergences correspond to 9 variations signed between March and June. The contracts file took them in; the grants file stayed on the original amounts.
So it is not a keying error: it is one file that follows variations and another that never receives them. The problem is the circuit, not the data.
What that produces today: statements of grants paid are drawn up on pre-variation amounts. The cumulative gap is €47,600, running both ways.
What I propose: flagging each signed variation to the department holding the second file — and not copying the amounts across myself. A file fed by a tool without anyone knowing where the value came from is a file nobody checks any more. 9-variations_47600-eur.pdf9 variations · 2 files · cumulative gap
✎ Proposal · flagged when a variation is signed — no automatic copying
Fictional simulation — not a client result
A pair this morning ticks the strongest signal in my rule and contradicts it from end to end — and it has not been filed into a box for that.
What I see: two rows carry the same resident identifier — the only signal that is enough on its own in my rule. And no other field agrees: two unrelated names, two addresses in two different towns, two dates of birth eleven years apart.
The rule to apply here has not yet been defined: my rule says a shared identifier is enough to match, and it assumes the identifier is unique. Here it is uniqueness that is missing, not agreement. So I have matched nothing — and both records are intact.
Three ways forward. Hold the match on the identifier, as the rule says: mechanically compliant, and you bring together two records sharing neither name, nor address, nor date of birth. Set the pair aside and treat the two rows as distinct: both records are preserved, and the duplicate identifier stays in your files with nobody knowing. Leave the two rows separate and flag the conflicting identifier to the department that issues them: the records stay intact and the cause is handled where it sits, at the cost of one more flag to look into.
I recommend the third. A wrong merge mixes two lives into one record, and it is the hardest fault to undo: here the risk is simply not taken, and the real subject is not a match — it is an identifier issued twice, which is a reference-data question.
You can also give me another rule of your own — for instance: a shared identifier only counts as a strong signal if at least one second field agrees, and it becomes a reference-data flag otherwise.
Shall I remember it for the next cases? Across the 18,400 rows compared, 11 identifiers are carried by two rows with no other field in agreement. If you approve the rule, I will handle them that way instead of sending them up one by one, and I will give you the count each month.
⛓ Source · pair of 11/08, 18,400 rows compared, 11 conflicting identifiers, matching rule
What I see: two rows carry the same resident identifier — the only signal that is enough on its own in my rule. And no other field agrees: two unrelated names, two addresses in two different towns, two dates of birth eleven years apart.
The rule to apply here has not yet been defined: my rule says a shared identifier is enough to match, and it assumes the identifier is unique. Here it is uniqueness that is missing, not agreement. So I have matched nothing — and both records are intact.
Three ways forward. Hold the match on the identifier, as the rule says: mechanically compliant, and you bring together two records sharing neither name, nor address, nor date of birth. Set the pair aside and treat the two rows as distinct: both records are preserved, and the duplicate identifier stays in your files with nobody knowing. Leave the two rows separate and flag the conflicting identifier to the department that issues them: the records stay intact and the cause is handled where it sits, at the cost of one more flag to look into.
I recommend the third. A wrong merge mixes two lives into one record, and it is the hardest fault to undo: here the risk is simply not taken, and the real subject is not a match — it is an identifier issued twice, which is a reference-data question.
You can also give me another rule of your own — for instance: a shared identifier only counts as a strong signal if at least one second field agrees, and it becomes a reference-data flag otherwise.
Shall I remember it for the next cases? Across the 18,400 rows compared, 11 identifiers are carried by two rows with no other field in agreement. If you approve the rule, I will handle them that way instead of sending them up one by one, and I will give you the count each month.
⛓ Source · pair of 11/08, 18,400 rows compared, 11 conflicting identifiers, matching rule
The third. But the flag must go out without the two records — just the identifier, the two creation dates and the two files. The issuing department has no business reading the records. And yes, keep it.
Written exactly as you just said it, and it carries your correction.
The rule, in one sentence: an identifier carried by two rows with no other field in agreement produces no match; it produces a flag to the department that issues the identifier, and that flag carries only the identifier, the two creation dates and the two files.
Why your correction matters more than it looks: the department that issues identifiers does not need to know the residents in order to fix a counter. A flag carrying two records would open two records to a department that has no need of them — and that is exactly the step this page does not take.
What it changes this morning: the two rows stay separate and intact, the flag went out at 9:30 with the identifier, the two creation dates — 6 and 11 March 2025 — and the two files, and nothing else.
What lets you undo it: the rule is written into your matching rules under its own name, with its date, the head of department who approved it and the pair that gave rise to it. You remove one line, and these pairs go back to a plain flag.
✎ Rule approved · matching rules, entry “conflicting identifier”, approved on 11/08 by the head of department
The rule, in one sentence: an identifier carried by two rows with no other field in agreement produces no match; it produces a flag to the department that issues the identifier, and that flag carries only the identifier, the two creation dates and the two files.
Why your correction matters more than it looks: the department that issues identifiers does not need to know the residents in order to fix a counter. A flag carrying two records would open two records to a department that has no need of them — and that is exactly the step this page does not take.
What it changes this morning: the two rows stay separate and intact, the flag went out at 9:30 with the identifier, the two creation dates — 6 and 11 March 2025 — and the two files, and nothing else.
What lets you undo it: the rule is written into your matching rules under its own name, with its date, the head of department who approved it and the pair that gave rise to it. You remove one line, and these pairs go back to a plain flag.
✎ Rule approved · matching rules, entry “conflicting identifier”, approved on 11/08 by the head of department
The 11 conflicting identifiers — where do they come from?
They all come from the same fortnight, and they are only the visible part.
What I looked at: the 11 conflicting identifiers, their creation date, and every row created in the same window — across the two files you paired for me.
What comes out of it: the 11 were created between 3 and 14 March 2025, and across that twelve-day window 203 rows carry an identifier already issued elsewhere. The 11 are the ones the matching happened to meet; the other 192 have not been met yet.
Where the cause sits, and it is not in the typing: the identifier counter was reset by hand after the March 2025 migration, and it restarted from a number already used. Twelve days later it was corrected. It is a window, not a practice.
What I propose, and it is a clean-up to decide on your side: handle the 203 in one go rather than as matches happen to meet them. I hand you the list, file by file, with the two rows carrying each identifier and their dates.
What it is worth: at the pace of matching, those 203 rows would come up one by one for years, at 12 minutes of work each: 40 h 36. Handled in one go, with the list and the cause known, it is 2 minutes a row: 6 h 46.
The decision is yours: an identifier clean-up touches your reference data, it belongs to the department that holds it, and I rewrite nothing on my side — I match, I do not overwrite.
✎ Proposal · 11 conflicting identifiers, window of 3 to 14 March 2025, 203 rows concerned, 40 h 36 against 6 h 46 — the clean-up belongs to the reference-data department
What I looked at: the 11 conflicting identifiers, their creation date, and every row created in the same window — across the two files you paired for me.
What comes out of it: the 11 were created between 3 and 14 March 2025, and across that twelve-day window 203 rows carry an identifier already issued elsewhere. The 11 are the ones the matching happened to meet; the other 192 have not been met yet.
Where the cause sits, and it is not in the typing: the identifier counter was reset by hand after the March 2025 migration, and it restarted from a number already used. Twelve days later it was corrected. It is a window, not a practice.
What I propose, and it is a clean-up to decide on your side: handle the 203 in one go rather than as matches happen to meet them. I hand you the list, file by file, with the two rows carrying each identifier and their dates.
What it is worth: at the pace of matching, those 203 rows would come up one by one for years, at 12 minutes of work each: 40 h 36. Handled in one go, with the list and the cause known, it is 2 minutes a row: 6 h 46.
The decision is yours: an identifier clean-up touches your reference data, it belongs to the department that holds it, and I rewrite nothing on my side — I match, I do not overwrite.
✎ Proposal · 11 conflicting identifiers, window of 3 to 14 March 2025, 203 rows concerned, 40 h 36 against 6 h 46 — the clean-up belongs to the reference-data department
Fictional simulation — not a client result
The 412 rows with no counterpart — is that serious?
No — and it is the most useful of the four flags.
What I found on looking: the 412 are not scattered. 390 share one characteristic: they concern beneficiaries attached to a municipality that joined the joint authority in 2024. The second file was never extended to that perimeter.
What that means: the two files do not describe the same territory, and no document says so. Every cross-file statement produced for two years therefore understates part of the territory without anyone knowing.
The remaining 22 are isolated cases: 14 recent creations not yet carried over, 8 rows closed on one side and not the other.
What I propose: no data migration — first write down what each file covers. A one-page note, two perimeters, two dates. Migrating the data before writing that would amount to mixing two territories without knowing it. 412-rows_2-perimeters.pdf390 one cause · 22 isolated cases
⛓ Source · 412 rows, municipal attachments, file creation dates
What I found on looking: the 412 are not scattered. 390 share one characteristic: they concern beneficiaries attached to a municipality that joined the joint authority in 2024. The second file was never extended to that perimeter.
What that means: the two files do not describe the same territory, and no document says so. Every cross-file statement produced for two years therefore understates part of the territory without anyone knowing.
The remaining 22 are isolated cases: 14 recent creations not yet carried over, 8 rows closed on one side and not the other.
What I propose: no data migration — first write down what each file covers. A one-page note, two perimeters, two dates. Migrating the data before writing that would amount to mixing two territories without knowing it. 412-rows_2-perimeters.pdf390 one cause · 22 isolated cases
⛓ Source · 412 rows, municipal attachments, file creation dates
What do you keep out of all this?
The matches and their proofs, and nothing that builds a register of people.
What is kept: the match proposed, the agreeing and diverging fields, the decision taken, and its date.
What is not kept: no match between files you have not explicitly paired, no profile built by crossing several sources, no data copied from one file into another.
Why this is written here, and it is the most important point on this page: a tool that matches files is, technically, one step from a tool that cross-references all of them. That step is not taken, and it is not taken by design: every pair of files is paired explicitly by you, and two unpaired files never see each other.
What that gives you concretely: you can answer a resident asking what is done with their data — the answer is a list of file pairs, written down, short, and true. what-is-kept.pdf4 items kept · 3 prevented by design
✎ Framework · file pairings to be declared — nothing is matched by default
What is kept: the match proposed, the agreeing and diverging fields, the decision taken, and its date.
What is not kept: no match between files you have not explicitly paired, no profile built by crossing several sources, no data copied from one file into another.
Why this is written here, and it is the most important point on this page: a tool that matches files is, technically, one step from a tool that cross-references all of them. That step is not taken, and it is not taken by design: every pair of files is paired explicitly by you, and two unpaired files never see each other.
What that gives you concretely: you can answer a resident asking what is done with their data — the answer is a list of file pairs, written down, short, and true. what-is-kept.pdf4 items kept · 3 prevented by design
✎ Framework · file pairings to be declared — nothing is matched by default
Data hosted in France · sovereign model as an option
Your case is not here? That is exactly what a 30-minute conversation is for. Discuss your project →
How it works
The stages of your AI agent project
1
Audit & scoping
30 minutes to target the use case with the best return.
2
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
3
Design
We design the agent and its guardrails.
4
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
5
Rollout
Going live and training your team.
6
Operation
Continuous supervision and improvement.
The context
What does an AI agent bring to the quality of your data?
A duplicate spotted and documented is dealt with in moments; unspotted, it spreads through every process.
! The issue
Matching two databases calls for comparing records written differently and explaining why they correspond. The comparison is systematic; the decision to merge engages a member of the public's rights. The agent takes on the first and documents every correspondence by its agreeing criteria.
✓ Our answer
Your data department approves correspondences that are already documented, ranked by how far they agree, and concentrates its attention on the ambiguous cases. No merge is applied without a decision: confusing two identities has lasting effects on people's rights. Data hosted in France on an isolated resource; the AI model is called at its publisher, except with the Sovereign model option. With the 100% Sovereign package, members of the public's personal data does not leave the administration.
The decisive point
Members of the public's personal data: sovereignty & compliance
Matching databases by its nature handles personal data drawn from several processing operations. Here is how it is framed.
Local inference
With the 100% Sovereign package, the agent runs on a machine belonging to your organisation: no data about a member of the public and no record leaves the network.
Hosting in France
Otherwise, with the Agility and Serenity packages, a dedicated, isolated resource hosted in France, under French law: data hosted in France; the AI model is called at its publisher, except with the Sovereign model option.
Reduced extraterritorial exposure
For members of the public's personal data, the architecture aims to reduce exposure to the Cloud Act and FISA 702; being located in France or in the European Union does not, on its own, guarantee immunity.
Isolated resource
No pooling: an environment strictly dedicated to your administration and its reference data.
Matching criteria shown
Every correspondence states the agreeing criteria and how far they agree; encryption, role-based access and logging of the matches proposed.
AI Act: governed deployment
The agent carries out what you have authorised; no merge is applied and no identity is changed automatically; traceability and human oversight from end to end.
What depends on the architecture chosen These points are not general guarantees: they are settled deployment by deployment, in the quotation.
- The applicable location is that of the architecture set out in the quotation and verified before commissioning.
- Local execution is announced only for the configuration explicitly described and accepted in the quotation.
- The applicable isolation depends on the deployment mode set out in the quotation; no dedicated isolation is presumed.
- Roles and permissions are configured and accepted for the identities and systems actually connected.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For matching involving social, health or judicial data, SecNumCloud and reinforced hosting are options depending on your requirements. A single architecture is designed to answer both the GDPR and extraterritorial exposure. Designed for deployment in line with the GDPR and the AI Act, after the processing, roles and context-specific risks have been assessed.
The gain
How many records can a department match?
By taking on the comparison and the documenting, the effort shifts towards deciding the ambiguous cases. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Comparing the records
Documenting a correspondence
Ranking by how far they agree
Indicative figures, not contractual, to be confirmed by a pilot on your number of databases matched and their size. Confusing two members of the public's identities has lasting effects on their rights: no merge is applied without your decision.
Indicative estimate, to be confirmed by a pilot on your real files (general terms of sale, article 4).
Our commitment
Four guarantees that matter to your reference data
With 100% Sovereign, the public's data stays with youData hosted in France on an isolated resource; the AI model is called at its publisher, except with the Sovereign model option. With that option, no data about a member of the public entrusted to a third party, no data used to train a model.
Data in France, under French lawMembers of the public's personal data: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
Your data department keeps the decisionThe agent produces documented matches to approve, which can be checked and altered; the decisions remain yours.
Human oversight & traceabilityOn your number of databases matched and their size: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does the agent merge the duplicates?
No. It presents the correspondences with their agreeing criteria and prepares batches to approve. The merge remains your act, because it affects members of the public's rights.
What criteria does a match rest on?
On the criteria you define — name, date of birth, address, file reference — shown for every correspondence with how far they agree.
What does it do with ambiguous correspondences?
It ranks them separately, with the agreeing and the diverging criteria, so the decision is made in full knowledge.
How is the GDPR respected?
The matching covers only the databases you open to it, for the purpose you have defined, with logging of every operation proposed.
Is the public's data protected?
Yes. The agent is hosted in France, on local inference or an isolated resource, with the deployment objective of processing and access operated within the European Union and an architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. That data is not used to train a third-party model.
How long does it take to deploy this agent?
A few weeks as a rule, depending on the number of databases and their size, after a meeting with our sales team then a phase of design, integration and testing.
Let's talk
Let's size up the potential in your reference data
30 minutes to frame your databases and your criteria — hosted in France, supervised, with no commitment.