A researcher approves an AI-assisted interview summary. The research repository saves it, but the response never reaches the workflow. The next run creates a second entry—or generates a different summary under the original approval.
Recovery now affects the research record: which version was reviewed, where its evidence came from, and whether one interview appears more than once.
In How to AI UXR: A Map for Building AI-Augmented Research Operations, Kate Towsey describes a Crawl, Walk, and Run progression from assisting individual research tasks to connected research systems. Her examples include transcript preparation and repository ingestion with human validation.
That framework raises a practical engineering question: how should a research pipeline recover when a step appears to fail after completing its work? The proposed workflow below is my engineering extension of that question. It follows one interview summary from source material through researcher approval to a confirmed repository entry.
01 / The hidden success
Follow the summary across the system boundary
Consider a team conducting interviews about a product’s onboarding experience. Its proposed workflow has five stages:
- Accept an authorised transcript and record its study, session, and version.
- Prepare the material for the approved AI environment, checking redactions and preserving source references.
- Generate a draft summary with links to supporting passages and questions for the researcher.
- Let the researcher inspect the evidence, correct the draft, and approve a specific revision.
- Save that approved revision to the intended repository collection and record its destination ID.
Suppose the final API call times out. The repository might still be processing it, might have saved the summary, or might never have received it. The workflow’s error message cannot distinguish those outcomes.
Repeating the save without recognising the original action can create a duplicate. If later synthesis treats those entries as separate evidence, one session could receive disproportionate weight. Preserving session identity also helps downstream analysis distinguish repeated records from additional participants.
Idempotency means repeated requests have the same intended effect as one request. HTTP defines this property and cautions against automatically retrying non-idempotent requests without knowing that repetition is safe. See RFC 9110, section 9.2.2.
02 / Identity
Identify both the source and the intended write
An event ID identifies an incoming notification. An action ID identifies the particular repository write. Keep them separate: a transcript-ready event might trigger preparation, summary drafting, and a notification, each with its own state.
Verify incoming events and save them durably before acknowledging receipt. Use a uniqueness constraint scoped to the source and workspace to recognise repeated deliveries. Provider semantics matter: GitHub, for example, retains the original delivery identifier on a requested redelivery. See GitHub’s webhook guidance.
Two distinct events can also refer to the same transcript. Give the publication action a business uniqueness rule based on the workspace, session, transcript version, approved summary revision, operation, and destination. Store an opaque action ID once and reuse it for every attempt at that write.
{
"action_id": "act_7f2c91",
"workspace_id": "research_42",
"source_event_id": "evt_8b23",
"study_ref": "study_18",
"session_ref": "session_06",
"transcript_revision": 2,
"operation": "publish_interview_summary",
"approved_revision": 3,
"payload_ref": "summary_6d12_rev3",
"approval_ref": "approval_92ac",
"destination_collection": "collection_18",
"status": "pending",
"attempts": 0,
"destination_id": null
}These identifiers are illustrative. Generate collision-resistant IDs in an implementation and enforce uniqueness atomically. A separate lookup followed by an insert allows concurrent workers to accept the same work.
03 / Approval
A retry must preserve the reviewed interpretation
Replaying the entire pipeline may ask the model to summarise the interview again. Imagine an approved summary says a participant struggled initially but completed onboarding unaided. A regenerated version could omit the recovery and imply that the participant could not finish. The earlier approval cannot establish that the new interpretation was reviewed.
Persist the exact approved content, source references, transcript version, and destination. Bind the approval to that revision. The publication worker reads the saved payload during recovery, preserving the researcher’s corrections and qualifications.
Retain model and prompt versions alongside the decision record so the draft’s origin can be explained. Keep sensitive source material behind the appropriate access controls; attempt logs can refer to it without repeating interview text.
A changed summary needs a new revision and the required review. Resolve an uncertain publication of the old revision before sending its replacement. Record which entry the correction supersedes, so later retrieval can distinguish current findings from their history.
Check that approval and permission to publish remain valid when delayed work resumes. Preserving a payload does not require executing an action whose authorisation has been withdrawn.
04 / Recovery
Confirm what the repository actually saved
Save the approved action and its pending-work entry in one database transaction. A worker claims that work, calls the repository, and records the result. This transactional outbox pattern keeps the local decision and the obligation to execute it together.
A gap remains: the worker can crash after the repository saves the summary but before local completion is recorded. A local transaction cannot make that external call atomic.
When the repository supports idempotency
Use its documented idempotency mechanism with the saved action identity and unchanged payload. Record the returned entry ID and revision. For an asynchronous API, an accepted job needs a later completion check before the summary is marked published.
Check the provider’s retention and error rules. As an example from another API, Stripe documents parameter matching, cached results including server errors, and key pruning after at least 24 hours. Reusing a pruned key can create a new request. Consult Stripe’s idempotency contract for those specific semantics; establish your repository’s own contract separately.
When the repository cannot deduplicate
Look for an authoritative operation-status endpoint or a destination-enforced unique external reference. A search returning no matching summary is weaker evidence: indexing might lag, or the first write might still be running.
If the outcome remains uncertain, record outcome_unknown and route it to an operator with the action ID, request time, destination, and available receipt. Reconciliation means establishing whether the original write completed before deciding what to do next.
Keep uncertainty visible. An unknown publication outcome needs investigation. A fresh model-generated summary cannot resolve what happened to the approved one.
05 / Retry policy
Give recovery a limit and an owner
A retry needs a plausible recovery path and protection against an additional unintended effect. Set a policy for the repository write:
- Temporary failure with safe repetition. Use bounded attempts, an elapsed-time limit, and increasing delays with random variation to spread load.
- Rate limiting. Follow the provider’s instructions and honour a valid
Retry-Aftervalue. Defer work if the requested delay exceeds the job’s deadline. - Invalid input or denied access. Route the action for correction or cancellation.
- Unknown outcome. Use the documented idempotent recovery path or investigate the original write.
RFC 9110 defines Retry-After as a waiting instruction. The destination’s operation semantics still determine whether a write can be repeated safely.
Assign one layer responsibility for the overall attempt budget, including retries inside the client library. Retain action records for the intended replay period. Work older than the provider’s deduplication window needs reconciliation before another write.
When automatic recovery is exhausted, park the action with an owner and a reason. A manual resume should retain its identity, reviewed content, and approval checks.
06 / Research quality
Check execution and interpretation separately
Towsey also emphasises researcher familiarity with source material, attention to contradictory evidence, and evaluation as automation grows. These concerns remain essential when a pipeline can deliver records reliably. See her discussion of risks in the original article.
Verify the destination, content revision, entry ID, and duplicate status. Preserve an inspectable record of attempts and completion.
Check claims against source passages, retain qualifications, examine contradictory evidence, and assess what the study can support.
An idempotent write can faithfully deliver a flawed interpretation. Human approval is a recorded decision, not proof that every claim is correct. Research quality needs its own evaluation, correction process, and accountable review.
Repository retrieval should also preserve source lineage: several chunks, revisions, or summaries from one session are related records. Their presence does not increase the number of people interviewed.
07 / Verification
Test the handoff after approval
Use a controlled repository or test double to exercise these boundaries:
- Deliver duplicate events concurrently, then distinct events for the same approved revision. Confirm that both paths resolve to one logical publication action.
- Save the summary and drop the response. Verify that recovery finds the original entry or uses the supported idempotency mechanism.
- Crash the worker after the remote write. Confirm that its replacement preserves the action identity and approved payload.
- Change the prompt or model after approval. Confirm that recovery publishes the saved revision, including the researcher’s corrections.
- Replay an action after the deduplication window expires. Confirm that it requires reconciliation before another write.
- Simulate ambiguous repository status or withdrawn approval. Confirm that the action waits for resolution or is cancelled as appropriate.
Measure duplicate entries, unresolved action age, and time to confirmed publication. Track source fidelity and researcher corrections separately. Inspect the stored content as well as the workflow’s completion status.
08 / A practical starting point
Make one research handoff recoverable
Start with one approved interview summary and one repository collection. Establish the source identity, reviewed revision, destination contract, and evidence of completion. Then simulate losing the response immediately after the save.
The same handoff matters in the multi-source research workflow and the human-approved changes in my incident response architecture. Recovery should preserve the decision that was actually reviewed.
For a research team, the useful outcome is a repository entry whose source, interpretation, approval, and publication history can all be explained—even after the workflow has failed and resumed.
Stay up to date
Get new engineering notes by email.
Occasional, practical writing on engineering, automation, data, and product strategy.