Working with Projects

This chapter covers how to create, edit, and work with projects in Capital Project. It is the largest chapter in the guide (22 sub-topics); the flagship Project topic is covered in full below, and the remaining sub-topics are summarized concisely by their documented purpose given the chapter's scope.

Project

Data within a project is arranged into distinct sub-containers called designs — versionable data containers whose contents can be copied as required. A design is usually created per sub-system of a product line and contains diagrams from a design application (system/wiring diagrams from Capital Logic, harness diagrams from Capital HarnessXC, topological diagrams from Capital Integrator).

Hierarchy: Project → Designs → Diagrams.

A project can optionally be assigned to a Domain. Assigning a project to a domain restricts access to only users permitted to access that domain.

Note: because a project can contain a large number of designs, non-essential design data is not loaded until an individual design is selected in the Project Browser Tree — this improves performance for large projects.

Release Level

Defines the release/maturity level tagging for design objects at system or project level (e.g., Draft, Released, Obsolete equivalents), used to track and control the lifecycle state of data within a project.

Options

Covers Capital's Options mechanism — configurable variant points that let a single design represent multiple product variants/configurations. Options are typically combined with Option Configuration and Option Expression (below) to drive conditional inclusion of design content.

Module Code Maintenance

Covers maintaining module code values used to classify/organize modules (functional or physical groupings) within a project.

SBOM Pattern Management

Covers defining and managing patterns used to control Software/System Bill of Materials (SBOM) generation and content rules at the project level (mirrors the system-level SBOM Pattern Management under System-Level Data, but scoped per-project).

Default Object Names

Explains the default naming scheme applied automatically to newly created design objects (components, nets, etc.) within a project.

Specifying Default Object Names for a Project

Procedure-level topic for configuring/overriding the default object naming scheme for a specific project (working in conjunction with "Default Object Names").

Advanced Naming

Covers more sophisticated, rule-driven naming schemes beyond the basic default naming — e.g., naming patterns driven by context (location, function, hierarchy) rather than simple sequential defaults.

Object Type Information

Object Type Information (OTI) defines the attributes, behavior, and presentation associated with each object type in the data model. OTI can be defined at System level or Project level; Project-level OTI overrides System-level OTI when both exist for the same type.

Usage Definition

Defines "Usage" metadata — classification of how/where a component or object is intended to be used within designs, used elsewhere for filtering, reporting, and rules.

Preferred Component

Covers marking/maintaining "preferred" component designations — guiding designers toward approved or recommended parts during component selection.

Option Configuration

Covers configuring the option relationships and value sets that drive which variant of a design (per the Options mechanism) is active/generated for a given configuration.

Option Expression

Covers writing expressions that evaluate option/configuration values to conditionally control design content (e.g., include a wire or component only when a given option combination is selected).

Build List

Covers defining and maintaining a Build List — a defined list of option selections/configurations representing a specific buildable variant of the product, used to drive design generation and BOM/SBOM output for that variant.

Design Abstraction

Design Abstractions represent different levels/views of abstraction for a design (e.g., logical vs. physical representations), settable at system or project level, used to organize and manage varying levels of design detail.

Code Translation

Covers translation/mapping of internal codes (e.g., classification or type codes) to alternate representations, for interoperability with external systems or documentation standards.

Change Policy

Change Policies define rules governing what changes are permitted to attributes/properties of objects, and under what conditions (e.g., locking certain fields once released). Includes:

• Usage Example – Attribute and Property Edit Policy: a worked example showing how a change policy can restrict editing of specific attributes/properties.
• Creating a Change Policy: procedure for defining a new Change Policy.

Dataset

Covers Capital's Dataset construct — a data container/mechanism used to package and manage collections of project data (usage may include supporting import/export or bridging workflows described in the "Bridging Data In and Out of Capital" chapter).

Importing Library Component Data

Procedure-level topic covering how to import component data from a library source into a Capital project.

Importing Symbol Data

Procedure-level topic covering how to import symbol data (graphical symbol definitions used in diagrams) into a Capital project.

Project Template

Covers creating and using Project Templates — pre-configured project skeletons (with system values, preferences, naming schemes, etc. already set) used to standardize the creation of new projects.

Shared Object

Covers Shared Objects — data objects that can be shared/reused across multiple designs or projects rather than duplicated, helping maintain consistency for common data.