Knowledge check OCR & Custom Data Extraction
12 questions in pool · live exam draws 5
I04
Q1 multiple-choice · ocr-api-constraint What’s the key architectural constraint of PhotoRobot OCR that integrators must design around?
Source: I04 textbook §1 (The honest constraint).
Explanation: No OCR endpoint exists in the Cloud API. OCR is semi-automated — operator clicks “Extract OCR annotations” in CAPP Cloud → text extracted → output flows through item export’s data.json. Don’t design webhook-driven real-time OCR pipelines; design export-driven post-processing that watches the export destination and parses data.json.
Q2 scenario · ocr-workflow · weight 2 Your customer wants OCR-extracted text for 1000 grocery products. An operator photographs them and exports the items. The exports arrive in your S3 bucket — but data.json files are either missing or empty.
Source: I04 textbook §3 (operator workflow) + §10 (common failure modes).
Explanation: OCR is operator-triggered in 2 places: (1) per-item OCR extraction in Cloud Edit mode, (2) export options to include data.json. Both need explicit operator action. Empty extractedOcrData = step 1 missed. Missing data.json entirely = step 2 missed. Fix structurally: update saved export template (B22 §5) with OCR defaults checked, train operators on the per-item extraction step.
Q3 multiple-choice · ocr-output-format OCR-extracted text in data.json is returned as:
Source: I04 textbook §4 (The data.json structure).
Explanation: PhotoRobot returns raw text arrays per frame. Each detected text region becomes one string in the array. Your parser structures the output via regex (e.g., “INGREDIENTS:” → ingredient list), NER, or LLM extraction. Don’t expect PhotoRobot to provide { ingredients, nutrition, allergens } structured fields — that’s downstream parser work.
Q4 scenario · dedup-strategy · weight 2 Your OCR pipeline returns the same product brand name “ACME ORGANIC” extracted from 8 different spin frames — once per frame. The downstream PIM gets all 8 copies attached as separate metadata entries.
Source: I04 textbook §4 (Parsing strategy) + §10 (Common failure modes).
Explanation: Repeated text across frames is normal — the brand name visible from 8 angles produces 8 OCR hits. The integrator’s parser concatenates across frames + deduplicates + filters. Suggested parse pipeline: collect → dedupe (case-fold, exact match) → filter (length ≥ 3) → optionally structure via regex → push to downstream.
Q5 multiple-choice · tags-vs-ocr When should you use custom tags vs. OCR to attach metadata to PhotoRobot items?
Source: I04 textbook §5 (Custom metadata fields — tags) + §1 (OCR API constraint).
Explanation: Tags = structured + API-accessible. Use for everything you can structure upfront (campaign metadata, channel routing, regulatory flags). OCR = unstructured + export-driven. Use for text that exists physically on packaging and isn’t in any source database. Reach for tags first whenever possible — much simpler to query, filter, and route via API. OCR fills the gap when text exists only on the product.
Q6 multiple-choice · gs1-image-standards GS1 image standards are required when:
Source: I04 textbook §6 (GS1 image standards).
Explanation: GS1 is retailer-required, not universally mandatory. Walmart, Target, Carrefour, Tesco, etc. enforce GS1 for product image ingestion — non-compliant images get rejected. Verify per-retailer (each has its own image spec doc). Own-brand e-commerce or single-channel customers usually don’t need GS1. PhotoRobot supports it via ${gs1} filename template variable + naming conventions per B22 §4.
Q7 scenario · regulatory-review · weight 2 Your pharmaceutical customer wants OCR-extracted active-ingredient text from drug packaging fed into their compliance database. Their QA team says regulatory tolerance for OCR errors is zero .
Source: I04 textbook §9 (Quality + manual review gates — Regulatory / pharmaceutical exception).
Explanation: OCR + 100 % manual review is the right pattern for regulatory contexts. OCR doesn’t replace human review — it accelerates it by pre-filling the form. Reviewer sees image + extracted text side-by-side, corrects or approves. Auto-accept anything in pharma will produce regulatory incidents; skipping OCR entirely loses the productivity boost. The textbook explicitly: “Don’t fight legal / QA requirements. Build the review gate into the pipeline.”
Q8 multiple-choice · post-export-architecture Because OCR has no API endpoint, the integrator’s pipeline is export-driven . What triggers the worker to process new OCR data?
Source: I04 textbook §8 (Post-export pipeline architecture — Worker triggers).
Explanation: OCR pipeline is export-driven . Worker watches the export destination for new bundles via: (1) S3 ObjectCreated notification → Lambda, (2) file-watch (inotify/FSEvents), (3) scheduled polling, or (4) PhotoRobot item.exported webhook (per I02) → fetch data.json from destination. There’s no direct OCR webhook because OCR isn’t an event-driven feature in PhotoRobot.
Q9 true-false · structured-fields PhotoRobot’s OCR returns structured fields per category (e.g., { ingredients: "...", nutrition: "...", allergens: "..." }).
Source: I04 textbook §4 (Anti-pattern: assume per-field structure).
Explanation: False. PhotoRobot OCR returns raw text arrays (extractedOcrData: [...]), not structured semantic fields. If your downstream needs structured fields, your parser provides the structure via regex pattern matching, named entity recognition, or LLM extraction. The semantic interpretation lives in your integration , not in PhotoRobot’s output.
Q10 scenario · routing-pattern · weight 2 Your customer has 3 downstreams: ERP (needs SKU + status), PIM (needs OCR text + tags), DAM (needs images + filename metadata). You’re choosing the routing pattern.
Source: I04 textbook §11 (Custom metadata + downstream routing).
Explanation: Pattern B (route by tag) is the recommended default. Tags drive routing rules in your worker code. Matches mental model (per-channel, per-region, per-brand). Pattern A wastes downstream storage on irrelevant data. Pattern C duplicates worker logic. Tag consistency requires discipline (per the tag taxonomy + naming conventions in §5), but the payoff is clean routing logic.
Q11 multiple-choice · ocr-weakness Where does PhotoRobot’s OCR typically struggle ?
Source: I04 textbook §2 (Where OCR struggles).
Explanation: OCR is strongest on printed text in standard fonts (sans-serif, serif) at reasonable size on flat or cylindrical (Unwrap-friendly) surfaces. OCR struggles with handwriting, decorative/script fonts, micro-print, low-contrast text over busy product imagery, and glare from reflective/foil/glossy surfaces. Know the limits before promising the customer 100 % accuracy.
Q12 scenario · data-json-missing · weight 2 Your post-export worker watches an S3 bucket for new item bundles. For the past week, 100 % of items uploaded had data.json files. Today, you notice 20 % of items have no data.json. The customer’s operators haven’t reported any issue.
Source: I04 textbook §10 (Common failure modes — data.json missing).
Explanation: Most common cause: operator drift away from the canonical export template . Either an operator improvised export config (forgot to check the OCR data toggle), or someone modified the saved template. Monitoring discipline: alert on data.json absence when items are exported from OCR-enabled projects. Fix structurally — single canonical template per OCR-enabled customer in the studio’s template library, ops discipline to load template by name (per B22 §5).
Ready to commit? You can review and change your answers before submitting. Once submitted, this attempt is final and we'll show you your score, correct answers, and explanations.
Submit final answers
