How it works

From idea to citable, versioned knowledge infrastructure in five steps

NodeRail is built on three primitives: structured nodes, Git-based version lineage, and permanent DOIs. Here is how they work together.

Step 1
01

Create a Field Node

A Field is the top-level unit in NodeRail. It defines the scope, core constructs, ethics, governance rules, and contribution standards for a domain of knowledge. Think of it as the constitution for a field.

Every Field has a Field Founder — the person responsible for its initial architecture. The Field Constitution template ensures every field is structured consistently and can be extended by others.

Field Constitution: scope, constructs, ethics, governance

Canonical Construct Map: every term defined and versioned

Contribution Standards: who can add nodes and how

# Field Node structure field: name: "Human Capacity Science" id: "hcs" version: "0.1.0" founder: "Gao Kabubi" status: "draft" constructs: - name: "Cognitive Load" canonical_def: "v1.0" - name: "Capacity Degradation" canonical_def: "v1.0" governance: contribution_model: "invite-only" review_required: true doi_on_release: true
Step 2
02

Publish Nodes Inside the Field

Once a Field exists, contributors can publish three types of nodes inside it: Frameworks, Measurements, and Projects. Each node type has a structured template that ensures consistency and citability.

Framework: A reusable method, model, or operational playbook

Measurement: An instrument, index, or scale for measuring a construct

Project: A capstone, case study, or pilot with a Continuation Hook

# Framework Node structure framework: name: "Capacity Audit Protocol" id: "hcs-fw-001" version: "1.0.0" field: "hcs" author: "Gao Kabubi" constructs_used: - "Cognitive Load" - "Capacity Degradation" links: - type: "supports" target: "hcs-m-001" - type: "depends-on" target: "hcs"
Step 3
03

Version and Timestamp Every Change

NodeRail uses Git as its version control backbone. Every change to every node is committed with a timestamp, author attribution, and a change log entry. Nothing is ever overwritten — only superseded.

This creates a complete, auditable lineage for every piece of intellectual work on the platform. You can always see what changed, when, and why.

Every commit is timestamped and attributed

Forks preserve the full lineage back to the origin node

Change logs are required for every version increment

# Git lineage example # $ git log --oneline hcs-fw-001.md a3f9c2b v1.1.0: Add digital load construct 7e2d1a4 v1.0.1: Fix measurement reference 2b8f6c9 v1.0.0: Initial publication # Each version is a citable snapshot # Forks point back to origin commit lineage: origin: "2b8f6c9" forked_from: null forked_by: - "hcs-fw-002 (v1.0.0)"
Step 4
04

Issue a Permanent DOI

When a node reaches a stable version, a GitHub Release is created and Zenodo automatically archives the snapshot and issues a permanent Digital Object Identifier (DOI). The node becomes a citable academic artifact.

Two DOIs are issued: one for the specific version, and one that always points to the latest version. Both are permanent and will resolve for decades.

Version DOI: cites this exact snapshot forever

Concept DOI: always points to the latest version

Indexed in OpenAIRE, Crossref, and Google Scholar

# Citation for NodeRail v0.1 citation: author: "Kabubi, G." year: 2026 title: "Human Capacity Science (Founder Field v0.1)" publisher: "NodeRail" doi: "10.5281/zenodo.18764766" url: "https://doi.org/10.5281/ zenodo.18764766" # Resolves permanently # Indexed in OpenAIRE # Archived in Software Heritage
Step 5
05

Fork, Extend, and Continue

Any node on NodeRail can be forked by another researcher or practitioner. The fork preserves the full lineage back to the origin, so the original author always gets credit. The field grows without losing its roots.

Project nodes have a required Continuation Hook — a structured section that explicitly invites the next person to build on the work. This turns every project into a starting point, not an endpoint.

Forks are first-class nodes with their own DOIs

Continuation Hooks on Project nodes invite the next researcher

Original authors receive attribution in all derivative work

Four link types between nodes

Links are directional, versioned, and part of the node's permanent record. They allow the field to grow as a connected graph, not a pile of documents.

The standard

NodeRail Continuity Standard v0.1

The minimum requirements for a node to be considered continuity-grade. Every node published on NodeRail must meet all six criteria.

01

Structured

Uses the official node template for its type. No freeform documents.

02

Versioned

Has a semantic version number and a change log for every increment.

03

Attributed

Has a named author and a named steward. Authorship is never anonymous.

04

Citable

Has a permanent DOI issued via Zenodo on every stable release.

05

Linked

Has at least one typed link to another node in its field.

06

Continuable

Has a Continuation Hook: an explicit invitation for the next contributor.

Ready to publish your first node?

NodeRail is in early access. The process takes less than five minutes.

Request Access → See use cases