diff --git a/fm/msg-schema-implementers-draft b/fm/msg-schema-implementers-draft
new file mode 100644
index 0000000..85d21f3
--- /dev/null
+++ b/fm/msg-schema-implementers-draft
@@ -0,0 +1,643 @@
+=== fm.adoc Federation Manager P*P
+https://github.internet2.edu/InCommon/siteadmin/blob/master/api/swagger.json +
+https://fmdev.inc.testbed.tier.internet2.edu/siteadmin/api
+
+- - -
+_2020-08-05 20:23 Fed Mgr messaging FMIC-25_
+
+Create and test FM message consumer(s) to read FM messages in ICP dev environment, reconcile group changes into the proper groups via Grouper API calls. Reconcile user changes into COmanage via COmanage API calls.
+
+Reference: Message schema https://docs.google.com/document/d/1jS2eyBXV49hs29WSAJxpPeWn6Xz2HE5vzhZI4q8EbDg/edit?usp=sharing
+
+Consume messages consisting of outer resourceTypes:
+
+*FMperson*
+
+==== eventType "create":
+These messages should be processed into COmanage person add actions where a person with a matching ePPN and/or email address does not exist in COmanage. The ePPN and/or email address sent in the message should be mapped into upstream / source system ePPN and email address in the new person record.
+
+==== eventType "update":
+These messages should be processed into COmanage person update actions where a person with a matching ePPN and/or email address already exists in COmanage. The ePPN and/or email address sent in the message should be matched with into upstream / source system ePPN and/or email address in the existing person record. Any other attributes of the existing person record present in the message should be updated with values contained in the message.
+
+In the case where a person record does not yet exist for this person, the message should be treated as an eventType of "create".
+
+*FMrole*
+
+==== eventType "create"
+These messages should be processed into Grouper using Grouper API calls. They should result in groups within the folder/group structure
+
+"app:incommon:fm:(Normalized Organization Name (contained within the embedded FMorg message in the orgName field)):(roleName)"
+
+where (roleName) is the group name within an org folder. Organization groups should be decorated with attributes for "FMorgIdentifier" and "SForgIdentifier" and these attribute values should be set for these groups based on the information contained in the embedded FMorg resourceType message. All FMperson resourceTypes contained in the embedded collection of
+
+{ FMperson }
+
+messages should be added to the initial population of the group.
+
+organizationName values within embedded FMorg messages MUST be normalized by the message consumer using the following regular expression before being added to Grouper:
+
+[^a-zA-Z0-9 _\-] (all non-alphanumeric characters should be removed)
+
+==== eventType "update"
+An existing group matching the full computed group path determined using the folder/group structure noted in the "create" eventType for this resourceType should be treated as the target of an update. All fields EXCEPT the FMorgIdentifier and SForgIdentifier attributes on the organization folder should be updated according to the values contained in this message and any embedded FMorg and/or FMperson resourceType messages. In the case where an existing path to a group cannot be found, the message should be treated as a "create" message and a WARN log event should be generated noting this, along with appropriate diagnostic details.
+
+==== eventType "personadd"
+An existing group matching the full computed group path determined using the folder/group structure noted in the "create" eventType for this resourceType should be treated as the target of this message. Any FMperson resourceType messages embedded within the message should be added to existing group membership. In the event that a group cannot be found matching the computed group path, the message should be treated as an eventType of "create" and a WARN log event should be generated noting this, along with appropriate diagnostic details.
+
+==== eventType "personremove"
+An existing group matching the full computed group path determined using the folder/group structure noted in the "create" eventType for this resourceType should be treated as the target of this message. Any FMperson resourceType messages embedded within the message should be removed from existing group membership. In the event that a group cannot be found matching the computed group path, the message should be treated as an eventType of "create" and a WARN log event should be generated noting this, along with appropriate diagnostic details.
+
+*FMorg*
+
+These messages are only relevant in the context of a wrapping FMrole resourceType message, for the time being.
+
+All resourceType/eventType combinations not documented here should be silently dropped (FMperson and FMorg messages in the context of a wrapping FMrole resourceType / personadd or personremove eventType should be handled as documented above).
+
+- - -
+_2020-08-03 11:18 FM messaging requirements_
+
+*Bill Kaufman 11:10*
+
+Reminder @channel, Nick completed final implementer’s draft of the FM message types, thanks everyone for your feedback
+prior to the ICP meeting this Thursday:
+https://docs.google.com/document/d/1jS2eyBXV49hs29WSAJxpPeWn6Xz2HE5vzhZI4q8EbDg/edit?usp=sharing
+
+Additionally, here are the detailed FM message consumer requirements: https://todos.internet2.edu/browse/FMIC-25
+Please comment on these requirements in JIRA.
+
+*Nic Roy*
+
+Additionally, here are the detailed FM message consumer requirements: https://todos.internet2.edu/browse/FMIC-25
+Please comment on these requirements in JIRA.
+
+- - -
+_2020-03-10 18:06 references and links_
+
+https://docs.google.com/document/d/1uqYFBNVh1QS-LK-LyMenrJ0eVDk5TT1KMObo4zn0bKE/edit# <= Federation Manager 2020 ICP Planning +
+
+- - -
+_2020-02-24 11:18 SCIM / Swagger_
+
+- - -
+_2019-05-28 16:49 connector for fedmgr api: https://fmdev.inc.testbed.tier.internet2.edu/siteadmin/api_
+
+returnable resources
+
+```
+/entities
+/people
+/organizations/roles
+```
+
+next step: develop a very basic Java Spring Boot app that can accept the json object coming from the Fed Manager API and transform it to a pojo per http://www.jsonschema2pojo.org/
+
+- - -
+_2019-05-17 17:45 connector for fedmgr_
+
+https://wiki.evolveum.com/display/midPoint/Read-only+Resource+HOWTO
+
+notes from http://bit.ly/apiRegWG-9
+
+Federation Manager <=> midPoint: 1st as SoR0:00, eventually as provisioning target.
+
+* Initial Experiments with the Federation Manager read-only API
+* Notes on the use of API keys
+** “API keys aren't as secure as authentication tokens (see Security of API keys), but they identify the application or project that's calling an API.”
+** It’s a bearer token: “Because anyone who makes a request of a service transmits their key, in theory, this key can be picked up just as easy as any network transmission, and if any point in the entire network is insecure, the entire network is exposed. This makes API keys a hard thing to recommend – often misused and fundamentally insecure, they nonetheless do have their place when properly secured and hemmed in by authorization systems.”
+* Is the ConnID REST connector superclass from midPoint a good basis for developing a Federation Manager API connector? EthanK: Yes.
+* Wordpress connector is based on this superclass; See on I2 Github (Ethan)
+* midPoint provides a Dummy connector just illustrating the basic structure of a REST connector.
+* Example of a fully functional midPoint connector for Drupal using its REST API
+* midPoint’s core reference: Guide to Connector Development
+* Step 1: Understand which operations we want to do against the API, mapping to the connector functions; Understand which objects we expect to get from FM: Accounts, Organizations, Entitlements (roles)
+* Federation Manager API is read only for now
+
+- - -
+_2019-05-17 07:09 success with fedmgr api_
+
+using Poster
+
+```
+https://fmdev.inc.testbed.tier.internet2.edu/siteadmin/api/organizations/roles
+
+Content-Type application/json
+X-API-Key 0336034bd52cfadee08e9c87d20c7638
+
+
+Response:
+status: 200 OK
+content-security-policy: script-src 'self' blob: filesystem: chrome-extension-resource:; object-src 'self' blob: filesystem:;
+cache-control: no-cache
+etag: "5vpNazOuDZnW54clALeRFXoa+AI="
+content-type: text/html
+
+
+