NodeRail is infrastructure for intellectual continuity. Anyone can contribute. Not everything becomes canonical. This document explains how that works.
NodeRail has four roles. Access is determined by role, not by institution, affiliation, or seniority. The platform protects the ontology layer — Fields, Canon, and Lineage — while keeping everything else open.
| Role | Read nodes | Submit nodes | Edit own nodes | Curate a field | Canonicalise | Create a field |
|---|---|---|---|---|---|---|
| Public Reader | ✓ | — | — | — | — | — |
| Contributor | ✓ | ✓ | ✓ | — | — | — |
| Field Maintainer | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| Platform Admin | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Every node on NodeRail has a publishing state. Nodes publish immediately as Extensions. Maintainers may promote, draft, or deprecate them. All states remain visible and citable.
All submitted nodes begin as Extensions. Publicly visible, citable, and extendable. Not part of the curated canon.
Promoted by a Field Maintainer. Structurally foundational, quality-vetted, and referenced in the field index.
Visible but clearly marked as incomplete or under active revision. Not yet ready for citation or extension.
Replaced by a newer version or a better framework. Preserved for lineage integrity. Not recommended for new citations.
This is the structural heart of NodeRail. All submissions live publicly. Only some become Canonical Nodes. The distinction is not a quality judgment on the person — it is a structural judgment on the node's role in the field.
Nothing is hidden. Every Extension, Draft, and Deprecated node remains publicly accessible, citable, and extendable. NodeRail does not delete intellectual work.
A Canonical node is structurally foundational, field-aligned, and quality-vetted. Canonicalisation is a curation decision by the Field Maintainer, not a rejection of other work.
Contributors can fork, extend, and build on any node. They cannot overwrite canonical nodes or redefine a field's scope. Extensions are additions, not replacements.
Every node carries its lineage metadata: who created it, what it was forked from, who adopted it. This cannot be removed, even when a node is deprecated.
Field creation is not frictionless by design. NodeRail protects the ontology layer. A new Field must represent a genuine intellectual domain, not a topic, tag, or personal project. Every Field proposal requires a complete constitution before review.
A written document defining the field's purpose, scope, and intellectual boundaries.
At least five foundational terms defined clearly and distinctly from adjacent fields.
What the field includes and what it explicitly excludes. Prevents overlap and tag-soup.
How the field will be maintained, who the proposed Maintainer is, and how canon will be curated.
Field proposals are reviewed by the Platform Admin. At v0.1, this is the NodeRail founding team. Governance will evolve toward a council model as the platform matures.
Intellectual infrastructure should preserve lineage, even for flawed or superseded work. NodeRail does not delete nodes. Instead, it uses a structured lifecycle that keeps all work accessible while clearly signalling its status.
Deletion may be considered only in cases of plagiarism, harmful content, or legal obligation. In all other cases, deprecation and versioning are the correct tools.
NodeRail is currently in early access. All role applications are reviewed by the founding team. There is no institutional requirement for any role.
Submit nodes, fork existing work, and build your intellectual lineage on NodeRail. Open to researchers, students, practitioners, and independent thinkers.
Apply to contributeCurate the canon of an existing field. Review submissions, approve canonical status, and protect the field's intellectual integrity. Requires demonstrated expertise in the field.
Apply as MaintainerHave a domain of knowledge that deserves structured, citable infrastructure? Submit a Field proposal with a full constitution, definitions, scope, and governance model.
Propose a Field