docs: add organizational extension strategy to README

README.md

@@ -670,6 +670,55 @@ You can extend an existing category or create an entirely new one.
 3. Add a matching **opt-in file** using the naming convention `<name>.opt-in.md` (e.g., `compliance.opt-in.md`). See `security-baseline.opt-in.md` for the expected format. Omitting this file means the extension is always enforced with no user opt-out.
 4. Rules are blocking by default — if verification criteria are not met, the stage cannot proceed until the finding is resolved.
 
+### Organizational Complexity
+
+When multiple teams share a single AI-DLC installation, extension management benefits from a layered approach that separates org-wide concerns from team-specific ones.
+
+#### Layer 1 — Org-Wide Extensions
+
+These are extensions that apply across the entire organization (e.g., security baselines, compliance rules). They live alongside the AWS-shipped extensions under `extensions/`:
+
+```text
+aws-aidlc-rule-details/
+└── extensions/
+    ├── security/              # AWS-shipped extension
+    └── org-compliance/        # Org-wide extension (your addition)
+        ├── hipaa/
+        └── soc2/
+```
+
+Org-wide extensions follow the same format as any other extension — markdown files with rule IDs, applicability questions, and verification sections.
+
+#### Layer 2 — Team-Specific Extensions
+
+Individual teams can layer their own rules without modifying org-wide or AWS-shipped files. Create separate directories under `extensions/` with a team prefix:
+
+```text
+aws-aidlc-rule-details/
+└── extensions/
+    ├── security/              # AWS-shipped
+    ├── org-compliance/        # Org-wide (Layer 1)
+    ├── team-api-standards/    # Team-specific (Layer 2)
+    └── team-data-governance/  # Team-specific (Layer 2)
+```
+
+Each `team-*` directory is owned by its respective team. This naming convention makes ownership clear and avoids merge conflicts between teams.
+
+#### Distribution Approach
+
+For individual developers, downloading a release zip is sufficient. For organizations managing extensions across multiple teams, git subtree offers tighter integration. It embeds the rule files directly in each consuming repo (no special tooling required at clone time), avoids the detached-HEAD pitfalls of submodules, and keeps the full file history available locally — making it a pragmatic choice for teams that want simple, self-contained repositories.
+
+The following table summarizes the lifecycle events and who is responsible:
+
+| Event                      | What Happens                                                                                                                     |
+| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| AWS ships a new release    | Central team pulls latest via `git subtree pull`. AWS-shipped dirs (`security/`, etc.) overwritten; org/team dirs unaffected.    |
+| Org rules change           | Central team commits changes to `org-*` directories and pushes to the org's internal AI-DLC fork or overlay repo.                |
+| New team onboards          | Team creates a `team-<name>/` dir under `extensions/`; central team adds repo as a subtree source if distributing centrally.     |
+| Team adds own rules        | Owning team commits to their `team-<name>/` directory. Changes stay scoped to that team.                                         |
+
+> **Note:** Some organizations may choose to wrap `git subtree add` / `git subtree pull` in a convenience script. If your org doesn't ship one, the raw git subtree commands work directly. See the [git-subtree documentation](https://manpages.debian.org/testing/git-man/git-subtree.1.en.html) for details.
+
 ---
 
 ## Tenets