Appendix B: Templates and Tools

This appendix is the directory of reusable templates and tools for governing algorithmic management, in the repository that accompanies AI Boss. Each artefact is designed to be copied into an organisation's own repositories, adapted to its collective agreements, works agreements and national law, and maintained under version control. The chapter that introduces each artefact is listed so that readers can find the rationale behind the design. Each artefact appears in full in the chapter that introduces it, as a worked example or practical guide; those also collected in Appendix A are linked there. None of the templates is legal advice, and none serves covert monitoring or the circumvention of workers' representatives' rights.

The governance templates of AI Governance, Appendix C, the platform and security templates of AI Platform and Security, Appendix B, the threat-register artefacts of AI Threat and the role, control and mandate artefacts of The Transformed Security Architect remain the reference for those subjects and are not repeated here.

Templates by activity

No.	Activity	Artefact	Where to find it	Introduced in
B.1	Definition	Management function inventory	Chapter 2	Chapter 2
B.2	Definition	Delegation profile (`DLG-*`)	Appendix A	Chapter 25
B.3	Records	Delegation register of management functions	Appendix A	Chapter 25
B.4	Records	Management Decision Record template (`MDR-*`)	Appendix A	Chapter 25
B.5	Oversight	Oversight record	Appendix A	Chapter 26
B.6	Oversight	Oversight-quality metric	Chapter 26	Chapter 26
B.7	Contestability	Contestation and appeal form	Chapter 27	Chapter 27
B.8	Contestability	Contestation record (`CNT-*`)	Appendix A	Chapter 27
B.9	Contestability	Explanation template	Chapter 27	Chapter 27
B.10	Transparency	Worker information notice	Appendix A	Chapter 28
B.11	Transparency	Transparency register	Chapter 28	Chapter 28
B.12	Co-determination	Co-determination checklist	Chapter 23	Chapter 23
B.13	Co-determination	Works agreement clause set for algorithmic management	Chapter 23	Chapter 23
B.14	Assessment	FRIA template for worker-management systems	Chapter 21	Chapter 21
B.15	Procurement	Procurement requirements for algorithmic management systems	Chapter 24	Chapter 24
B.16	Agents	Mandate manifest for agents a manager directs (`MND-*`)	Appendix A	Chapter 16
B.17	Agents	Decision-rights matrix for the management chain	Chapter 20	Chapter 20
B.18	Leadership	Manager's weekly review protocol	Chapter 29	Chapter 29
B.19	Leadership	Development without a score: conversation guide	Chapter 19	Chapter 19
B.20	Governance	One-page board report on algorithmic management	Chapter 32	Chapter 32
B.21	Experience	Anti-pattern checklist	Chapter 31	Chapter 31
B.22	Experience	Year plan for governing the AI boss	Chapter 32	Chapter 32

Template descriptions

B.1 Management function inventory

Purpose: Lists, for a team or role, which of the five management functions (M1 Direction, M2 Evaluation, M3 Consequence, M4 Development, M5 Care) are performed, by whom and with which systems.
When to use: Before any delegation decision, and whenever a system that touches people management is introduced or changed.
Inputs: Job descriptions, the HR process map, the system inventory, interviews with line managers.
Outputs: A table of functions, performers and systems per team, the starting point for a delegation profile.
Chapter: Chapter 2

B.2 Delegation profile (`DLG-*`)

Purpose: States the degree of delegation, Level 0 Advisory to Level 4 Autonomous, for each management function of one system or team, with who delegated it, the review date and the linked records.
When to use: When a system that performs a management function is procured, built, changed or reviewed; never with M3 Consequence at Level 4 Autonomous.
Inputs: The management function inventory, the system's documentation, reversibility of each decision class, the works agreement or negotiation record.
Outputs: A versioned profile in management/delegation-register.yaml, referenced from every Management Decision Record the system shapes.
Chapter: Chapter 25; fuller version in Appendix A

B.3 Delegation register of management functions

Purpose: Holds every delegation profile in one versioned register, extending the delegation register of AI Threat, Chapter 26, so that HR, a works council or a supervisor can see what is delegated where.
When to use: Continuously; reviewed at least annually and on every change to a profile.
Inputs: Delegation profiles, AIDRs, FRIAs, works agreements.
Outputs: management/delegation-register.yaml, with a pipeline check that rejects M3 Consequence at Level 4 Autonomous and profiles past their review date.
Chapter: Chapter 25; fuller version in Appendix A

B.4 Management Decision Record template (`MDR-*`)

Purpose: Records one management decision that AI made or shaped about a person: the function, the system and version, the recommendation, the named human decider, the basis, the explanation given and the contestation route.
When to use: For every M3 Consequence decision a system shaped, and for M1 Direction and M2 Evaluation decisions above the threshold set in the delegation profile.
Inputs: The system's output and logs, the decider's reasoning, the delegation profile.
Outputs: A record the person can see, contest and have corrected, retained for the period the profile sets.
Chapter: Chapter 25; fuller version in Appendix A

B.5 Oversight record

Purpose: Records a human review of an AI recommendation: what the reviewer examined, how long the review took, whether the outcome changed, and seeded-error results where used.
When to use: For every review that the delegation profile requires, and for sampled reviews at Level 3 Bounded.
Inputs: The recommendation, the evidence shown to the reviewer, the review outcome.
Outputs: Oversight records that feed the oversight-quality metric.
Chapter: Chapter 26; fuller version in Appendix A

B.6 Oversight-quality metric

Purpose: Measures whether oversight is real: override rate, detection rate for seeded errors, distribution of review times and the share of reviews that started from the AI's answer, building on The Transformed Security Architect, Chapter 14.
When to use: Monthly per system and team, and before any proposal to raise a degree of delegation.
Inputs: Oversight records, seeded-error schedule.
Outputs: A metric with thresholds that trigger retraining, a lower volume per reviewer or a lower degree of delegation.
Chapter: Chapter 26

B.7 Contestation and appeal form

Purpose: Lets a worker, or a representative on the worker's behalf, challenge a management decision in plain language, with the MDR identifier pre-filled where known.
When to use: Whenever a worker disagrees with a decision a system made or shaped; offered with every explanation.
Inputs: The MDR, the worker's grounds, any evidence the worker adds.
Outputs: A submitted challenge that opens a contestation record.
Chapter: Chapter 27

B.8 Contestation record (`CNT-*`)

Purpose: Records the challenge, the reviewer (who is not the original decider), the time limits, the outcome and any correction propagated to the data or the system.
When to use: For every contestation, from receipt to closure.
Inputs: The contestation form, the MDR, the reviewer's findings.
Outputs: A closed record linked to the MDR, and a correction ticket where the data or the system was wrong.
Chapter: Chapter 27; fuller version in Appendix A

B.9 Explanation template

Purpose: Gives the person affected the main factors behind a decision, the role of the system and of the human decider, and the route to contest, in the form AI Act Article 86 and GDPR Articles 13–15 and 22 require as the chapter verifies them.
When to use: With every M3 Consequence decision and on request for other decisions.
Inputs: The MDR, the system's factor output, the decider's reasoning.
Outputs: A plain-language explanation stored with the MDR.
Chapter: Chapter 27

B.10 Worker information notice

Purpose: Tells workers and their representatives which systems manage them, which functions each performs at which degree of delegation, which data it uses, which decisions it feeds and how to contest them, serving AI Act Article 26(7), the GDPR and the Platform Work Directive.
When to use: Before a system is put into service at the workplace, and on every material change.
Inputs: The delegation register, the DPIA and FRIA, the system documentation.
Outputs: A notice issued to workers and their representatives, dated and versioned.
Chapter: Chapter 28; fuller version in Appendix A

B.11 Transparency register

Purpose: Publishes, inside the organisation, the current list of systems that take part in managing people, with their worker information notices and delegation profiles.
When to use: Continuously; updated with every notice.
Inputs: Worker information notices, the delegation register.
Outputs: An internal register a worker, manager or works council can consult at any time.
Chapter: Chapter 28

B.12 Co-determination checklist

Purpose: Lists, per jurisdiction, the information, consultation, negotiation or consent steps that apply before a system that manages people is introduced or changed (for example BetrVG §87(1) no. 6 and §§ 94–95 in Germany, MBL in Sweden, the WOR in the Netherlands).
When to use: At the start of every procurement, build or material change of such a system.
Inputs: The system description, the delegation profile, the list of entities and bodies concerned.
Outputs: A completed checklist with dates, linked to the works agreement or negotiation record.
Chapter: Chapter 23

B.13 Works agreement clause set for algorithmic management

Purpose: Provides clauses for a works agreement or collective-agreement annex: purpose limitation, the level at which figures are shown, delegation limits per function, change notification, contestation and review.
When to use: When negotiating a new agreement or revising one for a new system.
Inputs: The delegation profile, the worker information notice, the co-determination checklist.
Outputs: Draft clauses for negotiation; not legal advice, to be adapted to national law.
Chapter: Chapter 23

B.14 FRIA template for worker-management systems

Purpose: Structures the fundamental rights impact assessment under AI Act Article 27 for a system listed under Annex III, point 4, covering the rights of workers and applicants, the categories of persons affected, oversight and contestation, aligned with the DPIA.
When to use: Before first use of a high-risk system by a deployer to which Article 27 applies, and on material change; a public authority completes it in every case where the Article requires.
Inputs: The delegation profile, the DPIA, the provider's instructions for use, consultation with workers' representatives.
Outputs: A versioned FRIA (for example FRIA-2026-007) and its notification as the Article requires.
Chapter: Chapter 21

B.15 Procurement requirements for algorithmic management systems

Purpose: Lists requirements to put into a tender or contract: per-function configurability of the degree of delegation, logs sufficient for MDRs, explanation output, contestation support, disabling of prohibited features such as emotion recognition, data access for works councils, and exit.
When to use: When procuring or renewing any system that performs a management function.
Inputs: The delegation profile, the co-determination checklist, the FRIA.
Outputs: Requirements as code attached to the tender, with acceptance tests.
Chapter: Chapter 24

B.16 Mandate manifest for agents a manager directs (`MND-*`)

Purpose: States the tasks, autonomy level, tools, data, approvals and accountable manager for each agent a person directs, reusing the form of The Transformed Security Architect, Chapter 13.
When to use: Before an agent joins a team, and on every change to its tasks or tools.
Inputs: The task design, the team's delegation profile, the platform's containment profile.
Outputs: A versioned manifest (for example MND-HM-CLM-01) that the platform enforces.
Chapter: Chapter 16; fuller version in Appendix A

B.17 Decision-rights matrix for the management chain

Purpose: Assigns, for each management function, who may direct, evaluate, reward and dismiss along a chain of people, agents and orchestrators, and where accountability ends.
When to use: When an orchestrator, a mixed team or a new management layer is introduced.
Inputs: The delegation register, mandate manifests, the organisation chart.
Outputs: A matrix under version control, referenced from delegation profiles.
Chapter: Chapter 20

B.18 Manager's weekly review protocol

Purpose: Gives a line manager a short weekly routine: review the MDRs and overrides of the week, sample oversight records, read open contestations, check pace and rest flags, and hold one development conversation that no system prepared.
When to use: Every week, for every manager whose team works under a delegation profile above Level 0 Advisory.
Inputs: The week's MDRs, oversight records, contestation records and M5 Care flags.
Outputs: A short log of actions taken, feeding the oversight-quality metric and the board report.
Chapter: Chapter 29

B.19 Development without a score: conversation guide

Purpose: Structures M4 Development conversations that do not start from a system's score, and records what the worker can do and wants to learn.
When to use: At least twice a year per worker, and when a worker's work is reallocated to agents.
Inputs: The worker's own account, the manager's observation, learning records.
Outputs: A development record held in the HRIS without ratings.
Chapter: Chapter 19

B.20 One-page board report on algorithmic management

Purpose: Reports to the management body on the delegation register, M3 Consequence decisions and their contestation rates, oversight quality, worker information, co-determination status and open risks.
When to use: Quarterly, and after any serious incident or ruling.
Inputs: The delegation register, MDR and CNT statistics, the oversight-quality metric, the AI threat register.
Outputs: One page with a decision requested of the board.
Chapter: Chapter 32

B.21 Anti-pattern checklist

Purpose: Lists the recurring anti-patterns of algorithmic management, from the rubber-stamped review and the appeal to the same system to the dashboard that becomes a disciplinary tool, each with its warning sign and remedy.
When to use: In design reviews, procurement and the annual review of the delegation register.
Inputs: The system and its delegation profile, oversight and contestation statistics.
Outputs: A completed checklist with remedies assigned.
Chapter: Chapter 31

B.22 Year plan for governing the AI boss

Purpose: Sets out a prioritised plan for an organisation's first year: inventory, delegation register, MDRs for consequence decisions, oversight metric, notices, co-determination and review.
When to use: When an organisation starts to govern algorithmic management, and each year after.
Inputs: The conclusions of Chapters 25 to 31 applied to the organisation.
Outputs: A plan with owners, dates and AIDRs (Nordvik Region AIDR-0600 to AIDR-0649, Hansa Mutual AIDR-0650 to AIDR-0699).
Chapter: Chapter 32

Repository tools

Tool	Purpose
`scripts/toc_definition.py`	Holds the table of contents and regenerates `book_index.json`, the MkDocs navigation and the chapter list in `BOOK_REQUIREMENTS.md`
`scripts/generate_outlines.py`	Regenerates the chapter briefs in `BOOK_BLUEPRINT.md` and outline files for chapters not yet written
`scripts/format_citations.py`	Derives citation labels from the bibliography
`scripts/renumber_sources.py`	Keeps the bibliography numbered 1..N without gaps or uncited entries
`scripts/check_mermaid_diagrams.py`	Renders and validates the diagrams