Blueprint · Definitions
AI systems and the machine: levels and boundaries
A cascade of definitions for the network behind every AI answer
Dependence is not membership.
- By
- By Saina Veigel · Communications Specialist · Senior Technical Writer
- Edition
- 2
- First published
- Reviewed
Every AI answer that a technician, an operator or a buyer meets passes through a network that nobody sees in full: the AI function on the screen, the configuration the company has defined, the documentation and data behind it, the contracts with model providers, and the global environment of models, compute and public content that every provider draws on. The functions a company uses always reach into that global environment. That is why the network looks impenetrable: everything depends on everything, and so everything seems to belong to everything.
This blueprint divides the network into five levels, one role that runs across them and two boundary markers. It uses a single test throughout: who can decide or change something here? The levels don’t differ by technology — model, cloud, app — but by who holds the decision.
Two of the definitions come unchanged from the blueprint “AI-enabled information systems for technical writers”: AI systems and the machine. This blueprint keeps them as they are and adds the levels through which the machine runs, so that every place where it reaches into a company can be told apart and decided on.
It is written for technical writers and documentation systems developers who have to say, for every source, rule and answer, where it sits — and for everyone who has to explain which AI their documentation actually serves.
Why the network needs levels
Documentation is now read by the machine before people read the answer. Nobody can draw the machine’s boundary — but writers can know where it reaches into the company and what it reads there. Without levels, two mistakes are common: everything a function touches is counted as part of it, or nothing outside the company’s own systems is documented at all.
Both mistakes hide the same place: the point where the company reaches into the global environment. That is where a model version changes without notice, where inputs leave the company and where terms of use decide what may be done with the answers.
Behind a single answer of the assistant on an operator panel there are usually:
- a language model from a provider in the global AI environment
- a contract, a gateway and settings that fix which model, which version and which region
- company-wide rules on which AI may be used for what, and shared terminology and retrieval services
- the configuration of AI functions defined for this machinery line
- the documentation, product data and metadata that the retrieval selects
- the assistant itself, as the operator meets it
Each of these sits at a different level, and each is decided by someone else. The levels make that visible.
Technical writers don’t need to control every level. They need to know at which level a source, a rule or a risk sits, so that they can document it where it can be decided.
The core problem
In an impenetrable network, dependence is mistaken for membership.
- A model is counted as part of the company’s AI systems, although the company can only choose its version, not change it.
- A model update in the global environment changes answers, and nobody can say where that change should have been recorded.
- An app someone uses on their own initiative is called “our AI system”, and the documentation is suddenly expected to serve it.
- Company-wide rules are written into one configuration, and the next configuration starts without them.
- The assistant on the screen is documented, but the knowledge behind it is not, because it seems to belong to the app.
- A legal classification is read into a technical word, or a technical word into a legal classification.
When the levels are mixed up, documentation ends up describing the wrong owner — and a decision that nobody can find can’t be corrected.
Blueprints
The cascade
Five levels, the machine running through them and two boundaries
The cascade runs from the widest reach to the narrowest: from the global AI environment, which no company controls, to the AI function that one user operates. The machine runs across the levels. The two boundary markers name what lies outside: AI use without a configuration, and the legal term.
Scroll sideways to see every column.
| Level, machine or boundary | Test question | Documentation decision |
|---|---|---|
| Global AI environment | Can the company change it, or only choose it? | Provider and model family · what can only be chosen · dependencies · public content |
| Contracted access | Is it written in a contract or a setting? | Model and version · gateway or interface · tenant and region · retention · terms of use · change of version |
| Company AI estate | Does it apply to every configuration? | Usage policy · approvals · shared services · company-wide roles · AI management system |
| AI systems | Did the company decide that it belongs to this configuration? | Functions of the configuration · interfaces · device, line or set of systems · written scope |
| AI function | Is it the one thing a user operates or asks? | Name of the function · its configuration · its allowed sources · point of use |
| The machine | Where does it reach into this configuration, and what does it read there? | Points of entry · what it may read · documentation and product data · terminology and rules · the model version it answers with |
| Unconfigured AI use | Is it in a configuration? If not, it is here. | Name it · decide: configure or keep outside · what documentation does not promise |
| AI system (AI Act) | Is this a legal question? | Keep the legal assessment separate · refer to it · don’t derive it from the cascade |
The cascade is not an architecture of a particular AI product, and it is not a legal classification. It is a way to say where a source, a rule or a risk sits — and who can decide about it.
Dependence is not membership.
Scope and out of scope · Reference
The scope table
Each term with what it covers, what it doesn’t and the confusion it prevents
The table sets the boundaries of every term. Each row says who decides at that level, what is in scope, what is out of scope and which confusion the boundary prevents.
Scroll sideways to see every column.
| Term | Who decides | In scope | Out of scope | Typical confusion | Documentation decision |
|---|---|---|---|---|---|
| Global AI environment | No single company: model providers, cloud and compute providers, publishers of public content | Model families and their providers, compute and cloud services, public web content, AI search and crawlers, other companies’ AI services | Anything the company has agreed or configured | Treating the provider’s model as the company’s own system | Name the provider and model family · document what can only be chosen, not changed |
| Contracted access | The company and the provider together, through a contract and settings | Model and model version, interface or gateway, tenant, region, retention of inputs and outputs, terms of use | The provider’s training, training data and other services | Assuming the model stays the same because the app stays the same | Record model, version, region and terms per access · record every change of version |
| Company AI estate | The company: governance, approvals, the AI management system | Usage policies, approval rules, shared retrieval and terminology services, company-wide roles and reviews | The decisions of a single configuration | Writing company-wide rules into one configuration only | Keep company-wide rules in one place · let every configuration refer to them |
| AI systems | The people responsible for the configuration | The AI functions the company has specified and combined for one device, machinery line or set of interlinked systems, with their interfaces | Apps that nobody specified · the product (machinery) itself | Calling any available app “our AI system” | List the functions of each configuration · decide what belongs to it, in writing |
| AI function | The department and the user at the point of use | The one named function a user operates or asks, for example the assistant on the operator panel | The knowledge the function draws on (the machine reads it from the company’s documentation and data) | Documenting the app and forgetting the knowledge behind it | Name the function · say which configuration it belongs to and which sources it may use |
| The machine | Nobody as a whole · where it reaches into the company, whoever decides at that level | The worldwide web of AI compute and AI communication as it runs through every level — and every point where it reaches into the company and reads its documentation, product data, terminology and rules | Machinery · a map of the machine as a whole | Mistaking the company’s own configuration for the machine — or the machine for machinery | Document every point where the machine reaches in, and what it may read there |
| Unconfigured AI use | Individuals, without a company decision | Any AI app used outside a company-defined configuration | Everything the company has configured | Expecting the documentation to serve apps nobody specified | Name it · decide whether it becomes part of a configuration or stays outside |
| AI system (AI Act) | The legislator, and in the end the courts and authorities | The legal definition of Article 3(1) and the obligations attached to it | The levels of this blueprint | Reading a legal classification into a technical word, or the other way round | Keep the legal assessment separate · refer to it, don’t derive it from the cascade |
The table can be read next to the machine’s stack of the blueprint “AI-enabled information systems for technical writers”. Its ten layers describe the documentation that the machine finds where it reaches into a company; this table shows where it reaches in and who decides there.
Every term has a boundary — and every boundary has someone who decides.
The levels, the role and the boundaries
Each entry explains one term of the cascade: its test question, what it covers, where it ends and what documentation has to decide about it.
- Global AI environment
- Contracted access
- Company AI estate
- AI systems
- AI function
- The machine
- Unconfigured AI use
- AI system (AI Act)
1. Global AI environment
Core question: Can the company change it, or only choose it?
The global AI environment is everything a company’s AI functions draw on that no single company controls.
Questions to ask at this level:
- Which providers and model families do our AI functions depend on?
- What could change there without our decision?
- Which of our public content does the global environment read, and how?
Every AI function reaches into this level: the language model comes from a provider, runs on someone’s compute and was trained on content that the company never saw. Public documentation is read here too — by AI search and by crawlers that turn it into answers elsewhere.
Documentation can’t govern this level. It can name it, so that nobody mistakes it for the company’s own decision.
- The global environment is not part of the company’s AI systems.
- Choosing a provider is a decision; what the provider does is not.
Documentation decision
- Provider and model family
- what can only be chosen
- dependencies
- public content
2. Contracted access
Core question: Is it written in a contract or a setting?
Contracted access is the boundary layer: the agreed points at which the company reaches into the global environment.
Questions to ask at this level:
- Which model and which version does each AI function use, and through which access?
- Where are inputs and outputs processed and how long are they kept?
- What do the terms of use allow us to do with the answers?
- Who notices when the version changes?
This is the level that is most often left out, and the one through which the machine reaches from the global environment into the company. Here the company does decide — not about the model, but about which model it uses, how and on what terms.
For documentation, contracted access is the place where a dependence becomes a recorded decision. When answers change after a model update, this is where the change can be found.
- The model belongs to the provider; the access belongs to the company.
- An unchanged app is no proof of an unchanged model.
What isn’t recorded at the boundary can’t be traced behind it.
Documentation decision
- Model and version
- gateway or interface
- tenant and region
- retention
- terms of use
- change of version
3. Company AI estate
Core question: Does it apply to every configuration?
The company AI estate is everything the company’s AI systems share.
Questions to ask at this level:
- Which rules apply to every configuration, and where are they kept?
- Which terminology, retrieval or review services do the configurations share?
- Who approves a new configuration or a new AI function?
A company rarely runs only one configuration. A packaging line, a service portal and an engineering tool each have their own AI systems, but they share rules, services and people. This level is where those shared things are decided once.
For documentation, the estate is the place for company-wide terminology and rules. If they are written into one configuration only, every other configuration starts without them.
- The estate is not one big configuration.
- Shared rules belong to the estate; a configuration refers to them.
Documentation decision
- Usage policy
- approvals
- shared services
- company-wide roles
- AI management system
4. AI systems
Core question: Did the company decide that it belongs to this configuration?
AI systems are one company-defined configuration — always in the plural, because a configuration combines several functions.
Questions to ask at this level:
- Which AI functions belong to this configuration, and which don’t?
- For which device, machinery line or set of interlinked systems was it defined?
- Where is that decision written down?
The definition is the one set in the blueprint “AI-enabled information systems for technical writers”. It doesn’t say what is technically connected. It says what the company has decided belongs together.
That makes AI systems the level at which documentation can say exactly which sources, rules and answers a configuration needs. Anything outside the decision is outside the configuration, however often it is used.
- Connected is not the same as configured.
- The product the documentation describes is never part of the AI systems.
Documentation decision
- Functions of the configuration
- interfaces
- device, line or set of systems
- written scope
5. AI function
Core question: Is it the one thing a user operates or asks?
An AI function is one named function within AI systems, as its user meets it.
Questions to ask at this level:
- What is the function called, and who uses it where?
- To which configuration does it belong?
- Which sources may it answer from, and where must it stop?
The blueprint “AI-enabled information systems for technical writers” avoids the singular “an AI system” and names the function instead. This level gives that practice a name of its own.
The function is what the user sees. The knowledge behind it is not part of the function; the machine reads it from the company’s documentation and data. Documenting only the function leaves out what decides whether its answers are right.
- The assistant is the function; what it knows, the machine reads from the documentation.
Documentation decision
- Name of the function
- its configuration
- its allowed sources
- point of use
6. The machine
Core question: Where does it reach into this configuration, and what does it read there?
The machine is not a level. It runs through all of them: the unseen worldwide web of AI compute and AI communication, from the global environment down to the screen of one AI function.
Questions to ask about the machine:
- Through which functions, access points and shared services does the machine reach into our AI systems?
- What does it read there: which documentation, product data, terminology and rules?
- Who decides what it may read, and who reviews it?
The definition is the one set in the blueprint “AI-enabled information systems for technical writers”. It is a metaphor, because the machine can’t be pinned down technically: it changes faster than any description of it. Nobody sees it whole, and nobody owns it — not the provider of a model, and not the company that uses one.
That is why the levels matter. The machine can’t be documented as a whole, but every place where it reaches into a company can: the access through which a model is reached, the shared services of the estate, the configuration, the function on the screen — and the documentation, product data and rules it reads there.
The ten layers of the machine’s stack in that blueprint describe what the documentation has to be where the machine reads it. This blueprint describes where the machine reaches in and who decides there.
- No company owns the machine; every company decides where it lets it in.
- The machine never means machinery.
Dependence is not membership.
Documentation decision
- Points of entry
- what it may read
- documentation and product data
- terminology and rules
- the model version it answers with
7. Unconfigured AI use
Core question: Is it in a configuration? If not, it is here.
Unconfigured AI use is AI use outside any company-defined configuration.
Questions to ask at this boundary:
- Which AI apps are used without being part of a configuration?
- Should one of them become part of a configuration, with its sources and rules?
- What can the documentation not promise for these apps?
Any app that happens to be available can answer questions about a product. That doesn’t make it part of the company’s AI systems. The machine reaches the company through it all the same — only without any decision on sources, access or rules. Naming this boundary keeps the blurry singular “an AI system” out of the documentation.
The name is not a judgment. It makes the use visible, so that someone can decide whether it becomes part of a configuration or stays outside.
- Used is not the same as configured.
Documentation decision
- Name it
- decide: configure or keep outside
- what documentation does not promise
8. AI system (AI Act)
Core question: Is this a legal question?
The legal term of Article 3(1) of the EU AI Act is a boundary, not a level.
Questions to ask at this boundary:
- Has the legal classification been made, and by whom?
- Does the documentation refer to that assessment instead of implying one?
The AI Act defines an AI system in the singular and attaches obligations to roles along the value chain: provider, deployer, downstream provider. Whether an AI function or a configuration is an AI system in that sense is decided by the legal assessment, not by this cascade.
Keeping the two apart protects both: the technical words stay precise, and the legal classification isn’t read into them.
- A level is not a legal classification.
- Naming the AI Act does not mean that anything conforms to it.
Documentation decision
- Keep the legal assessment separate
- refer to it
- don’t derive it from the cascade
Why this matters for documentation
The cascade turns an impenetrable network into places where decisions can be documented:
- model versions and terms are recorded at the access, where they are decided
- company-wide rules are kept once, in the estate
- each configuration says which functions belong to it
- each function says which sources it may use
- every point where the machine reaches in is documented with what it may read there
- unconfigured use is named instead of silently served
- the legal assessment stays a legal assessment
A decision that can be found can be corrected.
Distinctions to keep
The cascade depends on a few distinctions that are easy to blur in everyday language. Each of them is a boundary between two levels or between a level and the machine.
- Dependence is not membership.
- The model is not the access.
- The estate is not a configuration.
- Connected is not configured.
- The function is not the machine.
- Used is not configured.
- A level is not a legal classification.
- The machine is not machinery.
Each distinction names someone who decides — and someone who doesn’t.
Tools and the cascade
Tools can make the levels visible: an inventory of AI functions, a register of contracted access with model versions, the policies of an AI management system, the logs of a gateway. They show what is connected.
They don’t decide what belongs together. That is the company’s decision, and it has to be written down where documentation can refer to it.
With the cascade, documentation can:
- say for every source which configuration it serves
- trace a changed answer to a changed model version
- keep company-wide terminology and rules in one place
- name AI use that no configuration covers
- keep the legal assessment apart from the technical description
Tools show the network. The cascade shows who decides.
The core principle
The core principle is short: dependence is not membership.
Every AI function depends on the global environment. Only what the company has agreed belongs to its access, and only what it has decided belongs to its AI systems. The machine runs through all of it and belongs to no one.
The cascade supports documentation decisions. It never replaces the legal assessment of an AI system, the manufacturer’s risk assessment, the safety information required for a product or the review by the people responsible for the documentation.
Cut complexity — create clarity
Explained in context
Context cards explain the general, checkable background of some of the questions this blueprint raises. They are written by knowledge.aitechdoc.world and are not part of the blueprint.
Reference updates
The glossary references, the terms under “Related established methods” and the context cards are attached to this blueprint, not part of it. They are checked and updated on their own, without a new edition.
The references haven’t been updated since the first edition.
How to cite
Saina Veigel (2026). AI systems and the machine: levels and boundaries. Blueprint, edition 2. knowledge.aitechdoc.world. https://knowledge.aitechdoc.world/uk/blueprints/ai-systems-and-the-machine-levels-and-boundaries
Edition and changes
Edition 2 · Reviewed
Corrections (something was wrong) and additions (something was missing) since the first edition.
- Correction
Corrected the definition of “the machine”: it is the unseen worldwide web of AI compute and AI communication that runs through every level and reaches into a company through its AI systems — not the parts that serve one configuration. The description of the machine, the scope table and the passages built on it were adjusted.
About this blueprint
This blueprint is a thinking model, not a standard or a method certified by anyone. Naming a standard, a law or an established method does not mean that documentation conforms to it.
It does not replace the manufacturer’s risk assessment, the instructions for use of a product or the review of documentation by the people responsible for it.
Copyright © 2026 Saina Veigel. All rights reserved. Copyright notice