Modeling resources and operations

A System Blueprint is more useful when it records both the components inside the system boundary and the important assets, services, boundaries, credentials, and other points those components reach or use. This guide helps you inventory those resources, add and describe them, and model each interaction with an accurate operation and resulting direction. Operations belong to component-resource relationships; they are not standalone Blueprint objects or general descriptions of component behavior.

What you'll need: Sign in and open an editable Draft system with an already established boundary. See System Workspace and Blueprint for help with that boundary. You also need at least one component before you can author a component-resource relationship.

Decide what belongs as a resource

A resource is something outside a system that a component in the system reaches or uses. It might be a data source or destination, another system, a network or trust boundary, a credential or access-control point, an invoked external service, or another important input or output.

Decide by the item's role in this model:

• Use a component for a functional building block whose behavior is represented inside the system.
• Use a resource for the asset, service, boundary, credential, or other outside point that the building block interacts with.

Software can fit either role. For example, a retrieval service is a component because it performs retrieval work inside the modeled system. The indexed content it reads is a resource. An external service that the retrieval component invokes can also be a resource when that interaction matters to the model. The distinction depends on the role you need to represent, not on a blanket software-versus-data rule.

Apply the same test to hosting platforms, networks, and environments. Include the hosting context as a resource when a modeled component has a real interaction with it. When it only describes where the system runs, keep it as context rather than adding a resource that has no supported relationship.

For component identity, metadata, and ordinary component-to-component connections, see Modeling components in a System Blueprint.

Inventory reachable assets from the outside in

Start with the meaningful inputs to and outputs from the established system boundary. For each one, identify the component that receives, sends, or otherwise interacts with it. Then work inward and account for the reachable assets used along the way:

• data sources and destinations;
• internal and external systems;
• credentials and points where access is granted or controlled;
• networks and trust boundaries; and
• invoked external services whose interaction matters to the model.

Treat the existing Blueprint as one source, not the complete inventory. Compare it with code, deployment configuration, data inventories, and input from people who operate or understand the system.

For each candidate, repeat the role test from the previous section. An invoked external service can be a resource even though it performs work of its own: in this System Blueprint, what matters is that a modeled component reaches it. Give every important reachable asset an accountable place in the inventory, and leave unrelated nearby infrastructure out of the model.

Add and describe a resource

From the editable system, open Blueprint and choose Add Resource. Use Quick Add when you need a new resource, or Resource Browser when you want to reuse an available resource from Library.

To create a resource with Quick Add:

1. Choose Quick Add.
2. Enter the resource's Name and choose its Type. For an ordinary resource, the available types are Data, System, Local Device or Application, Intranet, and Internet. Other resource subtypes may present different details.
3. Add applicable Risk Tags, then review the resource's Connections.

Use applicable Risk Tags, including Public, Internal, Confidential, and Restricted, to record classification context in the Blueprint panel. The panel handles that context through Risk Tags rather than a separate Classification field. When you select Internet as the Type, expect the panel to add Untrusted so you can review that context with the resource.

To reuse an available resource, choose Resource Browser. On the Library page, search or filter by Resource type, open Resource Details when you need more context, and choose Add for the correct resource.

A resource added from Resource Browser appears under NOT CONNECTED until you connect it to a component in the Blueprint resource panel. In Blueprint, open the resource panel to review its Type and keep its applicable Risk Tags current.

Describe each component-resource interaction

An operation describes what one component does with one resource. It belongs to that component-resource connection—not to the resource by itself, the component's general behavior, or an ordinary component-to-component connection.

Use these five concrete operations when interpreting the available presets:

Available presets and combinations vary by resource type, so a resource may not offer every operation in the table.

To author the interaction:

1. In Blueprint, select the resource to open its panel.
2. Add or select the component that interacts with it. The operation picker becomes available after you select a component.
3. Choose the preset that describes what this component actually does with this resource.

Operation and direction communicate related but distinct facts. Read results in a resource-to-component direction, Write results in a component-to-resource direction, and Read + Write shows both directions. A drawn arrow by itself does not establish the operation. Choose the supported preset from the real interaction, then review the resulting direction or directions and abbreviated connection labels together.

Every component-resource relationship needs a concrete operation. Set or correct it in the Blueprint resource panel, then reopen the panel to confirm the selection.

Inspect and maintain relationships from the right surface

Use Blueprint to maintain one resource relationship. Open the resource panel when you need to change its operation preset or choose Remove connection. Removing the connection keeps the resource record available for another supported relationship. When the resource itself no longer belongs in the model, choose Delete resource and review the destructive confirmation before removing the node.

Use List View to inspect the model across components and resources. An unconnected resource shows No connections. Connected resources expose incoming and outgoing endpoint badges; a Read + Write relationship appears in both directions.

From List View, choose Edit on the resource row to open its Blueprint panel, where you can change the operation or remove the connection. The operation picker is available in Blueprint rather than inline in List View.

Confirm the model matches the real interactions

Review the completed Blueprint and List View against the same evidence you used for the inventory. Confirm:

• Coverage: Every important reachable input, output, data source, destination, system, credential or access-control point, and trust boundary has an accountable modeled place.
• Modeled role: Each resource has a real component interaction. Functional building blocks remain components, while incidental hosting context remains context.
• Relationship: Each resource connects to the component that actually interacts with it, and the resulting connection direction matches that interaction.
• Operation: Each connection retains the concrete preset that truthfully describes read, write, execute, delete, grant, or a supported combination.

Compare the result one final time with code, deployment configuration, data inventories, and knowledgeable human review. You are done when each resource has a current Type and applicable Risk Tags, connects to the correct component, retains its operation preset after reopening, and displays directions and connection labels consistent with the real interaction.

Once the underlying structure and operations are accurate, use Using Execution Flows to interpret the derived end-to-end flow.

Next steps

• Follow Creating a system manually for the complete worked system-building sequence.
• Read Modeling components in a System Blueprint for functional building blocks, component metadata, and ordinary component-to-component connections.
• Review System Workspace and Blueprint for help understanding the system boundary and workspace.