Problem
The source was a public PDF announcement with thousands of candidate rows. Useful signals were buried in text, and direct record exposure would be inappropriate for a portfolio.
Case Study
RTA Exam Candidate Structure Analysis
A public-sector data case study built from an official Royal Thai Army exam announcement. I turned a long-form PDF candidate list into a structured, privacy-aware dashboard that validates row quality, analyzes venue allocation, and maps high-frequency prefixes to BORA registry-office codes.
15,817
Degree-level rows parsed
100%
Checksum validation pass
15
Top prefixes mapped
Approach
Parse the PDF into structured rows, validate the ID format, normalize venues, map top prefixes to official R-Code offices, and present only aggregate insights with masked identifiers.
Outcome
A source-grounded dashboard that shows data cleaning quality, venue distribution, registry-office clustering, and clear analytical limits.
Dataset & Validation Logic
- Source dataset: the official degree-level candidate list for the Army general knowledge exam (ภาค ก).
- Core fields extracted per row: seat number, 13-digit ID number, and exam venue.
- Validation step: every ID was checked with Thai 13-digit checksum logic before aggregate analysis.
- Cleaning step: venue strings were normalized to remove page artifacts and preserve a reliable two-venue distribution.
- Privacy step: all examples in the dashboard mask the ID number and avoid showing raw row dumps as the main output.
What the Analysis Answers
How many degree-level candidates were listed, and how were they split across exam venues?
Was the extracted data structurally clean enough to analyze with confidence?
Which 5-digit prefixes appeared most often, and what BORA registry offices do those R-Codes map to?
What can be stated safely from public data, and what must be left unsaid without stronger evidence?
Dashboard Preview
The output focuses on quality, structure, and limitations. It highlights venue allocation, top prefixes, and R-Code mapping while explicitly warning against unsupported demographic claims such as age or gender.
Stack used: HTML/CSS/JS dashboard + source verification + ID checksum validation
Key Insights
- The degree-level announcement contained 15,817 candidate rows, clean enough for row-level parsing.
- Checksum validation passed for every extracted ID row, which increased confidence in structural quality.
- Venue allocation was nearly balanced across the two Ramkhamhaeng campuses.
- The most frequent prefix was 11037, which can be decomposed into type digit 1 and R-Code 1037, mapped to Rajthevi local registration office from BORA’s table.
Data Governance & Limits
- This project intentionally avoids exposing full identification numbers and does not treat a public candidate list as license to publish raw personal data.
- R-Code mapping supports a registry-office interpretation, not definitive claims about current address, age, gender, or personal background.
- The work demonstrates the judgment to separate what the data can support from what would be overreach.