An answer arrived. That does not mean the problem is solved.

A reply has arrived. That does not tell us whether the problem is solved.

Imagine a fictional question board receiving this request: mark a question resolved and close it as soon as somebody replies. The question says that an exported file contains garbled text. An answer suggests changing the encoding. The author has not reopened the file yet. Closing it now would record answer delivery as problem resolution.

Start with the existing question, answer and comment states, who can confirm resolution, who can lock comments, and what edit history exists. If the service does not record something, mark it unverified. Do not invent a high reply or resolution rate to justify the request. This example uses existing member identity and allows one selected answer per question.

Rewrite the request as: let the author identify the answer that resolved the question, and manage conversation restrictions separately. That decision gives interface labels and reporting a shared meaning.

The sequence starts with no answers, then one suggestion to change the encoding. The reply-arrived demonstration represents that first-answer stage. A second answer suggesting UTF-8 through the import menu is added later. The two-tab selection test starts only after both answers exist.

Convenience does not decide who can confirm resolution

Consider automatic resolution on the first answer, automatic resolution after inactivity, and explicit author confirmation. The first two can reduce an operational backlog, but both can close a question whose author has not checked or whose problem remains. For this example, keep unconfirmed questions open and require author confirmation.

GitHub’s discussion documentation presents marking or unmarking an answer and locking a conversation as separate operations. That separation is the reference here. Author-only confirmation and invalidation after body edits are independent choices for this fictional board, not claims about GitHub’s implementation.

Moderation authority also needs a boundary. A moderator may clear confirmation with a recorded reason or lock comments, but cannot declare resolution on the author’s behalf. A support service where staff close cases needs a different ownership decision before reusing this design.

Store what was confirmed, not only a resolved flag

A flag alone loses its basis when the selected answer changes. Connect the question, selected answer, both confirmed body revisions and the resolution-state revision. Revisions are implementation values. The public interface can simply say that the content changed and needs confirmation again.

Any body edit, hiding or deletion of the question or selected answer clears confirmation in this example. That includes typo corrections. It avoids inventing an automatic test for whether an edit is meaningful, at the cost of extra author checks. Record that tradeoff. Editing a different answer or a comment does not change the selected evidence and leaves confirmation intact.

Restoring text or making it public again must not revive the old confirmation. The author must review it again. Notify the author of the clearing reason without exposing hidden text. Record relationships, before/after state, actor, time, reason and notification outcome; check retention against the existing policy.

Two tabs must not silently choose two different answers

In one atomic operation, the server checks the current author, access, answer membership in the question, visibility, viewed body and state revisions, and whether the question is still unresolved. Atomic means that another request cannot change the relevant conditions between the check and the saved result.

If two tabs select different answers from the same unresolved state, only one request succeeds. Show the current selection to the other request instead of overwriting it. Replacing an answer requires clearing the previous confirmation and reviewing the new answer. Clearing also checks the current selection and state revision so an old screen cannot remove a newer choice.

A retry after a lost success response needs both the original operation result and the current state. The original request may have succeeded before an answer edit cleared it. The interface follows the current state. Retrying must not recreate history, notifications or a resolved badge.

Locked and unresolved is a valid screen

A single closed label hides whether the author solved the problem or moderation restricted conversation. Display resolution and comment locking separately. When content is public, the author can confirm or withdraw even while comments are locked. Hiding content changes access and is a different condition.

After a click, show processing until the server confirms the result. If conditions changed, explain why the author must review current content instead of offering only a generic retry. The four views below are fixed message examples; selecting them does not change a live question board.

Ask AI to find broken conditions before asking for a polished flow

A bare request to write a resolution specification may introduce automatic closure or moderator confirmation without asking. Supply the confirming actor, edits that invalidate confirmation, and exactly what a lock restricts. Delegate the search for missing cases and before/after states within those boundaries.

If a proposed answer says to return the first successful result for duplicates, test a lost response followed by an answer edit. An answer that cannot distinguish historical success from current non-resolution is incomplete. Carry the corrected condition into interface copy, server handling and QA rather than leaving it in the chat.

The prompt below is an unexecuted example. It is not a transcript or a claimed AI response. When using it, compare every proposed case against permissions, revisions, retries and locking. Treat new policy suggestions separately from already chosen requirements.

Example prompt: This public question board uses existing member identity. Only the question author can confirm one answer. Editing, hiding or deleting the question or selected answer clears confirmation; comment locking is independent. There is no automatic resolution or moderator confirmation. Examine two tabs selecting different answers, confirmation racing a body edit, and a lost success response followed by an edit and retry. Give initial state, request order, final state, interface copy and QA expectations. Label any proposed policy addition separately.

Give each handoff document a decision it can support

The planning document explains why unconfirmed questions remain and why even typo edits require another check. The design specification connects state-specific copy, available actions, permissions and competing edits to observable results. Repeating identical prose in both documents does not supply what their readers need.

W3C’s status-message guidance supports making non-focus-taking feedback identifiable by assistive technology. Here, provide textual distinctions for processing, confirmation and changed conditions, with appropriate status feedback. A dark badge alone is insufficient, and repeatedly forcing focus is unnecessary.

Operations needs reasons for cleared confirmation rather than a shortcut to increase the resolved count. A failed notification does not reverse an already committed state change. Retry the notification for that same event and keep delivery separate from the author’s new confirmation.

Inspect the state left behind, not just a working button

QA needs explicit starting states: an unresolved question with two visible answers, or a confirmed question with comments locked. Expected results should cover the selected answer, confirmed revisions, history and duplicate notifications as well as the screen.

Exercise an edit race in both orders. If confirmation commits first, the following edit clears it. If editing commits first, confirmation using the old revision is rejected. The table specifies tests to run after implementation. Testing this article’s fixed demonstrations is not the same as passing integration tests of the fictional board.

Change the confirming actor before reusing the template

This handoff assumes one question author decides resolution. A workflow with several required approvers or staff closing on behalf of customers needs a new decision about actors, consent and invalidation. Changing the labels alone does not adapt the policy.

After implementation, count questions receiving answers separately from questions confirmed by authors. Retain clearing reasons and unconfirmed states so the numbers remain explainable. Author confirmation does not establish that another reader solved a similar problem. Agree on the recorded event before interpreting outcomes.

Treat unauthorized confirmation, cross-question answer selection, stale confirmation on edited text and revival through retries as release-blocking defects. Have planning, design, engineering and QA compare this handoff with their documents and distribute the same revised conditions.

Question board — resolution confirmation design and QA handoff
Example: a fictional public question board with existing member identity. One selected answer per question. No rewards, anonymous questions or moderator confirmation on behalf of the author.
Purpose: distinguish receiving a reply from the question author confirming resolution. A first reply, silence or a comment lock never confirms resolution.
Presentation: no answers / answers received, awaiting confirmation / resolution confirmed by the question author. Comments allowed or locked is an independent dimension.
Actor: only the question author selects a currently visible answer to that question. Recheck access and question-answer ownership on the server. Moderators may clear confirmation with a reason or lock comments, but cannot confirm on behalf of the author.
Confirmation: the question must currently be unresolved. Question body revision, selected answer body revision and resolution-state revision must match the viewed values. Check them with visibility, access and membership in one atomic operation, then save the selected answer and confirmed revisions.
Changes: any body edit, hiding or deletion of the question or selected answer clears confirmation, including typo edits. Other answers and comments do not affect it. Restoring content or visibility never restores confirmation automatically.
Clear or replace: author withdrawal and moderator clearing both check the current selection and state revision. Keep the answer and any comment lock. To select a different answer, clear the old confirmation and then review the new answer.
Lock: a comment lock prevents new comments. Author confirmation and withdrawal remain available for visible content. A hidden question or answer is not a comment-lock state.
Concurrency: two different answers selected from the same initial state produce one winner. Show the current result to the losing request without overwriting. Racing confirmation and body editing must never leave an old confirmation attached to changed text.
Retries: the same member's same operation must not create another change, history event or notification. Return the original operation result separately from current state. A later body edit means an old successful request must not revive the resolved badge. Reapply current access to the returned view.
Interface: do not show success before server confirmation. Distinguish success, changed conditions and loss of access. Announce textual results to assistive technology without unnecessary focus changes. Link to the selected answer and offer withdrawal.
Record: question-answer relationship, confirmed revisions, before/after state, actor, time, clearing reason, duplicate-request handling and notification outcome. Do not leak hidden text in errors or notifications. Check retention against the existing policy.
Handoff: planning owns alternatives, permissions and invalidation; design owns states and feedback; engineering owns revisions, atomic changes and retries; QA owns starting states and request order; operations owns clearing reasons and notification failures.
QA: test first answer, inactivity, wrong actor, another question's answer, valid confirmation, edit/hide/delete/restore, unrelated comments, competing selections, edit race, lost-response retry, withdrawal with a retained lock and confirmation while locked. Record actual state and history.
Before reuse: redesign services with multiple resolvers or staff closure. These are a design contract and fixed interface examples, not completed integration tests of a live board.
Example sequence: no answers → first-answer display with one answer → second answer added before competing-selection QA. Additional QA: reject stale withdrawal/moderator clearing after a new choice; do not expose content after hiding/access loss before a retry; notification retries preserve state and do not create duplicate jobs. Compare all 15 acceptance rows with the article.

Sources and example conditions

A fictional design informed by GitHub’s separate answer-selection and locking controls and W3C’s status-feedback principle. Permissions, edits and retry policy are choices for this example, not live service outcomes. AI prompts are unexecuted examples. English and Chinese localize the same Korean case.

GitHub Docs — Moderating discussions

W3C — Understanding SC 4.1.3: Status Messages