Methodology

The Body of Knowledge is 24 chapters in five parts, plus the Thesis and the datasets the site renders from them. This page says how that text is sourced, dated, checked, corrected and released. The rules themselves live in the repository, in STYLEGUIDE.md and CONTRIBUTING.md; this page is their summary for readers.

How sources are chosen

• Every number carries a source. No statistic, date, version or quote appears without a numbered citation. A figure that cannot be sourced is cut, or the sentence is rewritten so it does not need one.
• Primary first. The book cites the official text wherever it can open it: the regulation in the official journal, the legislature's bill, the regulator's own page, the standards body's listing, the original paper. The text of EU law is cited to its EUR-Lex identifier (ELI) or the consolidated text; a third-party explorer or commentary is at most a secondary reading.
• Vendor claims are attributed. A claim carried only by a vendor (a comparison blog, the vendor's own survey, its account of an analyst report) is attributed to that vendor in the sentence, never stated as a fact about the market; the analyst or official source is cited instead or beside it when it exists.
• No expiring evidence. A claim never rests on a job posting or any other URL that expires or gets reassigned. Without stable evidence the claim is removed or reworded.
• Paid standards by identifier. ISO/IEC and other paid standards are cited by identifier and title and paraphrased; the book does not reproduce their text.
• Categories, not brands. Tools are named only as examples of a category, never as a recommendation: every tool list is illustrative, not exhaustive and not an endorsement.

How sources are tagged

Citations are numbered per chapter and restart at [1] in every file. Each one is listed under the chapter's own Sources heading in the house format (title, publisher, date, URL) with one of three verification tags:

primary

The official primary source was opened: the regulation text, the standards body, the organisation's own release, the report itself.

secondary

A reputable outlet reporting a primary fact that could not be opened directly.

reported

A claim carried only by secondary sources, or a figure the primary does not state verbatim. Copy that uses a reported fact says "reported" in the sentence.

Every citation also has a row in the consolidated table, sources/SOURCES.md, under its chapter's section and with the same number, so one file lists every source the book relies on. An already verified row is reused rather than re-verified. A crosswalk reference that could not be checked against its source stays marked unverified, with a note saying why.

The registers the pages render (the obligations, the crosswalk, the glossary, the patterns and the rest) are also published as open data, one JSON file per dataset with its schema, so a reader can check a mapping against the same rows the page shows.

How dates are kept current

Anything that can change (the status of a harmonised standard, a draft, a grace period, the application date of a law, the edition of a report) carries an "as of" stamp with the date it was last verified online, in the form as of 2026-09-24. The stamp moves only when the claim is re-verified, never when the page is merely edited. The text does not use expressions relative to the time of writing ("in the last two years", "to date") where a date fits. EU AI Act dates are the dates in force after the Digital Omnibus.

Separately, every chapter shows the date of its last change, read from the repository's history at build time, so a reader can tell a recent edit from a recent verification.

Review cadence

• Release passes. Before a release, the chapters it touches are fact-checked and their "as of" stamps re-verified. The passes so far are dated in the header of sources/SOURCES.md: the v0.1 baseline on 2026-09-10, the v0.3.1 and v0.4.0 passes on 2026-09-19, a debt and date pass on 2026-09-24, and the v0.5.0 fact-check pass on 2026-09-24 and 2026-09-25.
• Weekly link check. Every Monday a scheduled workflow checks the external links in the Thesis, the chapters, the sources table and the site's data files, and keeps the results in a single open "Link rot report" issue.
• Daily regulatory watch. A daily regulatory change monitor watches the official pages the site cites and opens an issue for a person to review when one changes; nothing is published automatically.
• On every change. Each pull request and each push to the main branch runs the build, the test suite and the accessibility audit in continuous integration, followed by a Lighthouse audit that reports without blocking.

What the build checks

A change that breaks one of these rules fails the build, so it cannot be published:

• Type check and build of the whole site, with every chapter matched 1:1 to its entry in the chapter manifest.
• Content lint: the built pages are scanned for the retracted or unverifiable claims on the house blocklist, and for the em dash the house style forbids.
• Link check: every internal link and every #anchor must resolve to a real page and heading.
• Schema check: every JSON Schema in the templates library parses, every filled example validates against its schema, and the schemas stay compatible with the shapes the patterns chapter publishes.

The test suite adds data checks: for example, every anchor a dataset points at must exist as a heading in its chapter, so a renamed heading cannot silently break the map, the stack or the learning path.

Corrections and contributions

Everything is in a public repository. Found something wrong? Open the form that fits; each one asks for the page and, for new content, the primary source and its verification tag:

• Report an error on a page: a wrong fact, a dead or wrong source, an outdated date or a broken page, with its URL.
• Suggest a source: a stronger primary source, or a claim that needs one.
• Propose an obligation row: an obligation, the artefact that evidences it and its stack layer, for the regulatory map.
• Propose a glossary term: a term, its one-paragraph definition, its source and the chapter that treats it.
• Propose a case study: a public AI incident, its primary record and the control that would have caught it.
• Sign the Thesis: your name under the definition, values and principles.
• Review a control: one control of an open control profile, checked against a system you know or the sources it cites.
• Propose a failure mode: a way an AI system or agent fails that a control should catch, with the record that shows it.
• Share an implementation example: how you implement a control or pattern, and the evidence it leaves behind.
• Propose a framework mapping: a control mapped to a clause of a law, standard or framework, with the official source.
• Propose a technical correction: a wrong requirement, evidence statement, mapping, threat id, version or date in a control or research note.
• Review a research note: a research note, or one of its claims, checked against the sources it cites.

Or open a pull request that follows the style guide: every factual claim with a tagged citation and its row in the sources table, categories rather than vendors, no invented figure. A corrected fact ships as a patch release and is recorded in the changelog.

Authors, reviewers and contributors are defined in bok/CONTRIBUTORS.md and credited on the contributors page: accepted substantive contributions and completed reviews are credited by name, and neither changes the stated authorship unless expressly agreed.

Versioning and DOI

Versions follow semantic versioning in spirit¹: a patch release fixes facts and typos, a minor release adds chapters or patterns, and 1.0 will mark a completed, reviewed core. Every change is recorded in the changelog. This is v0.5.0.

Releases are archived on Zenodo. v0.5.0 has the DOI 10.5281/zenodo.22956197; the concept DOI 10.5281/zenodo.22857084 represents every version². Citation metadata lives in CITATION.cff, and every chapter offers a ready-made citation and BibTeX entry.

Control profiles: versioning, status and review

The open control profiles and the research notes are versioned on their own, apart from the book. Each profile and each note carries its own semantic version¹ and a status shown beside it: a research note is draft, review or published; a control profile and each of its controls is draft, in review, stable or retired. Today every profile and every note is a draft, open for technical review.

• Published means reviewed. A note is published, and a profile or control marked reviewed or stable, only when a named reviewer is credited in bok/CONTRIBUTORS.md. Until then it says "Open for technical review".
• Every version bump is recorded. A substantive change (a requirement, an evidence statement, a mapping, a claim) bumps the version and adds a changelog line: in the profile's own changelog, or in bok/CHANGELOG.md for a note. A wording fix that does not change the meaning needs no bump.
• What a review is. A review is a written objection or confirmation against the sources the control or note cites, filed in the open through one of the review forms listed under corrections and contributions. An objection that holds changes the text and bumps the version; a confirmation is credited by name.
• No claim without evidence. No reviewer, endorsement or adoption is named on the site unless it can be pointed to: a credited review, a public issue or a public implementation.

What this is not

The book is not a compliance checklist and not legal advice: it describes how to build the controls and the evidence that let someone qualified decide whether a system complies. Every mapping to a law or a standard is illustrative, not a claim of conformity.

Sources

1. [1] Semantic Versioning 2.0.0 (MAJOR.MINOR.PATCH: increment MAJOR for incompatible changes, MINOR for backward-compatible additions, PATCH for backward-compatible fixes). semver.org (originally authored by Tom Preston-Werner). Undated. https://semver.org/spec/v2.0.0.html (verified: primary)
2. [2] What is DOI versioning? (a Version DOI identifies one version of a record; a Concept DOI represents all of its versions). Zenodo. 2026-04-11. https://support.zenodo.org/help/en-gb/1-upload-deposit/97-what-is-doi-versioning (verified: primary)