Appearance
Product engine architecture
Date: 2026-05-13. Status: product direction and implementation map.
SKN is not only a card scanner. The product target is a collection, scan, and pricing platform for Pokémon-first TCG collectors and sealed investors. The marketplace is intentionally later. It only becomes safe after identity, collection ownership, and pricing confidence are strong enough.
Product thesis
The durable product edge is:
- identify raw cards, graded cards, and sealed products quickly;
- store the user's collection as a trusted private inventory;
- produce transparent weighted prices across market sources;
- explain confidence instead of pretending that every market price is exact;
- make future marketplace actions natural because SKN already knows the item, ownership context, and fair market range.
The user-facing "wow" should be: "this app explains why the price is what it is."
Example:
| Signal | Value |
|---|---|
| SKN estimate | 42.00 EUR |
| Cardmarket trend | 39.50 EUR |
| eBay sold average | 45.20 EUR |
| Recent EU liquidity | Medium |
| Confidence | 82% |
The four product engines
1. Identity Engine
The Identity Engine answers: "What is this object?"
It covers:
- raw cards;
- slabs and graded cards;
- sealed products.
Raw cards use the current card-recognition stack: card crop, visual embedding, ANN retrieval, OCR/rerank later.
Slabs require two recognitions:
- the inner card identity;
- the grading label: grader, grade, certificate number, and label text.
Sealed products are a separate object class. They need their own product catalog and index. ETBs, displays, booster bundles, tins, blisters, and collections must not be forced through the card table.
2. Collection Engine
The Collection Engine answers: "What does this user own, and what is the trusted history of that ownership?"
It must model:
- user-owned holdings;
- item type: raw card, slab, sealed product;
- quantity;
- language;
- condition;
- acquisition price;
- acquisition date;
- storage location;
- user photos and evidence;
- provenance notes;
- current valuation snapshots;
- change history.
Security matters here because the collection database can reveal valuable assets at a physical address. Default posture:
- user holdings are private;
- exports are explicit;
- marketplace listing is opt-in;
- audit trail protects against accidental or malicious edits;
- public sharing must never leak private acquisition or location metadata.
3. Pricing Engine
The Pricing Engine answers: "What is this worth, and how confident are we?"
It should ingest observations, normalize them, then publish explainable estimates.
Candidate observation sources:
- Cardmarket;
- eBay sold;
- eBay active listings;
- TCGPlayer;
- PriceCharting or graded-market providers;
- Vinted and Leboncoin later for French peer-to-peer signals;
- specialist graded sources when available.
Each observation should keep:
- source;
- source URL or external identifier;
- observed price;
- currency;
- shipping treatment;
- fee treatment if known;
- condition;
- language;
- raw / graded / sealed classification;
- grader and grade when relevant;
- sale date or listing date;
- region;
- confidence flags.
The estimate should not be a magic average. It should be a weighted result with an explanation:
- recent sold data weighs more than old data;
- sold data weighs more than active listing data;
- same-language and same-region data weighs more than mismatched data;
- graded estimates are separate from raw estimates;
- sealed estimates are separate from raw card estimates;
- low-liquidity prices must show low confidence.
4. Marketplace Engine
The Marketplace Engine answers: "Can this trusted item be sold or bought inside SKN?"
This is deliberately later. It introduces:
- seller reputation;
- listing moderation;
- item proof requirements;
- payment and payout handling;
- disputes;
- fraud prevention;
- shipping state;
- possible KYC or regulatory obligations.
Marketplace should only build on top of the other engines. If identity, collection evidence, and fair-value range are weak, marketplace trust will be weak.
Data sources and licensing posture
1niceroli/ptcg-assets is useful for an internal sealed-product POC. As of 2026-05-13, the GitHub repository describes itself as a collection of Pokémon TCG product images including packshots, Elite Trainer Boxes, collections, blisters, pins, logos, symbols, banners, mini-tins, tins, and coins. It has no declared GitHub license.
That means:
- good for local exploration and internal indexing experiments;
- not safe to treat as production-distributable assets without permission or a replacement source;
- useful as a catalog-shape reference for sealed-product types and file naming;
- not enough alone because it is image-first, not a structured product database.
For production, SKN needs either permission, licensed assets, user-uploaded images, or a legally safe asset strategy.
Pricing sources need the same posture. Scraping and third-party pricing APIs must be evaluated against terms, quotas, and redistribution rights before becoming production dependencies.
First implementation slices
- Scanner lab UX: keep the five endpoints but make the scan surface camera-first and move endpoint comparison into a bottom sheet.
- Scan-case feedback loop: store correct / wrong / picked-match cases from real Android scans so accuracy can improve with evidence.
- Sealed product POC: create a separate sealed catalog and
/scan-sealed-labpath using internal-safe assets first. - Pricing schema: create the observation and estimate model before integrating many providers.
- Collection security foundation: model private user holdings, ownership history, and sharing boundaries before marketplace features.
Non-goals for now
- No production marketplace.
- No payment handling.
- No public asset redistribution from unlicensed repositories.
- No claim that one market price is absolute truth.
- No mixing sealed products into the raw-card index.