If this is representing the conceptual data model as a GraphQL schema, it should be Manuscript.journal rather than Manuscript.journalId. I've submitted !1 (merged) to change this and other occurrences of the same issue.
Is the Journal type just for multi tenancy? Will it be required for all xpubs? It could mean quite a lot of complexity for a feature not used by the vast majority.
Are past ManuscriptVersions immutable? i.e. do all changes happen on the most recent version? If so, would it be better to have Manuscript hold all the current data and be mutable and at key points that data gets copied into a ManuscriptSnapshot which is immutable? Otherwise we will have to be constantly checking if the ManuscriptVersion being acted on is the most recent and those types of queries are relatively expensive.
Does a Manuscript really have no properties? Shouldn't the status be at that level?
What does the Team -> [User] type mean for reviewers?
I would expect it to be common for a ReviewerInvitation not to have a User. In which case does it need some extra fields to store user data? Or would a user be created on invite?
It seems like the only link between a ReviewerInvitation and a Manuscript is the Review but presumably that would not exist at the point of invitation.
What is the cardinality of the link between invitations and reviews? Can an invitation have more than one review? If not, why not merge them into a single entity?
Same question for reviews and recommendations.
Are the files on a recommendation properties of the Recommendation or the Comment?
Please let's not have Recommendation.recommendation. It is silly.