> ## Documentation Index
> Fetch the complete documentation index at: https://docs.m9tz.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Scope & Boundaries: What Is Documented vs. What Is Consulting

> A transparent explanation of what this documentation covers freely, what requires a consulting engagement, and how the two relate.

This page explains clearly what is covered by this documentation site and what is not. Both sides of that line are intentional — neither is an accident nor a gap.

## What this documentation covers

The entire M9TZ Agent Blueprint — the architecture, the staged communication model, the integration patterns, and the example department and role structure — is fully documented on this site. That includes:

* The definition of an agent and how it is bounded to a department or function
* How agents are structured: role definitions, SOPs, input sources, outbound interfaces
* How departments communicate through a message layer rather than shared state
* How integration with external systems (ERP, CRM, back-office platforms) works using the adapter pattern
* The staged build approach: reference implementation first, production adapter when the workflow is validated
* The five-phase engagement model and what each phase produces
* Scoping principles, design review process, and the handoff structure

This is comparable to how public product documentation for a large enterprise software platform is freely available — the architecture, the concepts, the reference structure are all there. Anyone can read it, understand it, and build from it. That is deliberate. The blueprint is only useful if it is understood, and it can only be understood if it is open.

<Note>
  The blueprint is technically reproducible by anyone with the relevant skills. This documentation gives a complete picture of the architecture and method. What the consulting engagement provides is the application of that architecture to a specific organisation — which is a different kind of work.
</Note>

## What is not included for free

The following are not covered by this documentation and are offered as part of a paid consulting engagement:

* **Organisational analysis** — systematically capturing your actual departments, the processes each one owns, the people involved, the existing systems in use, and how decisions flow between them. The blueprint provides the framework; analysing your specific organisation against that framework is consulting work.
* **Mapping your organisation onto the blueprint structure** — determining which departments get agents, which roles map to which SOPs, which authority limits apply to which functions, and where the generic template needs to be adapted for your real company structure.
* **Building real integrations to your existing systems** — designing and implementing the adapter that connects the blueprint's stable interface to your actual ERP, CRM, back-office platform, or other established system. This is custom to your environment and cannot be documented generically.
* **Running the staged rollout** — managing the build in your environment, running test cases against your real data, transitioning from the reference implementation to production adapters, deploying to your production environment, and monitoring the launch.
* **Ongoing operation and support** — maintaining the agent system over time, handling changes in the underlying systems it connects to, updating SOPs as business processes evolve, and providing support if something goes wrong.

## How consulting engagements are scoped

Consulting engagements are scoped individually based on the customer's situation. There is no fixed package that applies to every organisation — the scope depends on the number of departments involved, the complexity of the existing systems that need integration, the state of the customer's existing process documentation, and the pace at which the rollout is planned.

The [Discovery phase](/blueprint/discovery) is where that scoping happens. It produces a written summary of the organisation, the workflows targeted for automation, and the constraints that affect the build — which becomes the basis for agreeing on what the engagement covers before any design or build work begins.

## Why this line exists

The boundary between freely documented and consulting-delivered work reflects a practical reality: the blueprint can tell you how a well-structured agent system is designed, but it cannot tell you how your organisation works. That knowledge lives inside your business — in the people, the processes, and the accumulated decisions that make your company what it is. Surfacing it, structuring it, and translating it into an agent design is work that requires direct engagement with your team.

The documentation gives you everything you need to understand what you are getting, evaluate whether the approach is right for your situation, and have an informed conversation about scope. The consulting engagement is what turns that understanding into a working system.

<CardGroup cols={2}>
  <Card title="Consulting process" icon="handshake" href="/consulting/engagement-model">
    How engagements are structured, what each phase delivers, and what both sides are responsible for.
  </Card>

  <Card title="Discovery phase" icon="magnifying-glass" href="/blueprint/discovery">
    Where organisational scoping begins and how the engagement gets started.
  </Card>
</CardGroup>
