<!--
## Implementation Issue To-Do list 
(_NOTE: This section can be removed when the issue is ready for creation_)
- [ ] Ensure that issue title is concise yet descriptive
- [ ] Add `Frontend :` or `Backend: ` per group [naming conventions](https://about.gitlab.com/handbook/engineering/development/ops/verify/pipeline-authoring/#splitting-issues)
- [ ] Ensure the issue containing the feature or change proposal and related discussions is linked as related to this implementation issue.
- [ ] Aside from default labeling, please make sure to include relevant labels for `type::`, `workflow::`, and `~frontend`/`~backend` labeling.
- [ ] Issues with user-facing changes should include the `~UX` label.
-->

## Summary

## Proposal

## Additional details
<!--
_NOTE: If the issue has addressed all of these questions, this separate section can be removed._
-->

Some relevant technical details, if applicable, such as:

- Does this need a ~"feature flag"?
- Is there an example response showing the data structure that should be returned (new endpoints only)?
- What permissions should be used?
- Is this EE or CE?
    - [ ] EE
    - [ ] CE
- Additional comments:

## Implementation Table

<!--
_NOTE: If the issue is not part of an epic, the implementation table can be removed. If it is part of an epic, make sure that the implementation table below mirrors the corresponding epic's implementation table content._
-->


| Group | Issue Link |
| ------ | ------ |
| ~backend | :point_left: You are here |
| ~frontend | [#123123](url) |

<!--
## Documentation 

_NOTE: This section is optional, but can be used for easy access to any relevant documentation URLs._
-->

## Links/References


/label ~"group::pipeline authoring" ~"Category:Pipeline Composition" ~"section::ops" ~"devops::verify" ~"workflow::planning breakdown"