@@ -68,6 +68,7 @@ Maintain two separate, InnerSource-governed repositories instead of one undiffer
 Create a repository containing individually identified controls (for example, `PC-001-data-retention.md`), each with a short, stable definition, the regulatory clause it maps to, its tier (mandatory / recommended / situational), and, where possible, a reference implementation (a shared library, Terraform module, or config template that a team can literally import). This repository is broadly readable across engineering, the same as any shared internal SDK, because driving adoption depends on it being easy to find and use.
 
 Distinguish two kinds of contribution, since they carry different risk:
+
 - **Refining an existing control:** fixing an unclear description, flagging that the reference implementation doesn't cover a given tech stack, or improving a code example. This is open to any engineer by pull request, and it's where InnerSource-style openness adds the most value: the people who just tried to implement a control are best placed to spot where it's ambiguous or incomplete, and their input improves the control without requiring legal judgment.
 - **Authoring a new control:** asserting that a new obligation exists, or that a regulation applies in a new way. This is seeded by privacy/legal, not by open proposal. Engineers can still raise the need for a new control (for example, "we don't have a control covering this new data flow"), but the control's substance originates from, or is explicitly commissioned by, privacy/legal, even though drafting and discussion can still happen transparently in the same repo.