Workflow architecture
Resuming Onboarding Without Overwriting the Record
A cleared browser draft should not erase a submitted application. I restored the authoritative server record and treated later answers as versioned amendments requiring fresh review.
Senior AI Engineer · M.S. Computer Science, Tsinghua University · See the products I built
In this article · 5 sections
The engineering decisions
- Validate the invitation before reading private submission data.
- Preserve the original submission and append versioned, conflict-checked amendments.
- Bind review to the latest answers and keep saving separate from activation.
Restore the saved version before offering a draft
Returning customers entered the review step with server-recovery feedback, readiness counts and links to missing items. The saved version won over the old first-entry draft. A newer unsent device draft could be restored only through an explicit choice, preventing an old browser from silently replacing the server’s answers.
Long waiver text exposed why these states matter. A rejected oversized save still needed to preserve the local draft for correction, while reopening the server version had to show the last accepted answer. A validation error is not permission to destroy the customer’s work.
Append an amendment instead of rewriting history
Each customer update carried a version, predecessor hash, timestamp, normalized complete answers and a field difference. The original submission, its hash and archive evidence remained unchanged. Saving used a serializable transaction and checked the previous version, so a stale tab could not overwrite a newer amendment.
Repeated requests did not append the same update twice. Reads normalized the stored answers again, including compatibility with PostgreSQL JSONB key ordering. Comparing serialized object text without normalization would have treated a harmless storage reordering as a different answer.
New answers invalidate an old review
Saving an amendment did not send the original lead notification again, create a venue, activate payments or operate hardware. The administration workflow displayed the amendments, and promotion required review bound to the latest amendment hash.
That boundary prevented two misleading outcomes: calling a successful save a completed configuration change, and letting an old review approve answers it had never seen. The customer could supply better information while the operational team retained an explicit implementation and verification step.
Prove preservation as well as recovery
The migration checks compared original submission hashes and body summaries before and after the compatible schema change. Local browser tests exercised recovery without a draft, two amendments, reopening and the oversized-text failure at desktop and mobile widths.
The September record confirms the test-site and onboarding control-plane releases. The production customer record was checked read-only, with no customer amendment submitted for the test. Local isolated end-to-end evidence and the real customer’s unchanged record were kept separate.
Project context and evidence
Written from my September 2026 onboarding recovery, migration and control-plane release records. Public links below support the product and attribution context. Internal project records are summarized, with customer records, credentials, and employer source code omitted.
- GolfJoy Play ↗
Public platform context. Acceptance and release scope are stated in the article.
- GolfJoy engineering case study ↗
Public product interfaces and attribution for the delivered projects.
