📍 Audit resubmission

[danswick]

Squad: @timoballard, @tadhg-ohiggins, @jperson1, @Leighdiddy. @danswick and @jadudm to provide support as needed. Timeframe: shipped to production by end of Q3.

What problems are we trying to solve?

1. The FAC application does not currently provide a way to indicate a submission is a resubmission. Users can only submit the same report again as a duplicate.
2. The FAC application doesn't currently link or otherwise support a relationship between submissions. Audit resolution officials must make assumptions about which of the duplicate reports should be considered the final or authoritative version.
3. The FAC application doesn't offer users any way to avoid accidentally creating a duplicate submission.
4. Search users cannot distinguish intentional resubmissions from accidental duplications.

What can we do today?

Broadly, our approach will be to create metadata that links report IDs and improve the audit submission flow to encourage clearer relationships between submissions and prevent unnecessary duplication to the extent possible. Ultimately, we can't guarantee that all duplicate reports are resubmissions: a single UEI is not consistent over time, users may create a submission using the wrong UEI, the original submission may have been created before UEIs were part of the FAC submission process, etc. We have accepted this as a risk until UEIs are improved or new guidance is issued.

As of late April, we're in the beginning stages of user research. Some of the requirements and details that follow are likely to change as we learn more.

Requirements

Each requirement below will link to a sub-issue where we will track work toward meeting the requirement.

### Requirements
- [ ] https://github.com/GSA-TTS/FAC/issues/3770
- [ ] https://github.com/GSA-TTS/FAC/issues/3771
- [ ] https://github.com/GSA-TTS/FAC/issues/3773
- [ ] Users can choose to mark a submission as a resubmission
- [ ] Users are prevented from creating a new submission if the chosen UEI-audit-year already exists in disseminated data
- [ ] Search users can differentiate single submissions from resubmissions in the search results table
- [ ] Search users can traverse all versions of an audit from the audit's summary page
- [ ] Users can learn how resubmission works and how to interpret resubmitted audit data by visiting the FAC documentation

Context and further reading

Ideally, we would create more clearly-defined pathways to both resubmission and amendment: the former with greater agency oversight and the latter user-initiated. That approach, however, will not be feasible until new single audit policy is issued (when and if). In the meantime, we still need to better support both auditees and resolution officials working with resubmissions. The links below provide additional context and more detail about possible future iterations for resubmission.

1. Resubmission and amendment planning doc (Google Doc).

[danswick]

Questions

• [ ] Should we provide a place for auditees to describe the changes they've made in their revised submission? This could be a single freeform text box, a series of prompts based on computed differences between versions, or something else entirely.
  • [ ] Justification: reason for resubmitting
  • [ ] Type of change: describe what changed
  • [ ] Probably requires a "no PII" attestation
• [ ] Do we need to load historical SF-SACs before we can support linking historical submissions to new resubmissions?
• [ ] Do we need to distinguish between the kinds of changes in a resubmission? Particularly whether the changes are in the SF-SAC vs the report PDF. For example, check a box to indicate the PDF has changed.
• [ ] Is any resubmission data not public?
• [ ] Can submissions/resubmissions have a mix of tribal-suppressed and public visibility?
  • See https://github.com/GSA-TTS/FAC/issues/3771. We may need to build a new feature for validation warnings in addition to errors.
• [ ] How should we handle submissions with biannual schedules (possibility of more than one submission per UEI/AY)?
• [ ] When a resubmission is accepted, how do we handle dates? Which does it inherit from the "parent" and which are unique to the resubmission? For example, submission date might be inherited, but acceptance date could be updated to reflect the date we processed the resubmission. Or maybe a new date field is added specifically for resubmissions.

Assumptions

• We will not "bootstrap" resubmissions off of existing submissions.
• We will clearly state that the "old" submission will remain public even after a new submission is made.
• We'll only support resubmissions if the "parent" submission has a report ID in our system.

[danswick]

Noting that this work is delayed a bit while we gather more user research. Our approach is not likely to change dramatically, but some details likely will.

[danswick]

Quick update: this work is still blocked pending more feedback from partners. It is looking more likely that our strategy will change.