diff --git a/Documentation/framework.md b/Documentation/framework.md
index 1425a88..ed5441d 100644
--- a/Documentation/framework.md
+++ b/Documentation/framework.md
@@ -326,6 +326,17 @@ use the findings in the report to improve design, engineering, build, and test p
 
 Several SRP sample reports can be found in [Appendix A](#appendix-a-example-reports).
 
+
+
+## Short-Form Report Guidance
+
+* **Issue detail level:** The SFR should describe risks for product consumers and encourage vendors to improve security. Include enough detail to explain impact, but avoid exploit-enabling specifics. Protect IP by omitting code identifiers (variable, module, or function names).
+    * Example phrasing: “Integer overflow in secure boot could lead to arbitrary code execution in ROM”; “Insecure protection configuration allows loading unsigned code.”
+    * Avoid: “external_parser.c:195 parse_xml(xml_string) has a stack overflow when xml_string exceeds 1024 bytes, leading to arbitrary code execution.”
+* **Qualitative Risk Ratings:** Any qualitative risk rating used by the SRP when reporting findings is not relevant for the purposes of the SFR. For the avoidance of doubt, the CVSS score is the **only** factor determining whether a finding should be included in the SFR. As such, any finding with a non-zero CVSS score **must** be included in the SFR. 
+* **Configuration-dependent findings:** If a finding hinges on deployment configuration and the secure configuration plus associated risks are clearly documented in integration guidelines, it should be excluded from the SFR. If integration guidelines are missing and insecure configurations are plausible, include the finding in the SFR.
+
+
 # Appendix A: Example Reports
 
 * Atredis Partners - [Sample Deliverables](https://www.atredis.com/sample-deliverables)