How Huesona scoring works

The pipeline has five steps, and every one of them is a pure function of your answers:

1. Normalize. Each of the 49 items feeds exactly one dimension. Reverse-keyed items (23 of the 49) are flipped first (6 − answer), then each dimension's items are averaged and rescaled from the 1–5 scale to 0–100. The output is your 13-dimension trait vector.
2. Match the class. Your vector is compared against all 12 class signatures by weighted distance (explained below, with a worked example). Closest class wins; the runner-up is kept and shown, so a near-miss is never hidden.
3. Match the subclass.The same distance calculation runs again — but only across the winning class's four subclasses, using smaller secondary signatures.
4. Match the element. Your 6-element tilt is scored on the residual— what is left of your pattern after the class's expected profile is subtracted — so the element adds information instead of restating the class.
5. Band the rarity + resolve badges. Pattern distinctiveness is compared against precomputed thresholds from a simulated reference population (details below), and badges resolve from fixed trait-and-motive rules.

One honest framing note before the math: the research supports the trait dimensions, not the fantasy names. The class, subclass, and element are an interpretation layer we built on top of the dimensional scores — we will never claim “science proves you're a Guardian.” The long version of that argument lives on the science page.

10 dimensions surface on your result as RPG stat bars; the other 3are Self-Determination Theory motives (Ryan & Deci, 2000) that stay internal — they flavor badges and result text but are never shown as a stat bar, because motives are needs, not skills to grade.

Two special rules. Energy Rhythm is bipolar flavor:0 means evening-leaning, 100 means morning-leaning, 50 means no strong lean — it is a spectrum, not a “higher is better” score, and no class signature uses it, so your chronotype can never decide your class. The three motives are internal: autonomy, competence, and relatedness shape which badges you earn and how your result reads, but they never appear as a bar to compare against anyone.

Class matching in Huesona is a weighted distance calculation: each class declares 3–6 signature traits with a target score and a weight, and you are assigned the class whose targets your trait vector sits closest to. No class scores you on all 13 dimensions — only on the few traits that define it, which is what keeps every match explainable. The formula, for one class:

distance = √( Σ weight × (your score − target)² ÷ Σ weight )

The units are score points (0–100), so a distance of ~6 means “on the traits this class cares about, you sit about 6points from its ideal, weighted toward its defining traits.” The displayed fit is simply 100 − distance.

A worked example, computed by the actual engine. Take a hypothetical respondent whose vector includes Discipline 85, Harmony 80, Structure 76, Resilience 64, and Command 50. Here is that vector against the Guardian's real signature (these are the live targets and weights from our content data, not illustrative numbers):

Square each gap, multiply by its weight, average, take the square root: the distance comes out to 5.85 points, a fit of 94. Running the full matcher over all 12 classes, this vector's best match is the Guardian (fit 94), with the Architect as runner-up (fit 88). The engine also records a human-readable “why” for the match — for this example: High Structure (76), High Discipline (85), High Harmony (80). Every real result carries the same trail, so an assignment is always inspectable, never an oracle's verdict. Ties are resolved by a fixed, documented class order — never by chance.

Rarity in Huesona measures how far a trait pattern sits from the middle of a simulated reference population — pattern distinctiveness, never a ranking of people and never a live human percentile. The reference is a synthetic population of 20,000 profiles, generated offline by a seeded Monte-Carlo simulation (seed 1337, so it is exactly reproducible) as a correlated multivariate normal parameterized from published statistics where they exist — BFI-2 domain and facet means and standard deviations (Soto & John, 2017), Big-Five inter-domain correlations (van der Linden et al., 2011, N = 44,971), and chronotype–trait correlations from morningness meta-analyses (Tsaousis, 2010) — with the remaining cells (the Exploration and motive dimensions, and the facet- and motive-level correlations) estimated under documented design rules and flagged as estimates in our research notes.

Your pattern's distinctiveness is its root-mean-square z-score across all 13 dimensions against that reference — roughly, the average number of standard deviations your scores sit from the reference means. That value is placed on percentile thresholds computed offline from the simulation and committed to the repository; the live engine only reads the committed numbers and never regenerates the population at runtime. The band cutoffs, as shares of the simulated population:

• Common — about 50% of simulated profiles
• Uncommon — about 28% of simulated profiles
• Rare — about 15% of simulated profiles
• Epic — about 6% of simulated profiles
• Mythic — about 1% of simulated profiles

The worked-example vector above lands in the common band (distinctiveness 0.62, around the 6th percentile of the simulated reference) — and that is a perfectly good result, because rarity is not worth. A common pattern means more simulated profiles share your shape; it does not mean a worse shape. Because the reference is a model, not a census, we never phrase rarity as “rarer than X% of humans.”

Yes — by construction. Scoring uses no randomness, no clock, and no per-user state: the only random number generator in the codebase is the offline one that built the rarity reference, and it never runs at scoring time. The result page recomputes everything from the trait vector encoded in the URL, so the same link reproduces the same class, subclass, element, rarity band, and badges — every time, on any device.

Two version stamps are written into every shared result: scoring version 2 (the math: normalization, distance, matching, rarity) and content version 1.1.0(the copy and class signatures). When we re-tune — say, adjust a class's signature weights or improve the element matcher — we bump the relevant version with a written migration note. An old link still decodes; the stamps let us detect that it was scored under an earlier engine, instead of silently pretending nothing changed. (Example: the v1 → v2 scoring change reworked element matching to use the residual profile, and the migration note says exactly that.)

All 49 items are original or adapted, with attribution, from the International Personality Item Pool (IPIP; Goldberg, 1999; ipip.ori.org), a public-domain library of validated personality indicators. We use no proprietary instruments and imitate none.

Three design rules keep the instrument honest. One item, one dimension: every question feeds exactly one trait, with no cross-loading, so you can trace any score back to the specific items that produced it. Likert 1–5: a five-point agree/disagree scale preserves trait degree — collapsing a continuous score into an either/or category at a cut-point is precisely the design flaw that makes type tests unstable, because most people sit near the cut and retest noise flips the label. Reverse-keying: 23 of the 49 items are phrased so that agreeing lowers the dimension score, which counters the tendency to just agree with everything (acquiescence bias).