Sounds like a good outline to me. Your structure will grow and develop as your understanding of both the software, how you work with it, and your process evolves, so I wouldn't worry about getting types and tags perfect to start with, just good enough. I generally get fussy about highly visited areas of my database, and let the rest evolve over time.
A few that might help to keep in mind: Another recommendation is to focus/fuss on one area at a time that is critical to your daily life and get it to where it works for your workflow. Then once you have that down, you can take the learnings from that and apply it to your next area. That way it's not overwhelming and you are not trying to get things perfect everywhere all at once. Because I've never gotten that to pan out for me.... 😃
Types can be good for having thoughts inherit colors and icons, and also make it easy to report on sets of data. Tags I generally use for the status of things. For example, in process, next, research. Because it can display icons below the the thought, it's a good indicator. It's also useful for narrowing down reports. Some structure and organization is good, but as the database grows, for me I've found that it becomes less important overall, whereas optimizing though names for finding via search becomes crucial. Once that thought is activated, I try to arrange things in context for that area and use, not necessarily via a arbitrary hierarchy (unless it's a public database).