eduKateSG · Why Science?
A researcher name becomes clearer when identity and provenance travel together
Read ORCID iDs through record ownership, visibility, sources, assertions, external identifiers, grouped works and permissions so research identity stays precise.
Researcher names are wonderfully human and inconveniently ambiguous. People share names, publish under initials, change names, move institutions and work across languages. An ORCID iD provides a persistent identifier that a researcher controls and can connect to contributions and affiliations.
The identifier does not turn every item on a record into a verified fact. ORCID records can contain assertions added by the researcher, a delegated trusted individual, or an authorised member organisation. Each item carries source and date information, and visibility settings affect what public readers or trusted parties can see.
Did you know? ORCID can group several versions of the same work when shared external identifiers connect them. The preferred display version and the source of each assertion remain separate pieces of provenance.
This guide treats an ORCID record as a permissioned identity graph. It helps disambiguate people and reduce repeated form entry, while expertise, authorship contribution and scientific quality still need evidence from the relevant works and organisations.
Chapter index
Chapters 1–9: iDs, visibility and record sections
Chapters 10–17: sources, grouping, permissions and responsible reuse
- 10. External identifiers connect objects
- 11. Grouped works reduce duplicates
- 12. Affiliations are relationships
- 13. Organisation assertions have provenance
- 14. Works do not prove contribution level
- 15. Public records protect private fields
- 16. APIs preserve structured context
- 17. Research identity supports careers
A researcher identifier helps distinguish a person from others who share or change names. An ORCID iD is a persistent identifier for an individual researcher. It is distinct from a work DOI, an organisation ROR ID or an account username. This makes research identity a lesson in consent as well as discovery.
Try this
Evidence question: Whose record does this iD represent? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Resolve the iD and compare the public name and other identifiers. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for the id identifies a person, its identifier or version context, and one limit that must remain visible.
An ORCID record is controlled through permissions and item-level visibility choices. ORCID states that only the person represented should create their identifier. This supports control and reduces duplicate or imposed records. It also prevents a profile from being treated as an automatic claim of expertise.
Try this
Evidence question: Was the iD authenticated by the person in this workflow? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Distinguish typed iD text from an authenticated sign-in. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for only the individual creates the id, its identifier or version context, and one limit that must remain visible.
Every assertion has provenance: who added it, when it changed and how it connects to an identifier. A record can include published names and other name forms. Those variants help discovery but should not be used to infer private identity changes. Students can see how people, outputs, affiliations and funding become connected without becoming identical.
Try this
Evidence question: Which name form appears on the cited work? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Match the work by identifier as well as by name. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for names can have variants, its identifier or version context, and one limit that must remain visible.
Works with shared external identifiers can be grouped even when several sources supplied them. Public records can include biography, affiliations, funding, works, peer review, research resources and other activities. Empty sections do not prove the activity never occurred. The useful habit is to read the source and visibility of each item before drawing a conclusion.
Try this
Evidence question: Which section supports the current claim? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Cite the item rather than the profile as a whole. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for the record contains sections, its identifier or version context, and one limit that must remain visible.
A researcher identifier helps distinguish a person from others who share or change names. Information can be visible to everyone, trusted parties or only the record holder under ORCID settings. Public API results therefore show a selected view. This makes research identity a lesson in consent as well as discovery.
Try this
Evidence question: What visibility boundary applies? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: State that the note describes the public record on the access date. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for visibility is item controlled, its identifier or version context, and one limit that must remain visible.
An ORCID record is controlled through permissions and item-level visibility choices. Member systems request permission before reading trusted data or writing items. Permission is scoped and can be reviewed or revoked by the record holder. It also prevents a profile from being treated as an automatic claim of expertise.
Try this
Evidence question: Which action did the researcher authorise? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Record read and write permissions separately. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for consent governs trusted access, its identifier or version context, and one limit that must remain visible.
Every assertion has provenance: who added it, when it changed and how it connects to an identifier. ORCID displays who added an item, such as the researcher or an authorised member organisation. Source helps readers judge provenance without declaring one source automatically correct. Students can see how people, outputs, affiliations and funding become connected without becoming identical.
Try this
Evidence question: Who added this affiliation or work? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Copy the source name and creation date into the note. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for every assertion has a source, its identifier or version context, and one limit that must remain visible.
Works with shared external identifiers can be grouped even when several sources supplied them. In multi-system workflows, the source that wrote an item can differ from the person or system that initiated the connection. ORCID distinguishes source from assertion origin. The useful habit is to read the source and visibility of each item before drawing a conclusion.
Try this
Evidence question: Who created the connection and who performed the write? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Draw the permission and data-flow path. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for assertion origin adds context, its identifier or version context, and one limit that must remain visible.
A researcher identifier helps distinguish a person from others who share or change names. Items include creation and last-modified dates. These are record events, not necessarily the publication, employment or research dates described by the item. This makes research identity a lesson in consent as well as discovery.
Try this
Evidence question: Which event does this timestamp represent? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Keep record timestamps beside, not inside, the activity timeline. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for dates show record history, its identifier or version context, and one limit that must remain visible.
An ORCID record is controlled through permissions and item-level visibility choices. Works, funding and other items can carry DOIs or supported identifiers. The relationship can mark the item itself, a part, or another version. It also prevents a profile from being treated as an automatic claim of expertise.
Try this
Evidence question: What object does the external identifier name? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Resolve the identifier before using it to group claims. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for external identifiers connect objects, its identifier or version context, and one limit that must remain visible.
Every assertion has provenance: who added it, when it changed and how it connects to an identifier. Multiple sources may add representations of the same work. ORCID groups items using shared identifiers and lets a preferred version appear first. Students can see how people, outputs, affiliations and funding become connected without becoming identical.
Try this
Evidence question: How many sources contributed to this group? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Inspect all grouped versions before choosing metadata. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for grouped works reduce duplicates, its identifier or version context, and one limit that must remain visible.
Works with shared external identifiers can be grouped even when several sources supplied them. Employment, education, qualifications and professional activities connect a person with an organisation for stated dates and roles. Overlapping affiliations can be legitimate. The useful habit is to read the source and visibility of each item before drawing a conclusion.
Try this
Evidence question: Which organisation, role and dates are asserted? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Use the organisation identifier when available. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for affiliations are relationships, its identifier or version context, and one limit that must remain visible.
CHAPTER 13 OF 17 · Use identity responsibly
13. Organisation assertions have provenance
A researcher identifier helps distinguish a person from others who share or change names. An institution can add affiliation data with the researcher’s permission. That source can strengthen provenance while still requiring attention to dates and scope. This makes research identity a lesson in consent as well as discovery.
Try this
Evidence question: Was the affiliation self-added or organisation-added? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Report the source without turning it into a ranking. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for organisation assertions have provenance, its identifier or version context, and one limit that must remain visible.
CHAPTER 14 OF 17 · Use identity responsibly
14. Works do not prove contribution level
An ORCID record is controlled through permissions and item-level visibility choices. A work on a record shows a connection to the person, often through an identifier. It does not by itself explain conceptual, experimental, writing or supervision contributions. It also prevents a profile from being treated as an automatic claim of expertise.
Try this
Evidence question: What contribution statement or byline evidence is available? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Separate connection evidence from role evidence. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for works do not prove contribution level, its identifier or version context, and one limit that must remain visible.
CHAPTER 15 OF 17 · Use identity responsibly
15. Public records protect private fields
Every assertion has provenance: who added it, when it changed and how it connects to an identifier. ORCID limits the data structure and lets users control visibility. A public record is intentionally not a complete personal dossier. Students can see how people, outputs, affiliations and funding become connected without becoming identical.
Try this
Evidence question: Which conclusion would overreach the visible data? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Write a boundary sentence that protects privacy. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for public records protect private fields, its identifier or version context, and one limit that must remain visible.
Works with shared external identifiers can be grouped even when several sources supplied them. ORCID APIs expose record sections, sources, dates and identifiers according to access permissions. Clients must preserve attribution and visibility rules. The useful habit is to read the source and visibility of each item before drawing a conclusion.
Try this
Evidence question: Which API scope and record version were read? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save endpoint, scope, access date and fields used. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for apis preserve structured context, its identifier or version context, and one limit that must remain visible.
A researcher identifier helps distinguish a person from others who share or change names. Researchers, librarians, publishers, funders and research administrators use persistent person identifiers to reduce ambiguity and repeated data entry. This makes research identity a lesson in consent as well as discovery.
Try this
Evidence question: Which hand-off benefits from authenticated identity? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Create an ethical ORCID checklist for a school research fair. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for research identity supports careers, its identifier or version context, and one limit that must remain visible.
Contents · Previous chapter · Continue at the Science Learning Hub
Read the source of each connection, not just the profile name
ORCID helps research outputs, affiliations and funding stay connected to the right person across systems. The identifier is most useful when consent, visibility and item provenance remain visible.
Record the authenticated iD, public access date, source, assertion origin when shown, external identifiers and relevant dates. Then use the underlying work or organisation record for claims that go beyond identity.
| Reading object | What it can support | Question to keep visible |
|---|---|---|
| ORCID iD | Persistent person identifier | Was it authenticated in the workflow? |
| Visibility | Who may read an item | Is this only the public view? |
| Source | Who added the assertion | What provenance does it provide? |
| External ID | Link to a work or award | What object and relationship does it name? |
Sources and next reading
Substantive resource claims in this article were checked against the primary pages below. A structured record is a route into evidence; it does not by itself prove a scientific conclusion. Recheck the live record, evidence labels and release context before using it in assessed work or research.
For a classroom enquiry, save a short research receipt containing the question, search terms, selected object, exact identifier, version, access date and the evidence boundary you observed. Add the file or page that supports each statement. This small routine turns browsing into accountable science learning and gives a teacher, classmate or future analyst a route they can independently follow.
Before sharing the conclusion, ask another reader to retrace the route without verbal hints. If they reach a different version, file or interpretation, improve the receipt and narrow the claim. Reproducibility begins with this practical check. It teaches careful reading, supports fair collaboration and keeps uncertainty visible while evidence moves from an online service into notes, analysis and a final explanation.
A useful final review separates five questions. What object was found? Which organisation or repository maintains it? What exact evidence was inspected? Which statement does that evidence support? What remains uncertain? Answer each question in one sentence, then connect every answer to a visible field, file or source page. This review catches common mistakes: citing a collection when a file supplied the value, treating the newest release as the analysed release, confusing permission with scientific suitability, or turning a discovery count into a conclusion. It also gives students a calm way to improve work. A missing detail becomes a next research step instead of an invitation to guess. When the route is complete, the final explanation can stay simple because the identifiers, dates, versions, limitations and supporting evidence are already organised underneath it.
Primary sources
- ORCID Trust programme — accessed 24 October 2026.
- ORCID record schema — accessed 24 October 2026.
- ORCID source and assertion origin — accessed 24 October 2026.
- ORCID visibility settings in the API — accessed 24 October 2026.
- ORCID journal workflow — accessed 24 October 2026.