The One-Page Landscape: Drawing It From What You Already Have

On a Friday afternoon in December 2026, the AI architect of Nordvik Region has three documents open. The scene is illustrative. The first is the Region's AI inventory, a list with one line for each AI system: its purpose, its owner, its risk class and whether it is in pilot, in use or stopped. The second is the written mandate under which the platform team and the security architect run coding and architecture agents; for each kind of action, it says what the agents may do without asking. The third is the agreement with the unions on the rostering system for home care, which says what the system may allocate by itself and who approves every roster.

None of the three was written to draw a picture. The inventory answers "what do we have", the mandate "what may it do" and the agreement "who decided". By the end of the afternoon the architect has joined them into one file and one figure: the Region's landscape as it will stand on 1 January 2027, with eleven marks on it (Figure 14.1). Two of the eleven were on none of the three documents.

This chapter shows how to do what the architect did. The landscape model, the text file from which every figure of an organisation in this book is drawn, is filled field by field from records the organisation already keeps. Two dimensions that no record holds, reversibility and reach, are assessed, the seat is found, and what nobody knows is drawn as unknown. The claim is modest and, I think, important: a landscape is a join of records that already exist, and the places where the join fails are the first things the picture has to say.

Author's note needed: Two paragraphs at most from the author's own practice of populating a first landscape model for a real organisation: what the registers contained, how long it took and which unit turned out to be missing. It would sit here, replacing or beside the illustrative opening.

Figure 14.1: Nordvik Region's one-page landscape on 1 January 2027, V1, the figure this chapter populates from the Region's records. Illustrative: rendered from landscape/models/nordvik_region.yaml.

What an organisation already has

A landscape needs four kinds of record, and most large organisations hold them already, in places that have never been read together.

The first is the AI inventory: the authoritative list of every AI system the organisation provides or deploys, with purpose, risk class, owner and lifecycle status. AI Governance, Chapter 9, makes keeping it a rule, "you cannot govern what you cannot enumerate", and treats a deployed system that is missing from it as a finding (2, Nordqvist, 2026). Each entry also records one of the six usage modes, from Mode 0 Ambient AI, which people meet without having chosen it, to Mode 5 Autonomous production agents.

The second is the mandate: the written statement of what an AI agent may do. AI Red Team, Chapter 6, sets the autonomy level per class of action, and Chapter 7 requires the written mandate and the signed rules of engagement that record it (4, Nordqvist, 2026). The Transformed Security Architect, Chapter 13, gives the mandate its file form, the mandate manifest, which a machine can read and which answers four questions: who decides what the AI may do, who decides each action, who answers for it and who can stop it (6, Nordqvist, 2026). It is where the autonomy level of each action is written down, and where a policy decision point is named: deterministic code outside the model that checks every request the model makes to a tool before the request runs.

The third is the delegation register: for each system that directs or evaluates people, a delegation profile records the degree of delegation per management function, the people who decide, the agreement with the employees' representatives, the stop path and a test of whether the delegation could still be undone. AI Boss introduces the profile in Chapter 4 and keeps the profiles in a register in Chapter 25 (7, Nordqvist, 2026).

The fourth is not a register at all. It is the contracts, which say which supplier does what and where, and the proxy logs, which record which AI services people actually reach from their desks. Nobody curates the proxy logs, which is why they find what the others missed. Alongside these sit the decision records: short numbered notes of a decision, its context and its consequences.

The model is the join of these records, one mark per unit, one AI use as Chapter 4 defined it. The unit is the use, which is what the inventory lists; the product behind it and the people around it are dimensions of its mark.

From record to model

The table says which record answers which field.

Model field	Comes from
name, description, mode, since, status	the inventory: purpose, usage mode, lifecycle
decision_holder, decision_tier	the inventory's owner, the mandate's "who answers", the delegation profile's deciders, placed on T1 to T4
hosting, operated_by, suppliers	the inventory and the contract, by role and jurisdiction
level, action_levels	the mandate's level per class of action; the delegation profile's degree per function
identity	the inventory: own for a machine identity, person for a delegated session
policy_point	the mandate: enforced, planned or none
evidence, evidence_kinds	gates and logs (automatic); attestations (attested)
reversibility, reach	assessed; the delegation register's reversibility test where there is one

Three entries need a word. The inventory's purpose becomes the unit's name, and the discipline is to name the use and not the product, because one product used in two ways is two units. The owner is the first candidate for the decision holder, since the unit head owns the system. And the risk class is the one field the notation refuses to draw. Whether a unit is a high-risk AI system under the AI Act, Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, follows from its use and from the law (39, European Union, 2024) (40, European Union, 2026), so the model keeps it in the description. The benefits-triage system carries "high-risk (Annex III point 5(a))", Annex III being the AI Act's list of uses that count as high-risk, here the evaluation of eligibility for essential public assistance benefits.

Where a unit does several kinds of thing, as agents do, the level per class of action goes into action_levels and the mark is drawn at the highest level the unit holds for any action that changes something outside it; actions that only read do not set the column. The rostering system shows the pattern. It holds Level 2 Supervised for drafting a roster and for offering an open shift to staff who opted in, and Level 1 Assisted for flagging a breach of the rest rules, so the model draws it at Level 2. In the scenario of Chapter 18 its open-shift class moves to Level 3 Bounded on 11 March 2027, and the mark moves with it.

The stop path is the field that migrates. A stop path that runs inside the system it stops fails when it is needed, so the mandate names a path outside the unit, and the landscape records it under evidence by whether it has been exercised. A stop run in a drill and logged is evidence, and the baseline is solid. A stop that exists as a paragraph in the mandate is a declaration, and the baseline is dashed.

Assessing reversibility

Reversibility is the row of the mark, and no inventory records it. The four tiers ask one thing of the unit: what it would take to undo the action the AI takes or shapes. A draft, a suggested ranking or a quarantined email can be undone at once (R1). A roster or a merged code change takes effort and a known procedure (R2). A benefit application pushed down a queue for a month, or a premium quoted, takes weeks and a process (R3). A deleted archive, a published personal dataset or a final administrative decision taken without a person cannot be undone (R4).

Two rules make the assessment repeatable. Assess the action, not the breach: what a compromised version could do belongs in the threat register, not here. And draw a unit with several classes of action at the tier of the hardest to reverse. The rostering system drafts rosters a manager can redraw, which is R1, and publishes rosters that staff have planned their lives around, which is R2, so it sits at R2.

The word "shapes" carries the chapter's first warning. A unit at Level 0 Advisory does not act, but its row is set all the same by the outcome its suggestion shapes. Nordvik Region's benefits-triage system only ranks a queue, and caseworkers decide every case, so it sits in the leftmost column. The queue it ranks sets how long an applicant waits for assistance, so it sits at R3.

The delegation register adds the one input that is tested rather than assessed. Its reversibility test asks whether the people who would take the work back still can. AI Boss, Chapter 33, concludes that reversibility decays within months of go-live, not years, and says itself that this is illustrated by its two fictional organisations and not measured (7, Nordqvist, 2026). This book takes the same care. A failed test moves the mark up a row; Chapter 15 shows what the test found at each organisation.

Assessing reach

Reach is the size of the mark: the number of people whose work or whose outcomes the unit touches in a year. S is under 100 people, M is 100 to 999, L is 1,000 to 9,999 and XL is 10,000 and more. The count is of people, not of transactions: a unit that handles 40,000 applications from 25,000 applicants in a year is XL by people.

Two populations are counted together, the staff who use the unit and the people whose cases it touches. Nordvik Region's figures, which are illustrative, show the range. The internal staff assistant is used by about 3,200 staff and touches nobody outside, so it is L. The case-note summariser serves 180 social-services caseworkers, so it is M. The benefits-triage system orders the applications of residents in a Region of about 450,000, so it is XL however the applicants are counted. The sources are the inventory's user counts, the licence counts and the case counts, converted to people. Where a pilot widens, the model adds a dated timeline entry rather than changing the size in place.

Finding the seat

The seat is the small grey circle above the mark that carries the decision tier of the person who holds the decision right for the unit: T1 the operator or user, T2 the system owner or architect, T3 an executive, T4 the board or an elected body. When nobody is named, the seat is absent and the tier is T0.

Ask three things of the unit. Who may raise or lower its autonomy level? Who may stop it today without asking anyone? Who answers for it? The decision record usually settles the first, the mandate the second and the delegation profile the third. Where the answers are one role, the seat is that role's tier; where they differ, the seat carries the holder of the first and the others go into the notes.

Translating a role into a tier is a judgement, made once and written down. A caseworker, an analyst or a developer who runs the tool is T1. A unit head who owns the system, or the architect who owns its mandate, is T2; Nordvik Region's chief information security officer holds the seat of the platform team's agentic work tools at T2. A director who holds the right by policy rather than by ownership, as the HR director does for the rostering system, is T3. An elected committee or a management body is T4.

Two cautions apply. The seat names a tier, not a competence: a person attached to a system's output can absorb the blame without having had the means to decide, and Chapter 17 asks whether the holder could decide otherwise. And a Mode 0 unit almost never has a seat on the first afternoon, because vendor AI inside licensed products may already act at an autonomy nobody decided. The honest mark for it is a square at Level 4 with no seat, no diamond and no baseline, which is how Nordvik Region's ambient AI is drawn on 1 January 2027.

Drawing the unknown

Sooner or later a field has no answer: nobody can say who owns the unit, whether a policy point exists or where the processing happens. The rule is to draw it as unknown and to read the gap as the finding.

For four dimensions the notation draws the unknown as an absence, and the model has a value for it: decision_tier: T0 and no seat; policy_point: none and no diamond; evidence: none and no baseline; and hosting: unknown, which the supply view of Chapter 16 places in a container labelled as such.

For mode, level, reversibility and reach the model has no unknown value, because a mark has to sit somewhere on the grid. The convention this book uses is the worst defensible case, written down as such. Where nobody has decided the level, draw the unit at the level its permissions allow, because a level nobody set is, in effect, whatever the permissions permit; write "level not decided" in the notes so that the mark is challenged rather than accepted. Where nobody can say the reversibility, draw the hardest action the permissions allow. Where nobody knows the reach, use the licence count. Do not leave a unit out because its fields are unknown. A bare square at Level 4 with nothing around it is the most useful mark on the page, because it is the one the picture was for.

Reading a model

The model is a text file, one per organisation, checked against a schema that lists the allowed fields and values; Appendix A documents every field. Each unit records the seven dimensions, the bookkeeping fields and the identifiers of the records that populated it. The unit's top-level fields give its state at the start of the period; change is a timeline, a list of dated entries that carry only the fields that changed. A renderer, a short program that reads the model and draws every view, applies the entries up to the date it is asked for. The rostering system's entry in Nordvik Region's model shows both ideas, with its description, its register identifiers and one note left out:

- id: NR-SW
  name: Rostering and shift allocation
  since: "2026-10-01"
  mode: 4
  identity: own
  level: 2
  reversibility: R2
  reach: L
  policy_point: planned
  decision_tier: T3
  decision_holder: HR director
  evidence: attested
  evidence_kinds: [attestations]
  operated_by: supplier
  hosting: eu-supplier
  suppliers: [shiftwise]
  status: pilot
  action_levels: {"draft a roster": 2, "offer an open shift": 2, "flag a rest-rule breach": 1}
  timeline:
    - date: "2027-01-20"
      policy_point: enforced
      status: active
    - date: "2027-03-11"
      level: 3
      action_levels: {"draft a roster": 2, "offer an open shift": 3, "flag a rest-rule breach": 1}
      evidence: automatic
      evidence_kinds: [logs, gates, attestations]
      note: Travel-time and rest constraints enforced as hard constraints; open-shift offers at Level 3 Bounded within the profile.

Read from the top. On 1 January 2027 the unit is a square, an identity of its own, at Level 2 and R2, with a hollow diamond because its policy point is planned, a T3 seat held by the HR director and a dashed baseline because the only evidence is the supplier's attestation. The first timeline entry fills the diamond and puts the unit into service. The second moves the column, because the open-shift class now runs at Level 3 Bounded within the delegation profile agreed with the unions, and turns the baseline solid because the system now produces logs and gate results of its own. Chapter 15 reads the same entries as a trail. Because the renderer draws every view from the model and a check fails whenever a committed figure no longer matches it, the record and the picture cannot drift apart.

The same picture can be drawn by hand in five minutes, and the first landscape of many organisations will be drawn that way, in a meeting; Appendix B carries the page. Draw five columns and four rows, shade the top-right cell, and place one mark per unit: a circle for a person's identity, a rounded square for an identity of its own, in one of four sizes, with the mode number inside. Add the diamond, the seat and the baseline. The renderer makes the sketch exact, not possible; what a sketch does that a file cannot is put the question of the seat to the people in the room.

What to do

For an executive

Ask for the list that comes out of the exercise, not for the picture: every unit with no seat, every agent without an enforced policy point, every control whose proof is a declaration. Then ask who is accountable for each gap and by when it closes. A board that receives only a picture has been shown what was found, not what to decide.

For an architect

An organisation that keeps no inventory starts at the second step, with the proxy logs.

1. Make one unit per inventory entry, naming the use and not the product, and list every supplier by role and jurisdiction from the contracts.
2. Read the proxy logs for the last quarter and the licence terms of the office suite, the email gateway and the business systems. Each AI service nobody registered becomes a unit with no seat; each family of features a vendor switched on becomes one Mode 0 unit.
3. For every unit, copy the level per class of action from the mandate or the delegation profile, or name the hardest action it takes and what it would take to undo it.
4. Count reach in people, find the seat, and set the evidence by whether the stop path has been exercised.
5. For every field you cannot fill, use the unknown value, or the worst defensible case with a note. Do not drop the unit.
6. Check the file against the schema, render the picture, and list every absent seat, every absent diamond at Level 3 and above, every dashed baseline at R3 and every "not decided". That list is the deliverable.

For a public official

A public authority can ask a supplier for exactly the fields a unit needs: its role, where it runs, what it may do without a person approving, who can stop it and what evidence the supplier will produce. Written into a tender, they are the fields of the model, and the picture can be drawn from the contract.

Nordvik Region and Hansa Mutual

The two organisations populate the model in opposite ways; both episodes are illustrative.

At Nordvik Region the work is the afternoon of the opening scene. Nine of the eleven marks come from records the Region already keeps, most of them from the inventory; the mandate fills the platform team's agentic work tools, with four classes of action and the chief information security officer in the seat, and the delegation profile fills the rostering system, with three classes and the HR director in the seat. Then the architect opens the contracts and the proxy logs and finds the two units nobody had registered. The licence terms of the office suite, the email gateway and the security tooling show AI features that vendors switched on by product update: Mode 0 Ambient AI, at whatever level the vendors chose, with no owner, no policy point and no evidence. The proxy logs show the approved enterprise conversational assistant, used by thousands of staff under an acceptable-use policy the regional director signed, but entered in no inventory. The ambient AI becomes a bare square at Level 4 Autonomous and R2 with no seat; the conversational assistants become a circle at Level 1 Assisted with a T3 seat and a dashed baseline. The list of findings is short: one unit with no seat, three with a planned policy point and four whose evidence is a declaration.

The model's timeline carries the picture through 2027. In the scenario of Chapter 18, the ambient AI is seated on 30 June and the recruitment screening pilot, paused since September 2026, is retired the same day. Figure 14.2 shows the end of the year, with thirteen marks.

Figure 14.2: Nordvik Region's one-page landscape on 31 December 2027, V1, rendered from the same model after its timeline entries for the year. Illustrative: rendered from landscape/models/nordvik_region.yaml.

At Hansa Mutual nobody has an afternoon like that, because the group platform team generates the model from the records in a pipeline: the records are files in one repository, and a step reads them, writes the model and renders the views on every change. The gain is that a unit cannot be forgotten, since a description without a landscape entry fails the build. The cost is that the pipeline draws what the records say and nothing else. Seventeen marks at the start of 2027, generated in seconds, do not by themselves answer the question the afternoon at Nordvik Region answered by hand: whether the page is the whole landscape.

Summary

A landscape is drawn from what an organisation already has. The AI inventory gives each unit its name, mode, owner, lifecycle and hosting; the mandate gives its level per class of action, its policy point and who can stop it; the delegation register gives the degree per management function, the deciders and the one reversibility test. The proxy logs give the units none of the records knew about. The model is the join, one mark per AI use, with the identifiers of the records kept on every mark.

Three fields are assessed rather than copied. Reversibility is assessed on the action the unit takes or shapes, at its hardest-to-reverse class, which is why a Level 0 Advisory unit can sit high on the page. Reach is counted in people, never in transactions. The seat is found by asking who may change the level, who may stop the unit today and who answers; it names a tier, not a competence. When a field is unknown, the unit is drawn anyway, with the absence where the notation has one and the worst defensible case, noted as such, where it has not.

The model is a file checked against a schema, a renderer draws every view from it, and the same picture can be sketched by hand in five minutes. Nordvik Region filled its model by hand and found two units nobody had registered; Hansa Mutual generates its model in a pipeline and has to ask by hand whether the pipeline sees everything. Both pictures are illustrative; the method is not. The gaps are the finding, and the list of gaps, not the figure, is what the work produces. Chapter 15 takes the model's timeline and draws the year.

Sources

1. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. aig.geon.se. (2, Nordqvist, 2026)
2. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. aired.geon.se. (4, Nordqvist, 2026)
3. Nordqvist, G. (2026). The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. tsa.geon.se. (6, Nordqvist, 2026)
4. Nordqvist, G. (2026). AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. aiboss.geon.se. (7, Nordqvist, 2026)
5. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act). Official Journal of the European Union. (39, European Union, 2024)
6. European Parliament and Council of the European Union (2026). Regulation (EU) 2026/1744 (Digital Omnibus on AI). Official Journal of the European Union. (40, European Union, 2026)