A milestone workflow should distinguish evidence readiness from client acceptance, preserve every revision and exception, and let only authorized roles change the final state.
Internal readiness before client submission
Use separate states for evidence draft, internal review, ready for client, submitted, and client response pending. Internal readiness requires a frozen deliverable version, mapped requirements, complete or explicitly missing evidence, known limitations, and a named submission owner. It does not imply that the client has accepted the work. The transition to submitted should record the channel, recipient, time, dossier version, and review window supplied by the governing process.
Role rules prevent the producer from approving its own client acceptance record. A delivery contributor may attach evidence, a delivery lead may mark the packet ready and submit it, and an authorized client reviewer may enter the client disposition. An administrator can correct access or metadata but should not silently rewrite an accepted state. Every state change needs an actor, timestamp, reason, and reference to the version it affects.
Revision, clarification, and exception branches
A revision request should cite requirement rows, requested change, supplied evidence, owner, due date if agreed, and retest condition. Clarification is different: it asks an authorized party to resolve language or provide missing direction before the team changes the deliverable. An exception proposes acceptance of a known variance and needs the affected requirement, rationale, impact, approving role, and scope of the exception. Keeping these branches separate prevents every review comment from being treated as a defect.
When revised work returns, create a new deliverable version and rerun only the affected checks plus any identified dependencies. Preserve the prior result and link the change to the request. If the client changes the requirement, record the approved change source rather than editing the original row. NIST's acceptance guide emphasizes controlled documentation and traceability because later reviewers need to understand both the procedure and the result.
Acceptance record, invoice gate, and reuse
The accepted state should identify the authorized reviewer, accepted dossier and deliverable versions, included exceptions, date, and any remaining obligations. An e-signature or approval platform can preserve identity and audit history, but the services agreement determines whether that record triggers an invoice or next phase. The workflow should expose the accepted state to the delivery lead without automatically representing that payment is due under every circumstance.
Milestone Proof configures and documents these states through Reality Contact, LLC. The delivery lead controls submission and invoice actions; the client controls acceptance; and both parties retain their own legal and commercial judgment. After acceptance, the system copies only the confirmed gates, open obligations, and exceptions into the next phase, leaving the signed milestone record immutable.
Where the service stops
Reality Contact, LLC implements the evidence system but does not provide legal advice, interpret disputed contract rights, decide whether a client must accept or pay, sign on either party's behalf, send the submission, or issue an invoice. The delivery lead reviews the packet, submits the milestone for explicit client acceptance, invoices under the applicable agreement, and carries the accepted gates into the next phase. This is delivery-operations implementation and document preparation; it does not replace either party's legal, contract, accounting, tax, or commercial review. We do not promise client acceptance, payment, dispute prevention, enforceability of a signature, or successful completion of requirements whose meaning remains unresolved.
Sources: NIST software-acceptance documentation guidance; PandaDoc approval workflows and audit features; Docusign real-time audit trail and signature plans.