Pith. sign in

REVIEW 3 major objections 6 minor 32 references

Prompts Blend Requirements and Solutions: From Intent to Implementation

T0 review · 3 major / 6 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper argues that prompts in chat-based AI coding are best understood as lightweight, evolving requirements artifacts that blend user needs with solution guidance, and supports this with a new Prompt Triangle model.

desk verdict A clean framing, thin evidence: the Prompt Triangle taxonomy is worth a referee, but the 98.3% numbers come from one unvalidated LLM pass over 120 prompts. read the letter →

arxiv 2603.16348 v2 pith:UTVUZN3B submitted 2026-03-17 cs.SE

Shalini Chakraborty , Jan-Philipp Steghöfer This is my paper
classification cs.SE
keywords promptengineeringrequirementsAIcodingassistantsvibeTriangleartifactsDevGPTchat-baseddevelopment
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that prompts in chat-based AI-assisted coding are not merely informal commands but lightweight, evolving requirements artifacts that combine what the system should do with how it should be built. To make this precise, it introduces the Prompt Triangle model, which decomposes any prompt into three components: Functionality and Quality (the requirement), General Solutions (architectural and technology choices), and Specific Solutions (implementation-level constraints). In a small analysis of 120 real prompts from the DevGPT dataset, the authors report that 98.3% contained requirements and 53.3% contained all three components, which they read as evidence that the model captures how prompts are actually written. Based on the model, the paper formulates four hypotheses about prompt evolution, developer characteristics, requirements validation and verification, and code quality, and lays out an empirical research agenda to test them.

What carries the argument

The Prompt Triangle: a conceptual model decomposing a prompt into three interrelated corners—Functionality and Quality (what the system must do and how well, including non-functional qualities), General Solutions (architectural approaches, technology, paradigms), and Specific Solutions (low-level implementation instructions and constraints). It is the analytical lens that lets the authors classify prompt content, spot patterns (e.g., requirements-first, optional solution refinement), and derive their four hypotheses. The machinery does the work of turning an informal practice (prompting) into a structured object that can be studied, measured, and validated like a requirements document.

What would settle it

A re-annotation study in which independent human raters, using a pre-registered coding protocol with measured inter-rater agreement, classify a fresh sample of prompts from multi-turn sessions; if raters cannot reliably separate requirement from solution content, or if the share of prompts containing requirements falls well below the reported 98.3%, the model's claimed empirical support fails.

Watch

Extended reading notes

Core claim

The central claim is that prompts themselves are structured artifacts with a consistent internal anatomy: when a developer writes a prompt for an AI coding assistant, they are simultaneously specifying requirements (what the system should do and how well) and solutions (general approach and concrete implementation details). The Prompt Triangle is offered as the first systematic model of this anatomy, distinguishing requirement content from two levels of solution content. The paper's initial evidence is a classification of 120 initial prompts from DevGPT conversations: requirements appeared in 98.3% of prompts, all three triangle components in 53.3%, and at least one solution component alongs

Load-bearing premise

The reliability of the prompt classification rests on a single LLM (Claude Sonnet 4.5) applying the three-component scheme to 120 initial prompts, checked manually by the authors; if that classification is biased or the sample is unrepresentative of real AI-assisted coding sessions, the empirical grounding for the model weakens.

Editorial extensions

If this is right

  • If prompts are requirement artifacts, then established RE activities—validation, verification, inspection, prototyping—can be applied to prompting, giving developers structured feedback before code generation.
  • The observed patterns (requirements nearly always present; solutions often but not always) suggest a natural refinement process from 'what' to 'how' that can be modeled and supported by tooling.
  • The four hypotheses define a concrete research agenda: if H1 holds, prompt evolution tilts toward implementation detail over time; if H2 holds, prompting strategies depend on developer experience; if H3 and H4 hold, iterative refinement with early requirement stabilization improves code quality.
  • If the model is built into IDEs, they could alert developers when prompts are solution-heavy but requirement-light, or when stated quality requirements conflict with the chosen approach.
  • Test generation can leverage the traceability between Functionality and Specific Solutions within a single prompt to produce tests that check both intent and implementation.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The 98.3% requirement presence may partly reflect the classifier being an LLM given the same three-category scheme; an independent human annotation study with inter-rater reliability would be the natural check of whether the triangle's boxes carve nature at the joints.
  • The model likely transfers beyond code generation—to document drafting, data analysis, or any LLM dialogue—as a general schema for separating intent from execution constraints; that extension is not tested in the paper.
  • Because the validation used only the first message of conversations, the paper's central 'evolving artifact' framing is not yet evidenced; the evolution claim is a prediction (H1) rather than a result.
  • A practical testable extension: prompt templates built on the triangle could be compared head-to-head against free-form prompts on code correctness and maintainability in a controlled experiment, operationalizing H4.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. This paper argues that in chat-based AI-assisted development, natural-language prompts should be treated as lightweight, evolving requirements artifacts that combine functional/quality requirements with solution guidance. It introduces the Prompt Triangle model, decomposing prompts into Functionality and Quality, General Solutions, and Specific Solutions. As initial support, the authors report a classification of 120 initial prompts from two DevGPT JSON files, performed by Claude Sonnet 4.5 and manually checked by the authors; Table 1 reports that 98.3% of prompts contain requirements and that the most common pattern (53.3%) includes all three components. The paper then proposes four hypotheses (H1–H4) on prompt evolution, user characteristics, validation/verification activities, and progressive refinement, and outlines a corpus- and experiment-based research agenda. The contribution is primarily a conceptual framework and a research agenda for a requirements-engineering view of prompting.

Significance. If the Prompt Triangle model is taken as a lens rather than an established empirical result, this is a useful and timely vision paper. It synthesizes related work on prompt patterns and requirements engineering, states falsifiable hypotheses, and provides a concrete initial dataset and replication package. The main strengths are the clear decomposition of prompt content and the connection of prompting to classical validation/verification concepts. However, the empirical grounding in §3.1 is currently too weak to support the quantitative claims: the classification is produced by a single LLM using the model's own categories, with no independent annotation or reliability measure. The paper's significance therefore rests on its conceptual contribution and the promise of the future agenda rather than on the reported percentages.

major comments (3)
  1. [§3.1, Model Validation / Table 1] The empirical support for the Prompt Triangle is not established. The 98.3% requirement prevalence and the co-occurrence pattern in Table 1 rest entirely on a single classification pass by Claude Sonnet 4.5 using the model's own three categories, followed by a manual check by the authors. No coding protocol, annotation guidelines, independent annotators, or inter-rater reliability statistic (Cohen's kappa, Krippendorff's alpha) are reported. The category boundaries are inherently fuzzy: in Table 2, for example, 'Implement in Python' is classified as General Solution while 'Use pandas.read_csv' is classified as Specific Solution, and the distinction could plausibly be inverted. Because the classifier was directly instructed with the model's definitions, the high percentage of prompts containing 'requirements' may reflect instruction bias. The manual check is not a substitute for independe
  2. [§3.1, Sample Selection] The sample is 120 initial prompts drawn from two DevGPT JSON files (20230803_095317_commit_sharings.json and 20231012_233628_pr_sharings.json). This is a narrow slice of AI-assisted development: only initial messages, only commit-sharing and PR-sharing conversations. The text generalizes to 'structured, multi-component prompts' and later in §5 to 'the vibe coding prompts we have studied' without acknowledging that initial prompts may differ systematically from later refinements, and that commit/PR sharing contexts may not represent standalone chat-based or vibe-coding sessions. Please restrict the conclusions to the sampled population and report the random-selection protocol (seed, inclusion/exclusion criteria, handling of non-English or code-only prompts) so the reader can judge representativeness.
  3. [§3.1, Validation Framing] Calling this procedure a 'validation' of the model is too strong. The exercise takes a model-defined label set and asks an LLM to assign prompt fragments to those labels; the fact that labels can be assigned does not confirm that the decomposition is correct, useful, or preferable to an alternative taxonomy. The test is not fully circular—prompts could have failed to fit—but the design pre-disposes the outcome because the LLM was instructed with the triangle's categories and the authors manually checked with the same model in mind. A more convincing validation would compare the Prompt Triangle against alternative prompt taxonomies (e.g., the pattern-based approaches discussed in §3.3) and show that the triangle components have distinct, measurable correlates. At minimum, please relabel the section as an exploratory assessment and soften 'validate this conceptual model' in the introductio
minor comments (6)
  1. [Table 1 and §3.1 text] The specific-solutions percentage is reported as 63.3%, but 77/120 = 64.2%. The same incorrect value appears in the text. Please correct both.
  2. [Footnote 1, §3.1] The footnote says solution components appeared without requirements in 'two cases' but then lists three explanations ('One of these prompt... The second prompt... The other prompt...'). Please correct the wording so the count matches the table (one Gen+Spec prompt and one Spec-only prompt, or adjust as appropriate).
  3. [§3.3 heading] The heading reads 'Prompt Patterns and and Prompt Iterations'—the duplicated 'and' should be removed.
  4. [§4, Hypotheses H1–H4] The hypotheses are stated at a high level. For reproducibility of the envisioned studies, specify the operational measures: e.g., what unit is used for 'percentage of Specific Solutions content' (words, clauses, prompts?), what significance test is planned, and how 'traditional development sessions' will be defined for H3's baseline.
  5. [§5, Discussion] The phrase 'the vibe coding prompts we have studied' overstates the current data: the 120-prompt sample comes from DevGPT commit/PR sharings and blog examples, not explicitly vibe-coding sessions. Please adjust the wording or provide evidence that the sample is representative of vibe coding.
  6. [§3.3, Related Work] The claim that the Prompt Triangle provides 'the first systematic model' decomposing prompts into requirement/solution dimensions is difficult to verify and may be contested by the cited works on prompt patterns and prompt engineering for RE. Consider softening to 'a systematic model' or adding a comparison that demonstrates the novelty more precisely.

Circularity Check

1 steps flagged · score 4.0 of 10

Partial circularity: the model's 'validation' classifies prompts with the model's own categories, so the 98.3% requirements finding is largely an artifact of the coding scheme; the model itself is also imported from the authors' prior work.

  1. self definitional [Section 3.1, 'Model Validation' and Table 1]
    "Functionality and Quality: Captures the core functionality or quality, i.e., what the developer wants the system to do. ... we extracted a sample of 120 prompts from the DevGPT dataset and asked Claude Sonnet 4.5 to categorize the information in them. ... Requirements appeared in 98.3% of prompts, establishing them as the foundational element of prompt construction."

    The validation is performed by instructing an LLM to classify prompt content into the very categories (Functionality/Quality, General Solution, Specific Solution) that constitute the Prompt Triangle. Because 'Functionality and Quality' is defined as 'what the developer wants the system to do,' and all sampled prompts are requests to a coding assistant, the reported 98.3% requirements figure is largely implied by the category definition and the sampling frame. The table shows no prompt outside the triangle, which is a consequence of the forced-choice coding scheme rather than an independent test. Thus the empirical support for the model reduces to the model's own definitions.

full rationale

Score is 4: the paper's own validation is partially circular, and the model itself is imported from the authors' prior work [6], but the central claim retains independent conceptual content (the three-way decomposition and the hypotheses). We are not claiming the paper's thesis is false; rather, the specific empirical support (Table 1) is generated by applying the model's categories, so it cannot serve as an independent confirmation. The self-citation [6] loads the model definition but not an external theorem; absent a uniqueness result or mathematical derivation, the citation alone would not be circular. Methodological concerns (single LLM annotator, no inter-rater reliability, N=120 initial prompts) are validity risks, not circularity. No fitted parameter is renamed as a prediction; H1-H4 are untested. Overall, one definitional reduction in the validation step justifies score 4, not higher.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The central claim rests primarily on the assumed validity of the Prompt Triangle categories and the reliability of LLM-based labeling; no numerical free parameters are fitted, and no new physical or formal entities are introduced.

assumptions (3)
  • domain assumption The three-component decomposition (Functionality and Quality, General Solutions, Specific Solutions) is a valid and exhaustive way to categorize prompt content.
    Used throughout Section 3.1; the model is assumed rather than derived, and the validation presupposes the categories.
  • domain assumption Claude Sonnet 4.5's classification of prompt content into the triangle components, checked manually by the authors, is accurate.
    Section 3.1 'Model Validation'; no inter-rater reliability or independent coding.
  • domain assumption The 120 initial prompts from two DevGPT files (commit sharings and PR sharings) are representative of chat-based AI-assisted coding prompts.
    Section 3.1 uses only initial messages from 20230803_095317_commit_sharings.json and 20231012_233628_pr_sharings.json.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Prompts Blend Requirements and Solutions: From Intent to Implementation." pith.science (2026). https://pith.science/paper/UTVUZN3B

@misc{pith2026260316348,
  author       = {Pith},
  title        = {Pith review of: Prompts Blend Requirements and Solutions: From Intent to Implementation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UTVUZN3B}},
  note         = {Machine review of arXiv:2603.16348}
}
read the original abstract

AI coding assistants are fundamentally reshaping software development by shifting developers' effort from writing code toward specifying intent through natural language prompts. In emerging chat-based development practices such as vibe coding, prompts mediate the transformation of human intent into executable software. While Requirements Engineering (RE) emphasizes capturing, validating, and evolving requirements, current prompting practices remain informal and ad hoc. In this vision paper, we argue that prompts represent lightweight, evolving requirements artifacts that combine expressions of user needs with varying degrees of solution guidance. We use an existing conceptual model that decomposes prompts into three interrelated dimensions: Functionality and Quality (capturing intended system requirements), General Solutions (capturing architectural strategies and technology choices), and Specific Solutions (capturing implementation-level constraints and directives). Building on this conceptualization, we formulate four research hypotheses concerning (i) the evolution of prompts over time, (ii) the influence of user characteristics on prompt evolution, (iii) the relationship between prompt content and requirements validation and verification activities, and (iv) the impact of prompt characteristics on requirements and resulting software quality. We envision an empirical research agenda combining real-world AI-assisted development data, corpus analysis, and controlled experimentation to investigate these hypotheses and derive evidence-based practices for requirements-aware prompt engineering. By reframing prompts through the lens of RE, we position prompting not merely as an interaction mechanism with AI systems, but as a central software engineering concern requiring systematic study.

Figures

Figures reproduced from arXiv: 2603.16348 by the authors.

Figure 1
Figure 1. Prompt Triangle: prompts composed of Functional- ity and Quality, General Solutions, and Specific Solutions. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

32 extracted references · 1 canonical work pages

  1. [1]

    Prompts Blend Requirements and Solutions: From Intent to Implementation

    Anonymous. Dataset for “Prompts Blend Requirements and Solutions: From Intent to Implementation” , February

  2. [2]

    Challenges of software requirements quality assurance and validation: A systematic literature review.IEEE Access, 9:137613–137634, 2021

    Issa Atoum, Mahmoud Khalid Baklizi, Izzat Alsmadi, Ahmed Ali Otoom, Taha Alhersh, Jafar Ababneh, Jameel Almalki, and Saeed Masoud Alshahrani. Challenges of software requirements quality assurance and validation: A systematic literature review.IEEE Access, 9:137613–137634, 2021

    2021

  3. [3]

    Grounded copilot: How programmers interact with code-generating models.OOPSLA, 7:85–111, 2023

    Shraddha Barke, Michael B James, and Nadia Polikarpova. Grounded copilot: How programmers interact with code-generating models.OOPSLA, 7:85–111, 2023

    2023

  4. [4]

    B.W. Boehm. Verifying and validating software requirements and design specifications.IEEE Software, 1(1):75– 88, 1984

    1984

  5. [5]

    Vibe coding and the new prototyping playbook.IEEE Software, 42(6):12–16, 2025

    Markus Borg, Elizabeth Bjarnason, and Fabian Hedin. Vibe coding and the new prototyping playbook.IEEE Software, 42(6):12–16, 2025

    2025

  6. [6]

    Exploring prompts as mixed requirements and solutions artifacts

    Shalini Chakraborty and Jan-Philipp Steghöfer. Exploring prompts as mixed requirements and solutions artifacts. InICSE Companion, 2026

    2026

  7. [7]

    Unleashing the potential of prompt engineering in large language models: a comprehensive review.arXiv preprint arXiv:2310.14735, 2023

    Banghao Chen, Zhaofeng Zhang, Nicolas Langrené, and Shengxin Zhu. Unleashing the potential of prompt engineering in large language models: a comprehensive review.arXiv preprint arXiv:2310.14735, 2023

    arXiv 2023

  8. [8]

    Do prompt patterns affect code quality? a first empirical assessment of chatgpt-generated code

    Antonio Della Porta, Stefano Lambiase, and Fabio Palomba. Do prompt patterns affect code quality? a first empirical assessment of chatgpt-generated code. InEASE, pages 181–192, 2025

    2025

Show all 32 references
  1. [9]

    Exploring prompt patterns in ai-assisted code generation: Towards faster and more effective developer-ai collaboration

    Sophia DiCuffa, Amanda Zambrana, Priyanshi Yadav, Sashidhar Madiraju, Khushi Suman, and Eman Abdullah AlOmar. Exploring prompt patterns in ai-assisted code generation: Towards faster and more effective developer-ai collaboration. InICMI, pages 1–7. IEEE, 2025

    2025

  2. [10]

    Specifications are (preferably) executable.Software Engineering Journal, 7(5):323–334, 1992

    Norbert E Fuchs. Specifications are (preferably) executable.Software Engineering Journal, 7(5):323–334, 1992

    1992

  3. [11]

    Specifications are not (necessarily) executable.Software Engineering Journal, 4(6):330–339, 1989

    Ian James Hayes and Cliff B Jones. Specifications are not (necessarily) executable.Software Engineering Journal, 4(6):330–339, 1989

    1989

  4. [12]

    Prompt engineering for requirements engineering: A literature review and roadmap

    Kaicheng Huang, Fanyu Wang, Yutan Huang, and Chetan Arora. Prompt engineering for requirements engineering: A literature review and roadmap. InRE Workshops, pages 548–557. IEEE, 2025

    2025

  5. [13]

    Understanding understanding and ambiguity in natural language.Procedia Computer Science, 169:209–225, 2020

    Philip Jackson. Understanding understanding and ambiguity in natural language.Procedia Computer Science, 169:209–225, 2020

    2020

  6. [14]

    Detecting cross-domain ambiguity in requirements through natural language processing, a systematic literature review

    Ibrahim Khalil, Israr Ahmad, Uzair Rasheed, Wasi Haider Butt, and Zaeem Anwaar. Detecting cross-domain ambiguity in requirements through natural language processing, a systematic literature review. InICACS. IEEE, 2025. 8 APREPRINT- MARCH18, 2026

    2025

  7. [15]

    A vision on intentions in software engineering

    Jacob Krüger, Yi Li, Chenguang Zhu, Marsha Chechik, Thorsten Berger, and Julia Rubin. A vision on intentions in software engineering. InFSE/ESEM, ESEC/FSE 2023, page 2117–2121, New York, NY , USA, 2023. Association for Computing Machinery

    2023

  8. [16]

    Vibe coding as a reconfiguration of intent mediation in software development: Definition, implications, and research agenda

    Christian Meske, Tobias Hermanns, Esther V on der Weiden, Kai-Uwe Loser, and Thorsten Berger. Vibe coding as a reconfiguration of intent mediation in software development: Definition, implications, and research agenda. IEEE Access, 13:213242–213259, 2025

    2025

  9. [17]

    Nuseibeh, J

    B. Nuseibeh, J. Kramer, and A. Finkelstein. A framework for expressing the relationships between multiple views in requirements specification.TSE, 20(10):760–773, 1994

    1994

  10. [18]

    A review on vibe coding: Fundamentals, state-of-the-art, challenges and future directions

    Partha Pratim Ray. A review on vibe coding: Fundamentals, state-of-the-art, challenges and future directions. Authorea Preprints, 2025

    2025

  11. [19]

    Prompt programming for large language models: Beyond the few-shot paradigm

    Laria Reynolds and Kyle McDonell. Prompt programming for large language models: Beyond the few-shot paradigm. InCHI, pages 1–7, 2021

    2021

  12. [20]

    A self-improving coding agent.arXiv preprint arXiv:2504.15228, 2025

    Maxime Robeyns, Martin Szummer, and Laurence Aitchison. A self-improving coding agent.arXiv preprint arXiv:2504.15228, 2025

    2025 arXiv

  13. [21]

    Conversation routines: A prompt engineering framework for task-oriented dialog systems.arXiv preprint arXiv:2501.11613, 2025

    Giorgio Robino. Conversation routines: A prompt engineering framework for task-oriented dialog systems.arXiv preprint arXiv:2501.11613, 2025

    2025 arXiv

  14. [22]

    Prompt engineering guidelines for using large language models in requirements engineering.arXiv preprint arXiv:2507.03405, 2025

    Krishna Ronanki, Simon Arvidsson, and Johan Axell. Prompt engineering guidelines for using large language models in requirements engineering.arXiv preprint arXiv:2507.03405, 2025

    2025 arXiv

  15. [23]

    An empirical evaluation of using large language models for automated unit test generation.TSE, 50(1):85–105, 2023

    Max Schäfer, Sarah Nadi, Aryaz Eghbali, and Frank Tip. An empirical evaluation of using large language models for automated unit test generation.TSE, 50(1):85–105, 2023

    2023

  16. [24]

    Using ai-based coding assistants in practice: State of affairs, perceptions, and ways forward.IST, 178:107610, 2025

    Agnia Sergeyuk, Yaroslav Golubev, Timofey Bryksin, and Iftekhar Ahmed. Using ai-based coding assistants in practice: State of affairs, perceptions, and ways forward.IST, 178:107610, 2025

    2025

  17. [25]

    The fault in our stars: Quality assessment of code generation benchmarks

    Mohammed Latif Siddiq, Simantika Dristi, Joy Saha, and Joanna CS Santos. The fault in our stars: Quality assessment of code generation benchmarks. InSCAM, pages 201–212. IEEE, 2024

    2024

  18. [26]

    Expectation vs

    Priyan Vaithilingam, Tianyi Zhang, and Elena L Glassman. Expectation vs. experience: Evaluating the usability of code generation tools powered by large language models. InCHI, pages 1–7, 2022

    2022

  19. [27]

    Prompts as software engineering artifacts: A research agenda and preliminary findings

    Hugo Villamizar, Jannik Fischbach, Alexander Korn, Andreas V ogelsang, and Daniel Méndez. Prompts as software engineering artifacts: A research agenda and preliminary findings. InPROFES, volume 16361 ofLNCS, pages 470–478. Springer, 2025

    2025

  20. [28]

    Prompting the future: Integrating generative llms and requirements engineering

    Andreas V ogelsang. Prompting the future: Integrating generative llms and requirements engineering. InREFSQ Workshops, 2024

    2024

  21. [29]

    Ai agentic programming: A survey of techniques, challenges, and opportunities.arXiv preprint arXiv:2508.11126, 2025

    Huanting Wang, Jingzhi Gong, Huawei Zhang, and Zheng Wang. Ai agentic programming: A survey of techniques, challenges, and opportunities.arXiv preprint arXiv:2508.11126, 2025

    2025

  22. [30]

    Chain-of-thought prompting elicits reasoning in large language models.Advances in neural information processing systems, 35:24824–24837, 2022

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. Chain-of-thought prompting elicits reasoning in large language models.Advances in neural information processing systems, 35:24824–24837, 2022

    2022

  23. [31]

    Devgpt: Studying developer-chatgpt conversations

    Tao Xiao, Christoph Treude, Hideaki Hata, and Kenichi Matsumoto. Devgpt: Studying developer-chatgpt conversations. InMSR, pages 227–230, 2024. 9

    2024

  24. [2026]

    https://doi.org/10.5281/zenodo.18713272

    doi

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.