I think the scope of SSC could grow/shift a little. Consider: your uploader is doing some PIC stuff which is certainly reusable, and right here you're futzing with envs and days, using that PIC.

Indeed, the generator you just built already makes a PIC and computes the current environment, using the profile path you passed to the generator (which I think we can assume must be the same as the one we're using for recording):

```
    Environment current = EnvironmentBuilder.getCurrentEnvironment(cache);
    return generateDocument(since, lastPingTime, current);
```

To noodle on this topic a little further: perhaps a submission recorder knows about a generator, which and a generator can expose its ProfileInformationProvider and even its (optional) current environment?

And isn't that arguably a `TrackingHealthReportGenerator(storage)`?

```
/**
 * A generator that automatically records generation failures in the same storage that it used
 * to generate the document, using the current ID from its own PIC.
 * Optionally provides a wrapped RequestDelegate that will likewise record upload failures
 * if used in an upload request.
 */
public class TrackingHealthReportGenerator extends HealthReportGenerator {
  public RequestDelegate wrapRequestDelegate(RequestDelegate delegate) {
    return new UploadRequestDelegate(delegate);
  }
}
```

Simply instantiate a `TrackingHealthReportGenerator` instead of a `HRG`, and run your submissions as usual.