Case Study · Operations & Physical Traceability Systems

Internal Records & Storage Tracking System

The Internal Records & Storage Tracking System is a full-stack Java industry-immersion project designed to digitize the tracking of physical files, books, records, and other stored materials.

Items could be associated with structured physical locations, identified through QR codes or barcodes, and tracked as they were taken out, returned, transferred, disposed of, or reported missing. Each movement contributed to a historical log showing who handled the item, when it moved, and where it went.

Domain: Operations (Physical Record Traceability)
My Role: Immersion Trainee (Primary Implementer)
Provenance: Spring Valley Tech Corp →
Year & Origin: 2025 · Java Industry Immersion
Core Stack: React · Tailwind · Spring Boot · PostgreSQL
Runtime & Docs: Docker · Swagger / OpenAPI
Status: Completed Immersion Deliverable

Overview & System Positioning

Rather than acting as a standard inventory counter, the Internal Records & Storage Tracking System focuses on physical record traceability: knowing exactly where items are stored, who accessed them, where they moved, and their full custody timeline.

By pairing multi-tier physical storage locations with QR code and barcode scanning, the system transforms unstructured paper records into traceable digital entities.

System Purpose Physical storage hierarchy, unique item identification, scan-driven custody workflows, and append-oriented movement auditing.

Engineering Focus Full-Stack · Architecture · Data

Central Case-Study Traceability Flow

The system narrative highlights how physical records move through structured digital tracking:

Physical Record / Item (File, Book, Material)
        ↓
Unique QR / Barcode Tagging
        ↓
Assigned Storage Location (Room → Cabinet → Drawer → Container)
        ↓
Scan Interaction (Camera / Handheld Scanner)
        ↓
Record Interaction & Custody Check
        ↓
Who Handled It? · Where Did It Go? · When Was It Taken?
        ↓
Update Operational Lifecycle Status (Taken Out / Transferred / Disposed)
        ↓
Append Movement Log Entry
        ↓
Traceable Historical Audit Log

Physical Storage Hierarchy

To enable precise physical retrieval, storage locations are modeled as a multi-tier hierarchy rather than flat text fields:

Room A
 └── Cabinet 3
      └── Drawer 2
           └── Storage Box 8
                └── Stored Record / File

Precise Physical Retrieval Knowing an item is in "Cabinet 3, Drawer 2" saves staff significant search time compared to generic "Room A" tags.

QR Code & Barcode Dual Identification

SYSTEM-GENERATED QR CODES

System generates unique QR codes for new physical records
Printable QR labels attached directly to files or containers
Scanning opens record detail and action menu instantly

BARCODE REGISTRATION

Registers existing manufacturer or institutional barcodes
Eliminates requirement to re-label pre-coded physical assets
Supported via standard barcode readers and camera scanners

Scan-Initiated Workflows

Scanning an item's code initiates contextual operational actions without requiring manual database searching:

Physical Item Scan
        ↓
Identify Corresponding Record
        ↓
Display Current Storage Location & Lifecycle State
        ↓
Select Operation Menu:
├── [Take Out] ───► Record Handler + Destination + Timestamp
├── [Return] ─────► Assign Return Storage Location
├── [Transfer] ───► Origin → Destination Location Update
├── [Dispose] ────► Log Disposal Reason & Archive
└── [Missing] ────► Flag as Lost/Missing for Investigation
        ↓
Append Movement Log Entry

Item Lifecycle State Machine

Items transition through distinct operational states across their physical tenure:

Stored
  │
  ├── Take Out ─────────► Taken Out ─────────► Return ─────────► Returned (Stored)
  │
  ├── Transfer ─────────► Transferred (New Location)
  │
  ├── Dispose ──────────► Disposed (Archived Record)
  │
  └── Mark Missing ─────► Lost / Missing (Flagged)

Append-Oriented Movement History Log

A critical architectural decision was designing the movement log to be append-oriented. Every physical interaction appends a new historical entry containing:

Handler Identity: Who took, moved, or returned the item?
Timestamp: Exact date and time of the interaction.
Location Transition: Origin location and new destination location.
State Change: Status transition (e.g., Stored → Taken Out).
Operational Notes: Purpose, return expectations, or disposal reasons.

Historical Traceability Preserves the full historical timeline so staff can investigate who previously handled missing or misplaced items.

Dashboard & Operational Visibility

The system dashboard provides storage staff with high-level operational metrics:

Total Tracked Records: Overall count of registered physical files, books, and materials.

Storage Distribution: Breakdown of items across rooms, cabinets, and container boxes.

Currently Taken Out: Active list of items checked out by staff with handler details.

Disposed / Missing Counts: Audit summary of archived or flagged physical records.

Full-Stack System Architecture

PHYSICAL STORAGE
      │
      ▼
Hierarchical Location (Room → Cabinet → Drawer → Container → Item)
      │
      │ QR Code / Barcode Scan
      ▼
FRONTEND APPLICATION
React · Tailwind CSS (Responsive Web UI & Scanner View)
      │
      │ REST API Requests (JSON)
      ▼
BACKEND API SERVICE
Spring Boot (Java REST Controllers, Service Layer & Persistence Coordination)
      │
      │ PostgreSQL JDBC Connections
      ▼
RELATIONAL DATABASE
PostgreSQL (Current State + Append-Oriented Movement Log Tables)

SUPPORTING TOOLING:
├── Swagger / OpenAPI (API Interface Documentation)
└── Docker Container Runtime (Standardized Local Execution)

Relational Schema Design

PostgreSQL schema relationships connecting core operational entities:

Storage Hierarchy Tables: Self-referencing and parent-child location tables (Room → Cabinet → Drawer → Container).

Item & Tag Identifiers: Items linked to unique generated QR codes or registered barcodes.

Append Movement Logs: One-to-many relationship connecting an item to its ordered history of movement records and handlers.

Key Engineering Tradeoffs

1. Detailed Hierarchy vs. Data Entry Maintenance

Tradeoff: Multi-tier physical storage modeling enables precise item retrieval but requires staff to keep container locations updated.

2. Dual QR + Barcode Support vs. Implementation Complexity

Tradeoff: Supporting both generated QR labels and existing barcodes increased backend lookup complexity but allowed re-use of legacy asset tags.

3. Append-Oriented Logging vs. Log Volume Growth

Tradeoff: Appending historical log entries preserves audit traceability but requires efficient database indexing for fast history timeline queries.

System Validation

The application deliverable was validated through functional testing covering React UI components, Spring Boot REST endpoint responses via Swagger, PostgreSQL relational integrity, and containerized Docker runtime execution.

Verified Qualitative Outcomes

Digital Record Replacement Demonstrated how manual paper ledgers can be replaced with a structured digital tracking system.

Enhanced Physical Traceability Improved location precision down to specific cabinets, drawers, and container boxes.

Handler Accountability Created an explicit audit trail for who accessed, moved, or transferred physical materials.

Successful Full-Stack Java Immersion Delivered a complete React, Spring Boot, PostgreSQL, and Docker application for the Spring Valley Tech immersion program.

Retrospective & Industry Immersion Experience

Enterprise Java & Spring Boot Development

Building this system during the Spring Valley Tech immersion provided hands-on experience structuring Java REST APIs, persistence layers, and relational schema designs for operational enterprise software.