You should never trust anyone's answer on what the system does. The system is the only source of truth. Hopefully there is another developer there who can give

You should never trust anyone's answer on what the system does. The system is the only source of truth. Hopefully there is another developer there who can give you answers to broader questions. Answer specific questions yourself using the system and its code. The first task is divide and conquering the code base. Every code base has an inherent architecture to it. Those without are usually small since it rapidly becomes impossible to grow them after a point. The first division is usually INPUT/LOAD/PROCESS/STORE/OUTPUT in poorly modular code bases. The main objective is to get a rough map of how data moves through the system by recursively tracing and naming places. Make lots of notes and save them in a grepable text file/folder. The next task is to tame the beast. You do this by creating or setting up tests. Take typical customer inputs and save outputs. The more of these, the better. You don't have to run the tests constantly. They will take forever most likely. You do however have to run them regularly enough that breaks don't live too long. The reason for this work is so that you have the confidence to make changes without breaking everything. While all of this is happening, management will expect you to be doing things. This is where you take out tech debt and make ugly bug fixes on top of the many other ugly bug fixes. As you grow in understanding of the system, you will have a better idea how it could be architected. You will know what code stays the same, what code changes, and what kinds of features are added. Begin spending at least half your time teasing apart the code base into modules that reflect the system and its needs. Management will never approve this. You just have to do it.