Something records managment routinely forgets and you're probably forgetting to use in your information architecture
The transition states.
Developing categories (however you implement them) always involves an aspect of maturity matching.
If your people are engineers, and used to thinking in terms of a shared body of practice and in ways that are structured and precise, your categories should reflect these things - because they are routine for your people.
If you try and deploy the same categories for non-engineers, you're going to find it doesn't work because there's a maturity gap. They don't know the body of practice, and probably aren't used to thinking in structured and precise ways.
This is a maturity problem.
Mostly, we try and bridge maturity problems with training.
People aren't used to thinking in a certain way, so we train them - and hope that the training is enough to bridge the gap.
Often though, it just isn't enough.
This isn't something that RM has been good at dealing with - which is one of the reasons our classification schemes and systems are often failures.
The problem is one of maturity.
The maturity gap is too much to bridge in one jump.
This is where transition states come in.
System architecture as I have seen it practiced, is generally considered in terms of the "current state" and "desired state," or "as-is" and "to-be" states.
In between those though, can be a set of transition states.
A transition state is any stopping point along the way that helps you get to your desired state - but isn't considered the end of the line.
It's an opportunity to say - "this represents a meaningful improvement in maturity" - while still keeping your key stakeholders focused on the end goal, and your people not running out the door because of all the change they're trying to absorb.
So many records projects fail because people are trying to adjust to too many things all at once - change of system (how to use), change of storage location (where stuff is) and how to think about the way they classify their stuff.
Transition states let you make small changes - and see how they go.
If they're going well, you keep going.
If they're not going well, you have a small change that you can either roll back, or increase the pressure on the other sides.
As we all try and grapple with new systems (one in particular) transition states are going to represent a useful tool.
Can't get to compliant?
Why not at least get to controlled first?
Can't get all the metadata you want?
How about just getting the first bit that you need?
Etc.
Transition states.