I have the following business case needs:
- I have a database of projects.
- Each project will have several people associated with it in different roles(project owners, support, etc).
- A single person may play multiple roles in the project.
- A persons’ contact details on a project are captured at the time of project creation and should not be updated for that project when they are updated for the person.
I have the following database structure proposed:

ContactDetails is planned as a 1-1 for now, but seperated in the event that multiple person/role mappings for a single project could share a single ContactDetail.
My question:
Typically I will be loading the list of associated people with my project in their various roles. Based on the structure I have laid out, what should my entity look like here: has ProjectPerson become the entity as opposed to just a cross reference (as it started out being)?
[UPDATE]
Including my new data structure based on the below answer in case it helps anyone else. As advised.

I would move the contact details into ProjectPeople and pull the roles out into a separate table with a one-to-many relationship to ProjectPeople.
To answer your question, yes ProjectPerson is now an entity in your domain model; in fact, I would say it became one as soon as it became more than a simple many-to-many mapping table.
We have a similar structure and it presents some challenges. I have it modeled so that Project has a collection of ProjectPerson and Person has a read-only collection of Project.