eduKateSG · Why Science?
A project can change people, outputs and funding while keeping one traceable identity
Read RAiD project records through dates, contributors, organisations, related objects, related projects, access conditions, controlled roles and version history.
Research projects are living activities. Team members join and leave, organisations take different roles, funding and services arrive at different times, and outputs appear long after the first plan. A project title alone cannot hold that changing context.
The Research Activity Identifier, or RAiD, is a persistent identifier and global registry dedicated to research projects. The official service is governed by ISO 23527:2022, with the Australian Research Data Commons as Registration Authority. RAiD identifiers are implemented as DOIs minted through DataCite, while RAiD metadata describes the project lifecycle.
Did you know? A RAiD is not a grant identifier. Official eligibility guidance describes a project as an undertaking that advances knowledge with a set scope and limited duration, while a grant is something the project receives. Grant identifiers can instead appear as related objects in a project record.
This article treats a RAiD record as project provenance. It can connect contributors, organisations, inputs and outputs without proving that every outcome was caused by the project or that the research conclusions are valid.
Chapter index
Chapters 1–9: project identity, dates and roles
- 1. The RAiD identifies a project
- 2. Projects differ from grants
- 3. The standard defines international governance
- 4. The metadata schema structures records
- 5. Core metadata is shared
- 6. Project dates define a lifecycle
- 7. Titles can change over time
- 8. Descriptions need typed context
- 9. Contributors use persistent person IDs
Chapters 10–17: related objects, access and lifecycle provenance
- 10. Administrative positions differ from scholarly roles
- 11. Role dates preserve team changes
- 12. Organisations have typed roles
- 13. Related objects connect work products
- 14. Related projects form project graphs
- 15. Access conditions need explicit reading
- 16. Record timestamps show metadata events
- 17. Project provenance supports careers
A research project changes over time even when its persistent identifier remains stable. RAiD provides a persistent route for a research project or activity across its lifecycle. It should not be used as the identifier for a person, organisation or durable department. This turns project administration into a readable evidence trail.
Try this
Evidence question: What bounded project does this RAiD 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 RAiD and record its primary title, dates and status context. 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 raid identifies a project, its identifier or version context, and one limit that must remain visible.
Project metadata can connect people, organisations, funding, services and outputs. A project is the activity being carried out, whereas a grant is a funding award it may receive. One project can involve multiple funding sources or exist beyond one award period. It also helps students see research as coordinated work rather than a single paper.
Try this
Evidence question: Is this identifier naming work or funding? 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 the RAiD and grant DOI in separate labelled fields. 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 projects differ from grants, its identifier or version context, and one limit that must remain visible.
CHAPTER 3 OF 17 · Identify the project
3. The standard defines international governance
Dates and roles preserve the lifecycle that a flat project title cannot show. RAiD is governed by ISO 23527:2022, and ARDC acts as the Registration Authority. Registration Agencies deliver services within this governance structure. The record becomes stronger when controlled roles and related-object identifiers stay visible.
Try this
Evidence question: Which authority and agency are responsible for this record? 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 governance and service roles without merging them. 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 the standard defines international governance, its identifier or version context, and one limit that must remain visible.
A project identifier answers a different question from a grant, person or organisation identifier. The RAiD schema defines mandatory, recommended and optional elements, occurrence rules, formats and controlled vocabularies. Core, extended and local components have different governance. A reader can follow the project graph while keeping record history and access conditions clear.
Try this
Evidence question: Which component and requirement apply to this field? 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: Check the schema before labelling a missing value as an error. 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 metadata schema structures records, its identifier or version context, and one limit that must remain visible.
A research project changes over time even when its persistent identifier remains stable. Core properties are standardised across Registration Agencies. Local controlled lists require mappings when they vary from canonical terms. This turns project administration into a readable evidence trail.
Try this
Evidence question: Is the returned value canonical, local or both? 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: Preserve the vocabulary URI beside the label. 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 core metadata is shared, its identifier or version context, and one limit that must remain visible.
Project metadata can connect people, organisations, funding, services and outputs. Start and end dates describe the bounded activity. Date precision can vary, so a year-only value should not be expanded into a full day. It also helps students see research as coordinated work rather than a single paper.
Try this
Evidence question: What precision and event does this date carry? 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 date exactly and avoid invented precision. 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 project dates define a lifecycle, its identifier or version context, and one limit that must remain visible.
Dates and roles preserve the lifecycle that a flat project title cannot show. The schema can associate title forms and date ranges with a project. Historical titles help follow the same project through renaming. The record becomes stronger when controlled roles and related-object identifiers stay visible.
Try this
Evidence question: Which title applied during the cited period? 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: Build a title timeline rather than overwriting the old 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 titles can change over time, its identifier or version context, and one limit that must remain visible.
A project identifier answers a different question from a grant, person or organisation identifier. Project descriptions can use designated types and language information. A description summarises scope; it is not a complete protocol or final report. A reader can follow the project graph while keeping record history and access conditions clear.
Try this
Evidence question: What kind of description is this and who maintains it? 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: Connect the summary to the detailed project document 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 descriptions need typed context, its identifier or version context, and one limit that must remain visible.
CHAPTER 9 OF 17 · Connect inputs and outputs
9. Contributors use persistent person IDs
A research project changes over time even when its persistent identifier remains stable. Contributor entries require supported person identifiers such as ORCID or ISNI under the current core schema. Identifier schemes reduce ambiguity across name changes. This turns project administration into a readable evidence trail.
Try this
Evidence question: Does the person identifier resolve to the intended contributor? 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: Verify the ID and avoid inferring unlisted personal information. 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 contributors use persistent person ids, its identifier or version context, and one limit that must remain visible.
CHAPTER 10 OF 17 · Connect inputs and outputs
10. Administrative positions differ from scholarly roles
Project metadata can connect people, organisations, funding, services and outputs. RAiD separates project positions, such as principal investigator or collaborator, from scholarly contribution roles expressed with the CRediT vocabulary. It also helps students see research as coordinated work rather than a single paper.
Try this
Evidence question: Is this field about project administration or scientific contribution? 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: Place position and contribution role in separate columns. 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 administrative positions differ from scholarly roles, its identifier or version context, and one limit that must remain visible.
Dates and roles preserve the lifecycle that a flat project title cannot show. Contributor positions can include start and end dates. A current record can therefore show changes without implying that everyone participated for the full project period. The record becomes stronger when controlled roles and related-object identifiers stay visible.
Try this
Evidence question: When did this person hold the stated position? 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: Compare role dates with the project dates. 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 role dates preserve team changes, its identifier or version context, and one limit that must remain visible.
A project identifier answers a different question from a grant, person or organisation identifier. Organisation entries connect persistent organisation identifiers with project roles and date ranges. A ROR record identifies the organisation; the RAiD relationship states its project context. A reader can follow the project graph while keeping record history and access conditions clear.
Try this
Evidence question: Which organisation served which role and when? 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 ROR and keep the RAiD role statement attached. 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 organisations have typed roles, its identifier or version context, and one limit that must remain visible.
CHAPTER 13 OF 17 · Track change responsibly
13. Related objects connect work products
A research project changes over time even when its persistent identifier remains stable. The relatedObject block can record project inputs, outputs and process documents identified by persistent identifiers. Types can include datasets, software, papers, instruments, plans and services. This turns project administration into a readable evidence trail.
Try this
Evidence question: Is this object an input, output or process document? 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 and record category and type separately. 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 related objects connect work products, its identifier or version context, and one limit that must remain visible.
Project metadata can connect people, organisations, funding, services and outputs. A RAiD can connect to another RAiD with a typed relationship. Related projects should remain distinct even when they share people or funding. It also helps students see research as coordinated work rather than a single paper.
Try this
Evidence question: What is the direction and reason for the project relationship? 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 both project IDs with a labelled arrow. 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 related projects form project graphs, its identifier or version context, and one limit that must remain visible.
CHAPTER 15 OF 17 · Track change responsibly
15. Access conditions need explicit reading
Dates and roles preserve the lifecycle that a flat project title cannot show. The access block records access type and can include embargo expiry or a statement. Public project metadata does not guarantee open access to every related object. The record becomes stronger when controlled roles and related-object identifiers stay visible.
Try this
Evidence question: Which layer is open, embargoed or otherwise restricted? 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: Check project metadata and each related object separately. 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 access conditions need explicit reading, its identifier or version context, and one limit that must remain visible.
CHAPTER 16 OF 17 · Track change responsibly
16. Record timestamps show metadata events
A project identifier answers a different question from a grant, person or organisation identifier. System-managed created and updated timestamps describe the RAiD record, not necessarily scientific milestones. Version history records changes to project information. A reader can follow the project graph while keeping record history and access conditions clear.
Try this
Evidence question: Which event is administrative and which is scientific? 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 metadata timestamps outside the research timeline. 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 record timestamps show metadata events, its identifier or version context, and one limit that must remain visible.
A research project changes over time even when its persistent identifier remains stable. Research managers, librarians, data stewards, infrastructure providers, funders and investigators use project identifiers to coordinate reporting and discovery. This turns project administration into a readable evidence trail.
Try this
Evidence question: Which repeated form or broken hand-off could a stable project ID improve? 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: Design a RAiD-style record for a year-long school research project. 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 project provenance supports careers, its identifier or version context, and one limit that must remain visible.
Contents · Previous chapter · Continue at the Science Learning Hub
Follow the project through change without flattening its history
RAiD gives a changing research activity a stable identity and structured metadata. It becomes most useful when person, organisation, object and funding identifiers keep their separate meanings.
Save the RAiD, title history, project dates, contributor and organisation roles, related-object identifiers, access conditions, record timestamps and retrieval date. Then inspect the underlying outputs before evaluating scientific claims.
| Reading object | What it can support | Question to keep visible |
|---|---|---|
| RAiD | Persistent project identity | What bounded activity does it name? |
| Contributor role | Person’s position or scholarly contribution | Which role and dates apply? |
| Related object | Input, output or process document | What type, category and PID are recorded? |
| Access | Visibility or embargo context | Which layer is actually available? |
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
- RAiD global overview — accessed 25 October 2026.
- RAiD documentation — accessed 25 October 2026.
- RAiD metadata schema — accessed 25 October 2026.
- RAiD core metadata properties — accessed 25 October 2026.
- RAiD related objects specification — accessed 25 October 2026.