• Who is the project for, and what task should it help with?
• What goes in, and what comes out?
• Which tools, models, or services are involved?
• What works today, and what is still planned?
• Where does a person review or approve the output?
• What kind of feedback would be useful right now?

A short workflow description is welcome if you do not have a public demo. Use sanitized screenshots or synthetic sample data when sharing an example.

If you report results, explain how you measured them. Disclose your connection to any product or commercial link you share, and keep the discussion focused on the implementation.

Share a small walkthrough covering:

• The AI-produced item the reviewer sees.
• The source information available for comparison.
• The criteria for approving, editing, or rejecting it.
• What happens when information is missing or uncertain.
• How the reviewer records a decision and requests another attempt.

A wireframe, checklist, or sanitized screenshot is enough. Label proposed interfaces as proposals and working interfaces as implemented.

If you have evaluated the review process, explain the task, sample size, and method. Otherwise, describe what you would measure first. What is one decision you deliberately keep with a person, and how does your interface make that decision clear?

• Goal: What the workflow was meant to do.
• Symptom: What failed and how you noticed.
• Evidence: The logs, outputs, or observations you examined.
• Investigation: What you tested, including unsuccessful attempts.
• Change: What you modified and why.
• Verification: How you checked the result and what remains uncertain.

Keep private data and credentials out of examples. If the issue is unresolved, say so and identify the next observation you need.

Replies should distinguish a confirmed cause from a plausible explanation. A useful lesson can be a better test or recovery procedure even when the project is still unfinished.