A Company Name Is Not an Entity: 14 Tests Before CRM Import

A prospect file can have one row per person and still describe several different things: a legal enterprise, one of its establishments, a trading name, a corporate group, or a contact who belongs to none of the above. If an importer treats a similar name as proof of identity, it can merge a branch into its parent, attach a person to the wrong account, or erase a legitimate separate buyer. The safe default is simple: match only on evidence that identifies the same entity; send relationships and ambiguity to review; never manufacture certainty from a score.

This is a practical extension of the French prospect-file checklist: that guide covers useful fields and basic deduplication. Here the question is narrower and more consequential: when two prospect rows look alike, are they the same legal unit, the same establishment, merely related companies, or separate records? The distinction matters before the file is written into a CRM, not after a salesperson has acted on it.

This article supplies a reusable 14-case synthetic test pack, a conservative matching policy, a small Python triage function, and a measurement plan. It does not test a vendor or real prospect data. It does not establish a universal match threshold, legal basis for outreach, or accuracy rate. Treat every example record as invented fixture data.

The decision: identify the thing before deduplicating the row

A duplicate is not simply a row with a familiar name. A record is a representation of an entity for a particular purpose. In French business data, the distinction between the legal unit and establishment is explicit: INSEE defines the SIREN as the identifier assigned to a legal unit, while a SIRET identifies an establishment and contains the SIREN plus an establishment number. The government’s enterprise identification guidance explains the practical difference. Therefore, two records with the same SIREN but different SIRET values can describe different establishments of one legal enterprise. Automatically collapsing them may destroy useful location and routing data.

The identity decision should precede person-level deduplication, lead scoring, enrichment, and campaign selection. If a person record is attached to the wrong account, later systems can make internally consistent decisions about the wrong business. A score, a CRM’s fuzzy match, or a third-party enrichment result can help find candidates; none is itself proof that two records refer to the same legal unit. The action should be one of three states: same_entity, related_entity, or unresolved.

A useful data model keeps identity and relationship separate. same_entity means two source records resolve to the same canonical entity under a documented identifier rule. related_entity means a parent, subsidiary, branch, franchise, successor, or shared trading brand relationship is known, but the records remain distinct. unresolved means available evidence is insufficient or contradictory. A fourth state, not_same_entity, can be used when a proposed pair is affirmatively disproved. Do not encode all four as “duplicate yes/no.”

Baseline: what ordinary prospecting guides and CRM rules already cover

Prospecting-file guidance commonly recommends fields such as company name, website, sector, location, contact, source, and freshness. Basic duplicate logic often starts with email, phone, or a registry identifier, followed by name similarity. Those are useful inputs. They do not, by themselves, settle whether a local establishment is equivalent to a legal entity or whether a shared web domain means common ownership. The guide linked above gives a field-oriented starting point; this article adds entity boundaries, relationship edges, confidence limits, and a human-review lane.

CRM matching rules can also behave less intuitively than users expect. In a Salesforce Trailblazer community question about missing duplicate candidates, an administrator described fuzzy account-name matching and blank phone or email values. A reply clarifies that “match blank” compares blank with blank; it does not make a blank value equal a populated one. This is one user’s configuration question, not evidence about how common the issue is. It is still a good test prompt: a missing identifier must not silently behave as a wildcard.

A vendor’s native duplicate feature may be excellent for its own object model and still be wrong for a particular business rule. A lead, account, contact, legal unit, and establishment are not interchangeable objects. Microsoft’s documentation for predictive lead scoring describes model configuration, data-dependent performance, and score lifecycle; that is a separate decision from entity identity. Keep scoring and matching pipelines distinct. First determine which account a person belongs to; only then ask how to prioritize that person or account.

The entity-resolution contract

Before running a matcher, write down the unit of identity. For this article, the primary unit is the French legal unit represented by SIREN. A separate establishment identity uses SIRET. If the target market includes foreign entities, each jurisdiction needs its own authoritative identifier type and normalization rule; do not force a French identifier schema onto another country. INSEE describes the SIREN as nine digits and SIRET as fourteen digits, with the SIREN embedded in the first part of SIRET. The identifiers are not arbitrary numeric scores and their digits do not encode a company-name similarity.

Define the claim each field can support. An exact valid SIREN can support candidate identity at legal-unit level, subject to current registry status and source provenance. An exact SIRET supports an establishment-level candidate, not a claim that two different establishments are the same site. A normalized domain can locate a shared web presence; it cannot prove legal identity. A normalized name generates candidates; it cannot prove a match. A phone number may be a switchboard shared across a group, a former number, or a number entered on several unrelated records. A contact email can be personal, role-based, stale, or reused by an agency.

The decision contract also needs temporal semantics. Every identifier or attribute should carry the source, capture time, and, where available, the time range during which it was valid. A current name and an old name may belong to one entity after a legal change; a company that was dissolved and a later company using the same brand are not automatically one entity. A snapshot cannot answer historical questions without effective dates. Preserve the raw value and the normalized value side by side so that a reviewer can reconstruct how the candidate pair was produced.

Finally, matching must not erase evidence. Store the original source-row ID, original field values, candidate pair, rule and version, evidence list, decision, reviewer, decision time, and reversibility status. A merge should be reversible or represented as a link until the organization has tested the effect on downstream workflows. If the CRM only offers destructive merging, export the two records and their associations first, record the merge receipt, and define how to restore them. A “merge” button is a data mutation, not a harmless cleanup action.

Four possible outcomes and when each is safe

Outcome	Meaning	Typical evidence	Permitted next step
Same legal unit	Both rows identify the same legal entity	Exact validated SIREN, consistent registry attributes	Link or merge only at legal-unit level; preserve separate establishments
Same establishment	Both rows identify the same site	Exact validated SIRET, matching SIREN and establishment identity	Consolidate the duplicate site record while retaining source and history
Related, distinct	Parent, subsidiary, branch, franchise, successor, or shared brand	Explicit relationship evidence, different legal IDs	Keep separate entities; add a typed relationship edge
Unresolved	Evidence is incomplete, stale, conflicting, or approximate	Name/domain/phone similarity only; missing IDs	Queue for review, ask for more evidence, or keep separate

“Not the same” is also a valid outcome: exact registry identifiers conflict, sources refer to different jurisdictions or periods, or the name match is only a common phrase. The matcher should not turn low confidence into an automatic yes simply because a sales import is time-sensitive. The U.S. Small Business Administration’s market-research guide frames market research around understanding the target market and competition; it does not authorize collapsing records based on a product’s geographic or sector filters. Target fit and entity identity are different questions.

Match evidence in descending order of strength

Use a hierarchy, not a single opaque score. First consider an exact authoritative identifier with a known type, country, validation method, and observation date. Then consider a confirmed source-to-CRM mapping or an explicit reviewed relationship. Next use combinations of independently informative attributes, such as normalized legal name plus address and registry context. Domain, switchboard, and fuzzy name similarity are candidate-generation signals, not standalone merge keys. Finally, absence of a field is not positive evidence. Empty SIREN does not mean “same SIREN”; two blanks must not produce an identity edge.

A weighted model can rank the review queue, but the weights must be learned or calibrated on labeled, representative pairs before they control action. The Frontiers paper on B2B lead prioritization describes a lead-scoring model evaluated as a case study at one B2B software company. Its scope is a single organizational setting; it does not demonstrate that a lead-priority model, or a name-similarity threshold, transfers to every market. Use this as a reminder that local evaluation matters, not as a universal recipe.

The OECD AI principles describe a risk-management approach across the AI lifecycle and emphasize human oversight, transparency, robustness, and accountability. Applied here, those are governance principles, not a source for a particular matching threshold. Record the rule version, expose why a pair was proposed, allow a reviewer to disagree, and monitor error consequences. Gartner’s abstract on AI impact in lead and account scoring recommends dynamic scoring to surface buyer insights. That is a vendor-neutral analyst recommendation at abstract level; the full research is not available from the abstract, and it does not validate identity resolution or guarantee conversion improvements.

Fourteen synthetic tests before import

The following matrix is an original acceptance fixture designed on 10 November 2026. It has 14 invented pair scenarios. No actual company, record, account, CRM, model, or matching performance was tested. Each case specifies a safe expected disposition, not a measured accuracy result. Implementers should replace fixture values with synthetic identifiers that pass the target country’s format checks but do not belong to real businesses.

#	Pair pattern	Expected disposition	Why	Unsafe shortcut to reject
1	Same exact valid SIREN; names differ by accents and legal suffix	Same legal unit candidate	Identifier type aligns; name variation can be reviewed	Treat the name string as the canonical key
2	Same SIREN; distinct valid SIRET values	Same legal unit, distinct establishments	Parent legal unit matches while sites differ	Merge establishment rows into one location
3	Same exact SIRET and same SIREN; formatting differs	Same establishment candidate	Normalize separators only after validation	Compare raw string without normalization
4	Same name and domain; different valid SIREN	Not same legal unit	Strong identity evidence conflicts	Let fuzzy name override registry conflict
5	Parent and subsidiary share a domain; different SIREN	Related, distinct	Shared brand/domain does not erase legal boundary	Merge because the website footer lists both
6	Branch and registered head office have different SIRET, same SIREN	Same legal unit, separate establishments	Establishment identity remains distinct	Delete branch as a duplicate row
7	Same name, different country and identifier scheme	Unresolved until jurisdiction-aware mapping	Identifier semantics are not comparable	Pad or truncate identifiers to force a match
8	SIREN blank in one row; populated in the other	Unresolved	Missing is not equal to known	Configure blanks as wildcards
9	Shared switchboard number across a group	Related candidate or unresolved	Phone can be a group contact point	Treat phone equality as entity identity
10	Similar transliterated name, different address and registry ID	Not same legal unit or unresolved	Similarity can be linguistic coincidence	Automatically merge at a fuzzy-score cutoff
11	Same old trading name, one record has newer legal name	Review temporal continuity	Change may be a rename or a new owner	Assume a brand name proves continuity
12	Same domain after a domain acquisition or rebrand	Unresolved	Domain control and legal succession differ	Infer legal succession from DNS or branding
13	SIRET copied across rows but one source has invalid checksum or stale status	Quarantine source value	Exact text is not necessarily a valid current identifier	Trust imported ID without validation/provenance
14	Two contacts share an agency email but different employers	Keep separate people/account links	Reused mailbox is not employer identity	Deduplicate contacts by email alone

The matrix is deliberately conservative. An exact SIREN match is still a candidate decision that must be interpreted against the data contract: the identifier may be mistyped, stale, copied from a group-level row, or supplied by an untrusted source. A production process should validate identifier syntax, retain source evidence, and use an authoritative registry lookup when the decision’s risk warrants it. The public definitions establish what SIREN and SIRET mean; they do not certify the quality of a third-party prospect file.

A small fail-closed triage function

The following example intentionally does less than a commercial matching engine. It normalizes only the identifier formatting that the caller has already verified. It never uses a fuzzy name score to auto-merge. The registry_valid flag means a separate, documented validation process produced evidence; it is not inferred by this function. A false or missing flag yields review. Production use needs country-specific validators, consent/source controls, tests, logging, and a restore plan.

from dataclasses import dataclass
import re

@dataclass(frozen=True)
class Record:
    country: str
    siren: str | None = None
    siret: str | None = None
    registry_valid: bool = False
    name: str = ""
    domain: str = ""


def digits(value: str | None) -> str | None:
    if not value:
        return None
    result = re.sub(r"\D", "", value)
    return result or None


def decide(a: Record, b: Record) -> str:
    # Never compare identifiers across countries without a typed crosswalk.
    if a.country != b.country:
        return "manual_review"

    a_siren, b_siren = digits(a.siren), digits(b.siren)
    a_siret, b_siret = digits(a.siret), digits(b.siret)

    if a_siren and b_siren and a_siren != b_siren:
        return "keep_separate"

    if a_siret and b_siret and a_siret != b_siret:
        # Different establishments can still belong to one legal unit.
        if a_siren and a_siren == b_siren:
            return "same_legal_unit_distinct_establishments"
        return "manual_review"

    if (a_siren and a_siren == b_siren
            and a.registry_valid and b.registry_valid):
        return "same_legal_unit_candidate"

    if (a_siret and a_siret == b_siret
            and a.registry_valid and b.registry_valid):
        return "same_establishment_candidate"

    # Name and domain similarities may queue work, but never merge records.
    if a.name.casefold().strip() == b.name.casefold().strip():
        return "manual_review"
    if a.domain.casefold().strip() == b.domain.casefold().strip():
        return "manual_review"
    return "unresolved"

This code is a teaching example, not a validator for INSEE identifiers. It does not check length, checksum, registry status, historical validity, parent relationships, or source authority. It also treats same-name and same-domain cases only as a review signal, so it can create false negatives where a business has changed identifiers or names. Do not “improve” it by adding SequenceMatcher > 0.9 => merge; if an approximate model is added, it should propose pairs for review until measured error rates and action-specific costs justify a different gate.

A production-shaped workflow

The workflow has two queues. Candidate generation should be broad enough to surface likely duplicates, while decisioning should be strict enough to protect distinct entities. A candidate pair can be created by exact typed identifier, exact normalized domain, phone, name-token similarity, address proximity, or a source-provided relationship. Each reason should be separately recorded. Combining three weak signals into one undocumented score does not automatically make the evidence strong; correlated fields can repeat the same underlying source error.

After candidate generation, apply hard conflict checks. Different validated SIRENs mean separate legal units for the French legal-unit key. Different SIRETs with the same SIREN mean potentially distinct establishments of the same legal unit. Cross-country comparisons go to a jurisdiction-specific mapping. Missing values remain missing. Invalid or stale identifier evidence goes to quarantine rather than being silently discarded. These gates should run before fuzzy similarity because hard conflicts should not be overridden by a high text score.

When evidence supports a relationship rather than identity, create a typed edge: parent_of, subsidiary_of, branch_of, franchise_of, successor_of, operates_brand, or shared_contact_point. Store evidence and dates on the edge. Do not invent parentage from a shared domain. If sales routing wants to roll subsidiaries up to a parent, implement that as a separate account hierarchy view rather than destructively merging records. The user’s operational purpose may need both the distinct legal account and the group view.

Human review is part of the design, not an emergency patch. Reviewers need a side-by-side evidence view, source timestamps, normalized/raw values, conflict explanations, candidate-generation rule, and a preview of downstream effects. The interface should offer same legal unit, same establishment, related, not same, and cannot decide. If the reviewer cannot identify what would change after confirmation, the system should not offer an irreversible merge action.

Measurement: evaluate the decisions, not just the model score

Before import, take a stratified sample from each outcome bucket: auto-match candidates, review candidates, no-match pairs, and hard-conflict pairs. Have two reviewers independently label pairs using written definitions; resolve disagreements with a third adjudicator or a documented policy owner. Preserve a test set that is not used to tune the candidate rules. Report pair-level precision and recall separately for legal-unit identity, establishment identity, and relationship detection. A single “accuracy” number hides the costs of merging distinct companies versus leaving duplicate records unmerged.

For a binary action gate, define precision = true_same / (true_same + false_same) and recall = true_same / (true_same + false_not_same), using the labeled sample and the specific identity unit. If there are no positive cases in a bucket, precision is undefined, not 100%. Publish the sample size, sampling method, time window, countries, identifier coverage, reviewer disagreement, and whether adjudicators saw the model’s recommendation. Do not invent confidence intervals or present small convenience samples as population estimates.

Measure operational consequences too: review minutes per 100 candidate pairs, proportion of pairs escalated, number of merges reversed, contact-to-account reassignment rate, duplicate creation after import, and downstream campaign suppression errors. These are proposed metrics, not findings from this article. A merge reversal should be traced to the original candidate, rule version, reviewer decision, and downstream records. If reversals are rare only because users cannot undo merges, the metric is meaningless; test restore capability deliberately.

Set separate release thresholds for different actions. A low-risk “show possible duplicate” suggestion can tolerate more false positives than a destructive merge. If the organization cannot estimate the false-merge cost, do not auto-merge. Use an approval gate with explicit evidence and treat unknown cases as separate until resolved. This is a recommendation, not a claim that all data organizations should prefer a particular model family.

Contradictions and limits: when strict matching is not enough

A strict identifier policy can miss real duplicates. Records may omit SIREN, contain typographical errors, come from another country, or reflect a legal change. A firm may trade under multiple brands or locations. For some workflows, keeping a parent and subsidiary as distinct records can fragment legitimate account ownership. The answer is not to weaken the entity key until everything looks merged; it is to preserve the relationship graph and give the downstream process an explicit roll-up rule.

A flexible, probabilistic matcher can surface useful candidates that exact identifiers miss. It can also learn the biases and errors of historical merges. If past users routinely merged by name, the model may treat that behavior as “ground truth.” A model trained on a single company’s outcomes may not transfer to a different sector, geography, or CRM schema. The cited B2B lead-prioritization study is a single-company case study, and Gartner’s lead-scoring abstract speaks to scoring recommendations, not legal identity. Neither source establishes an entity-resolution performance target for your dataset.

Registry evidence is also bounded. An exact identifier supports a typed identity claim only within its jurisdiction, validity period, and source context. It does not prove that a contact is employed there now, that the organization is a fit for the product, that it can be lawfully contacted, or that an outreach list is accurate. Privacy, marketing eligibility, data licensing, and suppression status are separate controls. The presence of an opt-out field in a source file is not proof that the file’s entire history of collection and use is lawful.

Finally, automated review can become “human rubber stamp” if queues are too large or evidence is opaque. Track review load and disagreement. If people approve nearly every suggestion without opening evidence, treat that as a process failure. Reduce candidate volume, improve the explanation, or change the action from “merge now” to “link for investigation.” A decision system is only as safe as the actual decision path after the classifier emits a result.

Failure modes to rehearse before going live

Name similarity overrides an identifier conflict. Test two fictional rows with nearly identical legal names but different valid SIRENs. Expected result: keep separate at legal-unit level. If the engine returns “same” because a fuzzy score is high, stop release and inspect rule precedence.

SIREN equality collapses establishment detail. Test same-SIREN records with different valid SIRETs and addresses. Expected result: one legal-unit relationship and distinct establishments. If import discards one site, the model has confused identity levels. Test downstream territory routing after the proposed merge.

Blank values act as wildcards. Test blank versus populated identifiers, blank versus blank, and a source whose import process filled missing values with whitespace. Expected result: blank is unknown unless a separately approved rule says otherwise. Normalize null, empty string, whitespace, “N/A”, and sentinel values before matching; never map them to a shared identity key.

Shared group data creates false equality. A parent and subsidiary may share a domain, phone, email convention, or switchboard. The data can be useful evidence of a relationship, but it is not proof of identical legal units. Test group-level contact fields and subsidiaries with separate identifiers.

A domain change creates a false successor. Domain ownership can change, brands can be acquired, and agency domains may host many customers. Use time-stamped source evidence. Domain equality may generate a candidate; it should not replace registry and relationship evidence.

Stale or invalid IDs pass through as exact matches. Test a syntactically invalid identifier, an identifier pasted from the wrong field, and a valid-looking value with no provenance. Exact string equality without type and validation metadata is not an authoritative check. Quarantine these values and preserve the raw source for diagnosis.

Cross-country normalization destroys meaning. Numeric identifiers from different registries can have the same length without sharing semantics. Type every identifier with a jurisdiction code and scheme. If no verified crosswalk exists, route to review; do not pad, truncate, or compare raw digits.

Review and rollback are missing. Simulate the wrong pair being merged, then ask an operator to restore both records, associations, campaign states, and audit history. If restoration cannot be proven, the action is not reversible enough for automatic execution. Use a link or staging table until the restore test passes.

Proof pack: claim, source, boundary

Claim used here	Source	What it supports	Limit
SIREN identifies a legal unit and is nine digits	INSEE definition of SIREN	French identifier meaning and format	Does not validate a value copied into a third-party file
SIRET identifies an establishment and embeds SIREN	INSEE definition of SIRET	Legal-unit versus establishment distinction	Does not imply different establishments should be destructively merged
Enterprise and establishment identifiers serve different purposes	Service-Public business guidance	Practical government explanation	France-specific; not a cross-country schema
Market research distinguishes target market from competition analysis	SBA market-research guide	Market research as a separate business task	U.S. guidance, not French legal advice or a matching standard
AI lifecycle governance should include oversight and risk management	OECD AI principles	High-level governance framing	Principles do not prescribe entity thresholds
Lead scoring recommendations concern prioritization, not identity proof	Gartner lead/account scoring abstract	Analyst recommendation at abstract level	Full report not assessed here; not a benchmark or match validation
Lead-prioritization research reports one company case	B2B lead-prioritization study	One studied context and its stated scope	Does not establish transferability or entity-match accuracy
Predictive lead scoring depends on configuration and available data	Microsoft predictive lead scoring documentation	Product-specific scoring and lifecycle context	Vendor documentation, not independent validation

The primary source page linked near the opening is editorial material about prospect-file fields and common duplicate indicators. It is used as the content baseline, not as an authority for French identifier definitions. Its published numeric claims about list decay or productivity are not repeated here because the page does not provide a method, sample, or independent validation for them. The original 14-case fixture contains no measured performance claims. The publication date is 10 November 2026; source checks recorded for this draft returned HTTP 200 for the primary page, INSEE definitions, Service-Public, SBA, the research article, and Microsoft documentation. The OECD and Gartner pages were available as cited search results/abstracts but returned access restrictions to the direct command-line fetch used during review; those sources are explicitly limited above and do not support threshold or performance claims.

A safer import runbook

1. Freeze the input file and compute a checksum. Preserve the source filename, delivery time, sender, license or acquisition record, and any stated update date. Do not overwrite the original file during cleanup.
2. Map each identifier to a typed field: country, registry scheme, identifier value, source, capture time, and validation status. Reject ambiguous columns named only “company ID” or “registration number” until the provider documents the scheme.
3. Normalize formatting deterministically and retain both raw and normalized values. Strip separators only when the identifier scheme permits it. Do not lower-case or remove punctuation from every field indiscriminately; punctuation may be meaningful in foreign names and identifiers.
4. Run format and provenance checks before candidate generation. Separate invalid, stale, and untyped identifiers into quarantine. An identifier can be exact and still be wrong if it was copied into the wrong column.
5. Generate candidate pairs using independent signals and record each reason. Run hard conflict rules before fuzzy ranking. A pair with a conflicting valid legal identifier cannot be rescued by name similarity alone.
6. Assign one of the explicit outcomes. Automatically apply only the action allowed for the evidence class and tested risk tier. Keep uncertain pairs unchanged; route them to review with the evidence exposed.
7. Test the 14 synthetic cases, plus organization-specific edge cases, on the exact importer and CRM configuration that will be used. Include blanks, accented names, international records, group structures, branch locations, repeated contacts, source conflicts, and reversals.
8. Import into a staging batch. Compare record counts, account relationships, establishment counts, and contact assignments before and after. Review representative accepted and rejected pairs.
9. Obtain named approval for the release rule, rollback process, and campaign suppression behavior. A field can be structurally valid and still lack permission for a particular use.
10. Import gradually, monitor reversals and downstream routing, then stop automatically if hard-conflict examples are merged or if the audit trail is incomplete.

The same runbook can be applied when buying a prospect file, receiving a partner feed, or joining two CRMs. The business purpose changes the acceptable cost of a false match. A route-to-sales suggestion may be reversible and visible; a destructive merge, suppression-list update, or automated outreach event has a different risk profile. Use the same identity evidence but authorize different actions at different confidence and approval levels.

Checklist: release only when every answer is concrete

• [ ] Is the unit explicit: legal unit, establishment, person, group, or brand?
• [ ] Is every identifier typed by jurisdiction and scheme?
• [ ] Are raw values retained next to normalized values?
• [ ] Does missing data stay unknown rather than acting as a wildcard?
• [ ] Do hard identifier conflicts override name/domain similarity?
• [ ] Are parent, subsidiary, branch, franchise, and successor relationships stored separately from identity?
• [ ] Are sources, capture dates, and validity periods attached to evidence?
• [ ] Does the reviewer see why a candidate exists and what the action changes?
• [ ] Are auto-merge actions limited to evidence classes tested on representative labels?
• [ ] Are precision and recall reported separately for legal units and establishments?
• [ ] Is the test sample size, selection method, geography, and adjudication process documented?
• [ ] Has a destructive-merge restore been demonstrated with linked records and audit history?
• [ ] Have all 14 synthetic cases passed in the actual import configuration?
• [ ] Is there a stop condition for unexpected hard-conflict merges, audit gaps, or rising reversals?
• [ ] Are marketing eligibility, lawful data use, opt-outs, and suppression handled by a separate control?

The practical rule

A prospect import should not ask “How similar are these two rows?” until it has asked “What kind of thing does each row represent?” Start with typed identifiers and source evidence. Preserve legal units and establishments at their proper level. Use similarity to find candidates, use relationship edges to model groups, and send uncertainty to a human rather than turning it into a destructive merge. For this draft, the 14 cases are a synthetic acceptance artifact, not a benchmark; the safe next step is to run them against your own schema and record what the importer actually does.