diff --git a/thoughts.adoc b/thoughts.adoc
index 1e5d0be..eef39d6 100644
--- a/thoughts.adoc
+++ b/thoughts.adoc
@@ -8,27 +8,7 @@ Each SoR record fires an event when it detects a person previously unknown to th
 
 MVService: create subscriber to 'noticedNewPerson'; Its only function is to generate a new internal identifier, link it to the Sorid-assigned unique identifier and persist that info.
 
-- - -
-
-*Hypothetical Precondition*
-
-A person was just now added to a System of Record,
-midPoint has not yet processed this, so has no record of their existence
+If ID Match is implemented and detects the need to merge two existing identities, send a 'mergeableIdentitiesFound' that the person registry will pick up and process appropriately.
 
-Process A: A Grouper admin wants to manage groups for the new person
-. Grouper admin types something they know about the person (a name or email or other identifier) into Grouper
-.. Case 1: Subject lookup--not found. What happens then?
-.. Case 2: Person is found in subject source. What identifier is used when adding them as a member to a group?
-... What manages getting subjects into the subject source
-... How does midPoint associate this group member with a know user?
-
-"Solutions and tradeoffs"
-
-. Have Grouper subject source be provisioned by midPoint;
-.. Consequences: Grouper subject search will fail until new person appears in subject source
+- - -
 
-. Have ID Match always return an identifier for the queried person
-.. works for cases where ID Match can definitively match a known identity or definitively be recognized as new, and return the identifier in either case
-.. If the result is multiple candidate matches that require human resolution, Id Match does not immediately return an identifier
-.. Fix: Have ID Match assign a new identifier to the person in question and return immediately while starting the identity resolution workflow
-... Consequence: If a match with an existing user is eventually found, an identifier correction needs to take place