These shape the revision UX and the legal/audit posture. None blocks Deliverable 1 v2, but all should be resolved before dev.
If a customer has the signing link open and hasn't signed yet, and the CSR needs to change something, we could either: (a) update the V1 record in place and push the new content to the same signing URL, or (b) invalidate V1 and create V2 with a new signing URL.
Update-in-place is simpler for the customer (their link still works), but legally dicey — the content they're looking at can change under them. V2 with new URL is safer (clean audit trail, unambiguous "what was signed") but risks the customer signing the old V1 if they refresh or the new email is slow. Industry best practice for e-signature leans toward V2-with-new-URL.
Post-signature revisions (e.g., customer had the MNR realization a week later) can either be (a) a full replacement agreement where V2 supersedes V1, or (b) an amendment document that references V1 and only captures deltas.
Full replacement is simpler to build and to explain to customers, but creates ambiguity in audit trail ("which one is the real agreement?"). Amendment model is legally cleaner but doubles the document-management complexity. Most rental businesses use full-replacement with clear version metadata; we should confirm this is acceptable for Q&F's state-specific compliance needs.
Original agreements expire after 7 days unsigned. If we revise and send V2, does V2 also have 7 days, or does it inherit the remaining time from V1?
Fresh-clock is customer-friendly and simpler to explain. Inheriting remainders (e.g., V1 had 2 days left, so V2 also has 2 days) prevents CSRs from using revisions to endlessly extend the window, which could be a concern if expiration is financially meaningful. Business policy call, not a technical one.
If a CSR fixes a typo in the student's name on a signed agreement, does the customer get an email saying "Your agreement has been revised"? Or does it silently update with an audit log entry?
Always-notify: full transparency, high trust, potentially confusing volume of emails for small fixes. Only-material-notify: cleaner customer experience, but we need to define "material" (price change? date change? name spelling?). A middle path: always log the change in the customer portal, but only email on material changes.
Superseded versions need to be retained for audit/legal purposes, but for how long? Indefinitely? 7 years (standard contract retention)? Until rental ends + 3 years?
Retention affects storage cost (minor) and legal exposure (more material). Without a clear policy, superseded versions will accumulate forever by default, which may not match Q&F's record-keeping standards. Worth getting a policy answer from Marsha / George.
Linked to Deliverable 1 Q6. Specifically for this deliverable: if we do allow inline edits on unsigned agreements (no V2 created), we still need a decision on whether the edit history is captured as an audit-log entry or just vanishes.
"Silent" edits leave no trace — fastest for CSR, weakest audit posture. Audit-logged edits give us accountability without forcing a V2 document. Always-V2 gives the cleanest record but creates revision noise for trivial spelling fixes.