Software practitioners can make sub-optimal decisions concerning requirements during gathering, documenting, prioritizing, and implementing requirements as software features or architectural design decisions -- this is captured by the metaphor `Requirements Technical Debt (RTD).' In our prior work, we developed a conceptual model to understand the quantification of RTD and support its management. In this paper, we present our perspective and the vision to apply the lens of RTD to software requirements concerning veracity, i.e., requirements related to truth, trust, authenticity, and demonstrability in software-intensive systems. Our goal is to cultivate awareness of veracity as an important concern and eventually support the management of RTD for software requirements concerning veracity, what we term as `Veracity Debt,' through its quantification.