# Image Rights Operator GUI Design > This document defines the user-facing GUI/UX shape for the internal image rights review tool. It does not implement a frontend app yet; the current workspace has no frontend framework or design system. ## Goal Give operators one coherent internal workbench where they can review every submitted image, inspect rights-risk evidence, run or retry enrichment, manage the criteria database, correct bad decisions, and control external providers without exposing automated analysis to applicants. ## Product Posture This is an operational review console, not a marketing site. The interface should be dense, calm, audit-friendly, and built for repeated decisions under risk. The first screen should be useful immediately: a review queue with risk-ranked submissions and enough context to choose the next case. ## Visual Thesis Use a quiet, utilitarian dashboard style: neutral surfaces, high contrast text, restrained accent colors for risk and action, compact spacing, stable table/list layouts, and persistent context panels. Avoid decorative hero sections, oversized cards, gradients, or illustrative marketing composition. ## Core Navigation Use a persistent left navigation rail with these primary areas: - Review Queue - Case Review - Evidence Search - Knowledge Base - Corrections - Provider Controls - Audit Log Use a top command bar for global search, current provider mode, queue health, and operator identity. Provider status should be visible but not visually dominant. ## Primary Screens ### 1. Review Queue Purpose: let operators decide what to review next. The queue should be a dense table or split list with: - Thumbnail - Submission ID - Risk score and band - Top two risk reasons - Provider state: internal, Naver, Google, LLM, failed, skipped, pending - Applicant-visible status - Operator decision status - Age / submitted time - Last analysis time Required controls: - Risk band filter: high, medium, low, failed, pending - Source filter: Naver hit, Google hit, fingerprint match, face/person, LLM summary, failed provider - Decision filter: unreviewed, held, rejected, approved, corrected - Sort by risk, newest, oldest, analysis failure, provider failure - Bulk selection only for non-decisive actions such as re-run analysis or assign reviewer; no bulk approve/reject in v1 UX rule: the queue should never require opening every item just to understand why it is high risk. ### 2. Case Review Purpose: let one operator make a final decision on one submitted image. Use a three-pane layout on desktop: - Left pane: image viewer - Center pane: evidence and reasoning - Right pane: decision and case controls Left image pane: - Original/internal review image preview - Zoom, fit, actual size, rotate - Side-by-side thumbnails for visually similar or matching search images - Basic file facts: dimensions, submitted time, analysis version - Clear indication when only an internal derivative is shown Center evidence pane: - Risk score, band, and top reasons at the top - Evidence grouped by source: - Internal fingerprints - Prior rejection similarity - Face/person presence - Naver search results - Google Web Detection results - Internal LLM summary - Failures and skipped providers - Each evidence row should show source, confidence or strength, query if relevant, URL/domain, retrieval time, and whether it contributed to the score - LLM summary must show citations or source chips; source-less claims appear as unverified notes and do not appear as score reasons - Failure states must be visible, not hidden in logs Right decision pane: - Current recommendation: low, medium, high, needs review, failed/partial - Manual action buttons: approve, hold, reject - Required memo on reject and correction - Optional memo on approve/hold - Rejection outcome preview: whether a rejected-image entry or candidate will be added to the knowledge base - Quick actions: - Add entity to knowledge base - Mark evidence irrelevant - Re-run enrichment - Disable stale automatic entry - Open correction flow UX rule: the final decision controls must be visually and functionally separate from the automated recommendation. The UI must make it clear that the system suggests and the operator decides. ### 3. Evidence Search Purpose: let operators inspect and reproduce why search evidence appeared. This screen should show: - Search query history per submission - Naver result list with title, thumbnail, source page, image URL, rank, timestamp - Google Web Detection entities, matching images, pages, and labels - LLM-generated query candidates with execution status - Provider failures, quota skips, disabled-provider states Required controls: - Manual text query run for Naver, subject to policy and quota - Re-run selected query - Mark result as relevant, irrelevant, duplicate, or unsafe - Create knowledge-base candidate from a result UX rule: Naver is text-query search only. The UI must not offer an image upload reverse-search interaction for Naver. ### 4. Knowledge Base Purpose: let operators build and maintain the criteria database that improves future filtering. Main objects: - Celebrity / public figure - Group - Work - Character - Webtoon - Game - Rejected image reference - Other policy-relevant entity Each entity detail should show: - Name - Aliases - Related keywords - Type - Policy memo - Exception conditions - Sample image fingerprints or rejected-image references - Provenance: manual, automatic rejection, search evidence - Active/inactive state - Created from decision or operator entry Required controls: - Create manual entity - Add alias - Add related keyword - Add sample fingerprint from reviewed case - Deactivate entry - Reactivate entry only with memo - View affected future matches or historical matches UX rule: automatic entries and manual entries must look different. Operators should not mistake a rejection-derived entry for a verified policy rule. ### 5. Corrections Purpose: prevent false positives from contaminating future review. This screen should focus on decision lineage: - Corrected decisions - Automatic knowledge entries derived from each decision - Current active/inactive state - Reason for correction - Operator who corrected - Timestamp Required controls: - Correct prior rejection - Deactivate all derived automatic entries - Keep selected derived entries active with memo - Add correction note - Show before/after risk impact for future similar submissions when available UX rule: correction should be a first-class workflow, not a hidden admin cleanup task. ### 6. Provider Controls Purpose: let admins safely operate external and assisted analysis modes. Provider cards or rows: - Internal analysis - Naver search - Google Web Detection - Internal LLM Each provider should show: - Enabled/disabled state - Compliance approval state - Daily quota and usage - Last successful call - Last failure - Data boundary summary - Emergency disable control Required controls: - Disable provider immediately - Set daily limit - View recent failures - Retry failed enrichments - Export provider usage audit UX rule: provider controls are admin-only and should not be mixed into normal operator decision controls. ### 7. Audit Log Purpose: make decisions and evidence changes reviewable. Audit events: - Analysis run created - Provider called/skipped/failed - LLM summary generated - Operator decision created - Rejection-derived entry created - Knowledge entry manually created - Knowledge entry deactivated/reactivated - Correction applied - Provider setting changed Audit rows should include actor, timestamp, object, event type, before/after where relevant, and linked case. ## End-To-End Operator Flow 1. Operator opens Review Queue. 2. Operator filters to high risk or failed analysis. 3. Operator opens a case. 4. Case Review shows image, risk score, top reasons, grouped evidence, and provider state. 5. Operator opens relevant Naver/Google result links or thumbnails. 6. Operator reads LLM summary only as a source-linked digest. 7. Operator approves, holds, or rejects manually. 8. If rejecting, operator confirms memo and knowledge-base accumulation behavior. 9. If later wrong, operator uses Corrections to deactivate derived entries. ## Information Architecture Principles - Queue optimizes prioritization. - Case Review optimizes judgment. - Evidence Search optimizes traceability. - Knowledge Base optimizes future detection quality. - Corrections optimize decontamination. - Provider Controls optimize operational safety. - Audit Log optimizes accountability. ## States And Empty States Every major screen must handle: - No analysis yet - Analysis pending - Internal-only mode - External provider disabled - Provider quota reached - Provider failed - Search returned no result - LLM unavailable - LLM summary unverified - Evidence conflict - Existing corrected decision - Knowledge entry inactive Empty states should be operational, not explanatory marketing copy. Example intent: "No Naver results for this query" with the query and timestamp, not a generic blank panel. ## Interaction Design Recommended controls: - Icon buttons for zoom, rotate, open link, copy URL, retry, disable, history - Segmented controls for risk filters and evidence source filters - Toggle switches for provider enablement - Checkbox selection for bulk queue operations - Menus for secondary actions such as mark irrelevant or create candidate - Textarea with required-state validation for rejection and correction memos - Tabs inside evidence pane only when vertical grouping becomes too long Do not place cards inside cards. Use panels for major layout regions and compact rows for repeated evidence items. ## Accessibility And Safety - All actions must be keyboard reachable. - Focus states must be visible. - Risk cannot be indicated by color alone; include labels such as high, medium, low, failed. - External links open with clear source/domain display. - Destructive or contamination-affecting actions require confirmation and memo. - Applicant-facing surfaces must not be able to render this GUI data. ## Responsive Behavior Primary target is desktop because image comparison and evidence review need space. On tablet: - Queue remains usable. - Case Review becomes two-pane: image/evidence tabs plus decision panel. On mobile: - Allow triage and status checks. - Avoid final reject/correction workflows unless the actual target product requires mobile operations. ## Data Needed From Current Backend The existing backend presenter and evidence model already provide most of the needed data: - Submission ID - Image reference - Score and band - Top reasons - Evidence grouped by source - Provider status - LLM summaries - Manual actions - Knowledge-base provenance - Correction/deactivation hooks Missing for a full GUI integration: - Real user/auth roles - Persistent DB records - Real submission list source - Original image storage and signed URL policy - Actual frontend framework - Admin routing - Audit event store ## Design Acceptance Criteria - An operator can identify the next high-risk case from the queue without opening every case. - An operator can make a final decision from one case screen without jumping between unrelated pages. - Naver, Google, internal, and LLM evidence are visually distinct. - LLM text is never presented as authoritative unless linked to source evidence. - Rejection-derived knowledge-base changes are visible before confirmation. - A wrong rejection can be corrected and its derived automatic entries deactivated. - Provider failures and disabled states are visible to operators and admins. - Applicant-facing views cannot access or display automated evidence. ## Recommended First GUI MVP Build these first: 1. Review Queue 2. Case Review 3. Knowledge-base entry creation from a case 4. Correction flow for rejected decisions 5. Provider Controls read/write for Naver, Google, and LLM enablement Defer these: - Advanced analytics - Bulk approve/reject - Mobile full decision workflow - Dedicated brand/logo detector UI - Applicant-facing explanation or appeal flow ## Implementation Handoff Notes The current repo has no frontend application. The next plan should either: - add a small internal web admin app around the existing Python module, or - integrate this GUI into the actual production app once its framework and routes are available. The second path is preferable if a production admin app already exists elsewhere, because auth, image storage, audit logging, and submission state should follow the real product's conventions.