Lost-and-found systems on campuses are difficult to scale. Lost items are usually described with vague text, while found items often sit in administrative offices with little to no structured metadata.
ReClaim tackles this problem by turning lost-and-found into a computer-vision-powered visual search system built specifically for campus communities.
Instead of relying solely on descriptions like "black water bottle lost near the library," users can upload photos of an item and let an AI-powered visual search pipeline identify visually similar items across the campus.
The goal is simple:
Upload → Search visually → Find a match → Reclaim your property.
How It Works
ReClaim combines a mobile-first reporting experience with a vision inference pipeline and campus-scoped vector search.
┌─────────────────────────┐
│ Image Capture │
│ 3:4 Crop │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ FastAPI Backend │
│ Python + PyTorch │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ CLIP Vision Model │
│ Image → Embedding │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Cosine Similarity │
│ Vector Comparison │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Match Thresholding │
│ > 90% Similarity │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Firestore + Notification│
│ Match Found │
└─────────────────────────┘
Technical Architecture
Mobile Frontend
Built using:
- Next js + Capacitor
- TypeScript
- Tailwind CSS
- Custom camera modules
The camera workflow enforces a 3:4 aspect-ratio crop, creating standardized visual inputs before they reach the inference pipeline.
Users can upload up to 6 photos per item, allowing the system to capture different perspectives, textures, colors, and identifying characteristics.
AI Inference Service
The backend is powered by:
- Python
- FastAPI
- PyTorch
- CLIP (Contrastive Language-Image Pre-training)
Images are processed through the CLIP vision encoder to generate dense visual embeddings.
These embeddings capture high-level visual characteristics such as:
- Shape and geometry
- Color distribution
- Texture
- Object appearance
- Visual similarity
Rather than storing only human-written descriptions, ReClaim creates a machine-readable representation of the item's visual identity.
AI-Powered Visual Matching Pipeline
1. Image Preprocessing
When a user reports an item, the uploaded images are normalized through the camera pipeline.
The standardized 3:4 crop helps reduce irrelevant background information and creates more consistent model inputs.
Users can provide multiple images to improve the representation of the object.
2. Dense Embedding Extraction
Each image is passed through the CLIP vision transformer.
Input Image
│
▼
CLIP Vision Encoder
│
▼
Visual Features
│
▼
Dense Embedding Vector
The resulting embedding represents the visual characteristics of the object in a high-dimensional numerical space.
For our implementation, the generated representation is treated as a 512-dimensional embedding vector.
3. Similarity Search
When a new lost or found item is submitted, its embedding is compared against active items within the same campus.
The backend calculates cosine similarity between the target embedding and candidate embeddings.
Target Item
│
▼
Embedding A ─────────┐
│
▼
Cosine Similarity
▲
│
Embedding B ─────────┘
│
▼
Similarity Score
High-scoring candidates are surfaced as potential matches.
A configurable similarity threshold is used to filter low-confidence results, with the current workflow targeting matches above 90% similarity.
Campus-Scoped Search
One of ReClaim's key design decisions is campus-level isolation.
Instead of searching a massive global database, queries are restricted to the user's verified campus.
For example:
User
│
▼
RV University
│
├── Lost Items
├── Found Items
└── Reclaimed Items
This significantly reduces the search space while making the results more relevant.
A lost laptop at one university should not be compared against thousands of unrelated laptops reported across an entire city.
Firestore Data Architecture
ReClaim uses Firebase as its backend platform.
The system leverages:
- Firestore for document storage
- Firebase Authentication for campus OAuth / SSO
- Firebase App Distribution for Android testing and release cycles
The core Firestore structure is organized around campuses:
/campuses/{campusId}/items/{itemId}
├── itemId: String
├── reporterId: String
├── status: LOST | FOUND | RECLAIMED
├── name: String
├── description: String
├── locationFound: String
├── dropoffDestination: String
├── imageURLs: Array[String]
└── embeddings: Array[Float]
Potential matches are stored separately:
/campuses/{campusId}/matches/{matchId}
├── targetItemId: String
├── candidateItemId: String
├── similarityScore: Float
└── timestamp: Timestamp
This separation allows the system to maintain the original item records while independently tracking generated match relationships.
Dark-Mode UX
Despite the complexity of the AI backend, ReClaim is designed around a simple principle:
The user shouldn't need to understand the AI.
The interface is optimized for fast reporting and high-visibility interaction.
Location Scoping
A verified campus badge such as:
RV University • Main Campus
makes the search boundary explicit to the user.
🎮 Action Router
The home screen immediately separates the two primary workflows:
"Lost Something?"
and
"Found Something?"
The retro pixel-art cards create a distinctive visual identity while making the application's primary actions immediately recognizable.
Report Workflow
Users can provide:
- Item name
- Description
- Photos
- Location
- Drop-off information
Found-item reports can also specify a physical destination such as:
Admin Block Reception
This connects the digital discovery system with the physical lost-and-found process.
Match Feed
Potential matches are presented as image cards containing:
- Item photos
- Lost / Found status
- Similarity confidence
- Relevant metadata
- Match information
This allows users to visually inspect potential matches instead of manually searching through hundreds of text-based reports.
Authentication & Campus Trust
ReClaim is designed around verified campus communities.
Authentication through Firebase allows the platform to associate reports with authenticated users while maintaining campus-level boundaries.
This creates a more trustworthy environment than a completely open lost-and-found marketplace.
Why Visual Search?
Traditional lost-and-found systems depend heavily on metadata.
For example:
"Black bottle"
"Lost near library"
"Found in Block B"
The problem is that users rarely describe objects consistently.
Two users might describe the same object as:
"Black Hydro Flask"
"Black water bottle"
"Metal bottle"
"Black flask with sticker"
A visual embedding provides another layer of information.
Instead of asking:
"Did someone use the exact same words?"
ReClaim asks:
"Does this object look like the one someone reported?"
Key Technical Challenges
1. Visual Ambiguity
Many campus objects look extremely similar.
Two black water bottles may have nearly identical shapes but belong to different people.
Because of this, similarity scores should be treated as candidate matches rather than absolute proof.
2. Background Noise
Photos can contain desks, floors, people, walls, and other irrelevant visual information.
The standardized 3:4 cropping workflow helps make the object itself more prominent within the model input.
3. Multiple Perspectives
A single photograph may not capture enough information to distinguish an object.
Supporting up to 6 photos per report allows ReClaim to build a stronger visual representation from multiple viewpoints.
4. Search Scalability
As the number of reports grows, comparing every new image against every stored embedding becomes increasingly expensive.
The current architecture establishes the foundation for eventually introducing dedicated vector-search infrastructure and approximate nearest-neighbor indexing for much larger campuses.
Future Improvements
ReClaim's current architecture can be extended in several directions:
- Approximate Nearest Neighbor (ANN) vector search
- Dedicated vector databases such as FAISS or Qdrant
- Multimodal text + image retrieval
- OCR for serial numbers and labels
- Object detection before embedding generation
- Duplicate report detection
- Push notifications for newly discovered matches
- Cross-campus federation
- Admin dashboards for lost-and-found offices
- Human verification before confirming a reclamation
- Confidence calibration using real campus data
A particularly interesting future direction is multimodal retrieval, where both the uploaded image and the user's textual description contribute to the final ranking.
What Makes ReClaim Different?
ReClaim isn't simply another lost-and-found form.
It combines:
Computer Vision + Vector Embeddings + Campus Authentication + Real-World Item Recovery
into a single workflow.
The system connects the entire process:
Physical Object
↓
Photo
↓
AI Embedding
↓
Campus-Scoped Search
↓
Potential Match
↓
User Verification
↓
Physical Reclamation
The ultimate goal is to make lost-and-found systems searchable, scalable, and intelligent.
Built For Campus Communities
ReClaim is designed around a simple observation:
Lost-and-found desks already have the objects. The problem is finding the right person.
By turning physical objects into searchable visual representations, ReClaim aims to bridge that gap.
Instead of manually browsing lists of vague descriptions, students can simply show the system what they're looking for.
See it. Search it. Reclaim it.
🔧 Tech Stack
| Layer | Technology |
|---|---|
| Mobile | React Native, Expo, TypeScript |
| Styling | Tailwind CSS |
| Backend | Python, FastAPI |
| AI / ML | PyTorch, CLIP |
| Authentication | Firebase Auth |
| Database | Firestore |
| Distribution | Firebase App Distribution |
| Search | Dense Vector Embeddings + Cosine Similarity |
ReClaim
A campus-centric visual search engine for lost and found property.
Don't describe what you lost. Show us.
Top comments (0)