What the Organisation Provides: Sandboxes, Templates, Golden Paths and a Register

The first sixteen chapters taught the builder. This one is for the people who run the platform, the tools and the budget, and it asks what they owe the builder in return. A builder who follows the twelve steps still needs somewhere to follow them: a place to work that holds no production data, an assistant the organisation has approved, a repository that already contains the files the steps ask for, a pipeline that promotes the result, a list that shows the result exists, and a developer who will take it over. If those are missing, the steps are a private discipline that costs the builder an evening each time. If they exist, most of the steps become a matter of filling in a file that is already there. The chapter concerns Step 3 Workshop, Step 9 Ship and Step 12 Hand over, because those are the steps where the builder most depends on something that only the organisation can supply, and the developer functions D2 Design, D3 Build and D5 Steward, because the provision is a design decision, a build task for the platform team and a duty of stewardship over many small tools at once.

Figure 17.1: The builder lane. The pipeline identity promotes, the register shows what exists, a receiving developer takes over and the stop path is held outside the assistant.

The argument has five parts. The gap between vibe coding and professional work has two sides, and an organisation that trains builders without providing the road has closed half of it. The provision is small and concrete: a workspace, templates with the steps built in, a register, a receiving developer and a support path. Prohibition is the weakest of the available responses, and the evidence on it is thin but points the same way. The provision is cheap to describe and easy to claim, so it has to be measured, with evidence that has an age. And the whole thing is a lane, not a gate: builders are not asked for permission, they are given a route that is easier than the alternatives. The chapter takes the register, the templates and the sandboxes from AI Developer, Chapter 19, which governed the builder from the organisation's side with four tiers and promotion gates, and the method of finding unsanctioned tools by asking and by service from AI Leader, Chapter 10 (86, Nordqvist, 2026) (85, Nordqvist, 2026). It adds the builder's view of the same provision and a plan for building it in 90 days. The platform in the examples is that of Nordvik Region, led by Maja Lindqvist, and the lane is that of Hansa Mutual's Group Application Development.

The gap has two sides

Chapter 2 described what vibe coding is: building software by conversation with an assistant without reading or structuring what comes back. Chapter 4 described what closes the gap on the builder's side, which is a set of habits, twelve steps and a gate at the end of each. The habits are real, but a habit is easier to keep when the surroundings help. A builder who has to find out for herself how to get a clean test dataset, where secrets are kept, which assistant is allowed and who could take over the tool will, on most evenings, skip one of those questions, and the organisation will not know which.

The case that the organisation's share matters rests on four kinds of evidence, none of them a measurement of lanes. First, the population is large and was large before AI. A survey of the research on end-user software engineering opens with a projection, from United States labour statistics, of fewer than 3 million professional programmers and more than 55 million people using spreadsheets and databases at work by 2012 (105, Ko et al., 2011). Building software outside the development organisation is the normal condition, and what changes is the reach of what a non-developer can build. Second, what non-developers build with AI is already in public use. A 2026 preprint audited 200 publicly deployed applications drawn from 9,041 open-source applications built with two AI app-building tools and found 1,186 vulnerabilities, with 91.0 per cent of the audited applications carrying at least one and 65.77 per cent of the vulnerabilities rated Critical or High, clustered in broken access control, injection and authentication failures; the study is not peer reviewed and concerns public applications, not those of any one organisation (109, Deng et al., 2026). Third, the failures of this kind often come from a default and not from carelessness. In 2021 a security vendor reported 38 million records exposed through Power Apps portals of 47 entities because lists had table permissions disabled by default, which the supplier first called by design and later changed for new portals (143, UpGuard, 2021), and the National Vulnerability Database records a row-level security weakness in one natural-language builder that let unauthenticated visitors read or write the tables of generated sites, a record tagged disputed because the supplier states that each customer is responsible for its own data (144, NIST, 2025). Fourth, a survey sponsored by a consultancy and a university, with self-reported data, found that people in organisations with a ban or a policy still put sensitive material into public AI tools (the figures are given below), so that the absence of a sanctioned route is not corrected by a rule alone (32, Gillespie et al., 2025).

The book's conclusion from these four is that a default decides more than a warning does. If the default in the organisation's workspace is a store that denies access until a rule grants it, a template whose pipeline fails when a secret is committed and an assistant whose mandate it cannot widen, the builder's good habit is the path of least effort. That is the sense in which the gap has two sides. This is the book's own conclusion; no study cited here measured the effect of a builder lane on outcomes.

The builder workspace

A builder workspace is the place where builders work: an environment, set up by the platform team, where the approved assistant, the repository service, the synthetic data and the secrets store are available together and production is not. It is not a separate product. It is a set of configurations of things the organisation already runs, and its first job is to remove the reasons for working elsewhere.

Five parts matter. The first is the approved assistant, at the usage modes of the series: Mode 2 (an assistant embedded in the editor) and Mode 3 (an agentic work tool executing delegated tasks) inside a sandbox, under a written mandate (MND-*-BLD-*, introduced in Chapter 7). Mode 5, autonomous production agents, is not provided to builders, and Level 4 Autonomous is not used for any action class. The second is synthetic data: generated records that have the shape of the real ones and none of their content, so that the builder can develop against realistic input without any personal data leaving production. The third is a secrets store, a service that holds passwords and keys and hands them to a running tool at the moment it runs, so that they are never in the repository or in a conversation with an assistant (Chapter 12). The fourth is the repository service with branch protection, so that the assistant works on a branch and a person merges. The fifth is the pipeline, which tests, scans and deploys, and whose identity, not the builder's, is the only one that can promote a tool into production. A builder with all five has what a professional developer in the same organisation has, at a smaller scale and with the dangerous permissions removed.

Platform vendors describe the same pattern in their own terms, and the book uses them as examples of a pattern and not as recommendations. One vendor's guidance for its low-code platform says that data policies are guardrails that enforce which connectors are enabled in each environment and which can be used together, that they are scoped to an environment or a tenant and not to a user, and that by default no data policies are implemented in the tenant (107, Microsoft, 2025). The same vendor's environment strategy describes the default environment as the place where personal productivity apps often start, the routing of makers to personal developer environments, separate development, test and production environments, and pipelines that promote assets between them (108, Microsoft, 2026). Both pages describe features; neither measures how well they work in an organisation, and the book makes no claim that they do. They show that the workspace is a known pattern: a place to build that cannot reach production, and a path that promotes.

Nordvik Region: the builder workspace

Maja Lindqvist's platform team opened the Region's builder workspace on 6 October 2031, recorded as AIDR-1200. It was built from parts the team already operated: the Region's Git service, the secrets store used by the integration teams, the pipeline engine, an approved assistant at Mode 2 and Mode 3 in a sandbox that cannot read production configuration, and a repository of synthetic data sets. Because the Region has no autonomous production agents (Mode 5), the assistant's sandbox has no route to any production system at all. The first template was the scheduled-job template, which Hanna Wikström's service-point-check later used for its Monday report. The workspace opened four weeks after Hanna had started her build on 8 September; her first weeks used public data and the enterprise chat assistant at Mode 1, which is why BLD-NR-2031-0001 carries the note that the first draft of the specification predates the mandate. The mandate itself, MND-NR-BLD-2031-01, was adopted a week later (AIDR-1201).

Templates with the steps built in

A repository template is a starting repository that a builder copies, so that a new tool begins with the files and checks that the twelve steps ask for. The idea is the oldest one in platform work. A golden path, in the words of an engineering team that described it, is the opinionated and supported path to build something; its aim is not to limit engineers, and engineers may leave it with less support (59, Niemen, 2020). The word that matters is supported. A path is golden because following it brings help, not because leaving it is forbidden.

For a builder the template has to contain at least these items:

builder-template-scheduled-job/
  AGENTS.md                  # rules file for the assistant, signed by the owner
  README.md                  # what the tool is for, how to run it, who to call
  pipeline.yml               # stages test, scan, deploy; fails on secrets and on missing files
  pyproject.toml             # pinned dependencies, Python 3.12
  src/                       # the tool's code
  tests/
    test_smoke.py            # one passing test, so the first pipeline run is green
    oracle/cases.yaml        # empty, to be filled by someone other than the builder
  data/synthetic/            # synthetic data only; the pipeline rejects other files
  docs/
    build-record.yaml        # BLD record skeleton, tier decision, gates
    specification.yaml       # SPC record skeleton
    ownership.yaml           # OWN record skeleton: owner, deputy, review dates, sunset
    runbook.yaml             # RBK record skeleton: start, stop, restore
    handover.yaml            # HND record skeleton
    adr/0001-template.md
  CHANGELOG.md

Three properties make such a template more than a folder of examples. The first is that it fails early and in plain words: a pipeline that stops with "docs/ownership.yaml has no deputy" is a step-by-step guide that cannot be skipped. The second is that the files are skeletons that the builder fills in, so that the gate of each step is met by completing a file that already exists and not by inventing a format. The third is that the secure defaults are already set: no network egress other than what the template lists, no secrets in the repository, access denied until granted. This is the lesson of the permission failures above; the template carries the setting that a builder would otherwise have to know about.

A template for a builder does not replace judgement. Chapter 6 decides the tier, and the template cannot know the tier. A scheduled-job template is a good start for a Tier B tool that becomes Tier C when it runs unattended, as service-point-check does at version 0.2.0; it is the wrong start for anything that ranks or decides about a person, which is Tier D and not a citizen build. The template's README says so in its first paragraph.

The register

A register is the organisation's list of what builders have made: one entry per tool, in version control, with its owner, deputy, tier, data classes, receiving developer, evidence dates and sunset. It is the instrument that turns a collection of private tools into something the organisation can govern, and it answers questions that otherwise have no answer: who owns this, what data does it touch, when was it last tested, and what happens when its owner leaves.

Three rules keep a register honest. Entries are written where the work is done, as part of the build record, and not collected afterwards by a survey. Discovery is by service and by asking, never by watching named individuals: the platform team counts which services and tools are reached from the network and the platforms without identifying who, holds structured conversations with units about what they build, and offers a time-limited amnesty in which declaring a tool has no consequence (AI Leader, Chapter 10) (85, Nordqvist, 2026). Covert monitoring of staff is never a method of this book. And evidence in the register expires: an entry states when each claim was checked and how long the check is valid, so that a register shows a state and not a hope.

A register entry for the Region's first builder tool looks like this:

register: BREG-NR
entry: BLD-NR-2031-0001
name: service-point-check
owner: Hanna Wikström
deputy: Elin Berg
manager: Gunilla Roos
tier: C                         # B as an on-demand tool; C from scheduled running (AIDR-1203)
tier_decided_on: 2031-12-15
data_classes: [public, internal]
personal_data: none
runs: scheduled, Mondays 06:00, scheduled-job template
receiving_developer: Rasmus Holm
repository: service-point-check
sunset: 2033-08-31
evidence:
  tests:        {result: pass, date: 2031-12-08, valid_days: 90}
  takeover:     {result: pass_after_fix, date: 2031-12-12, valid_days: 365}
  restore_test: {result: pass, date: 2031-12-05, valid_days: 90}
next_review: 2032-03-04         # 90 days after the oldest evidence
discovered_by: declared

The valid_days figure of 90 is the book's illustrative validity for evidence about a running tool of Tier C (the takeover test is valid for twelve months, Chapter 16), following AI Developer, Chapter 19 (86, Nordqvist, 2026); a platform team may choose another period if it records the choice. "Not tested" counts as not met, so a register entry with no restore test shows as red and is not left blank.

The receiving developer

The twelfth step ends in a person: a developer who did not build the tool and who can, in a working day, run it, change it, ship the change and switch it off and restore it (the takeover test, Chapter 16). That person does not appear by themselves. The organisation provides them by naming one per area, giving them time and recognising the work.

Time is the difficult part. A receiving developer who takes a builder's tool on top of a full backlog will do the takeover test as a formality, and the book's argument for the test collapses. A workable rule is a protected allowance, stated in the lane's manifest, for example half a day a fortnight per active build in its first quarter, falling when the tool is stable. Recognition is a matter for the line manager: the work counts in the developer's objectives, and the developer is told that it is a form of the stewardship that the role already carries. A handover reception route completes the arrangement. A builder who has finished Step 12 knows where to take the pack, a developer who receives it knows what a complete pack contains (Chapter 16), and the register entry carries the developer's name. Where no developer will receive a tool, the tool does not move up a tier; it stays where it is, with a sunset date, or it is switched off. That is a decision the organisation has made, not a failure of the builder.

A support path, and the stop path

Alongside the receiving developer the organisation provides a support path: a named contact and a rhythm. A weekly office hour in the first quarter is usually enough for a builder to ask the question that would otherwise be skipped, and it is the occasion on which the platform team learns which template file confuses people. DevOps Research and Assessment (DORA) programme material finds that heavyweight external approval, such as a change advisory board or a senior sign-off, has a negative impact on software delivery performance and that no evidence was found that a more formal external review is associated with lower change-failure rates (131, Google Cloud, 2025). The finding concerns professional delivery teams, and the book does not transfer its magnitude to builders. It supports the shape of the support path: help that arrives quickly and a pipeline that checks automatically, not a committee that meets monthly.

The stop path is the one control the organisation holds alone. For every tool in the register there is a way to switch it off that does not depend on the builder, the assistant or the tool itself: the platform team disables the scheduled job or revokes the pipeline identity's access to the data. The stop path sits outside the assistant, for the reason that runs through the series: a control inside the system it controls fails with it. The register entry says who may use it, and using it needs no prior justification.

What it costs and what it saves

A lane has a cost, and an organisation that wants evidence of its value has to count both sides. The cost is largely people's time: platform engineers to build the workspace and the templates, a developer allowance for receiving, support hours, licences for the approved assistant and the storage of synthetic data. In the illustration the Region's platform team spent about half of one engineer's time for the first 90 days and about a fifth afterwards; Hansa's Group Application Development allocated 0.4 of a full-time post to the lane in the first quarter. These figures are the book's illustration and not measurements from a real organisation.

The saving is harder to state, and this book states less than it might. The adoption data of the field are surveys. The 2025 DevOps Research and Assessment report announcement says that 90 per cent of respondents report using AI at work and that more than 80 per cent believe it has increased their productivity, with a positive relationship between adoption and delivery throughput and a negative one with delivery stability, no effect sizes given (28, Harvey & DeBellis, 2025). Those are beliefs and associations of professional respondents, and they say nothing of builders outside the development organisation. An industry report from IBM reports that 63 per cent of the surveyed organisations had no AI governance policies to manage AI or prevent shadow AI and that a high level of shadow AI added USD 670,000 to the global average breach cost, research whose method the page read does not describe (33, IBM, 2025). It is evidence that the cost of ungoverned use is being measured by vendors; it is not evidence about builders in a public authority and the book does not apply the figure to the Region or to Hansa.

The honest statement is therefore a method, not a number. Before opening the lane, count what exists: tools found by asking and by service, how many are in the register, how many have an owner and a deputy, how many have a valid restore test. After 90 days, count again, and give the age of every figure. The Region's own measure is a small one: the phone service counted 41 calls about wrong opening hours in August 2031 and 17 in January 2032, the first full month of the scheduled report. That is a before-and-after count of one category by the phone service itself, for one month, with no control group and with other changes in the period uncontrolled, and it measures one tool and not the lane.

Measures of the provision

Five measures describe whether the lane is easier than the alternatives. Each is a measure of the system and never of a named person, with a minimum group size, and the set is agreed with employee representatives before the first count.

Measure	What it shows	Evidence age
Days from a builder's request to a first commit in the workspace	Whether the sanctioned route is quick	Re-measured every quarter
Share of known tools that are in the register (the denominator found by asking and by service)	Whether the register describes the estate	Date of the last discovery round
Share of register entries at Tier C with a deputy who passed a drill and a named receiving developer	Whether Name is met	Per entry, 90 days
Share of first pipeline runs of a new repository that fail on a template rule, with the rule named	Which step builders find hardest	Quarterly
Share of entries with a restore test inside its validity	Whether Revert is met	Per entry, 90 days

A measure that is made a target stops measuring (Goodhart's law, discussed in AI Purple, Chapter 18) (82, Nordqvist, 2026). The five are therefore reported together and none is rewarded alone, and a falling "days to first commit" that comes with a rising failure share is read as a sign that the template was loosened.

Governance without prohibition

A prohibition is simple to announce and the evidence on it is thin. In the global survey cited above, uploading sensitive company information or copyrighted material into public AI tools was most common among employees who reported that their organisation had banned generative AI or had a policy guiding its use, compared with those whose organisation had no policy or who were unsure; the reported shares were 67, 56, 33 and 38 per cent respectively, and the authors read this as suggesting that bans may be ineffective and that policies alone do not guarantee compliance (32, Gillespie et al., 2025). The result is a correlation in self-reported data, funded by a consultancy, and it does not show that a ban caused the behaviour. It agrees with the conclusion of AI Leader, Chapter 10, that a sanctioned route has to exist that is at least as good for the task as the unsanctioned one, since otherwise the prohibition fails (85, Nordqvist, 2026).

The case for prohibition is not empty. Some builds must be stopped, and the Level 4 prohibitions are such stops: nothing that ranks or decides about a named person's access to work is built in the lane, no assistant changes its own mandate, and no action irreversible on production data is delegated. What differs is the proportion. The prohibition is narrow, reasoned and enforced at the platform, and the default is a route.

Practical guide: Standing up a builder lane in 90 days

Purpose. Open a builder lane with a workspace, one template, a register, a named receiving developer and a support path, and show that a volunteer builder can use it.

Roles. Head of platform (accountable), a platform engineer, a security architect, the head of the development organisation or a tech lead for the receiving developers, the data protection officer, the archivist where the organisation is a public authority, a representative of the employees, and one volunteer builder.

Inputs. The four tiers of AI Developer, Chapter 19, the mandate form of Chapter 7, a list of tools found by asking and by service, the organisation's existing repository service, secrets store and pipeline engine, and the chapters of this book as the content of the template.

Steps.

1. Days 1 to 15: count what exists, using the discovery method above, and write the number and the date at the top of the register. Hold the first structured conversations with units about what they build.
2. Days 1 to 30: configure the workspace from existing parts: approved assistant at Mode 2 and Mode 3 in a sandbox, no route to production, synthetic data sets for the first template, a secrets store, branch protection. Write the mandate with the platform's security architect and record the decision as an AI Decision Record.
3. Days 15 to 45: write the first template for the commonest build (a scheduled report or a data check). Test it by building a trivial tool from it and following the twelve steps.
4. Days 30 to 50: agree the logging of the workspace with the employee representatives before it is switched on. Logs that identify a named builder's queries are an object that works agreements and negotiation rules cover.
5. Days 40 to 60: name receiving developers and set the allowance. Agree the handover reception route and the support path with the line managers concerned.
6. Days 50 to 75: write the lane manifest and the register, and open an amnesty period in which declaring an existing tool has no consequence.
7. Days 60 to 90: run a dry run with one volunteer builder, from template to a promoted tool with a receiving developer who runs the takeover test. Fix what fails. Record the result with its date.

Gate. A volunteer builder has gone through the lane, from template to a promotion decision, and the dry-run record shows each failure and the fix. The lane manifest lists the workspace, templates, register, receiving developers and support path, with their evidence dates.

Artefact. The lane manifest in the platform team's repository, with the platform's service-level note:

lane: LANE-NR-2031-01
organisation: Nordvik Region
decision: AIDR-1200
opened_on: 2031-10-06
owner: Maja Lindqvist            # platform team lead
workspace:
  assistant: approved assistant of the builder workspace
  usage_modes: [2, 3]            # Mode 3 only in the sandbox; Mode 5 not provided
  level_4: not used for any action class
  data: synthetic only
  production_reach: none
  secrets: store injects at run time; never in repository or prompt
templates:
  - name: builder-template-scheduled-job
    for_tiers: [B, C]
    version: 0.3.0
    pipeline_rules: [secrets_scan, ownership_file, oracle_cases_present, synthetic_data_only]
register: BREG-NR
receiving_developers:
  - {name: Rasmus Holm, team: integration and data, allowance: half a day a fortnight per build, first quarter}
support:
  office_hours: Tuesdays 14:00-15:00
  contact: platform team
service_level_note:
  first_response: 2 working days
  template_defects_fixed: 10 working days
  stop_path: platform team disables the job or revokes the pipeline identity; no prior justification needed
  evidence: dry run with a volunteer builder, 2031-10-27, fixes recorded
  valid_days: 90

The two organisations

Across the degrees of delegation

The lane gives builders the same assistant at every tier, and what changes is what the assistant may touch.

Tier	Assistant at most	Reach of the assistant	What stays with a person
A personal	Mode 2 or 3, Level 2 Supervised	The builder's repository and synthetic data	Everything that leaves the builder's own use
B team	Mode 3, Level 2 Supervised, Level 3 Bounded for tests and formatting	The repository and synthetic data on a branch	Merge, release, any secret, any change to AGENTS.md, pipeline.yml or tests/oracle/
C business	Mode 3, Level 3 Bounded for listed classes	As Tier B; production runs only through the pipeline identity	Promotion, mandate changes, restore tests, all personal data
D project	Not a citizen build	The development organisation's mandate	Everything

Level 4 Autonomous is not used at any tier, and an assistant never promotes its own work.

Nordvik Region and Hansa Mutual

At Nordvik the platform team (Maja Lindqvist, with senior platform engineer Joakim Wester) opened the builder workspace on 6 October 2031 (AIDR-1200); the first template is the scheduled-job template, and Hanna Wikström's service-point-check is its first user. The receiving developer is Rasmus Holm in Anders Falk's integration and data team. Because the Region has no Mode 5, the sandbox has no route to production, and the stop path is held by the platform team.

At Hansa Mutual, Group Application Development (Dr. Philipp Reinhardt) provides the lane inside the claims analytics workspace, adopted on 13 October 2031 (AIDR-1250). It contains the approved assistant of the builder lane at Mode 2 and Mode 3, synthetic claim exports, the group's pipeline and a named receiving developer per market; the Polish receiving developer is Tomasz Wrona. Production exports are read only by the pipeline identity, never by the builder or the assistant. The lane's logs identify named builders, so the group agreed their use with the Hamburg Betriebsrat before switching them on, under the interim works-council arrangement in force.

The difference between the two is one of kind and not of quality. The Region runs a platform for a few dozen builders with synthetic public and internal data. The group runs a lane inside a workspace that sits next to personal data of claimants, which is why the production export has one reader and it is not a person.

When to call a developer

Providing the lane has its own stop signs. Call a developer, or the platform lead, when a builder wants to use a data source that is not in the workspace's synthetic set; when a template rule fails in a way the builder cannot explain; when a tool the register shows at Tier B is used by a second unit or runs unattended; and when a request would give the assistant a permission that its mandate lists as not allowed. Call the platform lead when a template defect makes a rule fail for everyone.

Observable, expected, speculation

Observable. Non-developers build software in large numbers, and AI-built applications are in public use with failures that cluster in access control (105, Ko et al., 2011) (109, Deng et al., 2026). Platform vendors publish patterns for environments, data policies and promotion pipelines (107, Microsoft, 2025) (108, Microsoft, 2026). Surveys show that bans and policies do not by themselves stop the use of public tools (32, Gillespie et al., 2025).

Expected. Builder lanes are an expected development in organisations that have already governed citizen development with registers, templates and sandboxes, because the same platform parts serve both. The evidence on their effect on outcomes is thin, and no study of a lane was found for this book.

Speculation. That a lane will reduce the number of builder tools that fail the takeover test, or that receiving developers can absorb the volume if building keeps growing, is plausible and has no evidence behind it.

Summary

The gap between vibe coding and professional work has two sides, and this chapter described the organisation's side: a builder workspace with an approved assistant, synthetic data, a secrets store and a pipeline that alone promotes; templates with the files and checks of the twelve steps built in; a register in version control that shows what exists and when each claim was last checked; a receiving developer with protected time; a support path; and a stop path outside the assistant. It concerned Step 3 Workshop, Step 9 Ship and Step 12 Hand over and the functions D2 Design, D3 Build and D5 Steward.

The argument against reliance on prohibition rests on a self-reported survey that shows no benefit from bans, and on the book's conclusion that a sanctioned route must be at least as good as the unsanctioned one. The provision is measured by five system measures with evidence ages, none of which is a target on its own, and the claim of savings is replaced by a method: count before, count after, and give the age of each figure. The lane is a 90-day task for a platform team, and the Region and the group opened theirs in October 2031 (AIDR-1200 and AIDR-1250).

The next chapter turns to the setting in which these provisions meet the most law: the builder in a public authority, where records, accessibility, procurement and legitimacy are not options.

Sources

1. Ko, A. J., Abraham, R., Beckwith, L., et al. (2011). The State of the Art in End-User Software Engineering. ACM Computing Surveys 43(3), Article 21. (105, Ko et al., 2011)
2. Deng, J., Fan, Z. & Meng, R. (2026). Understanding the (In)Security of Vibe-Coded Applications. arXiv:2606.23130. (109, Deng et al., 2026)
3. UpGuard (2021). By Design: How Default Permissions on Microsoft Power Apps Exposed Millions. UpGuard Research. (143, UpGuard, 2021)
4. National Institute of Standards and Technology (2025). CVE-2025-48757 Detail. National Vulnerability Database. (144, NIST, 2025)
5. Gillespie, N., Lockey, S., Ward, T., Macdade, A. & Hassed, G. (2025). Trust, Attitudes and Use of Artificial Intelligence: A Global Study 2025. The University of Melbourne and KPMG. (32, Gillespie et al., 2025)
6. Microsoft (2025). Implement a data policy strategy. Microsoft Learn, Power Platform guidance. (107, Microsoft, 2025)
7. Microsoft (2026). Develop a tenant environment strategy to adopt Power Platform at scale. Microsoft Learn, Power Platform guidance. (108, Microsoft, 2026)
8. Niemen, G. (2020). How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem. Spotify Engineering. (59, Niemen, 2020)
9. Google Cloud, DORA (2025). Streamlining change approval. DevOps Research and Assessment (DORA) programme. (131, Google Cloud, 2025)
10. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA Report: State of AI-Assisted Software Development. Google Cloud Blog. (28, Harvey & DeBellis, 2025)
11. IBM (2025). 2025 Cost of a Data Breach Report. IBM. (33, IBM, 2025)
12. Nordqvist, G. (2026). AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)
13. Nordqvist, G. (2026). AI Leader: How Leadership Roles Change When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 11. (85, Nordqvist, 2026)
14. Nordqvist, G. (2026). AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. The Transformed Architecture, Book 9. (82, Nordqvist, 2026)