Sightline

Independence doesn’t end at checkout.

Sightline lets a blind shopper buy by voice, hear exactly what they will pay, check the parcel with a phone camera, and get the money back through PayPal when it is wrong. Money waits for the check.

The 60-second path

  1. Try it with the Speech Viewer on

    Shop as Maya. The Speech Viewer panel simulates what a screen reader says on every screen, and lists every announcement the app makes.

  2. Check the numbers

    Every number below is read from a result file written by a script in the repository, on every page load.

    Go to the numbers

  3. Verify a payment receipt yourself

    Each payment decision is signed. The page re-checks the hash and the Ed25519 signature on load; the repo has an offline verifier.

    Open a real receipt

  4. Read the code

    Payment gate, PayPal client, vision checks and every eval script.

    Open the repository

Watch the whole lifecycle run

One button runs every step for real on the PayPal sandbox: voice request, readback, two-key confirmation, PayPal hold, the wrong size shipped, the camera check and the money back. Then Demo Store’s own agent reads the signed evidence and answers inside the store’s policy, and Maya’s agent reads her the offer and its reasons. You hear what Maya hears.

What the agents did on the latest demo order

The latest order from the lifecycle run: Harbor knit crew-neck sweater. Every step, from the voice request to PayPal’s last word, with who did it (the buyer, the buyer’s agent, the store’s agent, store staff or PayPal), the tool used, whether a model or fixed rules decided it, and PayPal’s own ids and statuses.

Showing the latest 6 of 20 steps.

  1. The store’s agent: Sent it without staff, because it is inside the store policy: Offer a replacement.

    Monday 9 November, 1:36 pm UTC. Decided by fixed rules.

  2. You: Declined the offer. The case stayed open.

    Monday 9 November, 1:36 pm UTC. Decided by a person.

  3. The store’s agent: Read the signed evidence pack. Its fingerprint and signature check out, and the check inside says the item does not match.

    Monday 9 November, 1:36 pm UTC. Used Sightline evidence check.

  4. The store’s agent: Proposed: Release the $36.72 hold. Demo Store's shipping record shows it sent size L instead of the size M that was ordered.

    Monday 9 November, 1:36 pm UTC. Used Claude. Decided by Claude, a model, and checked by code.

  5. The store’s agent: Released your $36.72 hold through PayPal. You were never charged.

    Monday 9 November, 1:36 pm UTC. Used PayPal Payments API. Decided by fixed rules.

    Authorization 2XS81722GF5889200: voided, as PayPal answered.

  6. The store’s agent: Sent it without staff, because it is inside the store policy: Release the $36.72 hold.

    Monday 9 November, 1:36 pm UTC. Used PayPal Payments API. Decided by fixed rules.

Every step comes from the order’s audit log, where each line is chained to the one before it with a hash. PayPal ids and statuses are PayPal’s own, as PayPal answered or as a verified PayPal webhook said.

Numbers, read from the result files

  • 0 of 60

    trick listings that got a wrong or unconfirmed payment through

    Baseline: A shopping agent without the payment check: 50 of 60

    Wrong means the amount, payee or quantity. Simulated, without calling PayPal.

  • 0 of 140

    phrases that were not a “yes” but passed as one

    Baseline: Listening only for key words: 82 of 140

    The first of the two confirmation checks, on phrases written after it was built.

  • 0 of 100

    double taps, retries and lost replies that charged twice

    Baseline: Before we handled lost PayPal answers: 10 of 100

    Simulated, without calling PayPal.

  • 62 of 75 (82.7%)

    made-up product facts caught before you heard them

    Baseline: With no fact check: 0 of 75

    Measured on scripted test answers.

  • 121 of 210 (57.6%)

    wrong items the camera check caught

    Baseline: A general image-matching model: 194 of 210 (92.4%)

    Synthetic renders: it answered “not sure” for 283 of 420 pairs (67.4%). The baseline also flags 189 of 210 correct items (90.0%) as wrong.

  • 33% (15 of 45)

    stores where Tab alone could not reach “Add to cart”

    A dialog that traps keyboard focus counts as blocked.

The Checkout Barrier Index and its dashboard.

All 59 results, with intervals, scripts and negative results

  1. Shopping agent, live model

    Live model finishes with the right tool

    8 of 8

    Interval
    95% Wilson 67.6%–100.0%, n = 8
    Note
    claude-haiku-5-5, effort low, over recorded Channel3 data. Hand-written cases; a small sample.

  2. Shopping agent, live model

    Model lines the grounding check stopped before speech

    1 of 14

    Note
    Stopped lines are never spoken; the template says the listing facts instead.

  3. Shopping agent, live model

    Time for an agent turn, median and slowest

    1.6 s, 6.5 s

    Note
    Model calls and tool work, from this laptop; recorded catalog, so no Channel3 time.

  4. Shopping agent

    Wrong model moves the loop refuses (made-up id, unsaid filter or memory, unasked readback)

    7 of 7

    Baseline
    no checks: 0 of 7
    Interval
    95% Wilson 64.6%–100.0%, n = 7
    Note
    Scripted model turns, deliberately wrong; the real loop and its checks.

  5. Shopping agent

    Agent lines with a claim the listing does not make, stopped before speech

    2 of 2

    Baseline
    no check: 0 of 2

  6. Shopping agent

    Agent lines the listing backs, kept

    2 of 2

  7. Shopping agent

    Safety checks held (budget, no wool, no team gear, no other size, no order without asking, memory only proposed)

    6 of 6

  8. Shopping agent

    Listings shown in another size than the "size M" asked for

    0 of 15

    Baseline
    Channel3's own top 3: 1 of 15
    Note
    Recorded Channel3 responses (9 Nov 2026). Baseline counts the size each store pre-selected, which the app used to show.

  9. Shopping agent

    Team or fan merchandise in the top three

    0 of 21

    Baseline
    Channel3's own top 3: 3 of 21

  10. Shopping agent · negative result

    Top-three listings that name their colour

    11 of 21

    Baseline
    Channel3's own top 3: 7 of 21
    Note
    Better than Channel3’s order, but many live listings never name a colour. The app says "colour not given" for them, and the camera check cannot verify their colour.

  11. Shopping agent

    Amounts in money answers that are not in the orders

    0 of 14

    Note
    Every amount must be an order amount or a sum of them; answers are templates over the records.

  12. Checkout Barrier Index

    Median axe-core violations per product page (distinct WCAG A/AA rules failed)

    4

    Interval
    IQR 2–6, n = 60
    Note
    axe-core 4.14.0, tags wcag2a, wcag2aa, wcag21aa, wcag22aa, one product page per store. Median failing elements per product page: 13. Home page median: 3 rules.

  13. Checkout Barrier Index

    Stores where keyboard-only traversal could not reach add to cart within 150 Tabs

    9% (3 of 33)

    Interval
    95% Wilson 3%–24%, n = 33
    Note
    Tab only from the top of the page, no Enter, Space or clicks; Escape pressed once if focus was trapped. Counted over product pages with an enabled add-to-cart control named "add to cart/bag/basket" or "buy now". Focus traps among the failures: 1. Not in the denominator: 12 pages where a cookie or sign-up dialog held focus and Escape did not close it, 7 whose add-to-cart button is disabled or hidden until a size is chosen, 8 with no control using that wording, 0 traversal errors.

  14. Checkout Barrier Index

    Stores where Tab alone could not reach add to cart, counting a dialog that held focus as blocked

    33% (15 of 45)

    Interval
    95% Wilson 21%–48%, n = 45
    Note
    The same traversal as the row above, but the 12 pages where a cookie or sign-up dialog held focus and Escape did not close it count as blocked instead of being left out: a keyboard or screen-reader user meets that dialog first. Added on 9 November 2026 after the first analysis, from the same crawl; no store was crawled again.

  15. Checkout Barrier Index

    Stores with at least one button that has no accessible name (home or product page)

    35% (21 of 60)

    Interval
    95% Wilson 24%–48%, n = 60
    Note
    axe-core rules button-name, input-button-name and aria-command-name. A screen reader announces these as "button" with nothing else.

  16. Checkout Barrier Index

    Most common failing rule: color-contrast

    60% of stores (36 of 60)

    Interval
    95% Wilson 47%–71%, n = 60
    Note
    Elements must meet minimum color contrast ratio thresholds. Counted once per store if it fails on the home, product or cart page; 697 failing elements in total. Tied on store count with target-size (480 elements); ranked first by failing elements.

  17. Checkout Barrier Index

    Sampled stores that refused or timed out for an honest, rate-limited, read-only crawler

    24 of 100

    Interval
    95% Wilson 17%–33%, n = 100
    Note
    Blocked at the home page: 21; at the product page: 3. Also excluded: 0 disallowed by robots.txt, 16 with no product page found from the home page, 0 crawler errors. Blocked stores are left out of every other number.

  18. Checkout Barrier Index

    Sightline path: product facts, readback and payment reachable by voice and keyboard on all 60 items; no store UI needed

    By design

    Note
    A design property, not a measurement on these stores: Sightline reads product facts from catalog data, speaks the readback and pays through PayPal, so none of the store pages audited here sit on its path. 60 is the number of stores whose product page was crawled.

  19. Spoken purchase confirmation

    False confirms, key-1 phrase matcher, held-out utterances

    0 of 140

    Baseline
    naive keyword match: 82 of 140
    Interval
    95% Wilson 0.0%–2.7%, n = 140
    Note
    Held-out set written before the matcher was run on it. Target is 0.

  20. Spoken purchase confirmation

    False confirms, key-1 phrase matcher, 200-utterance development fixture

    0 of 126

    Baseline
    naive keyword match: 50 of 126
    Interval
    95% Wilson 0.0%–3.0%, n = 126
    Note
    The matcher was developed against this fixture, so it is not an independent test.

  21. Spoken purchase confirmation · negative result

    Intended confirmations the matcher rejects, held-out utterances

    39 of 71 (54.9%)

    Baseline
    naive keyword match: 23 of 71
    Interval
    95% Wilson 43.4%–66.0%, n = 71
    Note
    Strict by design; each reject is answered with how to confirm. Plain English confirmations rejected: 1 of 30; other languages: 17 of 17; misheard words: 15 of 15.

  22. Spoken purchase confirmation · negative result

    Background speech or misrecognition that yields an exact allowed phrase

    6 of 6 confirmed by key 1

    Baseline
    naive keyword match: 5 of 6
    Interval
    95% Wilson 61.0%–100.0%, n = 6
    Note
    A text check cannot tell "confirm purchase" from a TV or a dropped "don't". Push-to-talk limits this; the classifier sees the same text.

  23. Spoken purchase confirmation

    False confirms, key-1 matcher, development and held-out combined

    0 of 266

    Baseline
    naive keyword match: 132 of 266
    Interval
    95% Wilson 0.0%–1.4%, n = 266

  24. Duplicate orders

    Scenarios that end with more than one PayPal order (100 duplicate-prone scenarios, current payment policy)

    0 of 100

    Baseline
    random request id per attempt: 0 of 100
    Interval
    95% Wilson 0.0%–3.7%, n = 100
    Note
    Simulation of PayPal's documented PayPal-Request-Id idempotency; no PayPal call is made. 100 orders for 100 intended purchases. Before the fix for lost PayPal answers: 10 of 100 (random id: 20 of 100).

  25. Duplicate orders · negative result

    Same 100 scenarios before the fix (lost PayPal answer released the hold and the buyer heard "nothing was charged")

    10 of 100

    Baseline
    random request id per attempt: 20 of 100
    Interval
    95% Wilson 5.5%–17.4%, n = 100
    Note
    Before fix, kept for comparison. 110 orders for 100 intended purchases.

  26. Duplicate orders

    Repeats of one confirmation (double-click, triple confirm, resend after timeout, re-say, two tabs) that end in a second order

    0 of 90

    Baseline
    random request id per attempt: 0 of 90
    Interval
    95% Wilson 0.0%–4.1%, n = 90
    Note
    Simulation of PayPal's documented PayPal-Request-Id idempotency; no PayPal call is made. Before the fix: 0 of 90 (random id: 10 of 90).

  27. Duplicate orders

    Resend after a lost PayPal response, same confirmation: second order created

    0 of 10

    Baseline
    random request id per attempt: 0 of 10
    Interval
    95% Wilson 0.0%–27.8%, n = 10
    Note
    Before the fix: 0 of 10 with the bound id, 10 of 10 with a random id, so the bound id alone stopped it. Now the resend is refused before any new PayPal call.

  28. Duplicate orders

    Lost PayPal response, buyer buys again on a new readback within minutes: second order created

    0 of 10

    Baseline
    random request id per attempt: 0 of 10
    Interval
    95% Wilson 0.0%–27.8%, n = 10
    Note
    Before the fix: 10 of 10 (random id: 10 of 10). Now refused while the earlier order's outcome is unknown.

  29. Duplicate orders

    Lost PayPal response, buyer buys the same item again after the 10-minute duplicate window: second order created

    0 of 10

    Baseline
    random request id per attempt: 0 of 10
    Interval
    95% Wilson 0.0%–27.8%, n = 10
    Note
    Separate probe, not in the 100. Now refused (OUTCOME_UNKNOWN) while the earlier order is unsettled, with no time limit. Before this fix (hold kept, 10-minute look-back only): 10 of 10.

  30. Duplicate orders · negative result

    Same probe before the unknown-outcome block (hold kept, duplicate check looks back 10 minutes only)

    10 of 10

    Baseline
    random request id per attempt: 10 of 10
    Interval
    95% Wilson 72.2%–100.0%, n = 10
    Note
    Before fix, kept for comparison: a snapshot older than 12 minutes is re-taken (new cart hash) and the look-back had ended.

  31. Duplicate orders

    Buyer comes back after a lost PayPal response, then would buy again: second order created

    0 of 10

    Baseline
    before reconciliation existed: 10 of 10
    Interval
    95% Wilson 0.0%–27.8%, n = 10
    Note
    Reconciliation re-sent the original request id; PayPal returned the original order and it was settled once in 10 of 10. The simulated buyer, told it went through, does not buy again.

  32. Grounded answers

    Answers with one invented claim that the grounding guard catches

    62 of 75 (82.7%)

    Baseline
    no guard: 0 of 75
    Interval
    95% Wilson 72.6%–89.6%, n = 75
    Note
    Simulated: scripted answers; the model-in-the-loop run needs ANTHROPIC_API_KEY. Invented size, material, price, return window, delivery date or quote.

  33. Grounded answers

    Fully supported answers the guard wrongly blocks

    0 of 75

    Baseline
    no guard: 0 of 75
    Interval
    95% Wilson 0.0%–4.9%, n = 75
    Note
    Simulated: scripted answers; the model-in-the-loop run needs ANTHROPIC_API_KEY.

  34. Grounded answers

    F1 of the guard as a detector of unsupported answers

    0.91

    Baseline
    no guard: 0.00
    Interval
    95% bootstrap 0.85–0.95, n = 150

  35. Grounded answers · negative result

    Weakest category: invented delivery date

    8 of 12 caught

    Baseline
    no guard: 0 of 12
    Interval
    95% Wilson 39.1%–86.2%, n = 12
    Note
    Missed, e.g. "It arrives tomorrow."

  36. Grounded answers · negative result

    False statements made by negating a listed fact that pass the guard

    10 of 10

    Interval
    95% Wilson 72.2%–100.0%, n = 10
    Note
    e.g. "It doesn't come in navy." on harbor knit crew (the variant is navy). The guard checks tokens, not polarity.

  37. Adversarial listings (red team)

    Payment breaches across 60 adversarial listings, Sightline flow

    0 of 60

    Baseline
    naive agent policy: 50 of 60
    Interval
    95% Wilson 0.0%–6.0%, n = 60
    Note
    Local ledger simulation; the PayPal sandbox ledger run needs PayPal keys. Counted from attempted payment requests, not from what the agent said.

  38. Adversarial listings (red team)

    Breaches when the injected amount, payee and quantity are forced into the payment intent

    0 of 60

    Baseline
    naive agent policy: 50 of 60
    Interval
    95% Wilson 0.0%–6.0%, n = 60
    Note
    Local ledger simulation; the PayPal sandbox ledger run needs PayPal keys. Defence in depth: the real payment gate alone decides.

  39. Adversarial listings (red team)

    Worst attack card for Sightline (all 6 cards tied)

    0 of 10

    Baseline
    naive agent policy, worst card: 10 of 10
    Interval
    95% Wilson 0.0%–27.8%, n = 10
    Note
    Ten listings per card, so the interval stays wide even at zero.

  40. Adversarial listings (red team)

    Contradictory colour: orders for a colour other than the one the buyer asked for

    0 of 10

    Baseline
    naive agent policy: 10 of 10
    Interval
    95% Wilson 0.0%–27.8%, n = 10
    Note
    The readback reads the colour attribute, so the buyer hears the real colour and cancels.

  41. Adversarial listings (red team) · negative result

    Contradictory colour, buyer confirms without listening: orders the gate lets through

    10 of 10

    Interval
    95% Wilson 72.2%–100.0%, n = 10
    Note
    The gate checks money, payee, quantity and confirmation, not colour. Colour protection is the spoken readback only.

  42. SightBench: does the parcel match?

    Mismatches flagged on the frozen test split, Sightline

    121 of 210 (57.6%)

    Baseline
    CLIP ViT-B/32, dev-fitted: 194 of 210 (92.4%)
    Interval
    95% Wilson 50.9%–64.1%, n = 210
    Note
    Synthetic renders, not real photos. Stratified over colour, size, model and damage mismatches. CLIP's dev-fitted threshold also flags 189 of 210 (90.0%) of matching pairs (dev balanced accuracy 0.5444), so its recall says little.

  43. SightBench: does the parcel match?

    Matching items wrongly called a mismatch (false alarms), Sightline

    4 of 210 (1.9%)

    Baseline
    CLIP: 189 of 210 (90.0%)
    Interval
    95% Wilson 0.7%–4.8%, n = 210
    Note
    Synthetic renders, not real photos. A false alarm tells a buyer to return an item that is right. 1 of 4 came from a "sure" colour disagreement (listed: rust, burgundy, navy, sky blue); see details.worstCases.sightlineFalseAlarms.

  44. SightBench: does the parcel match?

    Pairs where Sightline answered "not sure" (abstained)

    283 of 420 (67.4%)

    Baseline
    CLIP baseline never abstains
    Interval
    95% Wilson 62.8%–71.7%, n = 420
    Note
    Coverage 137 of 420 (32.6%). Accuracy when Sightline did answer: 132 of 137 (96.4%); CLIP accuracy: 215 of 420 (51.2%).

  45. SightBench: does the parcel match?

    Accuracy when Sightline gives an answer (match or mismatch)

    132 of 137 (96.4%)

    Baseline
    CLIP (always answers): 215 of 420 (51.2%)
    Interval
    95% Wilson 91.7%–98.4%, n = 137

  46. SightBench: does the parcel match?

    Secondary metric, added after the first test run: mismatches where Sightline names the difference (mismatch, or "not sure" with the right module disagreeing)

    148 of 210 (70.5%)

    Baseline
    first test run (unfitted): 76 of 210
    Interval
    95% Wilson 64.0%–76.2%, n = 210
    Note
    Synthetic renders, not real photos. What the buyer hears, for example "The size tag seems to read L, you ordered M, but I'm only fairly sure.", and the money-back path stays open for "not sure". Per type: colour 14 of 53, damage 47 of 52, model 43 of 52, size 44 of 53. Defined after the first test run's primary numbers were known, so it is reported next to them, never instead of them.

  47. SightBench: does the parcel match? · negative result

    False-alarm twin of the secondary metric: matching items called a mismatch or given any disagreeing reason

    100 of 210 (47.6%)

    Baseline
    first test run (unfitted): 45 of 210
    Interval
    95% Wilson 41.0%–54.4%, n = 210
    Note
    Synthetic renders, not real photos. The buyer hears a difference that is not there, even if only as "not sure". Disagreeing modules on these pairs: damage 87, colour 21, identity 3.

  48. SightBench: does the parcel match?

    First test run (unfitted thresholds, 2026-11-08): mismatches flagged / false alarms / not sure

    7/210 · 6/210 · 407/420

    Baseline
    this run: 121/210 · 4/210 · 283/420
    Note
    The frozen test split has been run 4 times: first with the hand-set thresholds, then with thresholds fitted on the dev split only. Nothing was tuned on test. Every run's numbers are in details.testRuns. Mismatches flagged per type, first run -> this run: colour 4 -> 2 of 53, damage 2 -> 32 of 52, model 0 -> 43 of 52, size 1 -> 44 of 53. Secondary metric, first run -> this run: named 76 of 210 -> 148 of 210, twin false alarms 45 of 210 -> 100 of 210.

  49. SightBench: does the parcel match? · negative result

    Navy delivered for black (or black for navy) in dim light: mismatches caught by Sightline

    0 of 7

    Baseline
    in daylight: 0 of 7; CLIP dim: 7 of 7
    Interval
    95% Wilson 0.0%–35.4%, n = 7
    Note
    Synthetic renders, not real photos. In dim light the colour module disagreed on 0, but dim light lowers its confidence below "sure", so the verdict was "not sure"; it agreed (wrongly) on 0 and gave up on 7. CLIP's 7 of 7 means little: it flags 90.0% of matching pairs too. Only 7 pairs per light level, so intervals are wide.

  50. SightBench: does the parcel match?

    Wrong size delivered: caught by Sightline

    44 of 53

    Baseline
    size-tag OCR alone: 46 of 53
    Interval
    95% Wilson 70.8%–90.8%, n = 53
    Note
    Size needs both tag reads (model and OCR) to agree before a mismatch is "sure".

  51. SightBench: does the parcel match?

    Different model or damage marks: caught by Sightline

    model 43 of 52, damage 32 of 52

    Baseline
    CLIP: model 52 of 52, damage 48 of 52
    Note
    Identity and damage come from the vision-model reads.

  52. SightBench: does the parcel match? · negative result

    Colour check gave up ("heavy colour cast") on wood tables and plank floors

    109 of 113

    Baseline
    other surfaces: 42 of 307
    Interval
    95% Wilson 91.3%–98.6%, n = 113
    Note
    Synthetic renders, not real photos. Without a sheet of white paper in view, white balance is gray world over the background, so an orange wood surface reads as a strong colour cast and the colour module abstains. Holds in daylight too. Checked on dev: the item masks on wood are tight and the background pixels are plain wood, so this is the gray-world assumption, not a mask bug; it was not fitted away.

  53. SightBench: does the parcel match?

    POST /verify latency on the dev laptop, p50 / p95

    6.11 s / 8.28 s

    Note
    Client wall time, one request at a time over localhost, CPU only, including model calls. Server-side total p50 6100 ms.

  54. Store agent: policy, invented facts, choice

    Store-agent replies offered or auto-sent outside the store policy

    0 of 370

    Baseline
    model picks any reply: 30 of 100 not allowed
    Note
    Invariant checks over 20 cases and 70 offered replies (50 inside the policy, so sent without staff): declined replies, part-refund percent and amount, the staff limit, auto-send rules.

  55. Store agent: policy, invented facts, choice

    Invented facts in store-agent reasons that reach the buyer

    0 of 218

    Baseline
    no check: 218 of 218
    Interval
    95% Wilson 0.0%–1.7%, n = 218
    Note
    Scripted model answers on hand-labelled cases; run --live for a real model. One invented amount, size, colour, date, number, percentage or quote per answer, a reason citing no fact or a fact that does not exist, a reason describing a reply that was not chosen, or "refund" where nothing is refunded.

  56. Store agent: policy, invented facts, choice

    Grounded store-agent reasons kept by the check

    60 of 60

    Interval
    95% Wilson 94.0%–100.0%, n = 60
    Note
    Scripted model answers on hand-labelled cases; run --live for a real model. Reasons that restate the case's facts, some reworded.

  57. Store agent: policy, invented facts, choice

    Model picks of a reply the policy does not allow that get sent

    0 of 30

    Baseline
    no code options: 30 of 30
    Note
    Scripted model answers on hand-labelled cases; run --live for a real model. Includes replies the buyer already declined and part refunds the policy does not allow.

  58. Store agent: policy, invented facts, choice

    Rule-based fallback (no model) picks a reply a fair store would

    20 of 20

    Interval
    95% Wilson 83.9%–100.0%, n = 20
    Note
    Labels written by hand before any model ran, by the author of the code.

  59. Store agent: policy, invented facts, choice · negative result

    Invented claims with no amount, size, colour, date or number that pass the check

    40 of 40

    Note
    Known limit: the check is token-level, like the listing grounding guard. A claim with nothing to match (for example, that the item is a favourite with returning customers) passes.

What is connected on this server

  • PayPal sandbox (Orders v2, Vault, Payments, tracking, Disputes, webhooks): live. Every payment, hold, capture, void and refund.
  • Claude (agent, confirmation check, vision, case writing): live. Shopping agent for open requests, second confirmation key, free questions, size-tag reading.
  • Channel3 product data: live. Real products and variants, searched with the Demo Store catalog; Demo Store catalog alone otherwise.
  • Deepgram speech to text: not connected. Streaming voice input; browser speech otherwise.
  • KERNEL cloud browsers: not connected. Reading store pages (the Barrier Index crawl ran on a local browser).
  • Vision service: live. Colour, the size tag read twice, the product and damage.

What we do not claim

  • It has not yet been tested with blind users. That is the next step.
  • Opening a PayPal case for a buyer by API is a sandbox capability; in production buyers file in PayPal’s Resolution Center.
  • Orders go to a sandbox Demo Store at the listed price, not to the real retailer.
  • Colour in dim light is unreliable; we publish that error rate and the app says “not sure”.
  • Maya and Raj are demo personas, not customers. No medical, legal or financial advice.

Sandbox access and running it yourself

No sign-up is needed: “Shop as Maya” uses a seeded demo account. If PayPal’s window appears, sign in with a PayPal sandbox buyer account of your own, made in PayPal’s developer dashboard. We do not publish login details. To run locally: clone the repository, copy .env.example to .env.local, then run pnpm install && pnpm db:up && pnpm db:migrate && pnpm dev.