A new model for how standards are built
Most standards are still developed as committee-edited PDFs, published on fixed cycles, with opaque change histories and limited interoperability. NEI is a working demonstration of a different approach.
The problem with traditional standards development
Most standards development processes share four structural weaknesses:
- →
Static documents with weak versioning. A new edition replaces the old one. There is no persistent, citable reference to a specific version of a specific requirement. Research and software that depends on the standard faces an unstable target.
- →
Opaque committee processes with poor traceability. Decisions are made in committee meetings, often without public record. The rationale for specific requirements is rarely documented and almost never archived in a way that survives organisational transitions.
- →
Minimal machine readability. Standards are written for human reading. Software that needs to work with standards content must parse PDFs or HTML — fragile, expensive, and often inadequate.
- →
Long publication cycles that slow evidence incorporation. A finding that challenges a standard requirement may take years to result in a published change, if it ever does. In fast-moving fields, this creates dangerous lag.
Standards as code
In NEI, indicators are files in a version-controlled repository. Every change is a commit. Commits reference the proposal that justified the change. Proposals include the evidence considered and the rationale for the decision. This creates a traceable, permanent history of how each requirement evolved and why.
The history is not a side effect — it is a core product. Researchers can trace why a specific criterion was written the way it was. Software can diff two versions of an indicator and display exactly what changed. Anyone can see who proposed a change, what evidence they cited, and how the review community responded.
Publication cycles are replaced by a continuous process: proposals can be submitted at any time, reviewed asynchronously, and merged when the evidence and review warrant it. Urgent changes don't wait for the next edition.
Stable, immutable references
NDI identifiers are generated by hashing the indicator's canonical title — they are deterministic and permanent. Once assigned, an identifier is never reassigned or retired. A citation to NDI-hgbbzn-v1 will refer to the same specification forever, regardless of how the broader framework evolves.
This is a commitment that most standards bodies cannot currently make. When a standard is superseded, previous versions often become inaccessible or at least difficult to cite with precision. NEI's identifier system makes permanent, version-specific citation a default property of the framework.
Open governance
The governance lifecycle is transparent: Proposed → Candidate → Standard → (Deprecated). Anyone can propose an indicator. Proposals are publicly reviewed before a maintainer makes a decision. The criteria for advancing from Candidate to Standard are documented. There are no closed committee sessions where consequential decisions are made without public record.
Machine-readable by design
Indicator and taxonomy data is available at stable URLs in structured formats. Software systems can query the framework without parsing documents. AI systems can retrieve specific indicators by ID. Analysis tools can work with the full framework as structured data. This is not a supplementary data export — it is the primary representation of the framework, from which human-readable documentation is generated.
NEI as a reference implementation
NEI is not just a framework for workplaces. It is a demonstration that modern software development tools — Git, YAML, structured identifiers, open governance — can replace or substantially supplement committee-PDF processes in standards development. The technical architecture is deliberately simple: nothing here requires specialized infrastructure. Any standards body could adopt these patterns today.