Ayush · Yadav the record room · case file 3 of 7

¶ case file 3 of 7 · visual assist — filed 2025-03 · last verified 2026-08

status: in progress — beta, per the readme

↳ filed at the review — ¶ 10 · 22:23 · receipt: 71 passed · 0 skipped

the line stands dark at 22:23 — the archive lamp is lit; a record is read in the light it needs.

Visual Assist

An iOS accessibility app that meets the room before its user does. LiDAR finds the obstacles, Vision reads the text, haptics and speech carry the answer — and the processing stays on the device.

role
ios accessibility engineer
timeframe
2025-03 to present
stack
Swift · SwiftUI · ARKit · Core Haptics · Vision
repo
yadava5/VisualAssist @ 22ebdaa ↗

[ problem ] · § as found

A visually impaired user needs the room described now, not after a round trip — and never at the price of shipping camera or location context to somebody else’s server.

constraints —

  • Prioritize on-device processing for privacy.
  • Support LiDAR obstacle detection and haptic feedback.
  • Respect VoiceOver-first interaction patterns.
  • Use native iOS frameworks for performance and accessibility.
on-device — nothing leaves itnavigation modelidar ⟶ haptic pulses · speechawareness modesvision ocr — textlocal recognitioncamera frames ⟶ read aloudvoiceover-first interaction

fig. 1 — two modes, one device: lidar guides, the camera reads. the two vision paths never touch the lidar — the modes are independent.

a drawn plate, at rest — not a screenshot. topology from the audited source at 22ebdaa: navigation reads lidar, the awareness modes read camera frames, and the modes share nothing but the device.

[ architecture ] · § fig. 2, inked

ARKit and Vision process device context locally, then SwiftUI and VoiceOver expose guidance through speech and haptics.

Camera

RGB frames — the input both vision modes read

frames

Local Vision

On-device recognition

frames

Vision OCR

Text reading

distance, on the navigation mode

LiDAR

Depth and obstacle signals

local recognition — Local Vision

interaction layer

VoiceOver

Accessible controls

text context

Haptics + speech

Guided feedback

fig. 2 — the system, inked.

[ decisions ] · § as filed

d1 — use native ios frameworks · accepted

LiDAR, Vision, haptics, and VoiceOver are first-class platform capabilities.1

1 tradeoff — The app targets capable iOS devices rather than every phone.

d2 — keep processing on-device · accepted

Camera and navigation context is sensitive.2

2 tradeoff — Local inference constrains model and compute choices.

[ validation ] · § the receipts

at a glance — 5 of 5 terminate in pinned artifacts

validation

walks the receipts below, top to bottom, and marks each row this page can verify: a check where a pinned artifact resolves, a ring where the trail ends in an on-page capture, a dash where a claim is described only. walked once, the result settles here and stays.

  1. 01claim: 71 tests cover models and utilities, and all 71 pass — executed on iOS 26.5 and again on 26.2, 0 failed, 0 skipped.

    method: xcodebuild test, .xcresult parsed with xcresulttooldate: 2026-05

    [public]

  2. 02claim: VoiceOver-first flows and voice commands are the interaction model, documented in the public README.

    method: README feature table, checked against the sourcedate: 2026-05

    [public]

  3. 03claim: ARKit, Vision OCR, human rectangles, and animal recognition are the vision paths; no custom Core ML model file was present in the audited repo.

    method: source audit of the vision code pathsdate: 2026-05

    [public]

outcomes

  1. 04claim: LiDAR obstacle detection with haptic feedback is the core guidance loop.

    method: README + source; no field-usage metric is claimeddate: 2026-05

    [public]

  2. 05claim: Vision OCR reads environmental text aloud via speech synthesis.

    method: README feature table + source pathsdate: 2026-05

    [public]

ci rows link the public run · repo pins are the exact commits verified 2026-08.

what i’m NOT claiming —

  • No custom-trained Core ML model is claimed — the vision paths use Apple’s frameworks, and no model file was present in the audited repo.
  • No live camera, location, or user sensor data is shown anywhere in this file.

[ corrections ] · § the register

  • erratum · 2026-05

    An earlier draft took its count from the repo’s CI run title rather than from the test tree; that draft is not in this repository’s history, so the figure it printed cannot be quoted back here. The audited count in the current tree is 71 test functions, and the receipt above links the tree so the number can be checked.

  • note · 2026-08

    Until now this file said “71 test functions”, deliberately — a count of what the tree declared, because the suite had never been run. Not in CI, which had no `xcodebuild test` step, and not locally, because xcodebuild wanted an iOS runtime the machine did not have. A count is a weaker claim than a result and it was worded to admit that. The runtime was installed on 2026-08-03 and the suite ran: 71 passed, 0 failed, 0 skipped, on iPhone 17 Pro under iOS 26.5, and again under 26.2 when the simulator resolver happened to pick a different device. The claim above is now a result. The static count did not move, which is the outcome that should be least surprising and was still worth checking.

[ appendix ] · § artifacts, indexed

artifact index —