Practice catalogue
18 standard practices across 6 domains define what a fourth generation standard must implement. FGR-1.0.0 includes 12 of these as the Foundational release. A further 5 practices in the LLM Accessibility domain are proposed via FGC-00001.
Version Control & History
All standard artifacts are stored in version control
Every file that constitutes the standard — practice definitions, taxonomy tables, release manifests, and governance documents — is stored in a distributed version control system. Every change is recorded with author, timestamp, and an optional rationale.
Every change is attributable and permanently recorded
Every change to any standard artifact is permanently recorded with: the identity of the person who made the change, the timestamp of the change, and the content of the change. Changes cannot be silently overwritten.
Data Format
Practice definitions are stored as structured, machine-readable data
Practice definitions, criteria, taxonomy, and release manifests are stored in structured data formats (such as YAML or JSON) rather than as prose in word processor documents or PDFs.
The standard is natively machine-readable without extraction
The authoritative form of the standard is structured data: it does not require scraping, parsing, or extraction from a PDF or word processor document to be consumed programmatically.
The standard supports linked data export (JSON-LD)
The standard can be exported in JSON-LD format, enabling it to be traversed by AI systems, semantic web tools, and knowledge graph applications without manual curation.
Published documentation is auto-generated from source files
The human-readable published form of the standard is generated automatically from the structured source files. There is no divergence between the source data and the published documentation.
Identity & Versioning
Every concept has a stable, deterministic identifier
Every practice or concept in the standard is assigned a stable, canonical identifier derived deterministically from a normalised form of the concept name (e.g., via SHA-256 hash). Independent contributors arrive at the same identifier without coordination.
Concept identity is separated from version criteria
Each practice exists at two distinct levels: a concept (what the practice represents — stable, never changes) and a version (the specific criteria at a point in time). A new version is created when criteria change; the concept ID remains constant.
Releases follow semantic versioning with explicit change rules
Standard releases use semantic versioning (MAJOR.MINOR.PATCH) with defined rules for when each component changes. Consumers can determine the impact of a version change without reading the full changelog.
Identifiers are governed through a namespaced registry
The identifier namespace is governed: minting new identifiers requires authorisation from the designated standards body. The namespace prefix is distinctive and does not conflict with other standards bodies' namespaces.
Taxonomy
Taxonomy domain relationships are stored as a queryable graph
The taxonomy is stored as a graph structure (nodes and edges) in a structured, machine-readable format. The graph is queryable: a tool can retrieve all practices in a domain, traverse domain relationships, or identify practices that span multiple domains.
Taxonomy is versioned independently of practice definitions
The taxonomy has its own version identifier, separate from release versions and practice versions. Taxonomy reorganisations do not require modifying practice definition files and do not invalidate existing practice versions.
A practice may belong to multiple domains without changing its definition
Because taxonomy relationships are stored separately from practice definitions, a practice can be classified under multiple domains simultaneously without modifying the practice concept or version files.
Validation
Automated validation runs on every proposed change
A CI/CD pipeline automatically validates proposed changes before they are merged. Validation checks include schema conformance, identifier uniqueness, internal reference integrity, and other consistency rules.
All standard artifacts are validated against published schemas
A published schema (such as JSON Schema) defines the required and optional fields for each artifact type. Every artifact in the repository conforms to its schema. The schemas are versioned and stored in the repository.
Internal references are validated for integrity
All cross-references within the repository are checked for integrity: version files reference valid concept IDs, release manifests reference valid practice version IDs and taxonomy versions.
Governance
Changes are proposed through an open contribution process
Any person may propose changes to the standard through a public, structured process (such as pull requests). Proposals are visible to all community members. The discussion history of every accepted and rejected proposal is permanently recorded.
Proposed changes follow a structured, documented lifecycle
Proposed changes progress through defined lifecycle stages (Proposed → Candidate → Standard) with documented criteria for advancement. Proposals that are withdrawn or rejected are documented, preserving institutional memory.
LLM Accessibility proposed — FGC-00001
These five practices operationalise the "LLM-accessible" property of fourth generation standards, derived from production experience with XframeworkID and ACT-ID.io. See the LLM Readiness guidance for how to apply them.
The standard publishes an /llms.txt context file
The standard's canonical website publishes a plain-text markdown file at /llms.txt describing its purpose, current version, scope, key resource URLs, and what kinds of questions an LLM should answer using this source. Follows the llmstxt.org specification.
Every standard artifact has a stable, resolvable HTTPS URL
Every defined concept, criterion, version, and term is reachable at a permanent HTTPS URL that resolves without redirect, without JavaScript, and without authentication. URLs include the version where applicable. Superseded version URLs resolve forever.
Superseded versions explicitly declare the current version
Every page belonging to a superseded version carries a machine-readable and human-visible declaration identifying the current version and linking to it. The declaration is present in the static HTML response so LLM retrieval systems see it.
The standard publishes an LLM-ingestible companion document
A single comprehensive markdown document (typically /llms-full.txt) that an LLM can ingest in one fetch — containing the overview, version history, key terms, methodology summary, FAQ, and citation guidance. Under 200 KB, regenerated from authoritative source files.
The standard exposes an MCP server for programmatic LLM query
A Model Context Protocol server allows MCP-compatible LLM clients to query the standard's content, registry, taxonomy, and methodology programmatically through the chat interface. Listed in at least one public MCP registry.
Practice detail: FGP-4ukccp-v1
The only practice with a published version file. This shows the full structure of a versioned practice.
All standard artifacts are stored in version control
Required criteria
The standard's artifacts (practice/indicator definitions, taxonomy, release manifests, and governance documents) are stored in a public Git repository. The repository's commit history is publicly accessible. Every change to any artifact produces a commit with an author identity and timestamp.
Recommended criteria
Commit messages describe the rationale for changes. The repository uses branch protection rules so that direct pushes to the main branch are blocked; all changes arrive via pull request with review.
Rationale
Without version control, there is no authoritative record of what changed, when, or who authorised it. This is the foundational characteristic of fourth generation standards: the full institutional history of the standard is permanently recorded and publicly auditable.
Citation
Crystal-Ornelas, R. et al. (2021). A Guide to Using GitHub for Developing and Versioning Data Standards and Reporting Formats. Earth and Space Science, 8(8).
Want to propose a practice?
4GS is governed through an open contribution process. Anyone can propose new practices or revisions to existing ones.