Management Decisions as Records: Decision Records and the Delegation Register

Part VI turns the book's analysis into designs, and this chapter supplies the two artefacts on which the others rest. The Management Decision Record (MDR) records one management decision that AI made or shaped about a person: what the system proposed, who decided, why, what the person was told and how to contest it. The delegation register of management functions, management/delegation-register.yaml, records what has been delegated across the organisation, whether each delegation can still be undone, and where further delegation is frozen. The chapter defines both, gives their schema, shows how records arise from normal operation rather than from paperwork after the fact, places them among the other artefacts the book has introduced, and answers open question Q3: how a decision made by or with AI is shown to the worker, a works council, a court and a supervisory authority. It concerns all five management functions, with most weight on M3 Consequence, where every decision needs a record, and on M1 Direction and M2 Evaluation, where records are sampled; M4 Development and M5 Care enter through the decisions they touch.

A management decision flows from the system's proposal, with its version and inputs, through a named human decider to a Management Decision Record. Above it, the delegation register holds the delegation profiles, the sum of delegation per function and team, and the reversibility tests that freeze further delegation on failure. The record draws provenance from the system logs, can be contested, and evidence from contests re-opens the profile through an AI Decision Record. Four readers surround the record: the worker, the works council or union, a court and a supervisory authority.

Figure 25.1: The Management Decision Record and the delegation register: a decision flows from the system's proposal through the named human decider to the record, the register above it sets the degree and shows the sum of delegation, and four readers use the record for different purposes.

Why records

The series has argued for decision records since its first volume. Architecture as Code (Chapter 4) concluded that architectural decisions are kept as short, numbered, immutable records beside the code, with context, options and consequences, so that the rationale survives the people who made it (F8), and its closing chapter added that an AI-assisted decision without a traceable human rationale should receive a record, written retrospectively if necessary (F14) (40, Nordqvist, 2025). Nygard's original proposal is modest: each record has a title, a context, a decision, a status and consequences, is one or two pages long, is numbered sequentially and monotonically, and when a decision is reversed the old record is kept and marked superseded (16, Nygard, 2011). AI Platform and Security, Chapter 5, kept that discipline for AI Decision Records, added the fields AI needs, validated them against a schema and let evidence re-open them (F38) (42, Nordqvist, 2026). AI Governance, Chapter 11, concluded that evidence is a by-product of delivery rather than something assembled in audit season (F20) (41, Nordqvist, 2026), as Architecture as Code (Chapter 15A) had argued for evidence as code (F4).

An Architecture Decision Record is about a system; a Management Decision Record is about a person. That changes four things. The record is personal data, to be minimised, protected and deleted on time. It has a reader with rights, the person it concerns. It is evidence in disputes that may reach a labour court. And its volume is high, so it must be produced by the work rather than written beside it.

Accountability explains why the record is needed. Bovens defined it as a relationship in which an actor must explain and justify conduct to a forum, which can pose questions and pass judgement, and the actor may face consequences (121, Bovens, 2007). Chapter 4 named the forums for a management decision: the worker, the representatives, the labour court and the supervisory authority. Each can only question what it can see. The GDPR states the same principle for personal data: the controller shall be responsible for, and be able to demonstrate compliance with, the principles of processing, under Article 5(2) (5, European Union, 2016). Without a record, the forum has the system's logs and the decider's memory, which fades under challenge. The MDR names the actor, states the justification at the time and points to the evidence.

The Management Decision Record

A Management Decision Record is a short, numbered, immutable record of one management decision about one or more people that an AI system made or shaped. It is the sibling of the ADR and the AIDR, and it keeps their discipline: one decision per record, a sequential number that is never reused, a status, and supersession rather than editing. Nordvik Region numbers its records MDR-NR-0001 onwards and Hansa Mutual MDR-HM-0001 onwards. A correction after a contest produces a new record that supersedes the old one, so that the history of what was decided, and when it changed, survives.

The record has twelve groups of fields. Each answers a question that one of the four readers will ask.

Field group What it holds Who needs it most
Identity Number, schema version, date, status, superseded record if any All readers
Decision class and function The class from the decision-rights file (Chapter 20) and the management function, with any related functions Works council, supervisor
Person affected Pseudonymous reference per person, resolved only in the HR system; the group affected where a decision covers many Worker, data protection officer
Inputs and provenance Each input the system or the decider used, with its source system Worker, court
System and proposal System name, version or release, the proposal, flags raised, a pointer to the system's log Court, supervisor
Degree of delegation Delegation profile and version, and the level applied Works council, supervisor
Human decider Role and name of the person who decided or approved Worker, court
Changes and reasons What the decider changed or kept, and why, in the decider's words Worker, court
Information given To whom, when, through which channel and with what notice Worker, works council
Contestation The route, the deadline for a request and the answer time Worker
Correction Immediate and lasting corrections, and the change class they trigger Works council, function owner
Retention The rule applied and the date of deletion Data protection officer, supervisor

Three fields carry most weight. The person affected is recorded by pseudonymous reference, because the record travels to readers who should not see names, while the HR system resolves the reference for anyone with a right to know. The system's version and proposal make the decider's part visible: without them, a record of a decision that followed the proposal looks identical to one that departed from it. And the reasons are written in the decider's words, since a reason the system generated and the decider accepted is the system's reason, and a record that hides this creates the moral crumple zone that Chapter 4 described.

The degree of delegation field ties the record to the register: every MDR cites a delegation profile and version. Where a system acted within a Level 3 Bounded playbook, the MDR records the person who changed or confirmed the outcome, and the profile, approved by a named authority, stands as the decision for the rest.

When an MDR is required

Recording every management decision would bury the records that matter and turn the record into the monitoring instrument Chapter 13 warned against. The rule has four parts.

  1. Every M3 Consequence decision that AI shaped receives an MDR: every hiring decision on a ranked list, every pay proposal that used a score, every promotion, disciplinary step, dismissal or removal of access to work in which a system took part. There is no sampling here, because each decision can be contested individually and the law treats each as individual.
  2. Every decision the delegation profile names receives an MDR. For DLG-NR-ROS-01 that is every approved roster and every change by a manager; for DLG-HM-CTA-01 every reassignment that overrides the agent, but not every allocation (Chapter 4).
  3. A sample of M1 Direction and M2 Evaluation decisions receives an MDR generated automatically for oversight, so that patterns can be examined without recording every assignment. Default: a random two per cent per decision class and month, with a minimum of twenty, adjusted to volume and agreed with the representatives.
  4. Every contested decision receives an MDR, whether or not the original decision had one, and the decision after review receives a new MDR that supersedes it. A contested decision without a record is reconstructed from the logs and the decider's account and marked as reconstructed, following F14.

Decisions in M4 Development and M5 Care need an MDR when they fall under one of the four, as a nomination for a leadership programme or an overridden protective block does.

Records by operation

A record that depends on the decider writing it after the decision will be incomplete when it matters most, in the busy weeks and the difficult cases. The MDR is therefore generated from two sources the work already produces: the system's events and the decider's action.

The system's events supply the proposal, the inputs, the version and the flags. High-risk AI systems must technically allow the automatic recording of events over the lifetime of the system, with logging capabilities that support the identification of risks, post-market monitoring and the deployer's monitoring of operation, under Article 12(1) and (2) of the AI Act (1, European Union, 2024). Deployers must keep the logs under their control for a period appropriate to the intended purpose, of at least six months unless Union or national law provides otherwise, under Article 26(6). ShiftWise, deployed by Nordvik as high-risk under Annex III, point 4(b), therefore produces events from which the MDR draws. The MDR does not copy the log; it points to the log entry and records what the decider saw. The log answers what the system computed, and the MDR answers what the organisation decided.

The decider's action supplies the decision, the changes and the reasons. The approval screen is where the MDR is completed: the unit manager who approves a roster sees the system's flags, makes changes, and for each change selects or writes a reason before the roster can be published. The claims team leader who reassigns claims records the reason in the reassignment dialogue. A reason field required only for changes slows departures from the proposal and leaves acceptances unexamined, so every M3 Consequence decision asks for a short reason on acceptance as well, and Chapter 26 measures how long decisions take.

The usage mode determines how much of this can be automated. Mode 4 Built AI applications and Mode 5 Autonomous production agents emit events that the organisation controls and can turn into records. Decisions shaped by Mode 1 Conversational assistants, Mode 2 Embedded workplace assistants or Mode 3 Agentic work tools leave no event in a management system: a manager who asks a conversational assistant to draft a rating, or accepts an embedded assistant's list of task owners, is the only one who knows the assistant took part. The MDR for such a decision must carry a field in which the manager records the assistant's part, and the delegation register records which modes touch each function, so that an organisation knows where records depend on the manager's honesty and where they can be generated.

Decisions about the systems themselves, such as adopting a profile or removing throughput from allocation as Hansa did in AIDR-0651, remain AI Decision Records. The MDR cites the AIDR and profile version in force; the AIDR cites the MDRs and contestation records that gave rise to it, so a pattern of overrides re-opens the profile, and the change is visible in every later MDR.

Schema, validation and change

The MDR is kept as code: a YAML file per record in version control or an append-only store, validated against a schema in the same pipeline that validates the delegation profiles. JSON Schema, in its 2020-12 version, describes the structure that a JSON document, or a YAML document read as JSON, must have (242, Wright et al., 2022). A schema turns the book's rules into checks that a machine can run on every record.

# management/schemas/mdr.schema.yaml (illustrative excerpt, JSON Schema 2020-12)
$schema: https://json-schema.org/draft/2020-12/schema
title: Management Decision Record
type: object
required: [id, schema_version, date, decision_class, function, trigger,
  affected, system, delegation, decider, reasons, information_given,
  contest, retention]
properties:
  id: {type: string, pattern: "^MDR-(NR|HM)-[0-9]{4}$"}
  schema_version: {const: "1.0.0"}
  status: {enum: [decided, superseded, reconstructed]}
  supersedes: {type: string, pattern: "^MDR-(NR|HM)-[0-9]{4}$"}
  function:
    enum: [M1 Direction, M2 Evaluation, M3 Consequence, M4 Development, M5 Care]
  trigger: {enum: [m3_decision, profile_rule, sample, contestation]}
  adverse: {type: boolean}
  affected:
    type: object
    required: [person_refs]
    properties:
      person_refs:
        type: array
        minItems: 1
        items: {type: string, pattern: "^(NR|HM)-PSN-[0-9A-F]{6}$"}
  system:
    type: object
    required: [name, version, proposal, log_ref]
  assistant_part: {type: string}   # required where Modes 1 to 3 shaped the decision
  delegation:
    type: object
    required: [profile, level]
    properties:
      profile: {type: string, pattern: "^DLG-(NR|HM)-[A-Z]+-[0-9]{2} v[0-9.]+$"}
      level:
        enum: [Level 0 Advisory, Level 1 Assisted, Level 2 Supervised,
          Level 3 Bounded, Level 4 Autonomous]
  decider:
    type: object
    required: [role, name]
    properties:
      name: {type: string, minLength: 3, not: {enum: [system, agent]}}
  reasons: {type: array, minItems: 1, items: {type: string}}
  information_given: {type: object, required: [to, date, channel]}
  contest: {type: object, required: [route, request_by, answer_within]}
  retention: {type: object, required: [rule, delete_after]}
allOf:
  - if: {properties: {function: {const: M3 Consequence}}, required: [function]}
    then: {properties: {delegation: {properties: {level: {not: {const: Level 4 Autonomous}}}}}}
  - if: {properties: {function: {const: M3 Consequence}, adverse: {const: true}}, required: [function, adverse]}
    then: {properties: {delegation: {properties: {level: {enum: [Level 0 Advisory, Level 1 Assisted]}}}}}

The two conditional rules at the end encode Chapter 4's rule for consequences: Level 4 Autonomous is never used for M3 Consequence, and adverse consequences go no higher than Level 1 Assisted. The decider must have a name that is not a system or an agent. Every record must name a retention rule and a contestation route. A record that fails is not stored, and the action is held until it is complete, which makes the record a condition of the decision rather than a report on it.

A small check in the pipeline joins the records to the register, so that an MDR cannot cite a profile the register does not hold, and a failed reversibility test cannot stand without a freeze.

# tools/check_management_records.py (illustrative)
import pathlib
import sys

import yaml
from jsonschema import Draft202012Validator

schema = yaml.safe_load(open("management/schemas/mdr.schema.yaml"))
register = yaml.safe_load(open("management/delegation-register.yaml"))
validator = Draft202012Validator(schema)
profiles = {p["id"] for p in register["profiles"]}
errors = []

for path in sorted(pathlib.Path("management/decisions").glob("MDR-*.yaml")):
    record = yaml.safe_load(path.read_text())
    errors += [f"{path.name}: {e.message}" for e in validator.iter_errors(record)]
    profile_id = record.get("delegation", {}).get("profile", "").split(" ")[0]
    if profile_id not in profiles:
        errors.append(f"{path.name}: profile {profile_id} is not in the register")

for test in register.get("reversibility_tests", []):
    if test["result"] == "failed" and not test.get("freeze"):
        errors.append(f"{test['id']}: failed test without a delegation freeze")

print("\n".join(errors) or "management records valid")
sys.exit(1 if errors else 0)

Change follows the discipline of the ADR. A record is never edited after it is stored. A correction is a new record with supersedes, and the old record's status becomes superseded. A change to the schema is itself an AI Decision Record, with a new schema version, because what an organisation records about decisions concerning its staff is a matter for the representatives as much as for the architects.

The delegation profile and the delegation register

Chapter 4 introduced the delegation profile (DLG-*): for one system or team, the degree of delegation per management function and action class, the named decider, the representatives' agreement, the stop path, the records the system must produce and the review triggers. A profile is a versioned file, adopted or changed by an AI Decision Record, and it is the management form of the mandate manifest of The Transformed Security Architect, Chapter 13 (F75) (46, Nordqvist, 2026).

The delegation register of management functions shows the organisation. AI Threat, Chapter 26, concluded that small delegations erode skill, process, capacity, interfaces and memory until the documented fallback no longer exists; that a delegation register shows the sum of what has been delegated; and that reversibility tests check that each delegation can be undone, with further delegation frozen where a test fails (F69) (44, Nordqvist, 2026). This book extends it to the management of people in four ways.

The sum per function and team. For each team or unit, the register shows how many systems touch each management function and the highest degree any of them reaches. This is how an organisation sees that three separately reasonable profiles leave a line manager little of M1 Direction to exercise, or that a function nobody meant to delegate, such as M2 Evaluation through a dashboard, is now performed by a system in every team.

Discovered, not decided. The register holds entries for features found rather than chosen, such as Mode 0 analytics in licensed software, with their status. Hansa's wellbeing and collaboration analytics, switched off pending agreement (AIDR-0670), and Nordvik's paused recruitment screening (AIDR-0601) both belong in the register, because a paused or switched-off delegation can be resumed by a configuration change.

Reversibility tests for management functions. The test asks of one function and team whether the unit could perform it without the system, at an acceptable level, for a defined period, and whether its managers still can. For M1 Direction that means planning rosters or allocating cases by hand. For M2 Evaluation it means judging work without the dashboard. For M3 Consequence it means deciding a shortlist from applications that have not been ranked. The result is recorded as passed, passed with conditions or failed, with findings, conditions, owners and dates.

The freeze. Where a test fails, or passes only with conditions, further delegation in that function and team is frozen until the conditions are met: no new action class, no higher degree, no extension to a new unit or entity. The freeze is entered in the register and enforced by the same pipeline that validates profiles, which rejects a new profile version that raises a degree in a frozen function. A freeze is not a stop. The system keeps running at the degree already agreed; what stops is the next step away from the way back.

The register also records the representatives' position per function and the oversight-quality metric of Chapter 26 against each Level 2 Supervised class, so that drift in practice is visible. It is what the management body receives, because what it answers for is the sum.

The record set

The book has introduced a family of artefacts, chapter by chapter. Read together they form one record set, in which each artefact has an owner, an event that creates or changes it, and a retention rule. The table gives illustrative defaults; national law, collective agreements, works agreements and an organisation's own archive rules decide the actual periods.

Artefact Identifier and file Owner Created or changed when Retention (illustrative default)
Function map FMAP-*, management/function-map.yaml (Chapter 2) Function owner Annual review; reorganisation Current and previous versions
Decision-rights file DRF-*, management/decision-rights.yaml (Chapter 20) Function owner; ceilings by the management body A ceiling or decider changes; annual review Every version while any record cites it
Delegation profile and register DLG-*, management/delegation-register.yaml (Chapters 4 and 25) Function owner New system, action class, degree, unit or entity; review date; failed test Every version while any record cites it
Feature register FTR-*, management/office-feature-register.yaml (Chapter 10) Function owner with system owner A vendor release adds or enables a feature As the register
Mandate manifest MND-* (Chapter 16) Line manager who directs the agents New agent, tool or permission As the profile
Chain record CHN-* (Chapter 17) Owner of the orchestrating agent A link is added to an agent chain; a stop drill As the profile
Team charter TCH-* (Chapter 18) Line manager Team composition changes; an agent joins Current and previous versions
Management Decision Record MDR-NR-*, MDR-HM-* (Chapter 25) Decider; generated by the system An M3 decision; a profile rule; a sample; a contest Per decision class, set by national law and agreement
Oversight record and metric OVR-* per profile and period, OQM-* metric (Chapter 26) Function owner Each review period for a Level 2 or Level 3 class Aggregates three years; individual data only as agreed
Contestation record CNT-NR-*, CNT-HM-* (Chapter 27) Reviewer outside the decider's line Any contest As the contested MDR, and until appeal routes close
Worker information notice and transparency register WIN-* per system, TRG-* register entry (Chapter 28) Function owner Before use; before a change affecting working conditions Every version while the system is in use
Disparate-impact test DIT-* (Chapter 12) Function owner with the data protection officer Before go-live; new model version; periodic Life of the system
Evaluation plan EVP-* (Chapter 15) Function owner Before a rollout wave; at each evaluation point Life of the system
Work risk assessment WRA-* (Chapters 6 and 14) Line manager with the safety representative New system; contest pattern; incident Under work-environment law
Competence record CMP-* (Chapter 19) The manager's own manager and HR Half-yearly; before a delegation requiring the competence Current and previous record
Reversibility test RVT-* (Chapter 25) Function owner After go-live; annually; before a profile is extended Life of the system
Stop drill SPT-* (Chapter 17) Owner of the system or chain Quarterly; after a change to the stop path Three years
Survey plan SVY-* (Chapter 11) Function owner with the representatives Before go-live; three and nine months after Aggregates for the life of the system
Platform Work Directive benchmark PWD-BENCH-* (Chapter 5) Function owner Before go-live; new action class; transposition Life of the system
AI Act control set AIA-* (Chapter 21) Function owner with the AI governance lead Classification trigger; change in the law Life of the system
Procurement requirement set NR-PRQ-* (Chapter 24) Function owner with procurement Each tender or contract review Life of the contract and its audit period
Role charter and horizon register ROLE-*, HZN-* (Chapter 29) The manager's own manager and HR New role or delegation; annual review Current and previous versions
Anti-pattern checklist AP-01 to AP-12 (Chapter 31) Function owner Before go-live; each quarterly review As the review record
Plan PLAN-* (Chapters 32 and 33) Function owner, endorsed by the management body Annual review; a revise-on trigger Every version while any record cites it
AI Decision Record AIDR-0600 to AIDR-0699 The decision's owner A decision about a system or profile Life of the system and beyond, as architecture records

The first four rows say what may be and has been delegated; the next three how agents and people are organised; the MDR, oversight and contestation records what was decided, whether the decision was real and whether it stood; the rest supply the evidence that re-opens them. Each record cites the others by identifier, never by copying their content, so that each keeps its own access rules.

Privacy and access

The MDR is personal data about at least two people: the person affected and the decider. Both are protected, and both must be able to read what concerns them.

Minimisation. The GDPR requires personal data to be adequate, relevant and limited to what is necessary, and kept in identifiable form no longer than necessary, under Article 5(1)(c) and (e) (5, European Union, 2016). For the MDR this means pseudonymous references in place of names for the persons affected, no health data even where health was the reason for a decision, and references to other records in place of their content. Hansa's MDR-HM-0001 shows the pattern: the record states that the handler worked an agreed reduced schedule and that no health data was recorded, because the reason is the schedule, not its cause.

The record of processing. Each controller must keep a record of processing activities stating, among other things, the purposes, the recipients and, where possible, the envisaged time limits for erasure, and make it available to the supervisory authority on request, under Article 30(1) and (4). The MDR store's entry should list the retention rule per decision class.

Retention by national law. Retention follows the time within which a decision can be challenged, and that differs by member state and decision class. Two examples show how. In Germany a claim for compensation for discrimination must be asserted in writing within two months, starting for an application or promotion when the rejection is received, unless the parties to a collective agreement have agreed otherwise, under AGG §15(4) (74, Germany, 2006), and an action must then be brought within three months of the written claim, under §61b(1) of the Labour Courts Act (244, Germany, 1953). Hansa therefore keeps a German hiring MDR for six months after the rejection and longer only where a claim has been asserted: a period chosen by the organisation to cover both deadlines, not one the statute prescribes. In Sweden, which this book uses as the example for Nordvik's national law, a public authority's archive is formed of its official documents, official documents may be disposed of with regard to the archive's purposes, and other statutes on disposal take precedence, under sections 3 and 10 of the Archives Act (241, Sveriges riksdag, 1990). Nordvik's retention of a roster MDR is therefore a disposal rule under its archive rules, decided as AIDR-0629, not a setting of the rostering system. The AI Act's minimum of six months for logs under Article 26(6) applies alongside, to the logs, not the MDR.

Public access. A public employer adds a reader that a private one does not have: the public. Under the Swedish example, an MDR held by a regional authority is an official document, and secrecy in personnel administration covers information about an individual's health and personal circumstances in a matter of redeployment or retirement where disclosure may cause harm, but does not apply in matters of appointment or discipline, under chapter 39, section 2, of the Public Access to Information and Secrecy Act (243, Sveriges riksdag, 2009). As an organisational implication, a public authority's MDR should be written on the assumption that much of it may be released on request, which is one more reason to keep health information and names of colleagues out of it.

Access for the decider and the representatives. The MDR records how a manager decided, how quickly and how often against the system. In Germany, technical equipment objectively suited to monitor employees' behaviour or performance falls under the works council's co-determination right in BetrVG §87(1) no. 6, whatever the employer intends (9, Germany, 2001) (71, Bundesarbeitsgericht, 2016). An MDR store is such equipment with respect to the deciders. Its access rules, the purposes it may serve and the level at which its data reach the works council are therefore agreed before it is used. Hansa's agreement, recorded as AIDR-0679, is that the Konzernbetriebsrat sees MDRs aggregated by team, and that MDRs are not used to evaluate a decider except through the competence record of Chapter 19, whose terms are agreed separately.

The resulting access rules are simple. The person affected reads every MDR that names them; the decider reads their own; the function owner and a contest's reviewer read their class; the representatives read aggregates, and individual MDRs where the person asks them to act. Nobody else reads an individual MDR by default.

One record, four readers

Open question Q3 asks how a management decision made by or with AI is shown to the worker, a works council, a court and a supervisory authority. The MDR is designed so that one record answers all four, each through a different view.

The worker needs to know who decided, what the system contributed, why, and how to contest. Under Article 86(1) of the AI Act, a person subject to a decision taken by the deployer on the basis of the output of a high-risk system listed in Annex III, which produces legal effects or similarly significantly affects them in a way they consider adverse to their health, safety or fundamental rights, has the right to obtain clear and meaningful explanations of the role of the AI system in the decision-making procedure and of the main elements of the decision taken (1, European Union, 2024). The Digital Omnibus did not move Article 86 (2, European Union, 2026). The MDR's system field supplies the role of the AI system and its reasons field the main elements. Where a decision is solely automated within Article 22(1) of the GDPR, the data subject may require the controller to explain, in a concise, transparent, intelligible and easily accessible form, the procedure and principles actually applied, and information the controller claims as a trade secret goes to the supervisory authority or court for balancing (65, CJEU, 2025). For platform work, the Platform Work Directive requires a written statement of reasons for any decision taken or supported by an automated decision-making system to restrict, suspend or terminate an account, refuse payment or affect the essential aspects of the contractual relationship, at the latest on the date it takes effect, and an adequately substantiated written reply to a request for review within two weeks, under Article 11(1) and (2) (47, European Union, 2024). The MDR's information and contest fields are where an employer shows that it meets these duties, and the worker information notice of Chapter 28 describes in advance, as Article 9 requires for platforms, the categories of decision and their main parameters.

The works council or union needs to see patterns rather than persons: how often managers depart from the system, in which decision classes, whether certain groups receive more adverse decisions, and whether the degree in practice matches the profile. The register and aggregated MDRs let the representatives exercise rights they already hold, such as co-determination under BetrVG §87(1) no. 6 or negotiation under MBL §11 (205, Sveriges riksdag, 1976), on evidence rather than assurances.

A court needs a record made at the time by the person who decided, not a reconstruction. In the Uber deactivation appeal, the Amsterdam Court of Appeal held that, because the relevant information lay with the platform, the platform bore a heavier burden to substantiate that its decisions were not solely automated, and it was not persuaded that the notes of its risk team amounted to more than a symbolic act (67, Gerechtshof Amsterdam, 2023). The guidelines on automated decision-making that the court applied require human involvement to be meaningful rather than a token gesture, carried out by someone with the authority and competence to change the decision (61, Article 29 Data Protection Working Party, 2018). An MDR that records the system's version and proposal, the decider's changes and reasons, and the time between proposal and decision is the evidence such a court asks for, and an employer that cannot produce it bears the consequence of the gap.

A supervisory authority needs to see that the controller can demonstrate compliance, under GDPR Article 5(2), and that the deployer of a high-risk system has kept logs and monitored operation, under AI Act Articles 26(5) and (6). The MDR store, its schema, its entry in the record of processing and the register give a supervisor the structure; individual MDRs give it the cases to sample.

Practical guide: Introducing Management Decision Records for one system

Purpose. Make one AI system that takes part in managing people produce Management Decision Records as a by-product of operation, validated against a schema, protected by agreed access rules and readable by the four readers.

Roles. The function owner (HR director or chief HR officer), who adopts the scheme; the system owner and an engineer, who connect events to records; two line managers who decide under the system; the data protection officer; the workers' representatives with rights over the system and over the MDR store; and two workers affected by the system, who read sample records.

Steps.

  1. Choose the decision classes. Start from the decision-rights file and the delegation profile. List every M3 Consequence class the system touches, the classes the profile names, and the M1 Direction and M2 Evaluation classes to be sampled. Default: no more than five classes in the first scheme.
  2. Map the fields to their sources. For each field in the schema, name the system event or the decider's action that supplies it. Where no event exists, as for a decision shaped by a Mode 1 to Mode 3 assistant, add a field the decider completes.
  3. Build the record into the decision screen. The approval or override cannot complete until the record validates. Ask for a reason on every change and on every acceptance in an M3 class; keep the reason field short and in the decider's own words.
  4. Set the retention rule per class from national law and agreements, record it in the GDPR Article 30 record of processing, and, for a public authority, in the archive rules.
  5. Agree access and purposes with the representatives before the first record is stored, including whether and how MDRs may be used to assess deciders. In Germany this is a co-determination matter under BetrVG §87(1) no. 6; in Sweden a matter for negotiation under MBL §11.
  6. Validate in the pipeline. Run the schema and the register check on every record and every profile change. A failed record holds the decision, not the pipeline.
  7. Test the four views. Produce, from twenty real records, the worker's view, the representatives' aggregate, a court bundle for one decision, and the supervisor's sample. Ask the two workers whether they understand who decided and how to contest.
  8. Record the scheme as an AI Decision Record and set a review six months after the first record. Default triggers for an earlier review: a contest the record could not answer, a schema change, a new decision class or an access request that took longer than one month to answer.

Definition of done. Every decision in the chosen classes produces a record that validates; no record names a system as decider; every record has a retention rule and a contestation route; the representatives have agreed access and purposes; the four views exist and the two workers could read theirs; the scheme is an AIDR with a review date.

Worked example: MDR-NR-0001 and MDR-HM-0001 in full

Illustrative. Chapter 9 summarised the first record of each organisation. The full forms below carry the same facts in the schema's fields, with the provenance, contest and retention fields added. Nordvik's record concerns the first four-week roster for the Strandvik home-care unit, approved by Mikael Strand under DLG-NR-ROS-01.

# management/decisions/MDR-NR-0001.yaml (illustrative, full form)
id: MDR-NR-0001
schema_version: "1.0.0"
status: decided
organisation: nordvik-region
date: "2027-01-22"
decision_class: NR-M1-ROSTER-APPROVE
decision: approve four-week roster, Strandvik home care, 2027-02-08 to 2027-03-07
function: M1 Direction
related_functions: [M3 Consequence, M5 Care]   # premium shifts and rest rules
trigger: profile_rule
adverse: false
affected:
  group: rostered staff of the Strandvik home-care unit
  person_refs: [NR-PSN-3A91C0, NR-PSN-7D20F4, NR-PSN-B1E655]   # staff whose shifts changed
inputs:
  - {name: forecast demand, source: ShiftWise forecast from approved visit plans}
  - {name: contract hours and competences, source: PeopleCore}
  - {name: stated preferences and availability, source: staff app}
  - {name: working-time rules, source: sector collective agreement table}
system:
  name: ShiftWise
  version: release in deployment log entry SW-DEP-2027-002
  proposal: draft roster version 3
  flags: [daily rest under 11 hours, evening route to morning route]
  log_ref: ShiftWise roster run of 2027-01-21
delegation: {profile: DLG-NR-ROS-01 v1.0.0, agreed: 2027-01-20, record: AIDR-0602, level: Level 2 Supervised}
decider: {role: unit manager, name: Mikael Strand}
changes:
  - {person_ref: NR-PSN-3A91C0, shift: 2027-02-09 morning route, change: swapped with a colleague on the same route}
  - {person_ref: NR-PSN-7D20F4, shift: Wednesday afternoons, change: fixed afternoon off restored in all four weeks}
  - {person_ref: NR-PSN-B1E655, shift: 2027-02-20 weekend evening, change: moved to an hourly colleague who asked for more hours}
reasons:
  - resolve flagged rest breach after an evening route ending 22:00
  - stated childcare preference had been outweighed in the draft by travel cost
  - draft gave four premium-bearing shifts against a unit rotation of three
open_shifts_offered: 6
information_given:
  to: all rostered staff
  date: "2027-01-22"
  channel: staff app, roster published with the reasons for changes
  notice_days: 17
contest:
  route: unit manager, then HR business partner care
  request_by: 30 days after the end of the roster period   # window for raising a contest as issued; four months under AIDR-0631 from 2027-03-15
  answer_within: 10 working days, never later than 14 calendar days   # AIDR-0631 from 2027-03-15
retention:
  rule: Nordvik archive rule for roster records, AIDR-0629
  delete_after: 2 years after the roster period; unit-level statistics kept

Hansa's record concerns Jana Petersen's reassignment of claims the agent had allocated to a handler returning on an agreed reduced schedule.

# management/decisions/MDR-HM-0001.yaml (illustrative, full form)
id: MDR-HM-0001
schema_version: "1.0.0"
status: decided
organisation: hansa-mutual
date: "2027-01-12"
decision_class: HM-M1-CLAIM-ALLOCATE, override
decision: reassign claims allocated by the claims-triage agent
team: motor claims, Hamburg
function: M1 Direction
related_functions: [M5 Care]
trigger: profile_rule
adverse: false
affected:
  person_refs: [HM-PSN-41C07E]     # handler on an agreed reduced schedule
  also_affected: three colleagues who received claims within authority limits
inputs:
  - {name: line of business and complexity tier, source: core claims system}
  - {name: authority limit and language, source: Hansa People}
  - {name: open workload, source: core claims system}
system:
  name: claims-triage agent, work-allocation function
  version: release 7.0, allocation rules v2026.4
  proposal: nine new motor claims allocated to one handler in one morning
  log_ref: agent allocation events of 2027-01-12, Hamburg motor queue
delegation: {profile: DLG-HM-CTA-01 v1.0.0, level: Level 3 Bounded}
decider: {role: claims team leader, name: Jana Petersen}
items_reassigned: 5 of 9
reasons:
  - handler on an agreed reduced schedule; the agent read open workload only
health_data_recorded: none
correction:
  immediate: five claims reassigned to three colleagues within authority limits
  lasting: capacity field added to allocation inputs, entered by the team leader without reasons
  change_class: allocation-rule change, notified to the works council under KBV-IT-2024
information_given:
  to: affected handler
  date: "2027-01-12"
  channel: in person, then the record in the employee portal
contest:
  route: contestation record CNT-HM, reviewer outside the team line
  request_by: 3 months after the decision
  answer_within: 15 working days
retention:
  rule: AIDR-0679, override records
  delete_after: 24 months; team-level aggregates kept for the Konzernbetriebsrat

The system fields make the decider's contribution measurable, and each reason refers to something the system could not see. The contest fields use each organisation's agreed answer time, ten working days at Nordvik and fifteen at Hansa.

Worked example: the delegation registers of Nordvik Region and Hansa Mutual

Illustrative. Nordvik's register is small: three profiles, one paused system, one jurisdiction. Its value lies in the sum per team and the first reversibility test of ShiftWise.

# management/delegation-register.yaml (Nordvik Region, illustrative excerpt)
register: delegation-register
organisation: nordvik-region
version: "1.2.0"
owner: role:hr-director            # Ingrid Halvorsen
adopted_by: AIDR-0629
profiles:
  - {id: DLG-NR-ROS-01, version: 1.0.0, system: ShiftWise, mode: Mode 4, scope: [hospital wards, home care]}
  - {id: DLG-NR-HCD-01, version: 1.0.0, system: home-care dashboards, mode: Mode 4, scope: [home care]}
  - {id: DLG-NR-SA-01, version: 1.0.0, system: staff assistant and embedded assistant pilot, mode: [Mode 4, Mode 2]}
paused_or_discovered:
  - {system: recruitment screening module, status: paused, record: AIDR-0601, profile: required before resumption}
sum_by_team:
  strandvik-home-care:
    M1_Direction: {systems: [ShiftWise, staff assistant], highest: Level 3 Bounded, class: offer_open_shift}
    M2_Evaluation: {systems: [home-care dashboards], highest: Level 0 Advisory}
    M3_Consequence: {systems: [], highest: not_delegated}
    M4_Development: {systems: [], highest: not_delegated}
    M5_Care: {systems: [ShiftWise], highest: Level 3 Bounded, class: protective block only}
reversibility_tests:
  - id: RVT-NR-ROS-2027-01
    profile: DLG-NR-ROS-01
    function: M1_Direction
    scenario: ShiftWise unavailable for four weeks in home care
    form: live exercise, Strandvik routes planned by hand for two weeks; desk exercise for the wards
    run: {from: "2027-04-05", to: "2027-04-16"}
    acceptance:
      - rosters published with at least 14 days' notice
      - no breach of minimum daily rest
      - travel time per CNT-NR-0001, routed time plus 5 minutes and never under 10
    result: passed_with_conditions
    findings:
      - the unit manager planned all routes; the deputy had never planned one by hand
      - the manual route template lacked the travel-time rule added after CNT-NR-0001
      - ward competence rules exist only inside ShiftWise and could not be exported
    conditions:
      - {action: export competence rules to PeopleCore monthly, owner: role:hr-director, due: "2027-06-30"}
      - {action: deputy plans one week a month by hand, owner: role:unit-manager, due: "2027-06-30"}
    freeze: no new ShiftWise action class, including the supplier's shift-swap feature, until conditions are met
    next_test: "2028-04"
representatives: {position: agreed, parties: [union for nurses and midwives, union for municipal and care workers]}
reported_to: regional-executive-committee, with the report under AIDR-0600

The test passed with conditions a desk exercise would not have found. The manual route template lacked the travel-time rule that CNT-NR-0001 had added to ShiftWise, so the fallback had fallen behind the system it replaces, and the wards' competence rules lived only inside the supplier's product. The freeze prevents the supplier's shift-swap feature, which would let staff exchange shifts through the system without the unit manager's approval, from being switched on until the way back is restored.

Hansa's register is the same file in a different shape, because its question is not the depth of delegation in one unit but its spread across seven markets with seven arrangements for representation.

# management/delegation-register.yaml (Hansa Mutual, illustrative excerpt)
register: delegation-register
organisation: hansa-mutual
version: "1.1.0"
owner: role:chief-hr-officer
adopted_by: AIDR-0679
markets: [DE, NL, SE, PL, NO, UK, CH]
profiles:
  - {id: DLG-HM-CTA-01, version: 1.1.0, applies_in: [DE], highest: {M1: Level 3 Bounded, M2: Level 1 Assisted}}
  - {id: DLG-HM-REC-01, version: 1.3.0, applies_in: [DE, PL], highest: {M3: Level 1 Assisted}}
  - {id: DLG-HM-SPS-01, version: 4.0.0, applies_in: [DE, NL], highest: {M2: Level 1 Assisted, M3: Level 0 Advisory}}
  - {id: DLG-HM-AB-01, version: 1.0.0, applies_in: [DE], note: people direct agents; no agent directs a person}
paused_or_discovered:
  - {feature: FTR-HM-CA-01, mode: Mode 0, status: switched off in all markets, record: AIDR-0670}
sum_by_market:            # systems touching each function
  DE: {M1: 1, M2: 2, M3: 2, M4: 0, M5: 0, gate: Konzernbetriebsrat or local Betriebsrat}
  NL: {M1: 0, M2: 1, M3: 1, M4: 0, M5: 0, gate: ondernemingsraad consent}
  PL: {M1: 0, M2: 0, M3: 1, M4: 0, M5: 0, gate: company trade union organisation and employee council}
  SE: {M1: 0, M2: 0, M3: 0, M4: 0, M5: 0, gate: unions under MBL}
  NO: {M1: 0, M2: 0, M3: 0, M4: 0, M5: 0, gate: union representatives on control measures}
  UK: {M1: 0, M2: 0, M3: 0, M4: 0, M5: 0, gate: staff forum; outside the AI Act}
  CH: {M1: 0, M2: 0, M3: 0, M4: 0, M5: 0, gate: employee committee; outside the AI Act}
reversibility_tests:
  - id: RVT-HM-CTA-2027-01
    profile: DLG-HM-CTA-01
    scenario: allocation by the agent stopped for one week in one team
    form: live exercise, Hamburg motor team on the team-leader queue
    run: {from: "2027-03-15", to: "2027-03-19"}
    acceptance: [no claim above an authority limit, first contact within service level, workload within agreed band]
    result: passed_with_conditions
    findings:
      - the team leader allocated within service level; the deputy needed three times as long
      - complex claims concentrated on the four most experienced handlers
    conditions:
      - {action: deputy allocates 10 per cent of new claims without the agent's proposal, owner: claims team leader, due: "2027-06-30"}
    freeze: no new allocation action class and no extension beyond DE until conditions are met
    next_test: "2028-03"
reporting: {to: [executive board, Konzernbetriebsrat], form: aggregated by team and market, frequency: annual}

The sum by market shows what no single profile does: algorithmic management at Hansa is concentrated in Germany, where two systems touch M3 Consequence, while four of seven markets have no system in any management function beyond the switched-off Mode 0 feature. Each market's gate is recorded beside its sum, because extending a profile to a new entity is a new delegation that must pass that entity's representation first. The freeze after the reversibility test holds the extension of agent allocation to other entities until the deputy team leader in Hamburg can allocate without the agent, which is also the condition under which Chapter 19's route into management stays open.

What is observable and what is expected

Decision records for architecture and for AI are observable practice, in the series and in engineering organisations that keep ADRs. Logging for high-risk systems is a decided obligation, and the right to explanation in Article 86 of the AI Act already applies. The Management Decision Record and the delegation register of management functions are this book's proposal. Their adoption is expected where explanation rights and co-determination require evidence of human decisions: the obligations of Chapter III, Sections 1 to 3, including Article 26, apply to Annex III systems from 2 December 2027 under Article 113 as amended by the Digital Omnibus (2, European Union, 2026), and the Platform Work Directive's duties to give reasons and review decisions take effect through transposition. That courts and supervisors will come to expect such records as the normal evidence of human decision is speculation until the first cases under Article 86 are decided.

Across the usage modes

The mode determines where the record's facts come from and how far the register can rely on generated rather than declared records.

Usage mode Source of the MDR What the decider must add Register entry
Mode 0 Ambient AI None until the feature is discovered The fact that a feature's output was used Discovered, not decided; status per market
Mode 1 Conversational assistants None in a management system The assistant's part in the field assistant_part Function touched, records declared by managers
Mode 2 Embedded workplace assistants Tenant activity, rarely linked to a decision Whether a proposed owner or summary was accepted Profile at Level 0 Advisory; sampled check
Mode 3 Agentic work tools Tool logs under the manager's identity Which actions the tool took in the manager's name Profile names the classes the tool may act in
Mode 4 Built AI applications System events and the approval screen Changes and reasons Profile per action class; MDR generated
Mode 5 Autonomous production agents Agent events and the override dialogue Override reasons; never a consequence decision by the agent Profile and mandate manifest; MDR on every override

Where AI acts most independently, in Modes 4 and 5, the record can be generated most completely; where it acts most quietly, in Modes 0 to 3, the record depends on the manager, and the register says so.

Nordvik Region and Hansa Mutual

At Nordvik Region, Ingrid Halvorsen adopts the MDR schema, access rules and retention rules as AIDR-0629, after negotiation with the public-sector unions, and records the two-year disposal of roster records in the Region's archive rules. MDR-NR-0001 shows what ShiftWise proposed, the three shifts Mikael Strand changed and why, and the seventeen days' notice. The register holds DLG-NR-ROS-01, DLG-NR-HCD-01 and DLG-NR-SA-01 and records the paused screening pilot, and nothing in it reaches M3 Consequence. Its first reversibility test passed with conditions and froze the supplier's shift-swap feature. Every MDR is written on the assumption that it may be requested under the public-access rules, and Ingrid reports the register to the regional executive committee with AIDR-0600.

At Hansa Mutual, MDR-HM-0001 records Jana Petersen's reassignment of five of nine claims, with her reason and the lasting correction it led to. Thomas Brandt agrees, as AIDR-0679 records, that MDRs are generated for every override and every consequence decision but not for every allocation, that the Konzernbetriebsrat sees them aggregated by team, and that they are not used to assess team leaders outside the agreed competence record. The register holds DLG-HM-CTA-01, DLG-HM-REC-01, DLG-HM-SPS-01 and DLG-HM-AB-01 across seven markets, and German hiring MDRs are kept for six months after a rejection unless a claim has been asserted. The difference between the two organisations lies in where the records strain: Nordvik's in public access and archive law, Hansa's in the number of national arrangements its register must show side by side.

Summary

The Management Decision Record records one management decision that AI made or shaped about a person: the decision class and function, the person affected by pseudonymous reference, the inputs and their provenance, the system's proposal and version, the degree of delegation, the named human decider, the reasons, what the person was told, the contestation route and deadline, and the retention rule. It keeps the discipline of the ADR and the AIDR, short, numbered and immutable, and is validated against a schema that rejects Level 4 Autonomous for M3 Consequence and adverse consequences above Level 1 Assisted.

An MDR is required for every M3 Consequence decision, for the decisions a delegation profile names, for a sample of M1 Direction and M2 Evaluation decisions, and for every contested decision; M4 Development and M5 Care decisions enter when they become one of these. Records are generated from the system's events and the decider's action, so that the record is a condition of the decision rather than a report on it, and the usage mode shows where the record can be generated and where it depends on the manager.

The delegation register of management functions, extending the register of AI Threat, Chapter 26, shows the sum of delegation per function, team and market, records reversibility tests for management functions, and freezes further delegation where a test fails or passes only with conditions. Together with the function map, decision-rights file, feature register, mandate manifests, chain records, team charters, oversight records, contestation records, disparate-impact tests, evaluation plans, risk assessments and competence records, it forms one record set in which each artefact has an owner, a trigger and a retention rule.

The answer to Q3 is one record with four views: the worker's explanation and route of appeal, the representatives' aggregate, the court's record made at the time, and the supervisor's evidence that compliance can be demonstrated. Chapter 26 turns to the condition on which every record depends: that the human decision it names was real, not rubber-stamped.

Sources

  1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
  2. European Parliament and Council of the European Union (2026). Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 (Digital Omnibus on AI). Official Journal of the European Union. (2, European Union, 2026)
  3. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union. (5, European Union, 2016)
  4. Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG) (Works Constitution Act), as amended. Gesetze im Internet. (9, Germany, 2001)
  5. Nygard, M. (2011). Documenting Architecture Decisions. Cognitect blog. (16, Nygard, 2011)
  6. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (40, Nordqvist, 2025)
  7. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (41, Nordqvist, 2026)
  8. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Architecture as Code Series, Book 3. (42, Nordqvist, 2026)
  9. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Architecture as Code Series, Book 5. (44, Nordqvist, 2026)
  10. Nordqvist, G. (2026). The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. The Architecture as Code Series, Book 6. (46, Nordqvist, 2026)
  11. European Parliament and Council of the European Union (2024). Directive (EU) 2024/2831 of 23 October 2024 on improving working conditions in platform work. Official Journal of the European Union. (47, European Union, 2024)
  12. Article 29 Data Protection Working Party (2018). Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679 (WP251rev.01). (61, Article 29 Data Protection Working Party, 2018)
  13. Court of Justice of the European Union (2025). Judgment of 27 February 2025, CK v Dun & Bradstreet Austria GmbH and Magistrat der Stadt Wien, Case C-203/22. EUR-Lex. (65, CJEU, 2025)
  14. Gerechtshof Amsterdam (2023). Judgment of 4 April 2023, ECLI:NL:GHAMS:2023:793 (drivers and App Drivers & Couriers Union v Uber). (67, Gerechtshof Amsterdam, 2023)
  15. Bundesarbeitsgericht (2016). Beschluss vom 13. Dezember 2016, 1 ABR 7/15. Bundesarbeitsgericht. (71, Bundesarbeitsgericht, 2016)
  16. Federal Republic of Germany (2006). Allgemeines Gleichbehandlungsgesetz (AGG) (General Act on Equal Treatment), as amended. Gesetze im Internet. (74, Germany, 2006)
  17. Bovens, M. (2007). Analysing and Assessing Accountability: A Conceptual Framework. European Law Journal, 13(4), 447–468. (121, Bovens, 2007)
  18. Sveriges riksdag (1976). Lag (1976:580) om medbestämmande i arbetslivet (Co-determination in the Workplace Act, MBL). (205, Sveriges riksdag, 1976)
  19. Sveriges riksdag (1990). Arkivlag (1990:782) (Archives Act). (241, Sveriges riksdag, 1990)
  20. Wright, A., Andrews, H., Hutton, B. & Dennis, G. (2022). JSON Schema: A Media Type for Describing JSON Documents. Internet-Draft draft-bhutton-json-schema-01, Internet Engineering Task Force. (242, Wright et al., 2022)
  21. Sveriges riksdag (2009). Offentlighets- och sekretesslag (2009:400) (Public Access to Information and Secrecy Act). (243, Sveriges riksdag, 2009)
  22. Federal Republic of Germany (1953). Arbeitsgerichtsgesetz (ArbGG) (Labour Courts Act), as amended. Gesetze im Internet. (244, Germany, 1953)