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
   • §6.9 When you can't retouch — request regeneration
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. Review and retouch run as strict alternating rounds: a review round must verdict every image before any retouch starts, and a retouch round must resolve every flagged image before re-review opens. The loop repeats until a review round ends with everything approved.

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

It all starts on the client's side. When the job's images finish generating, the client lands on a Job Results page with a Request Service panel. Picking Request Review, Request Retouch, or Request Review & Retouch with the Managed tier selected is what hands the job off to the pool.

From that click forward:

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 six-card stats strip at the top (Total Jobs, Approved, Needs Fix, Retouching, Regenerate, 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, retouching, regenerate, pending, total images), and the job expiry on the right. Regenerate counts as a settled status — it tallies toward the "done" side of the bar — but it means the image is waiting for the owner to regenerate; reviewers don't act on it again until a new version lands.
• 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: a single scrollable panel that holds everything you need on the current image — project/image metadata at the top, the Brief (what the AI was asked to produce), identity references and input images, the verdict controls (Approve Image, Submit flag & next), and the issue-categories form when you're flagging. No tabs; just scroll.
• Bottom bar: counter for images you've marked so far, plus the Submit All Reviews button.

A note on UI terminology: the verdict button reads Submit flag & next 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) and the Brief panel are accessible via the right sidebar.

The Brief panel is the source of truth for what the AI was asked to produce — pose, framing, lighting, garment cut, identity, background. Read it before you decide whether the output matches intent.

5.5 Making a verdict (drafts)

At the bottom of the right sidebar, two verdict buttons sit one above the other:

• Approve Image when the image meets the quality bar in §9.
• Submit flag & next when there's a specific, addressable defect — fill in the issue-categories form (§5.6) first, then click submit. The mark commits and the viewer advances to the next image.

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.

The quality bar is mirrored in the Guidelines dialog at the top-right of every session — job-type-specific Focus / Approve when / Common pitfalls columns. Open it before issuing a verdict if you're unsure where a defect lands; this handbook expands the same content with operational context (see §9).

5.6 Annotations (required when flagging)

The What's wrong? form sits below the Brief in the right sidebar. To flag, fill it in, then click Submit flag & next at the bottom of the sidebar. 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 Reason for [category] 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.

In addition to text, you can mask the region the annotation applies to. With a category selected, a drawing toolbar appears on the canvas; drag to paint the affected area. Localized masks save the retoucher inspection time and let them go straight to the right pixels.

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, which opens once the review round closes (§6).

Committed verdicts stay revisable while the review round is open, i.e. while at least one image still lacks a verdict. The moment every image in the job has one, the round closes and verdicts lock; the job flips to the retouch phase and review stays locked until the retouch round completes. The audit log is append-only. 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

Re-review happens in rounds, not per image. When the retouch round completes (every flagged image either re-uploaded or marked Regenerate), all corrected versions return to the Pending queue together and the next review round opens. You get one notification per round, not one per upload. You (or another pool reviewer) re-check each image using the same flow as a fresh review: open the image, click Approve Image or fill the form and click Submit flag & next, then commit with Submit All Reviews when done.

The loop can repeat. If you flag the retouched image again, a new retouch round opens once the review round closes; the retoucher fixes the new issues and the cycle continues. The job is done when a review round ends with every image Approved.

The same loop covers regenerations. When the owner regenerates an image that was previously marked Regenerate (see §6.9), the new version joins the next review round and the version counter increments. From your side, treat it like any other pending image: open it, issue a fresh verdict, submit.

---

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 review round completed with one or more flagged images. Ready for you to work on.
• Awaiting Review (blue): the review round is still open. Nothing to do until every image has a verdict and at least one is flagged.
• Retouching: you or another pool retoucher has claimed images on this job.
• Regenerate (red): one or more images on this job were marked unfixable (see §6.9). The owner regenerates from their side; no further retoucher action on those images until a new version lands.
• 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 banner means the review round is still open: you can inspect flagged images and read annotations, but Start Retouch stays disabled until the round completes.

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 shows what the reviewer recorded for that image, in a single scrollable panel — no tabs:

• 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); it signals the review round is still open, so Start Retouch stays disabled until they finish.
• 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 switches to a Manual Retouch panel, scrollable, with these sections in order:

• Revisions: a compact reminder of the reviewer's annotation (same content as the Flagged Issues panel in §6.2) plus a Manual regions preview with a Hide overlay toggle. The overlay paints the reviewer's mask directly on the canvas so you can see the affected region without re-reading the note.
• Brief: the full image brief (pose, lighting, garment, identity references). Stays visible while you work so you can sanity-check fixes against intent.
• Download Package: a single Download all (.zip) button that bundles the flagged output, every input the AI used, and the reviewer's mask. Grab it before leaving the page; the inputs 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.

If the image turns out to be unfixable once you've inspected the package — wrong garment, broken anatomy, completely off-brief — you can abandon the retouch from this panel. See §6.9.

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 — the generated garment is unrecognizable vs the source, body parts are missing, the composition is completely off-brief, or the base output is broken at the pixel level — use the Cannot retouch — request regeneration action in the panel footer (see §6.9). Partner ops escalation is no longer required for these; the action is self-serve and the owner is notified automatically.

The same scope rules and the regeneration criteria are mirrored in the Guidelines dialog (top-right of every session). Open it whenever you're unsure where a defect lands.

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 shows as Pending Review.
• The version counter increments.
• Your retouch claim is released automatically.
• Re-review opens once the retouch round completes: every flagged image in the job either re-uploaded or marked Regenerate. Resolving the last one is what notifies the reviewers (one notification for the whole batch). The re-reviewer could be the original reviewer or 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.

6.9 When you can't retouch — request regeneration

Some outputs come back so broken that retouching is a waste of effort. Rather than spending an hour fighting the pixels and uploading a half-fix, the platform lets the retoucher mark the image as unfixable and hand it back to the owner for regeneration.

When to use it. Mirror the in-app help dialog exactly:

• Missing or severed body parts (no torso, half a head, hand without fingers).
• Garment is unrecognizable vs the source — wrong cut, melted, or replaced entirely.
• Completely off-brief composition (wrong pose, framing, or scene).
• Base output is broken at the pixel level — the work needed to fix it is greater than re-running the generation.

If you're outside these criteria, attempt the retouch. The bar for marking unfixable is high.

Where the button is. Two places, depending on when you spot the problem:

• Before clicking Start Retouch — in the read-only flagged view from §6.2, the Cannot retouch — request regeneration action sits below Start Retouch in the panel footer. Use this when you've read the annotations and the inputs and concluded the base output isn't workable.
• After clicking Start Retouch — the same action moves to the Manual Retouch panel footer alongside Select Retouched Image. Use this when you've downloaded the package and concluded now that the image isn't workable.

Both paths trigger the same inline confirmation; the action only commits after you confirm.

What happens when you confirm.

1. The image's status flips to Regenerate (red pill). It counts as resolved for the current retouch round, so marking the last flagged image this way also completes the round and opens re-review.
2. If you'd already clicked Start Retouch, the in-progress retouch record closes with status abandoned and your per-image claim is released. No credit is charged for the abandoned retouch — the platform only bills on a successful upload, so an abandoned retouch costs nothing to either side.
3. The owner is notified (in-app and email) that the image needs their attention.
4. The owner clicks Regenerate on their results page when they're ready. A new version is created and joins the next review round (§5.9).

What you do next. Pick the next image. A regenerated version may come back to you, to another pool retoucher, or to a different pool reviewer — routing depends on the job's permissions, not on who originally marked the image.

What the owner sees. This is the page the job owner lands on once the job is back in their court. Each image you marked carries a Regenerate badge and an inline Regenerate button; the Review Summary card up top tallies the counts. The owner clicks Regenerate per image when they're ready — that's what kicks off a new version that re-enters review.

---

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. The strict round gate still applies: the action becomes available only once the review round completes, so verdict every image first, then circle back to fix the flagged ones.

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.

One boundary: a reviewer who is also credentialed to retouch should still flag fixable defects through Needs Retouch. The Cannot retouch — request regeneration action (§6.9) is exclusively a retoucher decision, made after attempting (or inspecting for) a fix — it's not a faster verdict shortcut for reviewers.

---

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

The same standards are surfaced in the product: every review and retouch session has a Guidelines link at the top right that opens a job-type-specific dialog (Model Swap, Flat to Model, Create Packshot). The in-product copy is the canonical bar — what you see in the dialog is what we enforce. This handbook expands the same content with operational context the dialog can't fit. The reviewer's view is in §5.5; the retoucher's view (which adds In scope / Out of scope / When to request regeneration columns) is in §6.4.

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." Reviewers still issue a binary Approve or Needs Retouch verdict. When the image is not fixable at all — wrong garment, missing limbs, broken composition — flag with the most-applicable category and an overall note describing the problem. The retoucher who picks up the task decides whether to attempt the fix or mark it for regeneration (see §6.9). Reviewers do not call regeneration directly; that decision sits with the retoucher.

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. While the review round is still open (some images lack a verdict), revisit the image and change your mark. Once the round closes, verdicts lock; tell partner ops and 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". As a reviewer, your job stays binary — Approve or Needs Retouch. If you suspect the image is unfixable, flag with the closest category plus an overall note explaining your read; the retoucher then decides. As a retoucher, the criteria for using Cannot retouch — request regeneration are in §6.9 and in the in-app help dialog. When in doubt, attempt the retouch — there's no penalty for abandoning if you discover mid-work that it's not workable.

What happens when an owner regenerates an image? The new version joins the next review round automatically. Same flow as re-review after retouch (§5.9): any pool reviewer can pick it up and issue a fresh verdict once the round opens.

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 that queues for the next review round. Only upload when you believe the retouch is ready; an extra round costs everyone a full review pass.

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

• Abandoned: a Retouch row that was started but consciously dropped by the retoucher because the image was found unfixable. Terminal status; not the same as failed (which is reserved for processing errors). See §6.9.
• 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.
• Needs regeneration: image status meaning the retoucher has decided no retouch is viable; the owner regenerates a fresh version. Settled for review-progress counting; not actionable by reviewers or retouchers. Surfaced in the UI as Regenerate.
• 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.
• Regenerate (action): owner-only operation that creates a new version of an image; the new version joins the next review round. Triggered manually from the job results page after a retoucher marks the image Needs regeneration.
• Retouch task: work item created when a reviewer flags an image. Actionable once the review round closes.
• 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.
• Round: one full pass of the alternating loop. A review round ends when every image has a verdict; if anything was flagged, a retouch round runs until every flagged image is re-uploaded or marked Regenerate, then the next review round opens. The job closes when a review round ends with everything approved.
• Token: secret in the invitation link. Per-operator credential.
• Verdict: Approve or Needs Retouch. Revisable while the review round is open; locks when the round completes.
• Version: n-th iteration of an image. Increments on every retouch upload.

---

15. Document changelog

Date	Version	Summary
2026-06-11	1.2	Documented the strict alternating review/retouch rounds: verdicts lock when the review round completes; Start Retouch opens per round (the in-progress banner now blocks it); re-review opens only when every flagged image is resolved, with one notification per round; regenerated images join the next review round. Updated §1, §5.7, §5.9, §6.1, §6.2, §6.7, §6.9, §7, §12, and the glossary (Round, Verdict).
2026-05-29	1.1	Documented the Cannot retouch — request regeneration action and the new Regenerate status; added §6.9, the partial-review-gate note in §6.2, and three glossary entries (Abandoned, Needs regeneration, Regenerate). Updated §9 and §12 to point at the new retoucher-led flow instead of the old partner-ops escalation.
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.