Typed Standards: relations to public projects

How Typed Standards was used here

Typed Standards, in its own record (core.md): A specification for signed records of how analytical artifacts were produced, including AI-assisted analyses of public data, with a reference producer, a reference verifier and a reference publishing application. Its mission: Make how an analytical artifact was produced checkable by anyone, offline, without trusting its publisher.

What was produced. Two signed records: package/core.bundle.json for core.md, and package/map.bundle.json for map.yaml. Each record carries:

• the file's exact bytes and their SHA-256, a 64-character fingerprint that changes if any byte changes;
• the sources the fetch program used, each with its location, SHA-256, size, HTTP status, fetch time and licence: 34 in the map record and 11 in the core record, 5 of them in both, out of the 40 recorded in corpus/manifest.json;
• the two programs that made the file, each named by the SHA-256 of its code;
• two labels. The profile says a script wrote the file and can write it again. The capture method says the packaging program read the finished file rather than watching the writer run. Nothing verifies that label (docs/verify-output.txt, line 15);
• the signer: a key that names itself, with no registry, account or person behind it.

How it was made.

1. corpus/pin.mjs fetched each source once and pinned it: it recorded the SHA-256 of what the location served. Then it wrote core.md and map.yaml from the list in corpus/sources.json and those pins.
2. package/build.mjs read the two finished files, then packaged and signed each one.

The key was generated for this example, outside the repository. It is now held in the publisher's 1Password vault, and signing runs only in the publisher's own terminal.

What you can check. After cloning the repository, in a terminal:

• Both records verify offline: npm ci && node verify.mjs. The output should match docs/verify-output.txt, whose line 46 reads network: global fetch calls 0; injected fetch calls 0.
• Each file is byte for byte what was signed: shasum -a 256 core.md map.yaml prints the SHA-256 that each record states for its file, as contentHash.sha256.
• Any pinned source can be fetched again and compared: node corpus/pin.mjs --force in a scratch clone, then git diff corpus/manifest.json.
• Both files can be written again from the pins, offline: node corpus/pin.mjs, then git diff --exit-code core.md map.yaml.
• The web page, docs/index.html, comes only from signed bytes: npm run check:page regenerates it and compares, and the generator refuses a signed file whose SHA-256 differs from its record.

What it does not establish. The table below marks five things as not covered: who holds the key, when the records existed, inclusion in a public transparency log, revocation of the key, and whether any statement in either file is correct. It marks four more as asserted: signed, but resting on the signer's word.

Why it was useful.

• The checks run offline on your own copy. They show that the files are what this key signed, whichever server delivered them, but not who holds the key.
• The source pins and the labels are inside the signed bytes, so changing any of them breaks check #1, which recomputes the hash of the whole signed record.
• A signed git commit also fixes bytes. A record is also self-contained, verifies offline against the specification's numbered checks, and carries its source pins and labels inside its signed bytes.
• Building this example ran into three gaps in the specification and its reference packages, all filed (docs/findings.md): two filed before (typedstandards#91, #88) and one found here (typedstandards#96, hub#230).

Terms used below.

• ref: a location, with the SHA-256 of what that location served.
• front matter: the YAML block between the two --- lines at the top of core.md.
• inline output: the file's bytes, carried inside the record. raw-bytes/v1 is the rule that they are carried exactly as they are.
• envelope: the whole signed record. The key signs its hash.
• did:key: an identifier made from the public key itself, so no registry is needed.
• Ed25519ph: the signature algorithm.

The map

• builds-on (12), circle and solid line. The subject implements, or normatively uses, the object's published specification or code.
• complements (7), square and dashed line. The two address different layers or artifact classes of one job and can be used together. Neither depends on the other.
• could-emit (1), triangle and dash-dot line. The subject's own public text states an intent to produce Typed Standards records, cited by URL and date.
• adjacent (14), diamond and dotted line. A related problem space. Neither depends on the other, and there is no public statement of an intent to emit or evaluate Typed Standards records.
• Dashed outline: the source has no fixed version, so it is not pinned (sha256 null). 1 edge.
• → ←In the tables, → marks an edge whose subject is typedstandards.org (typedstandards.org builds-on W3C PROV-O). ← marks one whose subject is the project in the row (civicaitools.org builds-on typedstandards.org).

What the map leaves out

No orbits edge

The published schema shows one edge type, orbits, from a satellite to a core. This map has no orbits edge. No core record exists in this domain to be the object of one, and the model says a core is never a satellite. Each edge names its relation in x-typedstandards.relation, because the published schema has no edge type for any of these relations.

map.yaml, x-typedstandards.edgeTypes

Not pinned (1)

• 34. Open-source AI foundation layer (Mila and Mozilla initiative) (https://mila.quebec/en/news/mila-and-mozilla-announce-new-initiative-to-build-trustworthy-open-source-ai-for-everyone): sha256 null. Only announcement pages exist, from Mila and from Mozilla, both dated 2026-09-17. No repository, specification or release is published, and an announcement page is not immutable.

Dropped (1)

Considered for the map and left out, with the reason map.yaml gives.

The core record: core.md

selfAssessment: satellite, typeDeclared: false.

Absence markers in the front matter (4)

Comment lines 6, 17, 18 and 19 of core.md. A YAML parser discards comments, so the generator reads them from the text.

Core responsibilities

The table from core.md (lines 90 to 99), whole. 5 of 8 verdicts read NOT DONE.

Every edge (34)

Every edge in map.yaml, in document order: the picture as text. → and ← as in the legend. Each edge's basis is in the collapsed table below.

What the records prove / what they do not

From README.md (lines 85 to 109), whole. README.md is not a signed record.

This section describes the offline output of verify-core as node verify.mjs prints it (docs/verify-output.txt).

Attested:

checkable by anyone from the bundles in package/. The row names the check that establishes it.

Asserted:

stated inside the signed bytes, but resting on the signer's word. No check establishes it.

Not covered:

nothing in this repository addresses it.

Provenance

generated from map.yaml @ 38945eb4cb3ac6528f77647e082778fa8d0ebc9afb66c8cc25508127ba8d155c, core.md @ c85c650af7c47608a27cff4f6760d3313d62ff18095e8f4f0fdb947df6aece3b, README.md @ 21f956a13e0f1a18065999baeee0e8fe010d9c5a55ff4c5318db562bd02f9d6a

Generated by site/generate.mjs in github.com/npstorey/typedstandards-core-satellite-example, with one YAML parser, yaml, pinned exactly. The page carries no generation time: it is a function of the three inputs alone.