Date: 2026-10-24. Status: implemented and development-verified after delegated concept review.
Language-corrected owner request: Create a change-request RST file for the
new target levels depicted in STV_CR_013_artifact_vertical_target_position.pptx.
Ensure that test cases and other artifacts align beneath one another in this
vertical order.
Evidence: the target-level diagram below and the owner’s request in this
conversation. The adjacent file
STV_CR_013_artifact_vertical_target_position.pptx is retained as backup
source material.
Requested vertical target levels for artifacts, test cases and execution records.
Requested behavior
Use the following top-to-bottom target order. Artifacts in the same target
level occupy a common horizontal row; different target levels appear beneath
one another, with test cases and execution records integrated into this vertical arrangement.
Below Stakeholder Requirement; above System Test Case
3
System Test Case
Below System Requirement; above System Test Execution Record
4
System Test Execution Record
Below System Test Case; above System Architecture Element
5
System Architecture Element
Below System Test Execution Record; above Software Requirement
6
Software Requirement
Below System Architecture Element; above Software Test Case
7
Software Test Case
Below Software Requirement; above Software Test Execution Record
8
Software Test Execution Record
Below Software Test Case; above Software Architecture Element
9
Software Architecture Element
Below Software Test Execution Record
The slide uses a single vertical stack to express the category order. This
record does not impose identical horizontal coordinates on every node in a
branching graph or prescribe pixel offsets, row spacing or a layout algorithm.
Existing nonoverlap, identity and navigation constraints remain relevant.
Proposed acceptance criteria for stakeholder refinement
A demonstration containing all nine categories displays their rows in the
order above. No visible node occupies a different category’s target row.
System and software test cases occupy their respective test rows rather than
relying solely on placement to the right of the artifacts they verify.
System and software test execution records occupy their respective execution
rows directly below the corresponding test-case category and above the
corresponding architecture category. Multiple executions of one test remain
individually identifiable and linked to their actual test case.
Multiple visible objects in one category align on that category’s row without
overlapping. Relationship edges continue to identify their actual endpoints.
Expanding and collapsing relationships preserves the relative vertical order
of the visible categories, including entry from a software requirement, test
case or test execution record. An absent category does not reverse the remaining categories’ order.
A test case linked to multiple requirement levels retains its verification
boundary classification; the requirement it verifies alone does not silently
reclassify the test or cause it to alternate between rows during exploration.
Position test evidence in c... (STV_SHR_012) replaces the project’s mandatory side lane with classified
rows and owner-selected fallback. Prior acceptance is retained in earlier
review rounds; explicit legacy-role models remain compatible.
Extensible ordered levels, hidden-object exclusion, shared identity, visible
capacity, compatible child-span centering and independent views are retained.
Later occurrence behavior remains separately deferred.
Resolved scope and concept decisions
Configurable tag maps classify cases; one-hop incoming executed_by links
classify executions from their cases, independently of current visibility.
The owner explicitly chose a common fallback row for missing/conflicting
evidence. It appears below Software Architecture and above Problem Tickets;
nodes are labelled Unclassified test evidence and retain all interactions.
Fixed/tag owners support execution classification. Invalid configuration
fails early; chained/cyclic or unresolved record links use the configured
fallback rather than recursive inference. Strict mode is available by
omitting fallback_level.
Problem Tickets retain the final custom row; project root remains above all
rows. Empty configured levels retain physical spacing. No additional domain
type or canonical relation is invented.
Fixed-level and explicitly selected legacy test-role models stay compatible;
the project’s model uses the nine-category arrangement. Shared identity,
routing, cap, offline delivery and PR013 stable navigation are retained.
Later occurrence mode remains deferred; no release is initiated here.
