Modeling components in a System Blueprint

A System Blueprint supports governance work when the components it shows match the system that is actually deployed. This guide helps you decide which parts to model, add an accurate component record, capture its role and connections to other components, and maintain it as the system changes. The Blueprint represents the system for governance purposes; the real implementation remains the source of truth.

What you'll need: Sign in, open the existing system, and work in an editable Draft version with system write access. A team Member or above, or an organization administrator, can make component changes. Reviewer-only users cannot make these changes, and historical versions or versions under review are locked.

Decide what belongs as a component

A component is a meaningful functional building block: something that processes, generates, filters, routes, stores, or observes information. Choose a boundary that reflects work the system actually performs, rather than every screen, file, or hosting detail around it.

A resource is an external or reachable asset that the system accesses, such as a data source, another system, a network, or a user-facing surface. For example, a service that searches support content is a component because it performs retrieval work. The indexed support content it reads is a resource. Hosting infrastructure is not a separate component or resource unless it performs distinct work or is itself an asset the system accesses.

If the important object is an asset rather than a functional building block, continue with Modeling resources and operations. When a component accesses an asset, model the work-performing component here and use that guide for the asset.

Separate the reusable definition from its Blueprint instance

The Library is where you browse reusable component definitions. Each definition identifies a component through information such as its current name and version, standard description, and type classification. Adding a definition creates one component instance in this System Blueprint.

The instance describes this occurrence in this system. A system-specific display name can distinguish its role, while Notes and Configuration capture local context or settings. These details remain specific to this system and do not change the reusable definition.

Add the same definition more than once only when it has separate uses in the deployed system. When the real product or version differs, find or create a definition that matches it rather than using a display name or note to represent the difference.

Add an accurate component definition

1. Open the editable system, select Blueprint, and choose Add Component.

2. Search for your component in the component picker. Organization-specific components appear under Custom Components, and globally available definitions appear under Global Library.

Search both sources before deciding whether you need to create a custom definition.

1. Choose a result whose name and version match the component that is deployed or called. To browse more options, select Library. In the full Library, organization-specific components appear under Org Components, and globally available definitions appear under Global Components. Select Add to System on a component card to add it to your system.

2. If you cannot find a component that matches your deployment, choose Add custom component in the picker or Add New in the full Library. Record the component's name and type, and include a version when one applies.

1. When using the component picker, select a result, review its name, any version information shown, and its type classification, then choose Add to system. Selecting a result does not place it in the Blueprint until you complete this action.

Record the component's role in this system

After the component appears in the Blueprint, select it and use system-specific information to distinguish this occurrence without changing its reusable definition:

• Display name identifies the component's role in this system when its standard name is not enough.
• Notes capture local context that helps reviewers understand this occurrence.
• Configuration records settings that materially distinguish this occurrence from another instance.

Optional details can capture who owns or operates the component, where it is deployed, and where it came from. Record them where they are known and useful; an accurate, focused record is more valuable than a completed field for its own sake.

Place the component where its structural role is easy to understand. Use Incoming Connections for connections into this component and Outgoing Connections for connections from it, then choose Save.

The connection lists record the orchestrator's actual structural relationships in both directions.

Inspect and edit from the right surface

Use Blueprint for focused work on one component. Select the component to open its compact detail panel, then review or update its type and deployment, Incoming Connections, Outgoing Connections, optional metadata, Configuration, and Notes. Choose Save when you finish. For identity or classification changes, open Edit Component from this panel, make the changes, and select Update Component.

Use the compact panel for instance details and connections; open the advanced editor for identity or classification changes.

Use List View when you need to compare components. It shows component names and versions, types, and connections in rows. Choose a row's Edit action to open Edit Component directly; after updating the component, this path returns to List View.

List View makes it easier to compare identities, classifications, and connections across components.

Replacement and duplication are Blueprint actions rather than List View row actions. Return to the component's compact detail panel when you need either one.

Maintain the instance as the system changes

Choose the maintenance action that matches the real change:

• Edit or create a version. Edit the instance when its system-specific display name, notes, or configuration changes. If the reusable version changes, open the advanced editor and choose Create New Version instead of overwriting the existing identity.
• Duplicate component. Duplicate only when the same reusable definition has a second real use in the deployed system. The duplicate copies visible instance details but starts without incoming or outgoing connections. Connect the new occurrence to match its actual interactions.
• Replace. Select the component in Blueprint and choose Replace. Use Find replacement component to search Organization Inventory and Global Library, select the definition that matches the replacement, review the choice, and choose Save.

Review the available definition sources and choose the replacement that matches the deployed component.

• Remove component. Choose Remove component and confirm that the Delete Component dialog identifies the occurrence you intend to remove. Select Confirm Delete to remove that occurrence and its attached connections. The reusable definition remains available in the organization or Global Library.

These maintenance actions update the editable Draft. They do not submit the system for review.

Check the Blueprint against the real system

Before treating the component record as current, check four things:

• Meaningful boundaries: Each component represents a real functional part of the system, not an incidental screen, document, or hosting detail.
• Current identities: Names, products or services, and versions match what is deployed or called now. Instance notes do not substitute for an identity change.
• Actual interactions: Incoming and outgoing connections match real structural relationships, and duplicated instances have been connected deliberately.
• Technical review: Someone who knows the implementation has checked for missing boundaries, stale identities, incorrect details, and incorrect connections.

You are done when the saved component instances, placement, system-specific information, and directional connections match the real system. Use List View for a final comparison. The system remains in Draft until you begin the separate review workflow.

Next steps

• Follow Creating a system manually for the complete worked system-building sequence.
• Continue with Modeling resources and operations for external or reachable assets and resource operations.
• Use Using Execution Flows after the component structure is accurate.
• Read System Workspace and Blueprint for orientation to Blueprint and List View.
• Continue with Review and release a system version when the saved Draft is ready for review.