Role, Competence and Career Tools

This chapter serves the activity of deciding what a person in a role may decide, showing what that person can do, and keeping the ability alive while AI does more of the work. It treats four kinds of tool. Most are artefacts: role charters (ROLE-*), competence frameworks, competence records (CMP-*), learning paths (LP-*), apprenticeship and craft records and the on-call charter (ONC-*). Some are methods, such as assessment by practical demonstration and the craft-keeping programme. A few are third-party frameworks, namely the skills frameworks and certifications to which the series maps its own. The own tools of the series that touch this activity are the Python utilities of Architecture as Code. The tools come from six volumes: Architecture as Code (Chapters 17 to 19), AI Governance, Chapter 14, The Transformed Security Architect, Chapters 4, 15, 16, 21 and 22, AI Boss, Chapters 19 and 29, AI Blue, Chapters 17, 22 and 23, AI Purple, Chapters 19 and 24 and AI Operations, Chapters 21, 25 and 26 (1, Nordqvist, 2025) (2, Nordqvist, 2026) (6, Nordqvist, 2026) (7, Nordqvist, 2026) (8, Nordqvist, 2026) (9, Nordqvist, 2026) (10, Nordqvist, 2026).

The tools form one chain, drawn in Figure 21.1. The role charter fixes what a role may decide and what it never delegates. The competence framework says which competences those decisions need, at which level and with what evidence. The competence record shows what a named person has demonstrated. Learning paths, craft programmes and apprenticeships feed the record. And the record, read for its levels and never for its content, may condition the autonomy that a mandate manifest grants an agent. The series puts one rule over the whole chain: a competence record is about development and about a check that a decision-right holder has the competence the delegation requires. It does not rank, pay or discipline anyone.

Role, competence and career

Figure 21.1: Role, competence and career. The role charter names the competences; the record carries levels; the conditions read levels, never content; employee representatives agree purposes and readers.

A word on the law that surrounds these tools. A competence record is personal data, and an assessment of judgement is among its more sensitive kinds. The series' architectural reading is that purposes, readers and retention belong in the record schema, which is why every record below carries purposes, not_used_for and readers. Under the GDPR, purpose limitation, data minimisation and storage limitation are principles of Article 5, and Article 88 lets Member States and collective agreements set more specific rules for employee data (196, European Union, 2016). Article 4 of the AI Act, as amended by the Digital Omnibus on AI, asks providers and deployers to support the AI literacy of their staff (195, European Union, 2024) (199, European Union, 2026). These are architectural implications, not legal advice.

Role charters

A role charter is a machine-readable statement of what a role is for, what it decides, what it only recommends and what it never does. The series has five charters of this kind, each written for a different role, and one older role description. They share a skeleton: an identifier, a version, an owner and reviewers, a mandate, decision rights using a small vocabulary of verbs, exclusions, and a review date. They differ in what the role has to be protected from. The security architect's charter protects against becoming the risk owner. The conductor's protects against approving what an agent then verifies. The line manager's protects time for development and care. The blue team lead's caps the use of the lead's own AI. The purple coordinator's keeps the person who routes a finding from closing it.

The vocabulary of decision rights is the most reusable part. The Transformed Security Architect uses decide, veto, recommend and escalate, each with a time limit, and names who may override a veto (6, Nordqvist, 2026). The other charters use the same idea in different words: may, referred_to and never_delegated in the conductor's charter, right: decide or recommend in the blue team charter, and decision_rights with none for choices that belong to someone else in the purple coordinator's.

Role charter (security architect, ROLE-*)
Kind Artefact
Origin The Transformed Security Architect, Chapter 4 (Appendix A)
Purpose Gives the security architect a mandate, accountabilities and decision rights (decide, veto, recommend, escalate), each with a time limit
Use when A post has grown by accretion and nobody can say what it decides, or an AI system has been added to the role's work
Inputs Thirty to fifty decisions from the last year, classed by decider, elapsed time and whether they were contested
Outputs A YAML charter such as ROLE-NR-SA-01, code-owner paths derived from it, and a linked competence record
Identifier family ROLE-* (for example ROLE-NR-SA-01, ROLE-HM-*)
Full template The Transformed Security Architect, Chapter 4, and Appendix A (04_CODE_ROLE)

The charter of Nordvik Region's single security architect, commissioned as AIDR-0500, sets a limit of five working days on the stop-path and egress requirements in a tender annex and fifteen minutes on stopping or restricting the architect's own AI tools. It gives the architect a veto on a tender annex without a stop path, which only the chief information security officer can override, on the record. It also caps the architect's own AI at Level 1 Assisted. The charter names what the role does not do: it does not accept residual risk for a system owner, operate the SIEM or approve every change. Those exclusions matter in practice, since unwritten exclusions surface during incidents, when each party assumes the other accepted the risk. The charter links to the competence record CMP-NR-01, which is where the chain of this chapter starts (6, Nordqvist, 2026).

Writing a role charter in five steps
Kind Method
Origin The Transformed Security Architect, Chapter 4
Purpose Produces a first machine-readable charter from thirty to fifty decisions
Use when Before writing the first ROLE-* file, or when a charter is rewritten after a reorganisation
Inputs The decision log of the past year
Outputs A charter in YAML, code-owner entries, and a test against ten past decisions

The five steps are to collect the decisions, class each by class, tier, actual decider, elapsed time and whether it was contested, assign a verb and a time limit, write the exclusions and the seams, and then encode, test and adopt. The test is the one that matters: at least eight of ten past decisions must resolve to a single holder, or the charter is not yet finished (6, Nordqvist, 2026).

Role charter for the operations conductor
Kind Artefact
Origin AI Operations, Chapter 21 (Appendix A.17, Appendix B.15)
Purpose Fixes the mandate, decision rights, independence and competence conditions of an operations conductor and what is never delegated
Use when A person supervises operations agents in a window, and decides on their behalf when to stop them or to approve what they propose
Inputs The services in scope, the loop functions O1 to O5, the agents conducted, the delegation profiles of Chapter 18
Outputs A YAML charter reviewed by the second line and the employee representatives
Identifier family ROLE-* (here ROLE-HM-OPS-001)
Full template AI Operations, Appendix A.17, quoted below

The charter is the worked example of this chapter because it combines every device of the family. The conductor may stop any operations agent with no approval, and the stop path lies outside the agents' platform. The never_delegated list holds four items: irreversible action on production data, action outside an authorised change window or freeze on a critical function, action that disables observation or the stop path, and any decision about a named person's access to work. The independence block bars the conductor from verifying their own approval. The competence block ties the role to exercises, not certificates, and states what happens when fewer than two holders are evidenced: Level 3 classes fall to Level 2. The people block reports metrics for teams and services only, with a minimum group size of five. AI Operations states that the artefact must never contain per-person reporting, a decision right not backed by a stop path outside the agents' platform, or a competence claim based on certificates (10, Nordqvist, 2026). The text below is quoted from the book's Appendix A.17 without change.

role: ROLE-HM-OPS-001
title: Operations conductor, night window (Polish service centre)
version: 1.0
effective: 2028-11-01
owner: Head of Group Site Reliability and Incident Management (Tobias Richter)
reviewers:
  - Head of operational resilience (second line)
  - Chair of the Konzernbetriebsrat (Thomas Brandt), under KBV-IT-2024-OPS-03
mandate:
  services: [SVC-HM-001, SVC-HM-002, SVC-HM-004, SVC-HM-006]
  window: "22:00-06:00 CET"
  loop_functions: [O1, O2, O3, O4, O5]
  agents_conducted: [HM-OPS-001, HM-OPS-002, HM-OPS-003]
decision_rights:
  may: [stop_any_operations_agent, approve_level_2_action, declare_tier_1_incident]
  referred_to: "delegation profiles DLG-HM-* (Chapter 22)"
  stop_right: no_approval_needed
  stop_path: outside the agents' platform
never_delegated:
  - irreversible action on production data
  - action outside an authorised change window or freeze on a critical function
  - action that disables observation or the stop path
  - any decision about a named person's access to work
independence:
  verification_of_agent_action: independent probe, not the acting agent
  conductor_may_not_verify_own_approval: true
competence:
  evidenced_by: exercises (CMP-HM-* records), not certificates
  minimum_evidenced_holders_per_window: 2
  fallback_if_fewer: Level 3 classes fall to Level 2
  manual_practice: one agents-off exercise per holder per quarter
people:
  metrics_reported_for: [teams, services]
  per_named_person_reporting: false
  minimum_group_size: 5
  agreement: KBV-IT-2024-OPS-02
review: 2029-03-31

The reference "Chapter 22" inside the quoted referred_to field is to the chapter of AI Operations, where the delegation profile is defined. In this book the mandate and delegation tools are in Chapter 18.

Role charter for a line manager
Kind Artefact
Origin AI Boss, Chapter 29 (Appendix A, 29_CODE_ROLE; Appendix B)
Purpose Gives a line manager written decision rights per management function, the systems and agents overseen, and a time budget that protects M4 Development and M5 Care
Use when AI directs or evaluates the manager's team, or the manager conducts agents
Inputs The delegation profiles of the systems in the manager's span, the mandate of the agents directed
Outputs A charter per manager or per post, agreed with employee representatives
Identifier family ROLE-* (ROLE-NR-MGR-01, ROLE-HM-MGR-01)
Full template AI Boss, Appendix A (29_CODE_ROLE)

The charter is organised by the five management functions of AI Boss (M1 Direction to M5 Care). Hansa Mutual's ROLE-HM-MGR-01 (AIDR-0683) protects 35 per cent of the manager's weekly time for coaching and care, names what is never delegated (development conversations and coaching, decisions on a reduced schedule or health-related capacity, any input to a consequence decision about a handler) and states a stop right with a time to effect of five minutes. The book marks some of these fields as its own extensions, and the time shares beyond those the chapter gives are illustrative (7, Nordqvist, 2026). The related method, Writing a role charter and time budget for a line manager (AI Boss, Chapter 29), is the practical guide for writing it.

Role charter (blue team roles)
Kind Artefact
Origin AI Blue, Chapter 17 (Appendix A and Appendix B.15)
Purpose States the mandate, decision rights and ceilings for a blue team role
Use when A security operations role conducts or approves agent work, and its own AI use needs a ceiling
Inputs The blue team functions B1 to B5, the mandate manifests of the agents conducted
Outputs A charter such as ROLE-HM-SOC-LEAD or ROLE-NR-SEC-DET
Identifier family ROLE-*
Full template AI Blue, Appendix A, "Role charter ROLE-HM-SOC-LEAD"

Hansa Mutual's group SOC lead charter lists the functions (B2 Detect, B3 Investigate, B4 Respond, B5 Learn), four accountabilities, decision rights that include the right to stop any SOC agent immediately, ceilings that cap the lead's own AI use and approvals at Level 2 Supervised and state that Level 4 Autonomous is not used, and two prohibitions: producing or requesting measures of output per named analyst, and deciding about a named person's access to work by tool output (8, Nordqvist, 2026).

Role charter (loop roles)
Kind Artefact
Origin AI Purple, Chapter 19 (Appendix A and Appendix B.19)
Purpose Charter for loop roles such as the purple team coordinator and the exercise controller
Use when A role schedules or controls emulation and must be kept separate from the roles that choose scenarios, accept risk or close findings
Inputs The loop stages P1 to P5, the mandates of the agents under the role
Outputs A charter such as ROLE-HM-SEC-PRP or ROLE-NR-SEC-XCT
Identifier family ROLE-*
Full template AI Purple, Appendix A, "Role charter ROLE-HM-SEC-PRP"

The coordinator's charter assigns none to choosing scenarios, accepting risk and closing findings, and it lists three prohibitions that keep the role from reviewing its own work: authoring a detection for a finding the holder routed and then closing it, sitting on the white team for an exercise the holder scheduled, and reading restricted content beyond the register view granted. The exercise controller's charter, ROLE-NR-SEC-XCT, gives the holder the right to halt an exercise without justification (9, Nordqvist, 2026).

Further role artefacts

Name Kind Origin Purpose
Role description (AI system owner) Artefact AI Governance, Chapter 14 A Markdown template (ROLE-AI-OWNER, version 2026.3) for the accountable executive of an AI use case, with accountabilities, decision rights and a "does not" section; the inventory tooling checks that each registered system has a named owner (2, Nordqvist, 2026)
Role-map workshop Method The Transformed Security Architect, Chapter 16 Draws a role map with one accountable owner per seam in one session of about two hours, from fifteen to twenty boundary-changing decisions of the last year (6, Nordqvist, 2026)

Competence frameworks

A competence framework says what the people of a function must be able to do, at which level, and by what evidence. The series builds its frameworks on the four levels of Architecture as Code (Chapter 18), and each later framework adds the domains of its own function. Three properties recur. First, evidence is a demonstration, not an attendance record. Second, a competence shown with and without an assistant counts at the lower level (AI Blue, Chapter 22), and a competence that exists only beside an assistant is assessed in the assisted form alone. Third, each framework is mapped to the European skills frameworks and records where the mapping fails as an extension, so a local competence for supervising an agent is not forced into a profile that predates agents.

Competence framework (SA-CF)
Kind Artefact
Origin The Transformed Security Architect, Chapter 21 (Appendix A, 21_CODE_COMPETENCE)
Purpose Six domains by four levels, with evidence per level, mapped to ECSF, SFIA and NICE
Use when A decision right or an agent's autonomy ceiling must depend on evidenced competence
Inputs The role charter, the external frameworks, the nearest SFIA skills
Outputs A framework file such as competence/security-architect-framework.yaml
Identifier family SA-CF (competences such as DES-01, AI-03, PPL-04)
Full template The Transformed Security Architect, Appendix A (21_CODE_COMPETENCE)

The file records level_rule: lower of unassisted and ai_assisted demonstrated level, an evidence validity of 24 months, and for each competence a maps field marking ECSF as direct, partial or none. It records AI-02, AI-03 and ADV-02 as local extensions, with an extension_reason field for the competences that the profiles do not cover, such as agent supervision and co-determination. The book marks the SFIA codes and ECSF and NICE names as needing a check against the current edition before use (6, Nordqvist, 2026).

AI competence framework
Kind Artefact
Origin AI Governance, Chapter 14
Purpose A framework of competence levels and learning paths for the roles of an AI delivery and oversight organisation
Use when A new usage mode raises the question of who holds the roles it needs
Inputs The roles, the usage modes each covers, the literacy requirement of AI Act Article 4
Outputs competence/ai-competence-framework.yaml, which a learning management system can import and a readiness check can query
Identifier family competence/ai-competence-framework.yaml
Full template AI Governance, Chapter 14

The framework has the four levels awareness, practitioner, advanced and expert and attaches to each role the usage modes it covers: AI architect and AI engineer for Modes 3 to 5, human oversight officer for Modes 4 and 5, agent operator for Mode 5. Assessment is by practical demonstration with a cadence of twelve months. The oversight officer role requires evidence before go-live (2, Nordqvist, 2026).

Competence framework SOC-CF
Kind Artefact
Origin AI Blue, Chapter 22
Purpose Eight domains and 24 identifiers (12 at Nordvik Region as SOC-CF-NR), at four levels with and without the assistant
Use when A blue team assigns autonomy ceilings to agents and needs evidence of the people who stand behind them
Inputs The five blue team functions, the group's level scale
Outputs A framework mapped to ECSF and SFIA through extension_reason fields
Identifier family SOC-CF, SOC-CF-NR
Full template None; the framework is described in the chapter

Four domains follow B1 Anticipate, B2 Detect, B3 Investigate and B4 Respond (HNT, DET, INV, CMD). B5 Learn has no domain of its own; it is carried by CMD-03, DET-02, HNT-03 and COM-03. The other four domains, AGT, DAT, LAW and COM, are those on which every function depends. Nordvik Region, with six analysts, uses the same eight domains but only twelve identifiers and leaves out AGT-03 because its triage assistant runs at Level 1 Assisted. The book calls these omissions decisions in a record, not oversights (8, Nordqvist, 2026).

Competence framework OPS-CF
Kind Artefact
Origin AI Operations, Chapter 26
Purpose Hansa Mutual's five-area competence framework (SY, VF, MO, AU, JU) with thirteen identifiers and an evidence type for each
Use when Operators supervise agents, and manual operation must be kept in practice
Inputs The operations functions O1 to O5, the four-level scale
Outputs A framework and the subset an organisation adopts (OPS-CF-NR, eight identifiers)
Identifier family OPS-CF, OPS-CF-NR
Full template None; a table in Chapter 26

The areas are Systems, Verification, Manual operation, Authorship and Judgement. Evidence types differ by area: game day and tabletop for SY, a seeded-error drill for VF, a dark day or a game day with agents off for MO, a written artefact reviewed by a second person for AU, and an exercise and review record for JU. The book notes that SFIA and e-CF have no skill for verifying an agent's proposal or for keeping manual operation in practice; those are additions recorded as extensions of the nearest skill (10, Nordqvist, 2026).

Earlier frameworks and utilities

Name Kind Origin Purpose
Skills matrix (technical Levels 1 to 4 and interpersonal) Artefact Architecture as Code, Chapter 18 Tables of technical competencies by level (Foundation, Practitioner, Advanced, Expert) and of interpersonal skill domains, reviewed in quarterly development conversations (1, Nordqvist, 2025)
IaC competency framework utilities (17_CODE_*) Own tool Architecture as Code, Chapter 17 and Appendix Python utilities (IaCCompetencyFramework) for a competency framework and for tracking progress; levels carry a description, required hours and assessment criteria
Competency development loop Method Architecture as Code, Chapter 18 Assessment, planning, learning, application, sharing and measurement as a cycle
Management as Code, Budgeting as Code, Competence Management as Code Method Architecture as Code, Chapter 19 Codified management policies, budgets and frameworks; competence frameworks held as structured data under version control and reviewed with HR, engineering leadership and learning teams

The Python utilities are the only own tool in this chapter. The frameworks of the AI volumes, by contrast, are YAML files read by checks, not Python classes.

Third-party frameworks and certifications

The series maps its frameworks to external ones and treats certificates as a floor, not as evidence of judgement. The limit of the claim is stated for each entry below; none is used as a source for a fact about an individual's competence.

Name Kind of thing What it is used for in the series Limit
ECSF Framework (ENISA) A common language of twelve cybersecurity role profiles, used to map the series' competence frameworks (112, ENISA, 2022) (113, ENISA, 2022) Presented as a common language for workforce planning and recruitment, not as job descriptions to adopt unchanged; it does not address the containment of agents or the setting of autonomy levels
SFIA 9 Framework (SFIA Foundation) Skills described at up to seven levels of responsibility; the bridge to HR grading (114, SFIA Foundation, 2024) Its autonomy attribute describes a person's independence, discretion and accountability for results in a role, not an agent's autonomy level
NICE Framework Framework (NIST SP 800-181 Rev. 1) Task, Knowledge and Skill statements grouped into work roles, used where multinationals or training suppliers need it (115, Petersen et al., 2020) Map only from a merged local framework, since mapping from an external one imports its structure
e-CF Standard (EN 16234-1) The area of ICT competences against which OPS-CF is mapped (116, European Committee for Standardization (CEN), 2019) Describes operations in the vocabulary of service management
ISC2 CISSP-ISSAP Certification A floor for external candidates and contractors (117, ISC2 (n.d.), n.d.) Validates knowledge on the day of an examination, not design judgement in a particular estate
Pluralsight, KodeKloud Learning platforms Named in Architecture as Code, Chapter 18, as sources of curated curricula Mentioned in passing; the series makes no claim about their content

Competence records

A competence record answers the question "what has this person demonstrated, and for what may that be used?". Four design decisions distinguish the series' record from a training log or a score. It records levels and references to evidence, and the evidence stays under its own access rules. It has a closed list of purposes and a list of prohibited uses, which employee representatives agree before the first assessment. It names its readers. And where an agent is involved, it holds both forms of a competence and counts the lower. The record of a manager holds reasons for overrides, not an override rate.

Competence record (CMP-*)
Kind Artefact
Origin AI Governance, Chapter 14; The Transformed Security Architect, Chapter 21; AI Blue, Chapter 22 (B.20); AI Purple, Chapter 24 (B.24); AI Operations, Chapter 26 (A.20, B.17)
Purpose A personal record of assessed levels and the evidence for them; it conditions decision rights and agent autonomy
Use when After an exercise or a demonstration, and before any decision that depends on a person's competence
Inputs The framework, the exercise record, two assessors, the person's comment
Outputs A YAML record with a development plan and a validity date
Identifier family CMP-* (CMP-NR-01, CMP-HM-04, CMP-NR-04, CMP-NR-21, CMP-HM-OPS-007)
Full template AI Operations, Appendix A.20, quoted below; the other versions are in the books named

The versions differ in what each adds to the common core. AI Governance keys the record by a person reference and adds revalidate_on triggers, so a major provider version expires it and prompts retraining, and a readiness_check that the platform reads. The Transformed Security Architect adds post_requires, which links the record to the role charter, and a record valid_until that follows an evidence validity of 24 months. AI Blue adds rota_guidance and rota_decision, because the record there may be an input to a duty-rota decision which a named person takes and records with reasons, and it keeps a competence that exists only beside the assistant (AGT-02) in an assisted_only field. AI Purple adds the loop framework LOOP-CF with competences for scenario design, emulation, detection engineering, observation, exercise control and evidence, and AI Operations adds a not_used_for list that excludes ranking, pay setting and disciplinary process, and a validity of 90 days tied to the next dark day (2, Nordqvist, 2026) (6, Nordqvist, 2026) (8, Nordqvist, 2026) (9, Nordqvist, 2026) (10, Nordqvist, 2026).

The record quoted here is that of Ewa Kowalczyk's role in the book's example, CMP-HM-OPS-007, a night incident commander and agent operator assessed after Hansa Mutual's first quarterly dark day. It shows the pattern in one place: competences assessed in both forms, the findings of the exercise (a manual runbook with no instruction to capture logs by hand, which added six minutes), the subject's comment, and a development plan with dates. AI Operations states that the artefact must never contain use for ranking, pay or discipline, a competence claim without an exercise, or a record read beyond its named readers. The text is quoted from Appendix A.20 as published; the person_ref is a pseudonymous reference.

# competence/records/CMP-HM-OPS-007.yaml (illustrative)
competence_record:
  id: CMP-HM-OPS-007
  person_ref: HM-EMP-61207
  role: ROLE-HM-OPS-001              # operations conductor, night window
  framework: {id: OPS-CF, version: "2028.1"}
  assessed_on: 2028-12-14
  exercise: DKD-HM-2028-Q4           # dark day of 2028-12-07, decision AIDR-0976
  assessors: [delegate_of_head_of_operational_resilience, peer_incident_commander]
  purposes: [development_plan, input_to_conductor_roster]
  not_used_for: [individual_performance_ranking, pay_setting, disciplinary_process]
  readers: [record_subject, head_of_group_sre, hr_competence_partner]
  competences:                       # both forms where an agent is involved; the lower counts
    - {id: MO-01, level: advanced, unassisted: ["DKD-HM-2028-Q4/a", "DKD-HM-2028-Q4/b"], runbooks: [RBK-HM-0007, RBK-HM-0012]}
    - {id: VF-01, level: practitioner, assisted: "DKD-HM-2028-Q4/c"}
    - {id: SY-02, level: practitioner, evidence: "game day 2028-10-24"}
    - {id: JU-01, level: foundation,   evidence: "DKD-HM-2028-Q4/d"}
  findings:
    - {run: "a", note: "manual form of RBK-HM-0007 v3 gave no instruction to capture logs and process state by hand; 6 minutes added"}
    - {run: "d", note: "escalation to the head of the product line at 14 minutes against a 10-minute target"}
  subject_comment: agrees; asks to write the manual form of RBK-HM-0007 v4
  development_plan:
    items:
      - {competence: JU-01, target: practitioner, by: 2029-06-30, means: "lead two tabletops as game master"}
      - {competence: AU-01, target: practitioner, by: 2029-06-30, means: "write RBK-HM-0007 v4 manual form, reviewed by a second holder"}
  valid_until: 2029-03-07            # 90 days from the exercise; next dark day 2029-03-01

Competence conditions on autonomy
Kind Artefact
Origin AI Blue, Chapter 22 (Appendix A)
Purpose Makes agent autonomy ceilings depend on evidenced human competence
Use when A mandate manifest grants an agent a ceiling above Level 2 Supervised and the supervision must stay in human hands
Inputs The mandate manifests, the framework, the competence records (levels and validity only)
Outputs competence/conditions.yaml, checked nightly
Identifier family COND-HM-SOC-*; file competence/conditions.yaml
Full template AI Blue, Appendix A, "Worked example: competence conditions on autonomy", quoted below

This is the tool that turns a competence record from an HR artefact into an architecture artefact. Each condition names a manifest and a ceiling, the competence and level required, the number of holders and the sites where they must be, and what happens if the condition is unmet: the ceiling falls to Level 2 Supervised and named roles are notified. The nightly check reads levels and validity and never reads record content, evidence or working notes. A lapse is treated as an expiry, not as a disciplinary event. Hansa Mutual adopted it as AIDR-0780 with the Konzernbetriebsrat and the Polish employee representatives (8, Nordqvist, 2026). The same pattern appears in the conductor's charter above (two evidenced holders per window or Level 3 falls to Level 2) and in the security architect's framework (two holders of AI-03 at Advanced for a Level 3 ceiling).

# competence/conditions.yaml (illustrative)
decision: AIDR-0780
framework: {id: SOC-CF, version: "2027.1", owner: group_soc_lead}
conditions:
  - id: COND-HM-SOC-01
    applies_to: {manifest: MND-HM-SOC-01, ceiling: level_3_bounded, classes: [SC-01, SC-02]}
    requires:
      competence: AGT-03
      level: advanced
      holders_at_least: 2
      per_site: [hamburg, polish_service_centre]
    on_unmet: {ceiling: level_2_supervised, notify: [soc_lead, group_ai_governance_board], rota_decision: soc_lead}
  - id: COND-HM-SOC-02
    applies_to: {manifest: MND-HM-SOC-02, ceiling: level_3_bounded, actions: [workstation_isolation, session_revocation]}
    requires:
      competence: CMD-02
      level: advanced
      holders_at_least: 2
      per_site: [hamburg, polish_service_centre]
      stop_drill_within_days: 90
    on_unmet: {ceiling: level_2_supervised, notify: [soc_lead, incident_response_lead]}
check:
  schedule: nightly
  reads: [level, validity]
  never_reads: [record_content, evidence, working_notes]
  lapse_is: expiry_not_disciplinary_event

Competence assessment by practical demonstration
Kind Method
Origin The Transformed Security Architect, Chapter 21
Purpose Assess against the framework by demonstration, with two assessors
Use when Before a level is entered in a record, and before a decision right that depends on it
Inputs A synthetic or real case, the framework's evidence description for the level
Outputs Evidence references (EVD-*) and a level

The method rests on the conclusion of Architecture as Code (Chapter 18) that practical demonstration on real delivery, not certification, shows capability (6, Nordqvist, 2026). Nordvik Region's architect was assessed by the enterprise architect and by a peer from a neighbouring region, on a synthetic case, because architecture information describes the Region's defences.

Competence with and without the assistant
Kind Method
Origin AI Operations, Chapter 26 (building on AI Blue, Chapter 22)
Purpose Assess competence shown with and without the assistant and count the lower
Use when An assistant or agent takes part in the work that the competence concerns

A skill that exists only beside the assistant is a skill of the pair. A competence that exists only beside an assistant, such as verifying an agent's proposal (VF-01), is assessed in the assisted form alone; manual operation competences (MO-01 to MO-03) are unassisted by definition (10, Nordqvist, 2026).

On-call charter
Kind Artefact
Origin AI Operations, Chapter 25 (Appendix A.19, Appendix B.16)
Purpose Sets coverage, response targets, noise budget, rest after call-out, escalation, handover and attribution of agent actions, agreed with employee representatives
Use when A rota or an AI operations tool changes, before the change
Inputs Working-time rules, load ceilings, the delegation profile of the agents
Outputs A YAML charter such as ONC-NR-2029-01 and triggers for review
Identifier family ONC-*
Full template AI Operations, Appendix A.19

The charter is a people tool in the same family as the competence record. Nordvik Region's ONC-NR-2029-01 fixes daily rest of eleven hours, a ceiling of five out-of-hours pages per shift as a design value, an actionable share floor of 0.5, and the rule that agent actions are attributed to the delegation profile and a named owner, never to the engineer on call. Reviews name roles, not people, and appraisal use is none. The artefact must never contain per-person metrics, a duty to stay at a location, or agent actions attributed to the on-call engineer (10, Nordqvist, 2026). The method of drafting it with a works council is treated in Chapter 22.

Learning paths and training

A learning path moves a named person from a starting point to target levels in a defined time, with protected time, mentoring and assessments. The series treats hiring and upskilling as complements: AI Governance, Chapter 14, concluded that upskilling is the strategy and hiring is for scarce specialisms, and The Transformed Security Architect, Chapter 22, applied that rule to the security architect (2, Nordqvist, 2026) (6, Nordqvist, 2026).

Learning path (LP-*)
Kind Artefact
Origin AI Governance, Chapter 14 (listed in Appendix C); The Transformed Security Architect, Chapter 22; AI Blue, Chapter 22; AI Purple, Chapter 24
Purpose A path with assessments that takes a named holder from a starting point to target levels
Use when A competence plan accompanies a role charter, or a rotation is designed between functions
Inputs The record of the holder, the framework, the budget for protected time and mentoring
Outputs A YAML path linked from the competence record's development plan
Identifier family LP-* (LP-NR-2027-01, LP-NR-SOC-2027-01, LP-HM-RED-2028-01)
Full template The Transformed Security Architect, Chapter 22 (twelve-month path); AI Purple, Appendix A, "Learning path LP-HM-RED-2028-01"

In AI Governance the path is a Markdown description for a role: Nordvik Region's oversight officer path (paths/oversight-officer.md) takes about nine hours over three weeks in five modules, each ending in a demonstration that writes an entry to the competence record. The Transformed Security Architect gives it a YAML shape: LP-NR-2027-01 (AIDR-0532) sets targets per domain, resources (fifteen per cent protected time, twenty training days, 48 external mentor hours), four quarters each with an evidence item, quarterly no-AI exercises, and a deputy from the platform team with 20 per cent of their time, which answers the single-point-of-failure risk of a one-person post. AI Purple uses a path to rotate staff between red team and detection engineering, with four unassisted checkpoints and a stated consequence of failing one: a return to supervised use for a quarter, with no effect on pay or appraisal (6, Nordqvist, 2026) (9, Nordqvist, 2026).

Twelve-month learning path
Kind Method
Origin The Transformed Security Architect, Chapter 22
Purpose Brings an enterprise architect to Practitioner level in twelve months
Use when An internal candidate has a starting point and the appetite

The path assesses the gap at month 0, builds an unassisted threat model in months 1 to 3, covers the AI domain in months 4 to 6, law and supplier boundaries in months 7 to 9, and consolidates in months 10 to 12 with a design led on a real change and an assessment once unassisted and once with the tool. Its definition of done is a record that shows Practitioner in design, code, adversary and AI (6, Nordqvist, 2026).

Training programme blueprint
Kind Artefact
Origin Architecture as Code, Chapter 18
Purpose A twelve-week blended training programme in YAML
Use when A team adopts Architecture as Code practices and needs a plan for the first quarter
Outputs training-program.yaml with modules, topics and deliverables
Full template Architecture as Code, Chapter 18

The blueprint's modules run in two-week blocks from foundation skills through infrastructure as code fundamentals, automation and CI/CD, and security and compliance, each with deliverables such as a basic Git workflow demonstration or a security policy implementation. The chapter asks managers to track completion but to emphasise practical demonstrations applied to real delivery (1, Nordqvist, 2025).

Hiring profile and interview exercise
Kind Artefact
Origin The Transformed Security Architect, Chapter 22
Purpose A hiring profile and an interview exercise that tests judgement with and without AI
Use when A post is filled from outside because no internal candidate has the experience
Identifier family HP-*, IX-* (HP-HM-2027-01, IX-HM-2027-01)
Full template The Transformed Security Architect, Chapter 22

Hansa Mutual's profile (AIDR-0584) sets required levels per domain, states what candidates are not screened on (tool names, years of experience, a named certificate), and says that the screening is a human review against the required levels with no AI ranking of candidates. The exercise has an unassisted design sitting and a proposal review in two equivalent versions, one with the approved tool in a sandbox, in counterbalanced order, with seeded flaws and a decoy. Unsuccessful candidates' data are kept for six months by default (6, Nordqvist, 2026).

Red apprenticeship route
Kind Method
Origin AI Purple, Chapter 24
Purpose Designs an apprenticeship route that survives the automation of routine emulation work
Use when Entry-level scenario and emulation work is taken over by agents

The route is a practical guide in the chapter, with no code. Its artefact is the learning path LP-HM-RED-2028-01 above (9, Nordqvist, 2026).

Keeping the craft

Automation removes the junior work through which experts learned and may erode the skill of those who remain. The series responds with deliberate practice that is measured at team level and with apprenticeship by design. The tools of this section are the same idea at four scales: a quarterly programme for architects, a twelve-month plan with a register for a blue team, an apprenticeship record owned by the apprentice and a managerial craft programme.

Craft-keeping programme and no-AI exercise calendar (CKP-*)
Kind Artefact (with the method Craft-keeping programme)
Origin The Transformed Security Architect, Chapter 15
Purpose A quarterly programme of no-AI exercises and seeded-error drills for craft-critical capabilities
Use when Agents draft the work that the people used to do, and review is the human's remaining task
Inputs A list of craft-critical capabilities, an agreed reporting level
Outputs A programme file (CKP-HM-SA-2027), a calendar kept in the competence record, seeded-error drill records (SED-*)
Identifier family CKP-* (named "Practice plan without AI" in Appendix B of that book)
Full template The Transformed Security Architect, Chapter 15

Hansa Mutual's programme lists seven craft capabilities, from drawing trust boundaries to explaining a decision to a board without notes, and a cadence: four protected practice hours per fortnight, one unassisted review per architect per month, one seeded-error drill per quarter and one degraded-mode exercise per half-year. Evidence is recorded in the competence record "as evidence in the architect's own words, never as a score", and reporting is at team level. Nordvik Region's calendar is for a single architect with no colleague: exercises are reviewed by a neighbouring region's architect, using synthetic or published designs only, and the book puts the cost at about twelve days a year. Its seeded-error drill, designed with a merge guard that stops any change carrying the seed marker from reaching a production branch, limits seeds to one in fifty queue items per reviewer (6, Nordqvist, 2026).

Apprenticeship plan
Kind Artefact
Origin The Transformed Security Architect, Chapter 15
Purpose Plans the mentoring of a junior architect when junior work is automated
Identifier family AIDR-0562 (plan); competence record CMP-HM-07
Full template The Transformed Security Architect, Chapter 15, "Hansa Mutual's apprenticeship plan"

The plan has four elements: reserved learning tasks that the agents could do but the junior does unaided with a senior's review, pairing on decisions, rotation through review, and a tutor configuration in which the junior's assistant questions and hints rather than answers (6, Nordqvist, 2026).

Apprenticeship record
Kind Artefact
Origin AI Blue, Chapter 23 (Appendix A)
Purpose A development record for a junior analyst, owned by the apprentice, with attempt-first use of the assistant
Use when A new analyst is made in a team whose agents work the queue
Identifier family APP-* (APP-HM-2027-01, AIDR-0781)
Full template AI Blue, Appendix A, "Worked example: apprenticeship record for a junior analyst at Hansa Mutual"

The record has three stages with what the apprentice may and may not do in each, a stage gate assessed by demonstration, and a statement that the tooling never decides. It is visible to the apprentice, the mentor and, at stage level only, the SOC lead, and it lists forbidden uses: pay, ranking, dismissal, performance rating and team reporting by name. The competence record receives levels only. If a stage is not met, the stage is extended and mentoring added; removal from the post is excluded (8, Nordqvist, 2026).

Craft programme and craft register
Kind Artefact
Origin AI Blue, Chapter 23 (Appendix B.21)
Purpose A twelve-month plan with a randomised unassisted share, seeded incidents, rotation, degraded-mode drills and a register of classes needing supervision
Use when A team delegates to agents at a level that depends on the people still being able to do the work
Outputs A programme and a register in version control, beside the mandate manifests
Full template None; described in the chapter's practical guide "Setting up a craft programme"

The craft register is a team-level table of the tasks the agents perform or support, with the number of analysts who have demonstrated each without assistance in the last twelve months, the date of the last demonstration and the minimum for the current degree of delegation. A name never appears in it. A class below its minimum is returned to Level 2 Supervised until it recovers. The register is what turns skill into a design variable of the delegation (8, Nordqvist, 2026).

Managerial craft programme and the manager's competence record
Kind Method, with the artefact Competence record for a manager
Origin AI Boss, Chapter 19
Purpose Keeps the judgement needed to oversee drafting systems (hand-made plans in reserved periods, drafting first, seeded-error drills) and evidences it for development and selection
Identifier family CMP-NR-MGR-01
Full template AI Boss, Chapter 19, "A competence record for a first-line manager"

The record of Nordvik Region's home-care unit manager (terms in AIDR-0608) lists judgement exercised, such as rosters changed and the reasons, disagreements with a rating, unassisted practice and conversations held. It refers to the Management Decision Records (Chapter 22) and does not copy them. The book cautions that an override count is not a measure of judgement: frequent overrides may be judgement or habit, and none may be complacency or a system that is right. Individual override rates are therefore not used to rank managers (7, Nordqvist, 2026).

Across the usage modes

The competence that each tool must evidence depends on the usage mode of the AI the person works with. AI Governance, Chapter 14, tabulated literacy for users and competence for operating teams by mode, and The Transformed Security Architect, Chapter 21, translated the levels of autonomy into what the architect must be able to do and how it is shown (2, Nordqvist, 2026) (6, Nordqvist, 2026).

Usage mode or level What differs for the tools of this chapter Tool that carries it
Mode 0 Ambient AI Staff must recognise AI-generated summaries; nobody chose the tool, so nobody is trained for it AI literacy objectives in the competence framework
Modes 1 to 2 Acceptable use, data classification, permission hygiene Learning path modules; framework entries at awareness level
Mode 3 Agentic work tools The person approves actions a tool then executes, so engineering judgement is needed; declared-use log and seeded-error results are evidence CKP-* programme; seeded-error drills
Mode 4 Built AI applications Oversight staff need intended purpose, limitations and override procedure; evidence before go-live Oversight officer role and path; framework with evidence_required_before_go_live
Mode 5 Autonomous production agents Design of identity, containment and stop paths; operation with the agent platform unavailable OPS-CF manual operation (MO); unassisted containment profile (AI-02); dark days
Level 3 Bounded Supervisors write and test the bounding playbook unaided; holders per site are counted AI-03 at Advanced; competence conditions
Level 4 Autonomous Deciding that an action is reversible enough is an expert decision recorded in an AIDR; never for irreversible actions Charter never_delegated; Expert-level evidence

Role charters, learning paths and the on-call charter do not differ by mode; what changes is the content of the competences and the evidence type they require.

Nordvik Region and Hansa Mutual

Nordvik Region has a single security architect, six analysts, seven platform engineers and no Mode 5 agent. It therefore uses subsets of the group-sized frameworks (SOC-CF-NR with 12 identifiers, OPS-CF-NR with eight) and records the omissions as decisions. Its role charter ROLE-NR-SA-01 and record CMP-NR-01 carry a single post; the learning path LP-NR-2027-01 includes a deputy from the platform team and an external mentor, because there is no second security architect. Its craft practice depends on peer exchange with a neighbouring region on synthetic material. Its on-call charter ONC-NR-2029-01 and drill-year plan PLAN-NR-OPS-2029-01 were agreed under the co-determination agreement MBL-NR-IT-2027-01, and the manager's record CMP-NR-MGR-01 rests on terms negotiated with the unions (AIDR-0608).

Hansa Mutual has breadth: the 24-identifier SOC-CF, the thirteen-identifier OPS-CF, conductor and line-manager charters with a stop right and a protected time budget, and competence conditions on two sites that tie Level 3 ceilings to evidenced holders at both (AIDR-0780). Its records are agreed with the Konzernbetriebsrat and the Polish employee representatives and exclude ranking, pay setting and disciplinary process. The pattern differs from Nordvik's: Nordvik uses exercises to find out what its few people can do, and Hansa uses them to keep the autonomy of its agents in step with a large team's demonstrated judgement (8, Nordqvist, 2026).

How to choose among them

A practitioner who needs one of these tools can start from the question being asked. To say what a role may decide, use the role charter of the nearest function and the five-step method. To say what a function's people must be able to do, adopt the nearest framework as a subset, record the omissions as decisions and map to the external frameworks only from the merged local file. To show what a person has demonstrated, use the competence record with a closed list of purposes and a list of prohibited uses, agreed before the first assessment. To tie an agent's ceiling to people, use competence conditions that read levels and validity only. To keep the ability alive, use the craft programme and the register at team level, and the apprenticeship record owned by the apprentice. The same three prohibitions run through all of them: no per-person ranking, no competence claim without an exercise, and no reading of a record beyond its named readers.

The chapter treats 47 of the 52 inventory entries, some in entries of their own and some in family tables or in entries that combine the versions of one artefact held by several volumes; Appendix A lists all of them. Five entries are reassigned in the findings file: the training run record (AI Platform and Security, Chapter 7), the procurement clause on training-data transparency (AI Threat, Chapter 16), the layered assurance against evaluation awareness (AI Threat, Chapter 23) and Goodhart's law awareness (AI Purple, Chapters 8 and 18) go to the chapters of this book that treat their activity, and the method of introducing, pausing or retiring a screening model with a record (AI Boss, Chapter 7) is treated in Chapter 22.

Summary

The tools of this chapter share one design. A role charter states decision rights with a time limit and names what is never delegated. A competence framework states, for each competence and level, what evidence shows it, and counts the lower of the unassisted and assisted forms. A competence record holds levels and references, a closed list of purposes, prohibited uses and readers, and a development plan. Competence conditions read only levels and validity, and lower an agent's ceiling when too few evidenced holders remain. Learning paths, craft programmes, registers and apprenticeship records keep the ability alive and report at team level, never by name. The series' most reusable rule, in the conclusion of this chapter, is that a record that cannot be used for ranking, pay or discipline can be shared widely enough to be useful, and that the first thing to agree with employee representatives is what the record may not be used for.

The chapter also leaves open questions that the findings file records: the validity of a record is 24 months in one volume, twelve in another and 90 days in a third; the CMP-* and LP-* identifier families are used by several volumes with no reserved ranges; and the first level is called Foundation in some volumes and awareness in others.

Sources

  1. Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
  2. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
  3. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
  4. Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (7, Nordqvist, 2026)
  5. Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
  6. Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
  7. Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
  8. European Union Agency for Cybersecurity. European Cybersecurity Skills Framework (ECSF) Role Profiles. (112, ENISA, 2022)
  9. European Union Agency for Cybersecurity. European Cybersecurity Skills Framework (ECSF): User manual. (113, ENISA, 2022)
  10. SFIA Foundation. SFIA 9: the global skills and competency framework for the digital world. (114, SFIA Foundation, 2024)
  11. Petersen, R., Santos, D., Wetzel, K. Workforce Framework for Cybersecurity (NICE Framework). (115, Petersen et al., 2020)
  12. European Committee for Standardization. EN 16234-1:2019 e-Competence Framework (e-CF): A common European framework for ICT professionals in all sectors, Part 1: Framework. (116, European Committee for Standardization (CEN), 2019)
  13. ISC2. CISSP-ISSAP: Information Systems Security Architecture Professional. (117, ISC2 (n.d.), n.d.)
  14. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (195, European Union, 2024)
  15. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (196, European Union, 2016)
  16. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). (199, European Union, 2026)