← CC-Analysis

◆ Capture → Sale: the end-to-end flow

Photo + spoken description, transcribed and condensed on-device for free, used to seed LLM image tagging, optionally stickered and/or appraised with tokens — then sold and synced across PROSALE / EstateSail / TroveSnap by one QR code.

Where it runs / cost: on-device · free deterministic · free token-metered Auth / connector review gate
1 Capture→ 2 Transcribe→ 3 Condense→ 4 Tag→ 5 Appraise (opt)→ 6 Sticker (opt)→ 7 Review → canonical→ 8 On the floor→ 9 Sold capture→ 10 What's Next
1

Capture

on-device · free

Seller photographs the item and speaks a quick description — hands-free, no form while walking the sale.

"Oak dresser, 1960s, dovetail drawers, small veneer chip on top, ask $120."
2

Transcribe locally

on-device · free

A local speech model (Whisper-class) turns the voice note into text on the device, offline — no API cost, works on spotty sale-site wifi.

3

Condense locally

on-device · free

The transcript is condensed into structured candidate fields (title, attributes, condition, asking price) and token-trimmed to fit the tagging model's prompt limit.

→ draft: title · attributes[] · condition · asking_price
4

LLM image tagging (seeded by the description)

deterministic + light LLM

The condensed text seeds the image tagger, so tags are specific ("mid-century", "oak", "dovetail") instead of generic. Produces treasure tags, category, and marketplace fields.

writes: inventory_candidate · item_treasure_tags · marketplace_score
Decision → if a high-value category is detected here, raise a notification: "an appraisal may be in order." This is the system trigger into the loop below.
5

Appraisal decision loop — token-metered, before or after

token-metered

Two triggers reach this step: the system flag from tagging above, or the seller's own suspicion that an item is worth more. The seller decides whether to spend tokens — the system only suggests, it never spends on its own.

Appraise → higher value confirmed? If yes: re-price + re-tag, apply a QR sticker, and route to auction / wishlist recovery; the result loops back into the record (and can re-flag it). Decline or "not higher value" → standard listing, revisitable anytime.

Appraisal decision loop: system flag and seller suspicion converge on the appraise-with-tokens decision; confirmed higher value triggers re-price/re-tag, sticker, and auction routing, looping back to update the record.
writes: appraisal · appraisal_recommendation · seller_alert · enhanced photo
6

Sticker — optional, on auctionable items

label · free packs · $

Apply a QR sticker — a pre-printed pack (blank code, binds on first scan) or print-your-own (code minted from the record). Bind = scan sticker → this item. Both synchronize to the account. Used selectively on items the seller knows can be auctioned later → item-level tracking from day one.

binds: qr_code(ts:ITEM) ↔ item · syncs to account
7

Review → promote → canonical

review gate

The candidate hits the review queue; the seller approves/edits. Only promoteInventoryCandidate() writes the canonical item — the QR code travels with it. Nothing publishes without approval.

writes: estate_sale_items (+ qr_code)
8

On the floor

deterministic · free

The QR is the price tag and the buyer portal (scan → public Trove Go listing). Every hunter scan is an anonymous interest signal that gauges auction demand per item.

public QR → listing only (never internal pricing) · scan_count++
9

Checkout & sold capture

Auth / connector

Whoever rings the sale — TroveSnap scan-PWA, PROSALE, EstateSail, or Square + manual — the item is keyed by its QR code, so a single itemized sold event flows back. No CSV guesswork.

writes: inventory_status_events (sold, final_price) keyed by qr_code
10

What's Next

deterministic comps · $

Reconciled in real time. Sold → recovered-revenue analytics; unsold → disposition routing (auction export, wishlist recovery), informed by demand + scan-interest.

feeds: demand graph · disposition recommendations · live dashboard

Full decision flow — every branch

The same journey as a decision flowchart: decision diamonds, branch outcomes, loop-backs, and badges (needs research, needs approval, tokens, optional, review, buyer-facing, action). Split into two readable halves; a single-page overview is also available. Nothing goes canonical or public without seller approval; tokens are spent only on the seller's choice.

Part A — capture → publish

Decision flow part A: capture, transcribe, condense, tag, then decisions for high-value flag, appraisal, research, photos, sticker, and publish-readiness/approval, ending at promote and publish.

Part B — sale → disposition

Decision flow part B: from the floor through the sold decision to checkout/reconcile or the unsold what's-next disposition fan-out, with a republish loop-back.

Sticker sync — PROSALE / EstateSail / TroveSnap

The QR code is the shared item identity that threads all three systems. TroveSnap owns the canonical record, demand, and disposition; the POS owns checkout. The code is the join key.

QR sticker code = shared item identity  ts:ITEM  (opaque — no price/data inside)

TroveSnap

canonical · demand · disposition
  • Mints the item + QR code
  • Prints label / activates pack code
  • Buyer portal + scan-interest
  • Checkout scan-PWA (offline-first)
  • Reconcile → What's Next
→ ①push catalog + code
(or shared printed label)
② ←sold report / API,
matched by code

PROSALE

estate-sale POS / clerking
  • Code used as SKU / lot
  • Rings sale · Square payment
  • Emits sold report (CSV / API)

EstateSail

estate-sale POS · Square
  • Code used as SKU
  • Square line-item sale
  • Emits sold report
All checkout paths converge: TroveSnap scan-PWA, PROSALE, EstateSail, or Square + manual — each keyed by the QR code — resolve to one itemized sold event in inventory_status_events. Real-time where an API exists; CSV-import fallback matched by code otherwise (reusing existing reconciliation).

Sync rules & guarantees