Open the specific public work record and read which ORCID field is attached to the work, then compare that with the identifier shown on the author profile. Treat the deposited work identifier as what a publisher attached to that work, the profile primary identifier as a curated profile field, and a login connection as a separate account relationship. When they disagree, note the layer and the gap rather than assuming two people or two identities.
Find public social profile clues with our TraceSeek app.
Start at the work record, not the profile summary
The useful first move is to look at the public record for the work itself and read which identifier it carries. In OpenAlex, the raw_orcid field is the identifier deposited on a work, while the profile's primary orcid and its observed_orcids are different fields. That difference matters because a work record and a profile record can be maintained from different inputs. If the work record is available and public, it tells you what was attached to that work. It does not tell you who controls the account or whether the person listed is currently employed. [OpenAlex: ORCID source fields and matching limits]
- Open the work record first and note the identifier shown on the work.
- Then open the author profile and note whether the primary identifier differs.
Read each identifier as provenance, not as identity proof
A deposited work identifier answers a narrow question: which identifier was attached to this work in the source data. A profile primary identifier answers a different question: which identifier the profile field currently shows. Linking an ORCID to a login account is a third, separate relationship. None of these layers is a face-based identity check, and a match is not a guarantee of ownership, current activity or who is behind an account. Keep the observation, its limit and any practical decision in separate lines so a weak clue does not quietly become a conclusion. [OpenAlex: ORCID source fields and matching limits]
A disagreement usually sits in one layer
Identifier provenance can differ because raw publisher data and curated profile fields are corrected at different times and by different processes. A profile correction does not necessarily rewrite the raw deposited identifier on a work. The checked documentation notes that raw_orcid can remain after a profile correction. So when the two disagree, the practical reading is not that one must be false; it is that the layers have not been reconciled. Also remember that multiple ORCIDs can arise from duplicate registrations, publisher attachment errors or overmerged profiles. Multiple identifiers are not proof of multiple people. [OpenAlex: ORCID source fields and matching limits]
| observation | limit | next step |
|---|---|---|
| Work record shows identifier A | Shows what was deposited on that work; does not show account control | Note the layer and compare with the profile field |
| Profile primary identifier shows B | A curated profile field; not a login confirmation | Record the difference rather than choosing a winner |
| A login connection is also present | A separate account relationship, not identity proof | Treat it as a third layer and stop short of identity claims |
| Two identifiers appear across records | Can stem from duplicates, attachment errors or overmerging | Record the possible causes as hypotheses, not findings |
When a layer is absent, private or ambiguous
If the work record is missing, private or ambiguous, record that precise limit and stop. An unavailable source does not license a private-account request or an identification workaround. Similarly, a mismatched or ambiguous match is a reason to narrow the claim, not to contact the apparent person to force confirmation. Contacting a stranger to resolve a public-record discrepancy is not a protective or necessary step, and silence or a non-response should never be read as confirmation. Write the limit plainly, for example that the deposited identifier could not be read from an accessible public record, and leave the inference open.
- State which layer you checked and whether it was public and readable.
- Stop the inference at the first absent or ambiguous layer.
- Do not treat a non-response or silence as agreement.
A simple worksheet for a disputed record
A short written worksheet keeps the layers from blurring together. Use it as a reader aid only; it is not a platform control and does not test anything on the service. Label each row with the layer you actually saw, the public artifact it came from, and the limit that applies. A hypothetical example: a work shows one identifier, the profile shows another, and no login relationship is visible. The honest note is that the layers disagree and the reason is unresolved, not that the person has two accounts or two identities.
| observation | limit | next step |
|---|---|---|
| Deposited work identifier read from a public work record | Says what was attached to the work, no more | Record it as the work layer |
| Profile primary identifier differs | Curated field; may postdate or predate the work record | Record the difference and the date checked |
| No login connection visible | Absence is not proof that no connection exists | Mark unknown; do not infer |
| Possible duplicate or overmerge cause | Hypothesis only without a supporting source | Stop before characterising the person |
Keep the practical decision narrow
Once the layers are separated, most decisions become smaller. You can describe the deposited identifier on a work, the profile's current primary identifier, and whether a login connection was visible, each with its own limit. You generally cannot use any of these to assert identity, ownership, current employment or safety. Photos, badges, status labels, matching images and privacy settings are not proof of identity, intent or safety, and they should not be used to infer income, wealth or relationship status. If a decision depends on identity verification, this public-record path cannot supply it. [OpenAlex: ORCID source fields and matching limits]
A couple more questions
What is the difference between raw_orcid and the profile's primary ORCID?
The raw_orcid field is the identifier deposited on a work, while the profile's primary orcid and observed_orcids are distinct profile fields. They can disagree because the work data and the curated profile are maintained from different inputs, and a profile correction need not rewrite the deposited identifier.
Does a login connection confirm the same person is behind both records?
No. Linking an ORCID to a login account is separate from attributing works, and a login link does not prove identity, ownership or current activity. Treat it as a third layer with its own limit rather than an identity confirmation.
If two ORCIDs appear, does that mean two people?
Not necessarily. The checked documentation notes that multiple ORCIDs can arise from duplicate registrations, publisher attachment errors or overmerged profiles, and that multiple IDs are not proof of multiple people. Record the disagreement and stop before making a personal claim.
Sources & editorial notes
Official references checked on October 24, 2026. Checklists, comparison tables and example wording are DateClues editorial tools, not official tests or validated risk scores.
General information. No guide or tool can certify a person’s identity, intentions or safety. Read our editorial standards.