How has the situation come about where you've been tasked with "improving code quality" and some sort of quantified metric or "proof" is being demanded after two weeks of shuffling the code formatting?
It seems to me like there is considerable confusion on all sides.
Quality
It's widely accepted that there are no effective metrics for measuring the whole quality of arbitrary code.
It's also widely accepted that simple transformations by automated tools do not appreciably improve quality.
Code formatting does matter for readability, but nobody ever encounters code that is just great except for the formatting.
Seriously poor formatting is typically a sign that the developer had no attention to detail or any other care in the world - and the problems with quality won't just be with the formatting.
Fuss about formatting more often amounts to good developers arguing amongst themselves about brace position or other style trivia that doesn't deserve attention, or it amounts to expecting the guy who looks after the dungeon to start eating with a knife and fork at the king's table (i.e. setting a standard too far away from the competence of the given developer, the underlying problem being recruitment or salary factors being mismatched to the need for developers with real skills).
Real improvements in code quality, where there is a real deficit, typically take a considerable amount of time to implement - a good guideline is that whatever number of man-hours it took to write the code under consideration, it will take at least that number of man-hours for a new developer to revisit.
If the poor quality is localised, then fine, but if it permeates the whole application then change can be a considerable amount of work, if one developer is attempting to take on what has already taken several developers several years to produce.
Proof
The proof of code quality will always be mainly in the judgment of those who work with the software. That is, those who read and write code, and who keep possession of the main and most detailed understanding of the system.
The code can be in poor condition quite some time before the problems become manifest to non-technical staff, such as through the frequency of bugs and breakdowns, the inability to adapt the code to even small changes in business circumstances, or the obvious flight of expertise and inability to retain developers.
Once these kinds of symptoms are manifest, there is often no hope of recovering the existing code base, and the cost of development (or the cost of lost opportunity for development that can't happen) changes up a step.
Your manager asking for "proof" of improved quality suggests either he's asking for independent metrics that don't exist, or he's asking at least for a very convincing explanation of the importance of the changes you've made and the worthiness of allocating your time to it.
Dangers
There's a danger here that you might very well know the problems with the code, but not necessarily the actual solutions.
There's also a danger of your manager commissioning or trying to assess the results of work he doesn't understand, and of you not being in a position to improve that understanding.
If your manager has asked you to "improve code quality", I'd take asking for results two weeks later as screaming siren that his understanding of what he is managing is as far away from reality as Hades from Elysium.
If you've asked for the right to allocate your time to "improving code quality" because you know it to be poor, then clearly what you haven't done is brief him at the outset about the scale of proposed work and likely timelines.
You might need to think about how exactly to explain the relevant points and correct the course.