# System workspace and Blueprint

> Navigate a system workspace, interpret its governance Blueprint, maintain general settings, and choose the right detailed guide.

Canonical URL: http://modelmonster.ai/docs/modeling-your-systems/system-view-and-the-blueprint/

## Article Metadata

- Reading time: 8 min

The system workspace brings the structure, context, governance, reporting, review, and documentation for one system into a shared working area. This guide shows you how to navigate that workspace, understand what its System Blueprint represents, maintain general settings, and choose the right guide when you are ready for more detailed work. Because the Blueprint is a governance model, validate it against code, deployed configuration, runtime behavior, and technical expertise.

## Orient yourself in the system workspace

![Editable Blueprint showing the system name, version and state, shared actions, full tab row, and a recognizable graph](/media/original_images/visual-1-blueprint.png)

From the left sidebar, select **Systems** and choose an existing system. The system workspace will open to the Blueprint. The system workspace is the overall page for the selected system; **Blueprint** is the visual model of its structure and relationships.

The shared header identifies the system, its version, and its current state. Depending on the selected tab, your permissions, and the system's state, it may also offer actions such as **Add Component**, **Add Resource**, and **Settings**.

Use the header as your reference point when moving among tabs. It helps you confirm that you are still working with the intended system and version before you inspect information or begin an available task.

The workspace contains eight tabs in this order: **Blueprint**, **List View**, **Use Case**, **Policies**, **Execution Flows**, **Reports**, **Documentation**, and **Overview**.

Each tab focuses on a different concern while keeping you within the same system record.

## Understand what the System Blueprint represents

A System Blueprint is a governance-oriented, human-validated representation of a real system. It gives governance, risk, compliance, and technical teams a shared model they can inspect and discuss. It does not replace the evidence needed to confirm how the technical team implemented the system or how it behaves.

The Blueprint uses a small set of related concepts. Components and resources form the modeled structure. Connections show relationships, while operations describe interactions involving resources. Execution flows build on that structure for downstream analysis. **Use Case** adds business and deployment context that the modeled structure cannot establish, and the other workspace surfaces use or summarize the same system record.

This distinction matters because a clean-looking Blueprint can still omit an important dependency, boundary, or behavior. Likewise, a complete technical inventory may contain more detail than governance reviewers need. The useful model is the one that makes important responsibilities and interactions understandable while remaining traceable to technical evidence.

> **Note:** Treat the Blueprint as a shared governance model. Validate it against the system's code, configuration, evidence from the running system, and knowledgeable technical reviewers.

## Define a useful system boundary

![A system boundary with user or machine entry and exit points, in-boundary components, external resources, and recorded assumptions](/media/original_images/visual-2-system-boundary.png)

Before adding modeling detail, decide what governable system the Blueprint should represent. Identify the user or machine entry points where relevant interactions begin and the exit points where results, actions, or data leave the boundary.

Choose enough detail to understand responsibilities and meaningful flow without reproducing every incidental implementation detail. A service that performs part of the system's governed behavior may belong inside the boundary. You might model a data source or service the system reaches as an external resource. Hosting context belongs in the model only when it adds governance value.

Record important assumptions, especially where the available evidence is incomplete or the boundary reflects a deliberate modeling choice. Name a technical reviewer who can compare the model with the real system and correct gaps.

Revisit the boundary when the system's purpose, deployment, or important dependencies change. A boundary that once supported a clear review can become misleading if the real system evolves around it.

> **Tip:** Start from what must be governed, not from every service that happens to exist nearby.

For detailed modeling decisions, use the component and resource guides in the final section of this article.

## Match the workspace surface to your task

Blueprint and List View present the same modeled components, resources, and connections in different ways. Overview summarizes the state of that system and routes you toward useful next actions.

| Surface | Use it when | What it emphasizes |
|---|---|---|
| **Blueprint** | You need to understand the system's overall shape | Spatial relationships and directional connections |
| **List View** | You need to scan modeled items systematically | Item details, categories, and incoming or outgoing relationships |
| **Overview** | You need to assess current state and decide what to do next | Review readiness, version, structure, resources, policy health, history, and activity |

![List View showing recognizable items and their incoming and outgoing relationships for the same system shown in Blueprint](/media/original_images/visual-3-list-view.png)

Use **List View** when rows and categories are easier to scan than a spatial graph. Moving between List View and Blueprint changes the presentation, not the underlying model.

For example, Blueprint can help a reviewer see how an external resource relates to several components, while List View can make it easier to locate that resource and scan its recorded relationships. Choose the presentation that makes the current question easier to answer.

![Overview showing review readiness, summary cards, version timeline, recent activity, and quick actions](/media/original_images/visual-4-overview.png)

Use **Overview** to answer three questions: What state is this system in? What may need attention? Where should I go next? Its destinations can take you to Blueprint, Execution Flows, Use Case, Reports, version history, or the audit log, depending on the task you choose.

Overview is a summary and routing surface, not a replacement for the detailed tabs. Follow its destination when you need to inspect or change the underlying information.

## Use downstream surfaces for their owning concern

All of these surfaces operate around the selected system. The actions available within them can vary with your permission and the system's state.

- **Use Case** captures business, deployment, and other context that the modeled structure cannot show.

- **Policies** presents policies associated with the system.

- **Execution Flows** provides flow-focused analysis built from the modeled structure.

- **Reports** provides report templates, preview, export, and report-generation entry points.

- **Documentation** holds supporting evidence and uploaded documents for the system.

- **Version history** and the **audit log** provide historical status and activity records outside the tab row.

## Update general system settings

![General Settings showing System Name, read-only System ID, Environment, Description, and Save All Settings](/media/original_images/visual-5-general-settings.png)

If **Settings** is available in the shared header, open it to inspect the system identifier and maintain its general metadata. Settings availability depends on your permission and the current version state.

Keep this metadata recognizable to collaborators who may encounter the system first through Overview, version history, or a report. A clear name, accurate environment, and concise description reduce ambiguity without turning the description into a full technical specification.

- **System Name** identifies the system throughout the workspace and is required.

- **System ID** is the system's read-only, copyable identifier.

- **Environment** records the environment represented by the system.

- **Description** gives collaborators concise context about the system.

To update these settings:

1. Change **System Name**, **Environment**, or **Description** as needed.
2. Select **Save All Settings**.
3. Confirm the values remain in place. If you changed the name, the updated name also appears in the breadcrumb and workspace header.
4. Select the breadcrumb labeled with the system name to return to **Blueprint**.

Settings also contains **Archive System** and **Delete System** under **Danger Zone**. Before using either lifecycle action, follow [Creating, Archiving, and Deleting Systems](/docs/managing-systems/creating-archiving-and-deleting-systems/) for its procedure and consequences.

## Account for version and access state

![Historical Blueprint showing Archive View, the archived-version banner, Edit Current Version, preserved workspace tabs, and no shared write actions](/media/original_images/visual-6-archive-view.png)

The same workspace can expose different actions as its version, selected history, or your access changes:

- **Draft** is writable when your permission allows it.

- A current **Active** system can retain write actions. Its next saved edit may begin a new draft.

- **Archive View** means you explicitly selected a historical released version. Archive View removes shared header write actions; select **Edit Current Version** before making changes.

Permissions, review state, archived-system state, and historical selection can remove or disable actions. If you cannot find an expected action, first confirm that you are viewing the current version and have the access needed for the task.

## Check whether the model is ready for human review

A model is conceptually ready for review when it captures the relevant boundary, important components and resources, meaningful connections and operations, and the assumptions needed to interpret it. A knowledgeable person should also have compared it with the real system.

During validation, ask practical questions: Does the model represent the important entry and exit points? Can reviewers tell which responsibilities sit inside the boundary and which resources remain external? Do the modeled relationships reflect the interactions that matter to the review? Record any material uncertainty instead of hiding it behind a tidy diagram.

**Overview** may surface readiness signals and route you to unfinished work, but readiness is not a universal one-screen checklist. The appropriate evidence and level of detail depend on the system and the purpose of the review.

For submission steps and review status changes, see [Review and release a system version](/docs/managing-systems/system-review-workflow/). For releases and version behavior, see [System Versioning Model](/docs/managing-systems/system-versioning-model/).

## Choose the next detailed guide

Use the guide that owns the task you want to complete:

| Task | Guide |
|---|---|
| Add or edit components and component connections | [Modeling components in a System Blueprint](/docs/modeling-your-systems/modeling-components/) |
| Model resources and operations | [Modeling resources and operations](/docs/modeling-your-systems/modeling-resources-and-operations/) |
| Import or scan a system | [System Scanning and Import](/docs/modeling-your-systems/system-scanning-and-import/) |
| Interpret or correct execution flows | [Using Execution Flows](/docs/risk-identification-and-management/using-execution-flows/) |
| Answer use-case questions | [Use Case Context](/docs/risk-identification-and-management/use-case-context/) |
| Create or manage policies | [Creating and Managing Policies](/docs/risk-identification-and-management/creating-and-managing-policies/) |
| Generate reports | [Reports](/docs/reporting-and-artifacts/reports/) |
| Review, release, or manage versions | [Review and release a system version](/docs/managing-systems/system-review-workflow/) and [System Versioning Model](/docs/managing-systems/system-versioning-model/) |
| Inspect system activity | [Review a system's audit log](/docs/managing-systems/system-audit-log/) |
| Archive or delete a system | [Create, archive, unarchive, and delete systems](/docs/managing-systems/creating-archiving-and-deleting-systems/) |