PRODUCT DESIGN·7 min

Gamma: agree on the story, then decide how to edit each card

Gamma creates visual content such as presentations and documents. People explaining a proposal or reporting on their work can start with notes, generate a draft, and refine it through conversation and direct editing.

Break down the problem and try your own design and implementation first. Then explore the reasoning to check states, edge cases, trade-offs, and ways to test your approach. The guide offers a reasoning path, not a complete implementation.

CODE EXERCISEAdvanced

Reject stale edit batches without partial writes

Implement a teaching module for reviewing proposed edits, in any language. It does not call real AI or model Gamma's internal system.

Inputs. A document has an integer version v and elements stored by ID. A generation request contains requestId, baseVersion and target element IDs. Its response is a whole batch of proposed changes. A snapshot is a copy of the document when the request starts; later edits do not change it.
Rules. At most one request may be pending at a time. A generated result enters preview without changing the document. Acceptance may apply the entire batch and increment the version once only if the current version still equals baseVersion and every target exists. Manual edits also increment the version. A version mismatch or missing target rejects the entire batch, with no partial application.
Cancellation and duplicates. A result arriving after cancellation must not reopen preview. Duplicate callbacks or repeated acceptance for one requestId must not write more than once. Conflicting callback content for the same request must report a conflict rather than silently replacing the result. A finished request must not affect a new one.
Small example. At v=4, request R targets A and B. While waiting, the user edits A manually, advancing the version to 5. R returns and the user clicks Accept. Write the final document, preview and request states by hand. Also consider cancelling R, starting S and then receiving R again.
Deliverables. Provide state definitions and a transition table, module interfaces, error categories, and five event traces: normal acceptance, a manual-edit conflict, a missing target, a result after cancellation and a duplicate callback. For each, state the expected document version and whether a write occurs.

Explore the reasoning

Separate document state from request state. A result arriving still leaves a user decision before acceptance.
Identify the only transition allowed to write. Check the version and all targets there; no failure may leave half a batch applied.
Walk through v=4 advancing to 5 after a manual edit. Decide whether retaining a candidate result also means allowing it to overwrite the current document.
Retain enough identity information for cancelled, completed and duplicate events. Distinguish identical replay from conflicting content for the same ID instead of checking only the currently active request.
Use traces to verify “at most one write per request” and “stale results cannot overwrite a newer document.” Network retries and cross-device collaboration are outside scope.