Multiple Intelligence Mapping

Grade 10 students in the Philippines pick a senior high school strand that shapes what they can study afterwards. In practice that decision is made from grades and a short conversation with a guidance counsellor, both of which measure how a student has performed rather than what they are inclined toward.

Existing multiple intelligence tools were not much better. Most run a handful of questions per category, which produces a dominant intelligence that can flip between sittings and a recommendation nobody should act on.

The client wanted something a counsellor could actually put in front of a student: a longer instrument, two frameworks rather than one, and a result that explains itself instead of announcing an answer.

A student answers a Likert-scale instrument covering both frameworks. Every item is mapped to exactly one intelligence domain or one RIASEC dimension, so scoring never has to guess what a question was measuring.

The backend scores each domain independently, normalizes across domains, then runs the normalized profile through a weighted mapping to rank the four strands. Scores, the profile they produced, and the resulting ranking are all persisted, which is what makes historical reporting and cohort analytics possible later.

The frontend renders the profile as a distribution rather than a headline, and the student can export a PDF containing the full profile, the strand ranking, and suggested career pathways to take into a counselling session.

Administrators manage the question bank, watch participation rates, and view aggregate intelligence distributions across a cohort, which turns a per-student tool into something a school can reason about.

Two frameworks instead of one

Multiple Intelligence describes cognitive strength. RIASEC describes vocational interest. They are not the same thing, and the gap between them is informative: a student who scores high on logical-mathematical intelligence but low on investigative interest is a genuinely different case from one who scores high on both.

Ranking against the combination rather than against the top intelligence is what stops the system from telling every mathematically capable student to take STEM.

The cost: two instruments is a longer sitting, and attention drops off in the second half. Any bias that introduces lands unevenly across the frameworks depending on which one is administered last.

Normalizing before comparing domains

Domains do not have equal numbers of items. Comparing raw totals would mean the domain with the most questions wins most often, which is a property of the instrument rather than of the student.

The cost: normalizing discards how much evidence sits behind each score. A domain measured by four items and one measured by twelve end up looking equally confident, when the second is much better supported. Carrying an item count alongside each score and surfacing low-confidence domains would be the honest version.

Mappings in the database, not in code

The relationships between intelligences, interests, strands, and careers are rows in relational tables rather than constants in the scoring engine. A counsellor's recalibration is a data change, and the engine itself stays untouched.

The cost: the mappings lose every guarantee code would have given them. Nothing type-checks a weight, nothing prevents a row that quietly makes one strand unreachable, and a bad edit changes recommendations for everyone with no diff to review. This needs validation on write and a change log, and it has neither.

Pinning the question set per session

Question banks get revised. If a result references live questions, editing one silently rewrites the meaning of every past result that used it.

Each session locks the active version, so an old result stays interpretable against the instrument that actually produced it.

The cost: results from different versions are not strictly comparable, so the year-over-year cohort analysis an administrator would most want either compares across instruments or throws away history at each revision. The system stores enough to do this correctly and does not currently do it.

Explaining the recommendation

The result shows the contributing domain scores next to the ranking rather than the ranking alone. This was as much a design decision as a technical one: a counsellor who cannot see why the system said STEM has no way to disagree with it, and a recommendation a professional cannot challenge is one they will stop trusting.

The weights in the recommendation engine are informed judgment, not calibrated values. Nothing in the system compares a recommendation against what a student went on to choose or how they performed, which means there is no feedback loop and no way to know whether the weights are good. Persisting the results was the groundwork for that, and the loop was never closed.

I would also give scores a confidence measure. Right now a domain backed by four items and one backed by twelve are presented identically, and a counsellor has no signal that one of those numbers is much softer than the other. That is a small change to the scoring output and a meaningful change to how honestly the result reads.