System Workspace and Blueprint

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

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.

Define a useful system boundary

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.

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.

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.

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

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 for its procedure and consequences.

Account for version and access state

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. For releases and version behavior, see System Versioning Model.

Choose the next detailed guide

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