diff --git a/source/content/operations-inc.adoc b/source/content/operations-inc.adoc
index ce49d36f96ff56d0a86d109cb4cf54e621c4d2ec..2ac80ba9497e0aadb1756b4e1589369b9dc6812d 100644
--- a/source/content/operations-inc.adoc
+++ b/source/content/operations-inc.adoc
@@ -149,12 +149,17 @@ The specification committee is responsible for producing, publishing, and mainta
 Process specifications do not have a TCK.
 ====
 
-The specification committee chair (or their delegate) is responsible for initiating ballots, tallying their results, disseminating them to the community, and (when appropriate; e.g., in the case a <<efspo-reviews-release,release review>> ballot) reporting them to the EMO.
-
 The specification committee is also responsible for defining and refining how they implement the EFSP for those specification projects under their purview.
 
+[#efspo-spec-committee-chair]
+=== Specification Committee Chair
+
+The specification committee chair is a member of the specification committee. 
+
+The specification committee chair (or their delegate) is responsible for initiating ballots, tallying their results, disseminating them to the community, and (when appropriate; e.g., in the case a <<efspo-reviews-release,release review>> ballot) reporting them to the EMO.
+
 [#efspo-roles-pmc]
-==== Project Management Committee
+=== Project Management Committee
 
 The primary role of the Project Management Committee (PMC) is to ensure that project teams are implementing the EDP. In particular, the PMC monitors project activity to ensure that project teams are operating in an open and transparent manner. The PMC reviews and approves (or vetoes) committer elections, first validating that candidate committers have demonstrated sufficient merit.
 
@@ -196,6 +201,18 @@ Appointing a participant representative this is a power that a member participan
 
 Additional committers can be added via {handbookCommitterElectionsUrl}[committer election].
 
+////
+=== Other Parties
+
+I expect that there will be some overlap between teams. That is, I expect (since this is what happens in other WGs) that there will be some SIG members who are committers on the specification project, some specification committee members who are on the SIG, etc. The SIG should never be surprised by something in a release version of the specification, because they should be paying attention to (and possibly participating in) the development of the specifications. Likewise for the specification committee. If these teams are all walled off from each other (which in my experience should be an exception), then we need to strongly encourage regular, formal check-ins to make sure that everybody is on the same page.
+
+The specification committee ballots should be boring because everyone should already know what's going on in the specs.
+
+If a specification project decides to go rogue, the specification committee will keep them in check by denying releases.
+
+While the SIG has no formal authority, the specification project and the specification committee are both committed to implementing their vision, so informal authority flows from that.
+////
+
 [#efspo-creating]
 == Creating a Specification Project