Correct. The implementation itself is very dependent on the RPM profiler since it makes assumptions on the format of the report. Outside of that, I think it's up to the profiler itself to determine what sorts of reports it wants to support. I may be wrong on that last point in which case we'll circle back and move some of it into the platform, but without another example it's very hard to see what should be platform and what is RPM-specific, so I air on the side of keeping the platform clean and finding something generic when we have the use cases to see more clearly.