DNS for machine-readable documentation. It maps COG identifiers to publisher-hosted content URLs. REGINALD does not host content — each publisher serves their own COGs from their own domain.
/api/v1/namespacescognovamx/cogs/{ns}/{name}/latest.jsoncanonical_urlcontent_hashThe publisher cryptographically attests their COG, proving "I wrote this and it is current." The attestation travels with the content.
REGINALD attests the pointer record with Ed25519, proving "this document was registered, validated, and conforms to specifications."
A COG is any document that carries MX metadata — a Certificate of Genuineness and Contract of Governance. An HTML page with Schema.org JSON-LD and <meta name="mx:*"> tags is a COG. A markdown file with YAML frontmatter is a COG. A JavaScript file with @mx:* JSDoc tags is a COG. The .cog.md extension is the human-readable naming convention for the markdown carrier format.
---
title: "Rancilio Silvia Pro X"
description: "Dual-boiler espresso machine with PID temperature control"
author: "Rancilio Group"
version: "2.1"
mx:
status: active
contentType: product
tags: [espresso, dual-boiler, pid]
maintainer: "product-team@rancilio.com"
reviewCycle: "quarterly"
expires: 2026-07-01
---
# Rancilio Silvia Pro X
The Silvia Pro X is a dual-boiler espresso machine...In the markdown carrier, the YAML frontmatter is for machines and the markdown body is for humans — same file, both audiences served. But markdown is just one carrier format.
Any file type can be a COG. The same trust and governance information travels in whichever carrier format suits the content:
| File Type | How MX Metadata Is Carried |
|---|---|
| HTML | Schema.org JSON-LD in <script type="application/ld+json"> plus <meta name="mx:*"> tags in <head> |
| Markdown | YAML frontmatter (--- delimiters) — the COG format |
| JavaScript | JSDoc comments with @mx:* tags |
| CSS | Block comments with @mx:* tags |
| Shell scripts | # --- YAML block with # prefix |
<!-- Schema.org for search engines and AI agents -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Rancilio Silvia Pro X",
"description": "Dual-boiler espresso machine with PID",
"offers": {
"@type": "Offer",
"price": "1299.00",
"priceCurrency": "GBP"
}
}
</script>
<!-- MX governance metadata -->
<meta name="mx:status" content="active">
<meta name="mx:contentType" content="product">
<meta name="mx:tags" content="espresso, dual-boiler, pid">
<meta name="mx:content-policy" content="extract-with-attribution">HTML pages use established standards first — Schema.org JSON-LD for structured data, Open Graph for sharing, Dublin Core for provenance. MX adds governance metadata (mx:status, mx:contentType, mx:content-policy) where those standards leave gaps. MX never duplicates what Schema.org already covers.
| Layer | Full Name | What It Proves |
|---|---|---|
| Certificate | Certificate of Genuineness | "This document is real" |
| Contract | Contract of Governance | "Someone keeps this accurate" |
Every COG carries both layers. The Certificate tells an AI agent whether to trust the content. The Contract tells it who is responsible for keeping the content current — with a named maintainer, a review cycle, and an expiry date.
A COG without an action block — documents, describes, certifies. The single source of truth for a product, API, or specification.
A COG with an action block — validates, generates, extracts, analyses. A Standard Operating Procedure that executes itself. The document is the programme.