Chapter Authoring Guide

This guide is the operational checklist for anyone drafting or revising a chapter of AI Boss, whether a human contributor or an AI-assisted writer. Read BOOK_BLUEPRINT.md for the chapter brief, SERIES_FOUNDATIONS.md for the conclusions of Books 1–6 it builds on, EXAMPLE_ORGANISATIONS.md for the people-management profiles of Nordvik Region and Hansa Mutual, AUTHOR_PERSONA.md for voice, and STYLE_GUIDE.md for language rules before writing.

File layout

Chapter file: docs/NN_short_name.md, where NN is the two-digit chapter number from book_index.json.
Diagram source: docs/images/diagram_NN_topic.mmd. The rendered docs/images/diagram_NN_topic.png is produced by python3 scripts/check_mermaid_diagrams.py --write-missing and committed alongside the source.
No YAML front matter. The first content line is the H1 title with a Pandoc anchor: # Title {#anchor}.

Required structure

# Chapter Title {#chapter-anchor}

Opening paragraph that states what the chapter covers, why it matters to the reader and which of the five management functions it concerns (for example **M1 Direction** and **M3 Consequence**).

![Alt text describing the diagram](images/diagram_NN_topic.png)

*Figure NN.1: One-sentence caption.*

## First major section

Prose. Use ### subsections where they improve clarity.

## Further sections ...

## The debate                       (Chapters 11–15 only; see rule 16)

### The case for concern

### The case for calm

### Where the positions meet

### What can be done

## Verdict                          (Chapters 11–15 only)

### Across the usage modes          (or ### Across the degrees of delegation)

### Nordvik Region and Hansa Mutual

## Summary

Three to five paragraphs that recap the chapter, name the management functions it concerns and point to the next chapter.

## Sources

1. **Author, A. (Year).** *Title.* Publisher. ([N, Author, Year](36_references.md#source-N))

Rules

Language. Oxford-standard British English. Headings in sentence case except for proper nouns, the terms AI Architecture and Architecture as Code, and the names of the five management functions and the autonomy levels. Every heading starts with a capital letter. No em-dashes in prose; use a colon, a comma or a new sentence.
Length and weighting. Measured as prose (excluding code blocks and tables): numbered narrative chapters 3,600 to 5,500 words, companion chapters 3,500 to 6,500 words, unless the brief says otherwise. A chapter far below the range should be expanded with substance, not padding. A chapter that grows beyond about 6,500 words, or a single section beyond about 2,500 words that treats a distinct subject, should be split into a companion chapter of its own. The brief records each such weighting decision.
Diagrams. At least one Mermaid diagram per chapter. Use graph, flowchart, sequenceDiagram, quadrantChart, mindmap, or classDiagram. Apply Kvadrat classes (:::kv-primary, :::kv-accent, :::kv-highlight, :::kv-muted, :::kv-pattern) to key nodes. No emojis. Labels in British English. Keep node text short so that diagrams render at 1400 by 900 pixels. Do not use quotation marks inside node labels unless necessary, and avoid parentheses in labels (use square-bracket node syntax with plain text). Diagrams show people as roles (line manager, worker, works council), never as faces or caricatures.
Code. At least one fenced code block with a language identifier (yaml, json, python, bash, rego, sql). YAML and JSON must parse. Keep examples under 60 lines; longer versions belong in Appendix A.
Citations. Cite only sources that exist in 36_references.md, in the form ([N, Author, Year](36_references.md#source-N)), which renders as (N, Author, Year). Run python3 scripts/format_citations.py --fix to derive the author label and year from the bibliography; see STYLE_GUIDE.md for the label rules. Do not invent sources. Do not add entries to 36_references.md from a chapter branch; propose additions to the editorial team instead. Verify every article number, recital and judgment against its live text (EUR-Lex for EU law, the official national gazette or court database for national law and case law) before citing it, and list in your report every claim you could not verify.
Sources section. The final section is ## Sources, a numbered list, one entry per cited source, in the format shown above, with the source link at the end of each entry.
Europe first. Include at least one concrete European or public-sector consideration. Attribute legal statements to the instrument and article (for example AI Act Annex III, point 4; AI Act Article 26(7); GDPR Article 22; Directive (EU) 2024/2831, Chapter III; BetrVG §87(1) no. 6). Frame them as organisational and architectural implications, not legal advice. Where national law differs, say which member state's law the example uses.
Codify it. Show at least one artefact that belongs in version control.
Practical guides. Where a chapter prescribes protective or operational measures, include at least one practical guide the reader can follow: a ### Practical guide: <task> subsection with the purpose, the roles involved (line manager, HR, works council or union representative, data protection officer, the worker affected), numbered steps, a codified artefact where it helps, and a short definition of done. Prefer concrete defaults (time limits, thresholds, review intervals, response times for an appeal) over general advice, and say when a default must be adapted to the collective agreement, the works agreement or the organisation's risk appetite.
Worked examples in the chapter. Show, do not only tell. Where a chapter recommends an artefact (a delegation profile, a Management Decision Record, an oversight record, a contestation record, a worker information notice, a mandate manifest, a policy, an AI Decision Record, a works agreement clause, a checklist), include at least one complete, realistic example in that chapter, at the point where the concept is explained, as a ### Worked example: <artefact> subsection marked as illustrative. Examples live in the chapter they illustrate, as in Architecture as Code; Appendix A holds only fuller versions of artefacts that a chapter introduces. Use the shared fictional organisations Nordvik Region (a regional public authority in a Nordic EU member state) and Hansa Mutual (a multinational mutual insurance group headquartered in Germany, operating inside and outside the EU) for continuity, keeping every fact consistent with their canonical profiles and people-management profiles in docs/EXAMPLE_ORGANISATIONS.md; a new fact goes into the profile in the same change. Use the identifier ranges of this book: MDR-NR-0001 onwards for Nordvik Region and MDR-HM-0001 onwards for Hansa Mutual, AIDR-0600 to AIDR-0649 for Nordvik Region and AIDR-0650 to AIDR-0699 for Hansa Mutual, and DLG-*, CNT-* and MND-* for delegation profiles, contestation records and mandate manifests. Make sure every YAML and JSON block parses. Every narrative chapter also ends, before its Summary, with a short ### Nordvik Region and Hansa Mutual subsection that states how the chapter's subject plays out for each organisation and where they differ. Chapter 30 follows four people through a year with the AI boss (Ingrid Halvorsen, Nordvik Region's HR director; Mikael Strand, unit manager of the Strandvik home-care unit; Jana Petersen, claims team leader in Hamburg at Hansa Mutual; and Thomas Brandt, chair of Hansa Mutual's Konzernbetriebsrat, as EXAMPLE_ORGANISATIONS.md profiles them), and Chapter 32 draws the chapters together into a conclusion for each organisation.
Five management functions as red threads. Chapter 2 defines the five management functions, and every chapter uses them by these exact names: M1 Direction (assigning, sequencing, pacing and instructing work); M2 Evaluation (measuring, rating and judging performance and conduct); M3 Consequence (hiring, pay, promotion, discipline, dismissal, deactivation and access to work); M4 Development (feedback, learning, coaching and career); M5 Care (safety, health, wellbeing, voice and the duty of care). Every chapter in Parts II to VI names, in its opening and its Summary, which management functions it concerns, by the exact names; Part I defines the functions and Part VII concludes them. Every narrative chapter has an ### Across the usage modes or ### Across the degrees of delegation subsection, normally a compact table. Use the usage modes by their exact names (Mode 0 Ambient AI, Mode 1 Conversational assistants, Mode 2 Embedded workplace assistants, Mode 3 Agentic work tools, Mode 4 Built AI applications, Mode 5 Autonomous production agents; AI Governance and AI Platform and Security, Chapter 2). The degrees of delegation reuse the autonomy levels of AI Red Team, Chapter 6, by their exact names, applied per management function: Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded, Level 4 Autonomous. A delegation profile states the level per function for a given system or team. The mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action. Level 4 Autonomous is never used for M3 Consequence: every consequence decision about a person has a named human decider who can be identified, contested and held to account.
Observable, expected, speculation. Every statement about the future of work, management or the technology carries one of the three labels of AI Governance, Chapter 22: observable (happening now and documented), expected (supported by a stated trend or a decided instrument, such as the transposition deadline of the Platform Work Directive on 2 December 2026), or speculation (plausible but unsupported by present evidence). The author's own projections are confined to Chapters 29 and 33 and labelled as the author's judgement; elsewhere, attribute forecasts to the source that makes them and label them.
Cross-references. Refer to other chapters of this book as "Chapter N". Refer to the earlier volumes in plain text, without a link, as "Architecture as Code (Chapter N)", "AI Governance, Chapter N", "AI Platform and Security, Chapter N", "AI Red Team, Chapter N", "AI Threat, Chapter N" and "The Transformed Security Architect, Chapter N", using the tables of contents in SERIES_FOUNDATIONS.md, and cite them as (Nordqvist, 2025) for Architecture as Code or (Nordqvist, 2026) for Books 2–6. Summarise just enough of an earlier volume's content that the reader is not left with a gap, and state explicitly when a chapter builds on a conclusion recorded in SERIES_FOUNDATIONS.md (F1–F80). The series builds strictly in publication order, so that there is no circular reasoning between the books: Architecture as Code (Book 1) refers to no other volume, AI Governance (Book 2) only to Book 1, AI Platform and Security (Book 3) only to Books 1–2, AI Red Team (Book 4) only to Books 1–3, AI Threat (Book 5) only to Books 1–4, The Transformed Security Architect (Book 6) only to Books 1–5, and AI Boss (Book 7) only to Books 1–6. Never refer to a later volume. Every new claim either cites an external source or is the book's own conclusion, drawn in a conclusions section or summary; a reference to an earlier volume builds on that volume's conclusions and never stands in for an external source for a factual claim. tests/test_series_references.py enforces the order.
Defensive and constructive. This is a book about governing the management of people, and it helps organisations, managers, workers and their representatives to do that well. Never include instructions for covert monitoring of workers, for defeating or circumventing the rights of works councils, unions or workers' representatives, or for evading labour law, data protection law or the AI Act, even as illustrations or counter-examples. Describe monitoring, scoring and profiling systems at the level needed to assess, negotiate and govern them: what they measure, what they infer, who sees the result and what decisions it feeds. Code examples are Management Decision Records, delegation registers and delegation profiles, oversight records, contestation records, worker information notices, mandate manifests, policies and decision records, not monitoring tooling.
Voice. No marketing language, no hype, no anthropomorphism, no rhetorical questions as transitions, no filler openers. Active voice, imperative mood for instructions. Describe workers, managers and representatives with respect: never call anyone lazy, stupid or replaceable, and describe effects on people by what studies measured.
Constructive debate in Part III. Chapters 11 to 15 each contain a ## The debate section with four subsections, in this order: ### The case for concern (the strongest version, in the words and with the evidence of those who hold it), ### The case for calm (the strongest sceptical or optimistic version, treated with the same charity), ### Where the positions meet (the facts and measures both sides accept), and ### What can be done (concrete actions for workers, managers, employers, workers' representatives and public authorities). It is followed by ## Verdict, which labels the outlook observable, expected or speculation and states what people and organisations can influence. State each position at its strongest; never caricature a position or use labels such as "Luddite" or "techno-optimist" in place of an argument. Separate what a source reports from interpretation: say what was measured, in whom, over what period and with what method before saying what it means. Describe effects on people (autonomy, stress, health, fairness, voice) by what studies measured, not by adjectives. Keep the author's own projections for Chapters 29 and 33, and end every chapter with something the reader can do. Other chapters may stage a shorter debate in the same form where the brief asks for one.
No anthropomorphism, and "decides" only where a decision was delegated. An AI system ranks, assigns, flags, scores, recommends or drafts; it does not want, judge, trust or decide in the human sense. Write "the scheduling system assigned the shift" or "the screening model ranked the applicant 212th", not "the algorithm decided she was unreliable". Use "decides" for a system only where a decision was formally delegated to it, and then name, in the same passage or the Management Decision Record, who delegated it, under which delegation profile and at which level. Because Level 4 Autonomous is never used for M3 Consequence, no system "decides" a consequence for a person in this book's recommendations; where a chapter describes a system that does so in practice, it says so as a finding and names the gap.

Before you submit

python3 -m pytest tests/test_completeness.py tests/test_consistency.py tests/test_reference_consistency.py -q
python3 scripts/check_mermaid_diagrams.py --write-missing
python3 scripts/audit_references.py