Reading your question and the other answers, I am under the impression there is some confusion caused by the fact the term "event based system" often is used differently from the way it is used in your question. I am pretty sure the requirement

he must inform the system so that it can generate a report afterwards of how much hours a certain project required.

does not mean your system needs to generate such a report immediately when an employer informs the system he stops working on a certain project. That is what the term event based system would make sense for, to trigger sequences of dependend actions to another, independent parts of the system, avoiding time lags and polling. In your case, however, the Report generation is probably triggered later by a person (for example the project manager), and not by the fact an employee ends his work on a certain day.

In your case, however, you just need to log tuples (employee, project, time, [start|stop]) somewhere. When you have your employees and your projects in a relational database, with tables Employee and Project (and corresponding classes), this will mean you add a table/class with four columns/attributes EmployerID, ProjectID, Time, StartStop to the system. One could call this table/class Event, indeed, but to avoid any confusion, I recommend you pick a more specific name, maybe WorkLog. Then, when it comes to report generation, one can evaluate this table and easily

retrieve the relevant events work log entries and compute time spans and sum them up.

This should already solve your "loose ends". For example,

finding a way to connect two such events so that we know that one refers to work started and the other referes to the ending of that started work.

is easy - there should be always pairs of WorkLog entries in the table for the same combination (EmployeeID,ProjectID), one with the state "Start" and one some hours later with the state "Stop", both on the same day. Of course, you need to make sure you have a strategy in your system to deal with situations if one employee forgets to record his begin or end of work on a certain day, but that is not a technical problem, you will have to solve this problem indepently from the solution you pick.

the other approach I thought seemed to bloat the employee class [by...] make the employee class hold a reference to the project the employee is currently working on

Obviously not. The solution above does neither add something to Employee class nor to the Project class.

Reading your question and the other answers, I am under the impression there is some confusion caused by the fact the term "event based system" often is used differently from the way it is used in your question. I am pretty sure the requirement

he must inform the system so that it can generate a report afterwards of how much hours a certain project required.

does not mean your system needs to generate such a report immediately when an employer informs the system he stops working on a certain project. That is what the term event based system would make sense for, to trigger sequences of dependend actions to another, independent part of the system, avoiding time lags and polling. In your case, however, the Report generation is probably triggered later by a person (for example the project manager), and not by the fact an employee ends his work on a certain day.

Here, just logging tuples (employee, project, time, [start|stop]) somewhere will be sufficient. When you have your employees and your projects in a relational database, with tables Employee and Project (and corresponding classes), this will mean you add a table/class with four columns/attributes EmployerID, ProjectID, Time, StartStop to the system. One could call this table/class Event, indeed, but to avoid any confusion, I recommend you pick a more specific name, maybe WorkLog. Then, when it comes to report generation, one can evaluate this table and easily

retrieve the relevant events work log entries and compute time spans and sum them up.

This should already solve your "loose ends". For example,

finding a way to connect two such events so that we know that one refers to work started and the other referes to the ending of that started work.

is easy - there should be always pairs of WorkLog entries in the table for the same combination (EmployeeID,ProjectID), one with the state "Start" and one some hours later with the state "Stop", both on the same day. Of course, you need to make sure you have a strategy in your system to deal with situations if one employee forgets to record his begin or end of work on a certain day, but that is not a technical problem, you will have to solve this problem indepently from the solution you pick.

the other approach I thought seemed to bloat the employee class [by...] make the employee class hold a reference to the project the employee is currently working on

Obviously not. The solution above does neither add something to Employee class nor to the Project class.

Reading your question, I am under the impression you have a misconception what the term "event based system" typically is used for. I am pretty sure the requirement

he must inform the system so that it can generate a report afterwards of how much hours a certain project required.

does not mean your system needs to generate such a report immediately when an employer informs the system he stops working on a certain project. That is what the term event based system would make sense for, to trigger sequences of dependend actions to another, independent parts of the system, avoiding time lags and polling. In your case, however, the Report generation is probably triggered later by a person (fir example the project manager), and not by the fact an employee ends his work on a certain day.

In your case, however, you just need to log tuples (employee, project, time, [start|stop]) somewhere. When you have your employees and your projects in a relational database, with tables Employee and Project (and corresponding classes), this will mean you add a table/class with four columns/attributes EmployerID, ProjectID, Time, StartStop to the system. One could call this table/class Event, indeed, but to avoid any confusion, I recommend you pick a more specific name, maybe WorkLog. Then, when it comes to report generation, one can evaluate this table and easily

retrieve the relevant events work log entries and compute time spans and sum them up.

This should already solve your "loose ends". For example,

finding a way to connect two such events so that we know that one refers to work started and the other referes to the ending of that started work.

is easy - there should be always pairs of WorkLog entries in the table for the same combination (EmployeeID,ProjectID), one with the state "Start" and one some hours later with the state "Stop", both on the same day. Of course, you need to make sure you have a strategy in your system to deal with situations if one employee forgets to record his begin or end of work on a certain day, but that is not a technical problem, you will have to solve this problem indepently from the solution you pick.

the other approach I thought seemed to bloat the employee class [by...] make the employee class hold a reference to the project the employee is currently working on

Obviously not. The solution above does neither add something to Employee class nor to the Project class.

Reading your question and the other answers, I am under the impression there is some confusion caused by the fact the term "event based system" often is used differently from the way it is used in your question. I am pretty sure the requirement

he must inform the system so that it can generate a report afterwards of how much hours a certain project required.

does not mean your system needs to generate such a report immediately when an employer informs the system he stops working on a certain project. That is what the term event based system would make sense for, to trigger sequences of dependend actions to another, independent parts of the system, avoiding time lags and polling. In your case, however, the Report generation is probably triggered later by a person (for example the project manager), and not by the fact an employee ends his work on a certain day.

In your case, however, you just need to log tuples (employee, project, time, [start|stop]) somewhere. When you have your employees and your projects in a relational database, with tables Employee and Project (and corresponding classes), this will mean you add a table/class with four columns/attributes EmployerID, ProjectID, Time, StartStop to the system. One could call this table/class Event, indeed, but to avoid any confusion, I recommend you pick a more specific name, maybe WorkLog. Then, when it comes to report generation, one can evaluate this table and easily

retrieve the relevant events work log entries and compute time spans and sum them up.

This should already solve your "loose ends". For example,

finding a way to connect two such events so that we know that one refers to work started and the other referes to the ending of that started work.

is easy - there should be always pairs of WorkLog entries in the table for the same combination (EmployeeID,ProjectID), one with the state "Start" and one some hours later with the state "Stop", both on the same day. Of course, you need to make sure you have a strategy in your system to deal with situations if one employee forgets to record his begin or end of work on a certain day, but that is not a technical problem, you will have to solve this problem indepently from the solution you pick.

the other approach I thought seemed to bloat the employee class [by...] make the employee class hold a reference to the project the employee is currently working on

Obviously not. The solution above does neither add something to Employee class nor to the Project class.