How to contribute

This book has one rule that overrides every other consideration: a claim needs a primary source someone personally opened, or it does not go in. A CVE ID, a version number, a quote, a statistic - each one is only as good as the record behind it, and a security reference that gets a fact wrong is worse than one that says less. Every process described below exists to hold every contribution, the maintainer’s own included, to that standard.

Two tiers of content

• Author-verified. The chapters, the incident board, and the reference library as they stand are written and fact-checked by the maintainer, with every factual claim traced to a primary source at the time of writing. Dated - the field moves, and a claim that was true in July can be stale by September. Check the changelog for what’s been re-verified recently.
• Community-submitted, pending review. Contributions via GitHub go through the same citation standard before merging, reviewed by a human who opens the sources - CI checks structure, not truth (see below). Until a submission merges, it isn’t part of the book.

There is no third, lower-scrutiny tier. A contribution either meets the bar or it doesn’t merge - “good enough for now” is not a standing the incident board or a chapter gets to hold.

What to contribute

• New incident-board rows - a real, sourced security event with a practitioner lesson. The board’s own note on how to read it explains the format.
• Corrections - a claim that’s wrong, stale, or no longer matches its source. These are usually the fastest contributions to review: cite what’s wrong, cite what’s right.
• New chapters - the book is organized by system layer, then by what you do with each layer (see the sidebar), with a numbering scheme ([I.x] through [VIII.x]) that roughly 950 in-body cross-references depend on. A new chapter needs an agreed home before it’s worth writing - propose it as an issue first.
• Reference library entries - a primary source worth citing that isn’t there yet.

The mechanics

The book’s repository is github.com/anguiz7z/aisecurity-zone. CONTRIBUTING.md has the full process: house style, the exact citation standard, and how to run the build locally.

Most of what could drift in a book this size - the table of contents, the chapter numbering, the risk-ID index, cross-reference labels - is generated from the content by scripts, not hand-maintained. A contributor almost never edits navigation directly; write the content, and the build derives the rest. It will refuse to build if something is inconsistent - a link to a page that doesn’t exist, a page that links to itself, an unlabeled cross-reference.

What CI checks, and what it cannot

Every pull request runs through an automated check: does the site build, do all internal links resolve, are there any em or en dashes (house style is a spaced hyphen), does every cross-reference carry a chapter name rather than a bare number. That catches structure.

It cannot check whether a citation is real or says what the contribution claims. That is a human review step, every time, with no exception - a green CI run checks that the site builds and the links resolve, not that a cited CVE record actually says what the text claims. Open every source before you trust the claim built on it.

License

Book content is CC BY-NC-SA 4.0 - free to share and adapt with attribution, non-commercially, if you share your own changes under the same terms. Site code and tooling are MIT. Full text in LICENSE.md in the repository.