This is a great question and something I think a lot of customer struggle with at the beginning. I think you are on the right path on segmenting the roles into 2 paths. I would look at it the same way. Let me try to cover the IT roles first.
You are going to have a single customer admin setup when you get your tenants. This can be changed in the future, but this person is the super user for your platform. I would just make this person your top level administrator for Reltio. They should be technical and definitely know enough to be dangerous.
During implementation (and even ongoing if you are follow a continuous improvement agile methodology), you will probably have some developers who are doing things like adding / editing the data model, adjusting match rules etc. Typically, I see these people get almost the same access as an admin, they may just only have this for dev and test tenants. It is important these resources can see data and use the business user capabilities as well so that they can effectively test and verify the changes that they are making.
We don't tend to see significant granularity beyond that for the IT side. Some customers do try to limit access to data, but it creates significant challenges in deploying your tenant config properly, and I would suggest that development teams need to see the data in order to do their jobs well.
Most of our customers break down roles on the business side to one of the following. There may be multiple flavors of Data Steward if say someone can only see US data, or only see EU data, but the core of the role is the same, they just apply it to only a certain geography.
Data Steward :
Someone who can edit or suggest edits to data in Reltio. These team members are typically resolving potential matches and applying changes in the platform. They are typically UI only users. For complex multi geography tenants, there may be different flavors of data stewards primarily to limit access to data based on geography or entity type.
Data Steward Elevated (Manager / level 2)
Most orgs that I have worked with do not have this role, but a sizable amount do. These are for when your level 1 stewards are only suggesting changes. These resources actually make the final call. They have typically the same permissions as a Data Steward except they can edit things vs just suggesting things.
Almost everyone sets up a read only role. This is for anyone who wants to search the data and view things inside of the UI. These read only roles can be broken down to limit access as well if desired.
In a final note, I would suggest that you start with these basic roles and create specific flavors of them as needed. Sometimes customers start with trying to create as many possible configurations of roles that they can think of and end up with an unmanageably mess of roles as they onboard more and more users. I am hoping some of our other customers and partners will also add their thoughts as well!