---
title: "feat: Add Image Rights Risk Filter"
type: feat
status: active
date: 2026-05-25
origin: docs/brainstorms/2026-05-25-image-rights-risk-filter-requirements.md
---

# feat: Add Image Rights Risk Filter

## Summary

Build a new backend rights-filtering subsystem that analyzes submitted images asynchronously, stores structured evidence, computes a 0-100 risk score, and presents recommendations to operators without changing application review status automatically. Because the current workspace has no application source code, this plan defines a portable module layout and integration contracts to adapt into the target app.

---

## Problem Frame

Operators need a first-pass risk filter before submitted images are commercialized. The origin requirements define the product behavior: batch analysis, operator-only recommendations, Korean celebrity/IP priority, no applicant-facing analysis output, and no automatic approval or rejection.

---

## Requirements

- R1. Analyze every submitted image through a batch pipeline. (Origin R1, F1)
- R2. Prioritize celebrity/publicity and copyrighted character/work risks, tuned first for Korean entities, while recording incidental strong evidence for out-of-core categories without building dedicated v1 detectors. (Origin R2, R3, R4)
- R3. Generate exact and perceptual image fingerprints for duplicate, transformed, prior-rejected, and operator-registered sample matching. (Origin R5, AE1)
- R4. Detect face/person presence without identifying specific individuals. (Origin R6, R7, AE2)
- R5. Use external APIs only when content non-retention, metadata logging, and legal/privacy constraints are approved. (Origin R8, R9, R10, R11, AE3)
- R6. Normalize internal and external evidence into a 0-100 risk score plus operator-readable reasons. (Origin R12, R13, R14, R15, AE4, AE5)
- R7. Preserve operator control: the system recommends only; operators choose approved, held, or rejected. (Origin R16, R17, R18, R19, AE6)
- R8. Start with an empty knowledge base and grow it from search evidence, operator registration, and rejected decisions. (Origin R20, R21, R22, R23, R24, AE7, AE8)
- R9. Store risk evidence, analysis versioning, external API usage, operator decisions, and governance-relevant metadata. (Origin R25)
- R10. Apply access, retention, deletion, and correction policy to original images, derivatives, fingerprints, and evidence. (Origin R26)
- R11. Provide usage limits, retry behavior, idempotency, and an external API disable mode. (Origin R27)

**Origin actors:** A1 신청자, A2 운영자, A3 필터링 시스템, A4 외부 이미지 분석 API

**Origin flows:** F1 배치 위험도 분석, F2 운영자 검토, F3 기준 DB 누적

**Origin acceptance examples:** AE1, AE2, AE3, AE4, AE5, AE6, AE7, AE8

---

## Scope Boundaries

- No automatic approval, hold, or rejection status changes.
- No applicant-facing risk score, evidence, or automated reason display.
- No Google Image Search or Google Lens web UI automation or scraping.
- No dedicated v1 detector, tuning, or management surface for global IP, brands, logos, trademarks, or stock-photo theft; incidental strong evidence may still be shown.
- No internal face recognition, celebrity identity matching from face embeddings, or biometric template storage.
- No legal advice or final rights judgment replacement.

### Deferred to Follow-Up Work

- Dedicated brand/logo/trademark/stock-photo detection: separate product iteration after celebrity and character workflows prove useful.
- Advanced model calibration from historical outcomes: future iteration after enough operator decisions are collected.
- Applicant-facing rights-evidence upload workflow: excluded from this internal v1 filter.

---

## Context & Research

### Relevant Code and Patterns

- No application source code, framework files, or tests are present in the current workspace. The only local source artifact is the origin requirements document.
- The paths in this plan define a proposed module layout under `src/rights_filter/` and `tests/rights_filter/`. If the actual application lives elsewhere, adapt these paths to its framework conventions before implementation.

### Institutional Learnings

- No `docs/solutions/` directory or prior local implementation notes were found in this workspace.

### External References

- Google Cloud Vision Data Usage FAQ: online immediate-response operations process image data in memory and do not persist it to disk; asynchronous offline batch operations temporarily persist data. It also notes temporary request metadata logging. https://docs.cloud.google.com/vision/docs/data-usage
- Google Cloud Vision Web Detection: returns web entities, full matching images, visually similar images, pages with matching images, and best guess labels that can become operator evidence. https://docs.cloud.google.com/vision/docs/detecting-web
- Google Cloud Vision Face Detection: detects faces and attributes, but specific individual facial recognition is not supported. https://docs.cloud.google.com/vision/docs/detecting-faces

---

## Key Technical Decisions

- Modular pipeline over inline review logic: keep collection, analysis, scoring, evidence storage, and operator presentation as separate boundaries so the filter can run asynchronously and be disabled safely.
- Fingerprint-first internal analysis: compute exact file hash plus perceptual image fingerprints before external calls so duplicates, retries, and rejected-image matches do not depend on third-party availability.
- Face/person detection is a risk signal, not identity evidence: it can raise review attention but must not become a celebrity-recognition system.
- Cloud Vision is an optional synchronous adapter: only use online `WEB_DETECTION`, never asynchronous offline batch, and only when compliance settings mark it approved.
- Evidence ledger is append-oriented: each analysis run records version, inputs used, evidence sources, and score components so operators can audit why a recommendation changed.
- Failed analysis adds uncertainty, not exculpation: failures become review reasons and must not lower already-detected high-risk evidence.
- Knowledge base entries carry provenance: automatic entries from rejections and manual entries from operators remain distinguishable and reversible.

---

## Open Questions

### Resolved During Planning

- Hashing strategy: use an exact content hash plus at least one perceptual fingerprint; final algorithm and thresholds are implementation choices validated by tests and sample data.
- Face/person strategy: use local or approved internal detection for presence only; do not store face embeddings or identify individuals.
- Google strategy: integrate as a disabled-by-default adapter gated by compliance configuration and usage limits.
- Score strategy: use a configurable weighted model that records component reasons rather than a hidden monolithic score.
- Data governance strategy: make original files, derivatives, fingerprints, and evidence all policy-managed data classes.

### Deferred to Implementation

- Exact application framework integration points: no app code exists in this workspace, so implementers must adapt proposed paths to the real app.
- Final perceptual hash algorithm, similarity thresholds, and score weights: tune against pilot samples and operator feedback.
- Exact face/person detector package or service: choose based on the target stack, runtime environment, and privacy constraints.
- Final retention durations and access roles: confirm with legal/privacy stakeholders before production rollout.
- Cloud Vision contract details, DPA, region, and metadata logging controls: confirm before enabling external API calls.

---

## Output Structure

    src/
      rights_filter/
        domain/
        analysis/
        integrations/
        jobs/
        admin/
        governance/
    tests/
      rights_filter/
    docs/
      operations/

The tree is the expected module shape for a new backend subsystem. The implementer may adjust it to match the actual application framework while preserving the boundaries and test coverage below.

---

## High-Level Technical Design

> *This illustrates the intended approach and is directional guidance for review, not implementation specification. The implementing agent should treat it as context, not code to reproduce.*

```mermaid
flowchart TB
  Submission[Submitted image] --> Batch[Batch analyzer]
  Batch --> Preprocess[Derivative and EXIF cleanup]
  Preprocess --> Internal[Internal fingerprints and face/person signals]
  Preprocess --> ExternalGate{External API allowed?}
  ExternalGate -->|yes| WebDetect[Cloud Vision web detection]
  ExternalGate -->|no| Skipped[External evidence skipped]
  Internal --> Evidence[Evidence ledger]
  WebDetect --> Evidence
  Skipped --> Evidence
  Evidence --> Scoring[Risk scoring]
  Scoring --> Operator[Operator review surface]
  Operator --> Decision[Approved / Held / Rejected]
  Decision --> Knowledge[Knowledge base updates]
  Knowledge --> Internal
```

---

## Implementation Units

```mermaid
flowchart TB
  U1[U1 Persistence and records]
  U2[U2 Image preprocessing]
  U3[U3 Internal analysis]
  U4[U4 Knowledge base]
  U5[U5 External API adapter]
  U6[U6 Evidence and scoring]
  U7[U7 Batch orchestration]
  U8[U8 Operator review integration]
  U9[U9 Governance and operations]

  U1 --> U2
  U1 --> U4
  U2 --> U3
  U2 --> U5
  U3 --> U6
  U4 --> U6
  U5 --> U6
  U6 --> U7
  U6 --> U8
  U8 --> U4
  U1 --> U9
  U7 --> U9
```

### U1. Persistence and Domain Records

**Goal:** Create the persistent model layer for analysis runs, evidence, risk scores, knowledge-base entries, operator decisions, and governance metadata.

**Requirements:** R1, R8, R9, R10; F1, F2, F3

**Dependencies:** None

**Files:**
- Create: `src/rights_filter/domain/records.*`
- Create: `src/rights_filter/domain/repositories.*`
- Create: `src/rights_filter/domain/policies.*`
- Create: `db/migrate/*rights_filter*`
- Test: `tests/rights_filter/domain/test_records.*`
- Test: `tests/rights_filter/domain/test_repositories.*`

**Approach:**
- Model each analysis as an immutable run with a version, source image reference, input classes used, evidence entries, score result, and failure reasons.
- Store evidence as structured records grouped by source: fingerprint, face/person signal, web entity, matching image URL, prior rejection, operator manual entry, and failure.
- Represent knowledge-base entries with type, provenance, active state, policy memo, exception notes, and links back to source decisions or manual registrations.
- Keep original image storage references separate from derived image references and fingerprints so governance policy can treat them independently.

**Patterns to follow:**
- No local app patterns exist. Follow the target application's existing persistence, migration, repository, and test conventions when integrating.

**Test scenarios:**
- Happy path: creating an analysis run with multiple evidence sources persists all evidence and returns the latest score for the submitted image.
- Happy path: manual and automatically generated knowledge-base entries are distinguishable by provenance.
- Edge case: an inactive knowledge-base entry is retained for audit but excluded from future matching.
- Edge case: a corrected operator decision records new state without deleting prior evidence.
- Error path: invalid evidence without a source, timestamp, or analysis run is rejected.
- Integration: rejected operator decision creates a linkable source for future knowledge-base entries.

**Verification:**
- The data layer can represent every origin evidence type without storing face biometric templates.
- The same submitted image can have multiple versioned analysis runs without overwriting prior audit data.

### U2. Image Preprocessing and Derivative Handling

**Goal:** Produce safe analysis derivatives from internally stored originals: EXIF-stripped resized images for external APIs, and normalized internal inputs for hashing/detection.

**Requirements:** R5, R10; AE3, AE8

**Dependencies:** U1

**Files:**
- Create: `src/rights_filter/analysis/preprocessing.*`
- Create: `src/rights_filter/analysis/derivatives.*`
- Create: `src/rights_filter/governance/data_classes.*`
- Test: `tests/rights_filter/analysis/test_preprocessing.*`
- Test: `tests/rights_filter/governance/test_data_classes.*`

**Approach:**
- Define data classes for original image, analysis derivative, external derivative, fingerprint, web evidence, and operator note.
- Strip EXIF and cap external derivative resolution before any external API call.
- Ensure preprocessing is deterministic enough for idempotent retries but does not mutate the internal original.
- Track derivative lifecycle so generated files can be cleaned up according to retention policy.

**Patterns to follow:**
- Use the target app's existing file storage and background temp-file cleanup patterns if available.

**Test scenarios:**
- Happy path: a high-resolution image produces an EXIF-free external derivative under the configured maximum size.
- Happy path: internal original storage reference remains unchanged after derivative creation.
- Edge case: an image already below the maximum size is still EXIF-stripped before external use.
- Error path: corrupt image input records a preprocessing failure reason and does not produce a misleading low-risk result.
- Integration: generated derivatives are associated with the correct analysis run and data class.

**Verification:**
- No external adapter can receive a file that bypassed the derivative policy.

### U3. Internal Fingerprint and Face/Person Analysis

**Goal:** Implement internal analysis signals: exact duplicate hash, perceptual image fingerprints, and face/person presence detection without identity recognition.

**Requirements:** R3, R4, R6; AE1, AE2, AE8

**Dependencies:** U1, U2

**Files:**
- Create: `src/rights_filter/analysis/fingerprints.*`
- Create: `src/rights_filter/analysis/face_person_detection.*`
- Create: `src/rights_filter/analysis/internal_analyzer.*`
- Test: `tests/rights_filter/analysis/test_fingerprints.*`
- Test: `tests/rights_filter/analysis/test_face_person_detection.*`
- Test: `tests/rights_filter/analysis/test_internal_analyzer.*`

**Approach:**
- Compute exact content hashes for repeat upload and idempotency checks.
- Compute perceptual fingerprints suitable for resize, compression, and modest crop/transform matching.
- Compare fingerprints against prior rejected images and active sample entries in the knowledge base.
- Detect face/person presence as a reason component only; do not identify a person, store face embeddings, or compare faces across images.

**Execution note:** Implement behavior test-first around the privacy boundary: face detection can emit count/presence evidence, but cannot emit identity or biometric template artifacts.

**Patterns to follow:**
- Use approved local libraries or internal services that can operate without sending original images to unapproved third parties.

**Test scenarios:**
- Covers AE1. Happy path: a resized or recompressed copy of a prior rejected image produces a high-similarity evidence reason.
- Covers AE2. Happy path: a normal face-containing image records face/person presence but does not become high risk without stronger celebrity/IP evidence.
- Edge case: no-face images produce no face/person risk reason.
- Error path: detector failure records an analysis failure reason and does not lower other high-risk evidence.
- Privacy: face/person analysis output contains no identity label, face embedding, or biometric template.
- Integration: internal evidence feeds U6 score components with source and confidence metadata.

**Verification:**
- Internal analysis can run with external API disabled and still produce useful duplicate, rejection, and face/person evidence.

### U4. Operator Knowledge Base

**Goal:** Build management and matching support for manual risk entities and automatic rejected-image accumulation.

**Requirements:** R8, R10; F3, AE7, AE8

**Dependencies:** U1

**Files:**
- Create: `src/rights_filter/domain/knowledge_base.*`
- Create: `src/rights_filter/admin/knowledge_base_handlers.*`
- Create: `src/rights_filter/admin/knowledge_base_views.*`
- Test: `tests/rights_filter/domain/test_knowledge_base.*`
- Test: `tests/rights_filter/admin/test_knowledge_base_handlers.*`

**Approach:**
- Support entity records for celebrity, group, work, character, webtoon, game, and other policy-relevant types.
- Store names, aliases, related keywords, image-level sample fingerprints, policy memo, exception conditions, active state, and provenance.
- Automatically add rejected image fingerprints as matching references while distinguishing them from operator-created entries.
- Provide correction and deactivation flows so bad rejections or bad samples do not keep poisoning future scores.

**Patterns to follow:**
- Match target app admin patterns for CRUD, audit fields, and permission checks.

**Test scenarios:**
- Happy path: operator creates a Korean celebrity entity with aliases, sample fingerprints, memo, and exception notes.
- Happy path: a rejected decision creates an automatic reference that participates in future similarity matching.
- Edge case: deactivating an automatic reference removes it from matching but preserves audit history.
- Edge case: manual and automatic entries with similar names remain separate provenance classes.
- Error path: attempting to upload a face biometric template or identity embedding is rejected by policy validation.
- Integration: U3 matching can query only active entries while U8 can show both active and inactive history.

**Verification:**
- The knowledge base can start empty and become useful through operator decisions and registrations without requiring seed data.

### U5. External Web Detection Adapter

**Goal:** Integrate Google Cloud Vision `WEB_DETECTION` as a compliance-gated, synchronous, disabled-by-default adapter.

**Requirements:** R5, R6, R11; AE3, AE4

**Dependencies:** U1, U2

**Files:**
- Create: `src/rights_filter/integrations/external_policy.*`
- Create: `src/rights_filter/integrations/cloud_vision_web_detection.*`
- Create: `src/rights_filter/integrations/web_detection_result_mapper.*`
- Test: `tests/rights_filter/integrations/test_external_policy.*`
- Test: `tests/rights_filter/integrations/test_cloud_vision_web_detection.*`
- Test: `tests/rights_filter/integrations/test_web_detection_result_mapper.*`

**Approach:**
- Gate all external calls behind explicit compliance configuration that records approval status, allowed operation type, metadata logging acceptance, and usage limits.
- Send only EXIF-stripped external derivatives, never internal originals.
- Use only synchronous online web detection; do not use asynchronous offline batch operations.
- Normalize web entities, best guess labels, full/partial/visually similar images, and pages with matching images into evidence records.
- Store call outcome, source, failure reason, and quota state without storing returned content beyond operational evidence needed by the origin requirements.

**Execution note:** Start with adapter contract tests using a fake client so disabled-mode, failure-mode, and evidence mapping are correct before enabling real credentials.

**Patterns to follow:**
- Follow target app secrets management and outbound HTTP client patterns.

**Test scenarios:**
- Covers AE3. Happy path: when compliance is approved and API is enabled, only the external derivative is sent and mapped evidence is stored.
- Covers AE3. Disabled mode: when compliance is not approved or external mode is disabled, no outbound call occurs and internal scoring continues.
- Happy path: web entities and matching-image URLs become operator-readable evidence reasons.
- Edge case: incidental global IP evidence is stored as evidence but does not activate dedicated brand/global-IP workflows.
- Error path: API timeout, quota exhaustion, or provider error records a failure reason and leaves existing high-risk evidence intact.
- Policy: attempting to call asynchronous offline batch mode is blocked by adapter policy.

**Verification:**
- External API can be switched off without breaking the batch pipeline.
- Provider results are auditable but not treated as final legal decisions.

### U6. Evidence Normalization and Risk Scoring

**Goal:** Combine internal analysis, external web evidence, knowledge-base matches, failures, and prior decisions into a transparent 0-100 risk score with reason components.

**Requirements:** R2, R3, R4, R6; F1, F2, AE1, AE2, AE4, AE5

**Dependencies:** U1, U3, U4, U5

**Files:**
- Create: `src/rights_filter/analysis/evidence_normalizer.*`
- Create: `src/rights_filter/analysis/risk_scoring.*`
- Create: `src/rights_filter/analysis/reason_builder.*`
- Test: `tests/rights_filter/analysis/test_evidence_normalizer.*`
- Test: `tests/rights_filter/analysis/test_risk_scoring.*`
- Test: `tests/rights_filter/analysis/test_reason_builder.*`

**Approach:**
- Define score bands for low, medium, and high risk while keeping the raw 0-100 score visible to operators.
- Use component reasons such as prior rejection similarity, active sample match, web entity strength, matching URL evidence, face/person presence, and analysis failure.
- Treat face/person presence as a modest signal unless combined with stronger celebrity/IP evidence.
- Treat fanart and AI-style images as high risk only when supported by strong entity, work, character, URL, or similarity evidence.
- Ensure failures add uncertainty/review reasons without reducing other risk components.
- Version the scoring model so score changes remain explainable.

**Patterns to follow:**
- Prefer a small configurable scoring table over hard-coded branching spread across analyzers.

**Test scenarios:**
- Covers AE1. Prior rejected-image similarity raises risk and produces a clear reason.
- Covers AE2. Face/person presence alone stays below high risk.
- Covers AE4. Character/work web evidence plus matching-image evidence can produce high risk for non-photo fanart or AI-style images.
- Covers AE5. External API failure adds a failure reason but does not lower an existing high-risk similarity match.
- Edge case: conflicting evidence is preserved in reasons rather than collapsed into an unexplained score.
- Regression: changing scoring version does not mutate historical analysis run results.

**Verification:**
- Operators can read the top reasons and understand why the score was low, medium, or high without inspecting raw provider payloads.

### U7. Batch Orchestration, Idempotency, and Operations

**Goal:** Run the analysis pipeline across all submitted images with retries, usage limits, idempotency, and partial-failure handling.

**Requirements:** R1, R5, R6, R9, R11; F1, AE3, AE5

**Dependencies:** U1, U2, U3, U5, U6

**Files:**
- Create: `src/rights_filter/jobs/batch_analyzer.*`
- Create: `src/rights_filter/jobs/analysis_worker.*`
- Create: `src/rights_filter/jobs/retry_policy.*`
- Create: `src/rights_filter/jobs/usage_limits.*`
- Test: `tests/rights_filter/jobs/test_batch_analyzer.*`
- Test: `tests/rights_filter/jobs/test_analysis_worker.*`
- Test: `tests/rights_filter/jobs/test_retry_policy.*`
- Test: `tests/rights_filter/jobs/test_usage_limits.*`

**Approach:**
- Select submitted images that need initial or version-triggered analysis, avoiding duplicate work for the same image and scoring version.
- Run internal analysis for every eligible image; run external web detection only when policy and usage limits allow it.
- Record partial failures per source so one failed provider does not invalidate the whole run.
- Provide retry behavior for transient errors and terminal failure reasons for persistent errors.
- Emit operational counters for processed, skipped, failed, externally called, externally skipped, and limit-exhausted items.

**Patterns to follow:**
- Use target app background job, scheduler, queue, and observability conventions.

**Test scenarios:**
- Happy path: all pending submissions receive analysis runs and score results.
- Happy path: re-running the batch does not duplicate analysis when inputs and scoring version have not changed.
- Edge case: external API usage limit is reached; remaining images still receive internal-only analysis and external-skipped reasons.
- Error path: corrupt images and transient provider failures produce failure reasons and retry behavior according to policy.
- Integration: batch execution creates evidence records, risk score records, and operator-visible summaries for each processed image.

**Verification:**
- The batch can run safely on a schedule and can be paused or degraded to internal-only mode without data loss.

### U8. Operator Review Integration

**Goal:** Expose risk scores, reasons, evidence, and final operator decisions to the internal review workflow without showing automated analysis to applicants.

**Requirements:** R6, R7, R9; F2, F3, AE6, AE7

**Dependencies:** U1, U4, U6

**Files:**
- Create: `src/rights_filter/admin/review_handlers.*`
- Create: `src/rights_filter/admin/review_presenters.*`
- Create: `src/rights_filter/admin/decision_feedback.*`
- Test: `tests/rights_filter/admin/test_review_handlers.*`
- Test: `tests/rights_filter/admin/test_review_presenters.*`
- Test: `tests/rights_filter/admin/test_decision_feedback.*`

**Approach:**
- Add operator-facing access to score, band, top reasons, evidence links, external API usage marker, and analysis failures.
- Keep the status action separate: operators explicitly choose approved, held, or rejected.
- Ensure applicant-facing surfaces cannot read risk score, evidence, automated reasons, or provider details.
- On rejection, trigger knowledge-base accumulation of image fingerprints and provenance for future matching.
- Allow operator memo and correction flows to update decisions and mark derived knowledge-base entries for deactivation review.

**Patterns to follow:**
- Match target app admin authorization, audit logging, and review-state transition patterns.

**Test scenarios:**
- Covers AE6. A high-risk score appears to operators but does not change application status automatically.
- Covers AE6. Applicant-facing endpoints or views do not expose score, evidence, or automatic reasons.
- Covers AE7. Rejection creates automatic knowledge-base reference with source decision provenance.
- Edge case: corrected rejection can mark derived reference entries as inactive or requiring operator review.
- Error path: missing or failed analysis is shown as a review reason rather than hiding the submission from the queue.
- Integration: operator review surface can display internal-only, external-enriched, and partial-failure analysis runs consistently.

**Verification:**
- Operators can make final decisions from the evidence view while automated analysis remains internal-only and non-authoritative.

### U9. Governance, Retention, and Runbooks

**Goal:** Add policy enforcement, operational controls, and documentation for sensitive image data, derivatives, fingerprints, evidence, external API usage, and corrections.

**Requirements:** R5, R9, R10, R11; AE3, AE8

**Dependencies:** U1, U2, U5, U7, U8

**Files:**
- Create: `src/rights_filter/governance/retention_policy.*`
- Create: `src/rights_filter/governance/access_policy.*`
- Create: `src/rights_filter/governance/correction_policy.*`
- Create: `docs/operations/image-rights-risk-filter.md`
- Test: `tests/rights_filter/governance/test_retention_policy.*`
- Test: `tests/rights_filter/governance/test_access_policy.*`
- Test: `tests/rights_filter/governance/test_correction_policy.*`

**Approach:**
- Define policy-managed classes for original images, external derivatives, internal derivatives, fingerprints, evidence, provider metadata, and operator notes.
- Enforce access boundaries for operator-only analysis output.
- Provide retention and deletion hooks that can be wired to the target app's storage cleanup mechanisms.
- Document external API enablement prerequisites: contract/DPA review, metadata logging acceptance, region/credential policy, quota limits, and rollback to internal-only mode.
- Document what the system is not allowed to do: no scraping, no applicant exposure, no face recognition, no biometric template store, no automatic status change.

**Patterns to follow:**
- Use target app policy, permission, and runbook conventions.

**Test scenarios:**
- Happy path: each data class has an assigned policy for access, retention, deletion, and correction handling.
- Covers AE3. External API cannot be enabled until required compliance settings are present.
- Covers AE8. A sample image entry stores image-level fingerprint evidence but no face biometric template.
- Edge case: deleting or correcting a source decision marks dependent automatic knowledge-base entries for deactivation handling.
- Error path: unauthorized access to operator-only evidence is denied and audited.
- Operational: disabling external API mode causes the batch to continue internal-only and records skipped-external reasons.

**Verification:**
- A deployer has enough runbook detail to enable, disable, audit, and roll back the filter safely.

---

## System-Wide Impact

- **Interaction graph:** The subsystem touches image submission storage, background job scheduling, external outbound API configuration, operator review, and decision feedback.
- **Error propagation:** Source-specific failures become evidence reasons and operational counters, not silent success or low-risk results.
- **State lifecycle risks:** Analysis runs are versioned; rejected decisions can create derived knowledge-base entries; corrected decisions must not leave stale active references behind.
- **API surface parity:** Operator-only review surfaces may read scores and evidence; applicant-facing surfaces must not.
- **Integration coverage:** Batch-to-evidence-to-score-to-review-to-knowledge-base feedback must be tested as a full flow.
- **Unchanged invariants:** Existing submission and operator decision status semantics remain authoritative; the filter never changes status directly.

---

## Risks & Dependencies

| Risk | Mitigation |
|------|------------|
| External API data terms are misunderstood | Keep external adapter disabled until contract, DPA, content retention, request metadata logging, region, and credential controls are approved. |
| False positives poison future matching | Keep provenance, deactivation, correction, and audit trails for all automatic rejected-image entries. |
| Face/person detection drifts into identity recognition | Validate output shape, forbid face embeddings/biometric templates, and document the boundary in governance policy. |
| Batch costs grow unexpectedly | Add usage limits, idempotency, external disable mode, and processed/skipped/failed counters. |
| Operators over-trust scores | Present reasons and evidence, keep final decision manual, and label provider output as evidence rather than legal judgment. |
| Actual application stack differs from proposed paths | Adapt module paths to the real app before implementation while preserving unit boundaries and tests. |

---

## Alternative Approaches Considered

- External-search-only filter: rejected because it would create unnecessary third-party dependency and weaker behavior when API use is disabled.
- Local-only filter: rejected for v1 because the knowledge base starts empty and would miss many celebrity/IP references before operator data accumulates.
- Automatic hold/reject workflow: rejected by origin requirements because operator judgment must remain authoritative.
- Face-recognition or celebrity-identification model: rejected because the origin explicitly excludes specific individual face recognition and biometric template storage.

---

## Phased Delivery

### Phase 1: Internal foundation

- Land U1, U2, U3, and the internal-only path through U6.
- Operators can see internal duplicate/rejection/face-person/failure reasons with no external API dependency.

### Phase 2: Knowledge and review loop

- Land U4 and U8 so operator decisions create reusable knowledge and correction paths.

### Phase 3: External enrichment

- Land U5 after compliance approval, then connect it through U6 and U7 with usage limits.

### Phase 4: Governance hardening

- Land U9 runbooks, retention hooks, access tests, and production enablement checklist before external API rollout.

---

## Documentation / Operational Notes

- Document how to run the system in internal-only mode and how to disable external calls immediately.
- Document the Cloud Vision approval checklist, including online synchronous-only usage and metadata logging review.
- Document how operators should interpret low, medium, and high scores without treating them as legal conclusions.
- Document how to deactivate or correct automatically generated knowledge-base references after an erroneous rejection.
- Document retention classes for originals, derivatives, fingerprints, provider evidence, and operator notes.

---

## Sources & References

- **Origin document:** [docs/brainstorms/2026-05-25-image-rights-risk-filter-requirements.md](docs/brainstorms/2026-05-25-image-rights-risk-filter-requirements.md)
- Google Cloud Vision Data Usage FAQ: https://docs.cloud.google.com/vision/docs/data-usage
- Google Cloud Vision Web Detection: https://docs.cloud.google.com/vision/docs/detecting-web
- Google Cloud Vision Face Detection: https://docs.cloud.google.com/vision/docs/detecting-faces
