Skip to main content

Locate the RTM Model Configuration

RTM model configurations are stored as YAML files in .polarion/nextedy/models/:
  1. Navigate to your Polarion project directory
  2. Open .polarion/nextedy/models/
  3. Locate the model file (typically rtm-model.yaml or a domain-specific name like safety-model.yaml)
TestAuto2 uses a single consolidated RTM model file that defines all entity types, relationships, and constraints. Multi-model configurations are supported but less common.

Understand the Model Structure

The RTM model defines three core elements: diagram

Sample Entity Definition

entities:
  - name: SystemRequirement
    displayName: System Requirement
    workItemType: systemRequirement
    expansion:
      - relationship: verificationTestCases
        target: VerificationTestCase
      - relationship: refines
        target: CustomerRequirement

Sample Relationship Definition

relationships:
  - name: verificationTestCases
    displayName: Verified By
    linkRole: verifies
    cardinality: many-to-many
    reverseRelationship: verifies

Add a New Entity Type

To add a work item type to the RTM model:
  1. Add an entity definition under the entities: section:
entities:
  - name: SafetyGoal
    displayName: Safety Goal
    workItemType: safetyGoal
    expansion:
      - relationship: derivedFromHazards
        target: Hazard
      - relationship: mitigatedByControls
        target: RiskControl
  1. Ensure the workItemType value matches the Polarion work item type ID exactly (case-sensitive)
  2. Define expansion paths to related entities using existing or new relationships
If you add an entity type that doesn’t exist in Polarion’s data model (.polarion/documents/types/), PowerSheets will fail to load. Always verify work item types exist before referencing them in the RTM model.

Define a New Relationship

To create a new traceability relationship:
  1. Add a relationship definition under relationships::
relationships:
  - name: mitigatedByControls
    displayName: Mitigated By
    linkRole: mitigates
    cardinality: many-to-many
    reverseRelationship: mitigatesRisk
    allowedTargets:
      - RiskControl
      - DesignRequirement
  1. Specify the linkRole that matches the Polarion link role ID (defined in .polarion/tracker/link-roles.xml)
  2. Set cardinality to control relationship multiplicity:
    • one-to-one: Each source linked to exactly one target
    • one-to-many: Each source linked to multiple targets
    • many-to-many: Multiple sources and targets allowed (most common)

Configure Expansion Paths

Expansion paths define multi-hop traceability chains used by PowerSheets:
entities:
  - name: DesignRequirement
    workItemType: designRequirement
    expansion:
      - relationship: verificationTestCases
        target: VerificationTestCase
        nestedExpansion:
          - relationship: externalReferences
            target: ExternalReference
This creates a three-level expansion: DesignRequirement → VerificationTestCase → ExternalReference PowerSheet Impact: When you configure a PowerSheet to expand through verificationTestCases, it will create column groups for both test cases AND their external references, enabling verification evidence traceability.
Use nested expansion for V-model verification workflows where you need to trace: Requirement → Test Case → Evidence Artifact. This pattern appears in all verification PowerSheets in TestAuto2.

Add Document Filters

To restrict relationships to specific Polarion modules:
relationships:
  - name: verificationTestCases
    linkRole: verifies
    cardinality: many-to-many
    constraints:
      documentFilters:
        - Testing/SystemVerificationSpecification
        - Testing/DesignVerificationSpecification
This ensures PowerSheets only display test cases from the specified LiveDocs, filtering out unrelated test cases from other modules.
Document filters use the module path format: <Space>/<DocumentName>. If the path doesn’t match any existing Polarion modules, the relationship will return zero results. Verify module paths in Polarion’s navigation tree before adding filters.
Enforce mandatory traceability links using constraints:
entities:
  - name: DesignRequirement
    workItemType: designRequirement
    constraints:
      requiredLinks:
        - relationship: refines
          minimumCount: 1
          message: "Each design requirement must refine at least one system requirement"
Validation Behavior: When users attempt to save a Design Requirement without a refines link, they will see the configured error message. This enforces ISO 26262 traceability requirements at the data entry level.

Verify the Model

After editing the RTM model YAML:
  1. Run the consistency-check skill to validate syntax and references:
    # Check if RTM model references valid work item types and link roles
    consistency-check
    
  2. Open a PowerSheet that uses the modified entity or relationship
  3. Verify the new columns or expansion paths appear correctly
  4. Check for console errors in browser DevTools (F12)
You should now see:
  • New entity types appear in PowerSheet source queries
  • New relationships create additional column groups
  • Document filters limit displayed work items to specified modules
  • Required link constraints trigger validation messages on save

See also