research-document
Research Metadata Schema
Research Metadata Schema
Canonical Fields
The publisher normalizes front matter into a versioned 1.1 record with these core fields:
schemaVersionidtitleslugurlartifactTypeprojectpurposesaudiencesentryPointentryPointOrderentryPointLabelresearchAreadisciplinesummarystatusversionconfidencecompletionpriorityauthorAgentcreatedupdatedtagskeywordsrelatedProjectsrelatedDocumentssupersedessupersededByevidenceIdshypothesisIdstheoryIdsheadingssourcePathcontentHash
Legacy Aliases
The first version supports these metadata aliases:
identifier->idstableId->idresearch_area->researchAreaartifact_type->artifactTypeupdated_at->updatedcreated_at->createdauthor->authorAgentprojectId->projectpurpose->purposesdocumentPurpose->purposesaudience->audiences
Reader-Purpose And Navigation Fields
These fields organize documents without changing their epistemic type:
project: stable lowercase key for the primary owning projectpurposes: controlled reader jobs; see Document Purpose And Project Guide Architectureaudiences: controlled intended readersentryPoint: explicit opt-in to the front of a project guideentryPointOrder: numeric order within that guideentryPointLabel: optional short presentation label
The build emits project entry points at data/research-guides.json. Unknown purpose or audience values produce warnings so vocabulary extensions are visible but do not silently remove content.
Compatibility Mode
When a Markdown file has no front matter, the build still publishes it in compatibility mode:
- Title is inferred from the first H1 or filename.
- Identifier is inferred only when a stable prefix already exists in the filename.
- Artifact type is inferred from the directory or identifier prefix.
- Dates fall back to the current repository implementation date.
Compatibility mode never invents canonical research claims, stable IDs, or relationship assertions.