QA Partner Handbook

Welcome. This handbook is for vetted operators in PiktID's official QA pool. We route work to you when a client pays for managed review or retouch. If you're reading this, you've signed our partner agreement and your team is in the pool. This document is the single operational reference you need.

This guide is operational only. Rates, invoicing cadence, throughput commitments, and contractual SLAs live in your partner agreement with PiktID. If anything below conflicts with that agreement, the agreement wins.

Contents

1. On-Model and the managed-service tier
2. Your role as a pool member
3. Onboarding and pool membership
4. How jobs reach you
5. Reviewer workflow
6. Retoucher workflow
7. Combined Review + Retouch
8. Concurrency and the claim system
9. Quality bar and annotation taxonomy
10. Throughput and operational expectations
11. Confidentiality, IP, and data handling
12. Troubleshooting and FAQ
13. Support and escalation
14. Glossary
15. Document changelog

---

1. On-Model and the managed-service tier

On-Model is PiktID's AI image platform for fashion e-commerce. Brands and retailers generate model-swap, flat-to-model, and packshot imagery at scale. Every output passes through a Review step before delivery, and any flagged output goes through a Retouch step.

Clients choose one of three tiers for each of these steps:

• Self: the client does the work themselves.
• External: the client invites a specific reviewer or retoucher they already know.
• Managed: PiktID handles it via the official partner pool. You are the managed tier.

When a client buys managed service, they are paying PiktID for a guaranteed turnaround, a guaranteed quality bar, and operators they don't have to recruit, train, or manage. Your job is to deliver on that promise. The client may never see your name; they see PiktID's name and PiktID's quality.

The lifecycle a managed job touches:

Generation → Review → (Retouch → Re-review)* → Approved → Delivered

Generation and delivery are automated. Everything in between is where the pool operates.

Vocabulary you'll see

• Job: the unit of work. Holds many images.
• Image / image index: one image inside a job. Stable position; versions stack.
• Version: n-th iteration of an image. Retouches always produce a new version.
• Output: the image the AI (or a retoucher) produced for review.
• Verdict: a reviewer's decision, either Approve or Needs Retouch.
• Annotations: structured feedback on a "Needs Retouch" verdict.

---

2. Your role as a pool member

You operate as PiktID's hands. That means:

• You enforce PiktID's quality bar, not the client's preferences. The bar is in §9; it does not bend per client unless your partner agreement explicitly says so.
• You do not communicate directly with the client. PiktID is the buffer. Questions about a job go through your partner ops contact at PiktID; PiktID asks the client if needed.
• Your output reflects on PiktID. Every approved image and every retouched file is something PiktID is shipping under our brand promise. Operate accordingly.
• You are accountable to PiktID for throughput and quality. SLAs and metrics live in your partner agreement; see §10.

In return, PiktID provides:

• A steady, prioritized flow of work routed automatically. No hunting for clients.
• A consistent platform, taxonomy, and quality bar so you can train operators once.
• Direct support, escalation, and product-team contact when something breaks or improves.
• Standardized confidentiality and IP terms so you don't negotiate per-client.

---

3. Onboarding and pool membership

Joining the pool

Pool membership requires:

1. A signed partner agreement and NDA with PiktID. Your partner ops contact handles execution.
2. Operator-level access provisioning. You provide PiktID with the email addresses of every operator who will review or retouch. Each gets added to the pool as a named identity, so PiktID can audit individual operator actions.
3. A calibration round before you're routed live work. We send a small batch of representative images so you can verify your tooling and we can verify your output against our bar.

You stay in the pool as long as your throughput, quality, and confidentiality compliance meet the terms in your agreement. We review pool membership periodically; the cadence is in the agreement.

Adding or removing operators

• To add an operator, send their full name and work email to your partner ops contact. We do not allow shared logins; every operator is a named pool member.
• To remove an operator (off-boarding, role change), tell your partner ops contact same-day. We revoke access immediately. Their historical actions remain in the audit log under their name.

---

4. How jobs reach you

When a client purchases managed review or managed retouch:

1. The platform creates the review session(s) for the job and assigns them to every operator in the relevant pool. There is no per-job routing decision from PiktID staff; it's automatic.
2. Each operator receives an email notification: subject line begins with "Review request" or "Retouch request" followed by the job ID. Sender is @piktid.com.
3. The email contains a secure link of the form /review/<token>. Each operator gets their own token.
4. Operators open the link, or log into On-Model and open the Review Portal from the sidebar. New work appears under the Assignments tab (see §5.1).

There is no central queue you have to monitor. The portal is the queue. Operators open the email and start working.

Multiple operators, same job

This is the common case. All your operators see the same job in their portal. The claim system (§8) prevents collisions: when one operator opens an image, it locks under their name until they release it or go idle for an hour. Other operators just pick a different unclaimed image.

Throughput pacing

You don't need to claim everything immediately. Other partners in the pool may also have access to the same job if the client's volume is large enough. Operate to your committed throughput; unclaimed images that other partners pick up are fine.

If you're consistently leaving images unclaimed at job-deadline time, that's a signal to your partner ops contact. Either your committed throughput is too low for the work being routed, or routing logic needs tuning.

---

5. Reviewer workflow

This section is prescriptive. The pool ships consistent verdicts; consistency comes from doing the same thing each time.

5.1 The Review Portal

Open Review Portal from the On-Model sidebar after you log in. The portal has two tabs at the top:

• My Requests: jobs you created yourself. Not relevant for pool operators.
• Assignments: jobs routed to you for review or retouch. This is your workspace.

The Assignments tab shows a five-card stats strip at the top (Total Jobs, Approved, Needs Fix, Retouching, Pending) and one card per active job. Each card displays the job ID, type (Model Swap, Flat to Model, Create Packshot), image count, who requested it, your role on the job (Review Only, Retouch Only, Review & Retouch), expiry, and a progress bar.

Use the All and All Roles filters to narrow the list. Cards are sorted newest-first by default.

5.2 The review session

Clicking a job card from Assignments opens the review session for that job: a single workspace where you handle every image in the job. There is no intermediate grid page; the thumbnail strip is your navigation.

The layout has five parts:

• Top bar: breadcrumb back to the portal, live status pills (approved, needs fix, pending, total images), and the job expiry on the right.
• Left thumbnail strip: every image in the job. Click a thumbnail to switch. Each thumbnail carries a status indicator so you can see your progress at a glance.
• Main canvas: the currently selected image at full size, with zoom controls.
• Right sidebar: two tabs, Review and Details. The Review tab is where you make verdicts (Approve, Flag Issues, Overall Notes); Details holds metadata about the image.
• Bottom bar: counter for images you've marked so far, plus the Submit All Reviews button.

A note on UI terminology: the button reads Flag Issues and the status pill reads Needs Fix, but both refer to the same verdict the rest of this handbook calls Needs Retouch (the underlying name for the retouch workflow in §6).

5.3 Picking an image and claiming it

Click any unclaimed thumbnail in the left strip. The portal places a per-image review claim under your operator name. The claim refreshes automatically on every interaction (zoom, scroll, draft save) and expires after one hour of inactivity.

If a thumbnail shows Claimed by <another operator>, pick a different image. Do not work on claimed images, even within your own team, since duplicate verdicts pollute the audit log.

5.4 The image viewer (main canvas)

The main canvas shows the currently selected output image at full resolution. Zoom and pan to inspect detail. If the image has prior versions (because a retouch already happened), use the version controls to compare against earlier outputs. Input images (source garment, identity reference, pose hints) are accessible via the Details tab in the right sidebar.

5.5 Making a verdict (drafts)

In the Review tab of the right sidebar, click Approve or Flag Issues.

• Approve when the image meets the quality bar in §9.
• Flag Issues when there's a specific, addressable defect. Annotations required (see §5.6).

Verdicts are drafts until you submit the session. Marking an image updates the thumbnail strip and header counters, but the decision is not committed yet; you can revisit any image and change your mark before final submission. This is the source of the bottom bar's "N images marked for review" counter.

5.6 Annotations (required when flagging)

When you click Flag Issues, the Issue Categories panel becomes the active input. The form has:

1. Issue Categories: multi-select from the nine-category taxonomy (Artifact, Shadow, Logo, Skin Tone, Background, Garment Distortion, Pose, Lighting, Other). See §9 for definitions.
2. Per-category notes: as you tick a category, a note field appears for it. Be specific, localized, actionable.
3. Overall Notes: anything that doesn't fit a single category.

The retoucher reads your notes and never speaks to you. Vague notes produce slow, expensive retouches. Operate to the standard in §9.

5.7 Submitting the session

Once you've marked every image in the job (or every image you intend to mark this session), click Submit All Reviews in the bottom-right. This commits every draft verdict at once. Approved images move toward delivery; flagged images queue for retouch (§6).

After submission, verdicts are immutable; the audit log is append-only. You cannot edit a verdict after Submit All Reviews has been clicked. Submitted annotations remain visible in the right sidebar when you revisit the image, which is useful when the retouch loop starts.

5.8 If you submit an incorrect verdict

You cannot undo. Escalate to your partner ops contact at PiktID. We can request a reset from the job owner (the client) on your behalf. Do not contact the client directly.

If you discover a systemic mistake (e.g. an operator misread the brief and approved a batch incorrectly), tell partner ops same-day. Bulk resets are possible.

5.9 Re-reviewing retouched images

When a retoucher uploads a corrected version of a flagged image (§6), that image returns to the Pending queue. You (or another pool reviewer) re-check it using the same flow as a fresh review: open the image, Approve or Flag Issues, Submit All Reviews when done.

The loop can repeat. If you flag the retouched image again, the retoucher fixes the new issues and uploads another version, which returns to the Pending queue for re-review. The job isn't done until every image is Approved.

---

6. Retoucher workflow

6.1 Your Assignments tab (retoucher view)

Retouch tasks are created automatically when a reviewer flags an image. To find them, open Review Portal → Assignments. Job cards look the same as the reviewer view (§5.1), but the status pills reflect the retoucher's perspective:

• Needs Retouch (orange): the reviewer flagged one or more images. Ready for you to work on.
• Awaiting Review (blue): the reviewer hasn't acted yet. Nothing to do until they flag at least one image.
• Retouching: you or another pool retoucher has claimed images on this job.
• Done (green): every image is approved. No more work here.

A card may also show a small in-progress banner (e.g. Being reviewed by Review) when the reviewer is mid-session. That's context only; it does not block you from acting on images the reviewer has already flagged.

Click a Needs Retouch card to enter that job's retouch session.

6.2 Read the reviewer's notes, then Start Retouch

Clicking a Needs Retouch job card opens the retouch session. Layout mirrors the review session: thumbnail strip on the left, main canvas in the center, sidebar on the right. The breadcrumb reads Review Portal → [job type] → Retouch.

Click a flagged thumbnail to load the image. The right sidebar's Review tab shows what the reviewer recorded for that image:

• A Flagged Issues panel listing each ticked category and the per-category note. These are the reviewer's words, read-only.
• An in-progress notice when a reviewer is still mid-session on the job (e.g. Being reviewed by Review); informational only, doesn't block you.
• A Start Retouch button below the annotations.

Read the annotations carefully before doing anything else. The reviewer's notes are how they tell you what to fix; if they're too vague to act on, escalate to partner ops rather than guess.

Click Start Retouch to claim the image. The platform places a per-image retouch claim under your operator name (1-hour idle timeout, refreshed by activity) and the sidebar switches to the retouch package (§6.3).

6.3 The retouch package

After Start Retouch, the right sidebar becomes a Manual Retouch panel with three sections:

• Issues to Fix: a compact reminder of the reviewer's annotation (same content as the Flagged Issues panel in §6.2). Stays visible while you work.
• Download Package: separate buttons to download the Output Image (the flagged version you're fixing) and each Input image used to generate it. Download everything you need before leaving the page; the input images are essential context for understanding what the AI was working from.
• Select Retouched Image: the upload entry point. You'll come back here in §6.6 to submit your corrected file.

A Back link in the top-right of the panel returns you to the read-only flagged view from §6.2 without releasing your claim.

6.4 Editing locally

Scope of an acceptable retouch is fix the flagged defects without changing anything else.

In scope:

• Artifact removal (extra fingers, melted edges, stray pixels).
• Shadow correction (missing, doubled, wrong direction).
• Logo fixes (smudged, misspelled, distorted brand marks).
• Skin tone adjustments (uneven patches, unrealistic hues).
• Background cleanup (visible seams, vignetting, color cast).
• Garment distortion (warping, broken pattern continuity, hem irregularities).
• Pose corrections (hand at wrong angle, "floating" limb).
• Lighting evening-out (blown highlights, crushed shadows, color-temp inconsistencies).

Out of scope. Never do these:

• Changing the model's identity, hairstyle, ethnicity, age.
• Changing garment design, color, cut, or fit.
• Re-posing the model or recomposing the shot.
• Adding accessories that weren't in the original brief.
• Beautifying beyond the brief (skin smoothing, slimming, etc.).

If the image has a defect outside retouch scope (e.g. the AI generated the wrong garment entirely), escalate via your partner ops contact. Do not attempt a regenerate-as-retouch.

6.5 Output file specs

• Format: PNG (preferred) or JPEG at quality ≥ 90.
• Color space: sRGB. Convert if your working space is wider.
• Resolution: match the original output exactly. No up- or down-scaling.
• Bit depth: 8-bit minimum, 16-bit accepted.
• File size: no hard cap; well-compressed PNGs in the 5 to 25 MB range are typical.

6.6 Uploading

From the Manual Retouch panel (§6.3):

1. Click Select Retouched Image. The OS file picker opens.
2. Pick your saved retouched file. The portal uploads it.
3. Click Confirm to register the file as a new version of the image.

Keep the tab open until both the upload and the confirm step finish. If confirm fails (network drop, server error), the portal surfaces the error and lets you retry without re-uploading. If you exit mid-upload before confirm, the file may be staged but not registered, so you'll need to start the upload again.

6.7 What happens after upload

• A new version is created.
• The image returns to Pending Review.
• The version counter increments.
• Your retouch claim is released automatically.
• A reviewer re-checks. Could be the original reviewer, could be a different pool member.

You're done with this task. Pick the next.

If you revisit a retouched image while it's pending re-review, the sidebar tells you so (e.g. "This image is pending review. Retouch will be available after the reviewer flags issues."). You can't act on it again until the reviewer either approves it or flags new issues.

6.8 If your retouch is rejected

You'll see the image return to Needs Retouch with a new annotation set describing what still isn't right. Treat the second pass as a smaller task: only the new annotations need addressing.

A high re-rejection rate on a specific operator's retouches is a calibration signal. Partner ops will reach out if we see a pattern.

---

7. Combined Review + Retouch

Pool operators are typically credentialed for both reviewing and retouching, depending on your agreement. When you flag an image as Needs Retouch and submit, the portal offers a Retouch this now action so you can flag-and-fix in one pass.

When to use it:

• The defect is small and you're already in context.
• A batch of similar defects is faster to resolve in a single flow (e.g. the same logo issue across 20 images).

When to flag and let someone else retouch:

• You're the QA reviewer for a job and retouching would compromise independence (your agreement may require this for certain clients).
• The defect is large and requires a tool switch.

The system accepts both flows. Use your team's judgment, consistent with your agreement.

---

8. Concurrency and the claim system

The claim system prevents two operators from working on the same image, whether within your team, across pool partners, or both. Two scopes:

• Per-image retouch claim: locks one image to one retoucher.
• Per-image review claim: locks one image to one reviewer.

Lifecycle

1. Open an image. A claim is placed under your operator name.
2. Any interaction heartbeats the claim.
3. After one hour of inactivity, the claim becomes stale.
4. Another operator can take a stale claim by opening the image. The original claimant gets a notification on their next action.

Visible signals

• No pill: unclaimed, take it.
• "Claimed by you": yours, work freely.
• "Claimed by <name>": someone else has it.
• "Claim taken" banner: you held it, lost it. Portal warns before any destructive action.

---

9. Quality bar and annotation taxonomy

What "Approved" means

Approved = production-ready for the client's PDP at PiktID's quality standard. Every approved image must satisfy:

• Anatomy is plausible. No extra digits, broken joints, melted limbs.
• Garment is intact and recognizable. Cut, color, pattern, brand details match the source. No invented buttons, no missing pockets.
• Identity is preserved. The model matches the identity reference. The face stays consistent across multiple images of the same identity in the same job.
• Lighting matches the brief. Direction, intensity, color temperature coherent. No dual light sources unless intended.
• No AI artifacts. No hallucinated text, ghost limbs, melted edges, synthetic shadows.
• Composition matches the brief. Pose, crop, framing are what the client asked for.

If a major retailer would refuse it on their PDP, flag it.

What "Needs Retouch" means

A specific, addressable defect that a competent retoucher can fix in reasonable time. Examples: an extra finger, a doubled buckle, a localized shadow problem, an edge cleanup, a smudged logo.

"Needs Retouch" does not mean "the whole image is wrong." If the AI generated a completely wrong garment, model, or composition, flag it with the other category and a note like "Wholly wrong: garment color is red, brief says navy. Recommend regenerate, not retouch." PiktID escalates to the client.

Annotation taxonomy

Category	Use it for
Artifact	AI-introduced visual noise: extra digits, melted edges, ghost limbs, stray pixels, hallucinated text.
Shadow	Missing, doubled, or wrongly-directed shadows; inconsistent shadow direction.
Logo	Brand marks that are smudged, misspelled, distorted, or mis-positioned.
Skin Tone	Uneven patches, unrealistic hues, inconsistent tone across body parts, face-vs-body mismatch.
Background	Visible seams, vignetting, color cast on the backdrop, distracting elements.
Garment Distortion	Fabric warping, broken pattern continuity, pocket misalignment, hem irregularities.
Pose	Implausible body positions, hands or feet at wrong angles, floating limbs.
Lighting	Blown highlights, crushed shadows; color-temperature inconsistencies; harsh transitions off-brief.
Other	Anything that doesn't fit above. Use sparingly and always add a detailed note.

Multi-category flags are encouraged when an image has multiple distinct issues. One comprehensive annotation is faster for the retoucher than three separate flags.

Writing actionable notes

• ❌ "Hands look weird." → ✅ "Left hand has 6 fingers; thumb is doubled."
• ❌ "Logo bad." → ✅ "Chest logo: the second 'A' in 'BRAND' is replaced by a curve. Fix to readable text."

Localize when you reference a region: "top-left of jacket", "right hem", "under the collar". Retouchers don't have annotation pins, so words are the channel.

---

10. Throughput and operational expectations

PiktID commits to clients on managed-service turnaround. The pool delivers on those commitments. Your specific numbers are in your partner agreement; the general shape:

• Turnaround: measured from the moment a job enters your portal to the moment all images reach a terminal state (approved or fully retouched).
• Quality: measured by re-review rate, client escalation rate, and PiktID-side spot-checks against §9.
• Availability: the pool is expected to staff for predictable client volumes. Surges are coordinated through partner ops in advance.

We share metrics with you regularly (cadence in agreement). If you're trending off-target, partner ops reaches out before it becomes a contractual issue.

Capacity signals

• You're not seeing enough work. Tell partner ops. Routing weights may need adjustment, or client volumes may have dipped.
• You're seeing too much. Tell partner ops same-day. Overcommitting risks SLA breach.
• A specific client's work is qualitatively different. Tell partner ops; calibration may be needed.

---

11. Confidentiality, IP, and data handling

Every image in the portal belongs to a client. Your access is granted by PiktID under our agreement with the client, and your obligations are governed by your partner agreement with PiktID.

Image handling

• Do not copy images outside the portal except as required to perform a retouch.
• Do not share images with anyone outside your authorized operator list.
• Do not use any image, identity, or garment design for any other purpose: training data, portfolio, social media, anything.
• Retain working files only as long as your agreement permits, and only in encrypted local storage. Personal cloud sync (Dropbox, iCloud, Google Drive) is not allowed unless your agreement explicitly authorizes a corporate-managed equivalent.

Token security

Invitation links are credentials, tied to an individual operator's email.

• Do not share or forward links.
• Do not bookmark on shared devices.
• If you suspect a link compromise, tell partner ops immediately. We rotate.

Communications

All job-specific questions go to PiktID partner ops. Do not contact the client directly under any circumstance unless your agreement explicitly authorizes it for a specific account. PiktID is the buffer; that's part of what the client is paying for.

---

12. Troubleshooting and FAQ

Access

My link won't open, says expired or invalid. Tell partner ops. We can re-issue managed-tier tokens.

I closed the tab mid-work. Draft annotations are saved server-side. Submitted verdicts are atomic and persisted immediately. Reopen the link and continue.

Can I bookmark the portal? Per-invitation URLs are fine to bookmark on a controlled work device for the token's lifetime. Don't bookmark on shared or personal devices.

Reviewing

I submitted the wrong verdict. You cannot undo. Tell partner ops; we can request a reset from the job owner.

The image matches the brief but the brief seems wrong. Approve. The brief is the client's call. Flag with Overall notes if you suspect a brief error; partner ops surfaces it to the client.

Two pool operators disagree on the same image. The system records both verdicts. Partner ops arbitrates and may call a calibration discussion if disagreements cluster.

I'm not sure if a defect is "needs retouch" or "regenerate". Flag with the Other category and explain in the note. Partner ops escalates to the client.

Retouching

Upload failed mid-way. Retry from the Upload Retouch button. The portal handles partial uploads. If it keeps failing across multiple attempts, tell partner ops.

Reviewer's notes are vague. Tell partner ops; we'll either clarify or coordinate with the reviewer. Do not guess.

My file is too large. You probably saved as 16-bit uncompressed TIFF. Resave as PNG or quality-90 JPEG (§6.5).

Can I upload multiple retouch attempts on the same image? Each upload creates a new version. You can iterate, but every upload re-opens review. Only upload when you believe the retouch is ready.

Concurrency

"Claim taken by another user." Pick another image. Don't try to override.

I lost my claim mid-work. Save your local file. When the other operator is done, re-claim and upload. Local work isn't lost; it's just not on the server yet.

Can I see who else is working on a job? You'll see Claimed by <name> per image. There's no global roster view today; coordinate within your own team out-of-band, and across the pool through partner ops.

---

13. Support and escalation

Routing

• Job-specific questions → partner ops at PiktID.
• Platform issues (portal won't load, link broken, upload errors) → partner ops.
• Account, commercial, contractual questions → partner ops.
• Direct client contact → not allowed (see §11).

Contact

For all the above, email qa@piktid.com with the job ID, image index if relevant, and a short description. Your partner agreement may name a specific account manager; use that channel for routine work and qa@piktid.com for general support.

Response time

PiktID aims to respond within one business day for routine support. For production blockers (job-deadline-affecting issues), use subject prefix URGENT: production blocker and we prioritize same-day.

Escalation path

Partner ops → partner operations lead → PiktID operations director. If routine support is unresolved after one business day, ask explicitly to escalate. Don't escalate by CC-ing more people; ask for it.

---

14. Glossary

• Annotation: structured feedback on a Needs Retouch verdict. Categories, per-category notes, and optional overall notes.
• Claim: soft lock on an image. Heartbeated by activity, expires after one hour idle.
• Image / image index: one image inside a job. Position is stable; versions stack.
• Job: unit of work routed to the pool. Holds many images.
• Managed tier: the service level where clients pay PiktID to handle review/retouch via the pool. This is your tier.
• Output: the image the AI (or a retoucher) produced for review.
• Partner ops: your account/operations contact at PiktID.
• Permission: one of view_only, review_only, retouch_only, review_and_retouch. Pool operators are typically credentialed review_and_retouch.
• Pool: PiktID's official roster of vetted partners eligible for managed-service routing.
• Retouch task: work item created when a reviewer flags an image.
• Review session: scoped session created when an operator opens an invitation link. Tied to one operator email.
• Reviewer type: internal classification (self / human / managed / ai). Pool operators are managed.
• Token: secret in the invitation link. Per-operator credential.
• Verdict: Approve or Needs Retouch. Immutable.
• Version: n-th iteration of an image. Increments on every retouch upload.

---

15. Document changelog

Date	Version	Summary
2026-05-22	1.0	Initial publication.

---

This handbook is maintained by PiktID partner ops. Errors, ambiguities, or drift between this doc and on-the-ground reality should go to your partner ops contact, and we update fast.