The Specification
What exactly must a standard do to qualify as fourth generation? This specification defines the practices, identifiers, lifecycle, and compliance model.
The four generations of standards
Standards have evolved through distinct technological eras. Most are still stuck in the second or third generation.
1st: Paper
Printed documents distributed by mail. Changes require a new edition. No search, no linking, no machine access.
2nd: Electronic
PDFs and web pages. Searchable text, but still static documents. No stable identifiers, no version diffing, no structured data.
3rd: Database
Structured data behind proprietary platforms. Machine-readable in theory, but locked behind paywalls and vendor APIs.
4th: Revision-controlled
Version-controlled repositories with deterministic IDs, graph taxonomies, and machine-readable formats. Open, diffable, LLM-accessible.
Core concepts
Practice
An observable, implementable characteristic of a fourth generation standard.
Taxonomy
A domain hierarchy that organises practices into meaningful groups.
Contribution
A formal change request that introduces or modifies practices or taxonomy.
Release
A versioned, stable snapshot of standard practices.
Identifier formats
Every entity in a 4GS standard gets a deterministic, namespaced identifier derived from the SHA-256 hash of the normalised name.
| Entity | Format | Example |
|---|---|---|
| Practice concept | FGP-xxxxxx | FGP-4ukccp |
| Practice version | FGP-xxxxxx-vN | FGP-4ukccp-v1 |
| Taxonomy release | FGT-<semver> | FGT-1.0.0 |
| Contribution | FGC-xxxxx | FGC-00001 |
| Standard release | FGR-<semver> | FGR-1.0.0 |
Practice lifecycle
Every practice progresses through three stages before becoming part of a numbered release.
Proposed
Submitted via a contribution. Under active discussion. Any community member may comment.
Candidate
Accepted for inclusion pending final review. Complete, uncontested, and reviewed by a maintainer.
Standard
Approved after 14-day Candidate window with no blocking objections. Included in a numbered release.
Compliance levels
A standard may claim fourth generation status at one of three levels.
Foundational
Implements all practices in the Foundational release (FGR-1.0.0). The minimum bar for fourth generation status.
Extended
Foundational plus all practices in the Extended release. Covers additional quality and interoperability practices.
Full
All Standard practices in the current release. The complete 4GS practice set.
The OSS toolchain applied to standards
Fourth generation standards borrow proven infrastructure from open source software development.
| OSS tool | Standards application | What it replaces |
|---|---|---|
| Git | Full change history with attribution | Committee meeting minutes |
| YAML / CSV | Machine-readable practice definitions & taxonomy | PDF / Word documents |
| JSON Schema | Artifact validation against published schemas | Manual editorial review |
| CI/CD | Automated validation on every proposed change | Ad hoc quality checks |
| Semantic versioning | Predictable release impact | "2024 Edition" with unknown scope |
| Pull requests | Transparent, public contribution process | Closed committee review |
| SHA-256 hashing | Deterministic, collision-resistant identifiers | Centrally assigned sequential numbers |
Current release
12 practices across 5 domains. The first numbered release and the minimum bar for Foundational compliance.
Licensing
Data layer
Practice YAML, taxonomy CSVs, release manifests — CC0 1.0 (public domain).
Specification documents
Framework, methodology, governance, contributor guide — CC BY 4.0 (free use with attribution).
Reference tooling
Validation scripts and reference implementation — Apache 2.0 (open source).
The 4GS identifier namespace (FGP-, FGR-, FGT-, FGC-) is a trademark of atypical. Identifier minting is a governed operation.