diff --git a/devdocs/specs/core-notification.txt b/devdocs/specs/core-notification.txt
index 750c34a9..5693743e 100644
--- a/devdocs/specs/core-notification.txt
+++ b/devdocs/specs/core-notification.txt
@@ -38,10 +38,25 @@ OBJECTS Saving an object triggers notification processing for that object:
 
 
 
+TABLES
+v7
+aNotifyEventOfInterest - subscribercount, ayatype, eventtype, "guidvalue" (extra info),created/creator/updated/updater
+v8 
+similar but with hash maybe for faster checking? and no created/modifed stuff, guid value would maybe be some other thing to accomodate RAVEN as it seems to deal with id of specific or maybe things like status 
+
+v7 this is the main table where events are stored and delivered from (saved message is for quick notification)
+anotifyevent - ayatype, objectid, eventtype, appliestouserid (single subscriber event), aEventDate, ASAVEDMESSAGE
+
+v7 all subscriptions - used to process deliveries (checks for generic event to see who subscribes to it)
+anotifysubscription - ayatype, eventtype, userid, guidvalue
 
 
+v7 - logs deliveries, removes any older than 7 days (that's short!?)
+aNotifyDeliveryLog (aRootObjectType, aRootObjectID, aEventType,aGuidValue, aDeliveryDate, aToUserID, aDeliveryMethod, aDelivered, aErrorMessage, aToClientID )
 
-
+QUESTIONS ABOUT v7 / improvements
+Why the anotifyeventofinterest table?
+	The subscription table already contains all that info, seems like an extra step plus it has to keep a tally of subscribers which seems prone to issues