Design Principles

1. This is a personality tracker, not a personality test

A "test" implies a single authoritative result — pass/fail, score, label. Quadrantology is not that. It is a tracking tool for something that evolves over time, like a mood journal or a fitness log. The word "test" is used in entry-level marketing copy because it's familiar, but the product experience pushes people toward the tracker framing as quickly as possible.

2. The model is continuous monitors, not spot tests

Reference products: continuous glucose monitors, sleep trackers, fitness trackers. These deal in trends, baselines, drift, and variance — not in single readings. A single glucose reading tells you almost nothing; the trend over days tells you everything. The same is true here. One run of the questionnaire is almost meaningless. The arc across multiple runs is the product.

A complementary reference is the Dexa scan model: a service you can use as a one-off (single body composition scan) or subscribe to annually for regular scans. The one-off gives you a snapshot; the subscription gives you a longitudinal picture that compounds in value over time.

3. Personal Circle, not social network

The relational feature is called the Personal Circle. It is not an address book, a social network, or a contact list. It is a small set of intimate people — partners, close friends, mentors, key colleagues — whose personality arcs you track alongside your own, because those relationships actively shape who you are. The model is closer to a therapist's genogram or a coach's relationship map than to LinkedIn connections.

Sharing is intentionally friction-ful and bilateral: you generate a share URL from your own logbook, send it to someone directly, and they add it to their circle. There is no follow, no discovery, no feed. The circle is private to each user and stored only in their logbook.

4. The main result is the personality arc, not a point state

Like a character arc in a story, what matters is the shape of the trajectory — where you started, where you moved, what inflection points appeared, whether you're converging or oscillating. A single archetype label is a thumbnail; the arc is the full picture. Features and copy should consistently reinforce this: the trendline is not a bonus feature, it is the core deliverable.

5. Data model first

The app is stateless — no server-side user data, no accounts. The logbook is the product. All feature design begins by updating the data model documentation to reflect what new data is needed and where it lives, before touching any code. If a feature can't be expressed as a clean addition to the data model, the feature design isn't ready yet.

6. Historical runs are never re-scored

A logbook entry is an honest record of what the scoring model computed at the time. Retroactively applying a new scoring model would be like altering a journal entry — it destroys the integrity of the arc. When a scoring model is updated, all past runs keep their original scores and their original model version. Analytics code handles mixed-model logbooks transparently: model version boundaries are visible annotations on trendline charts, never silently homogenized.

This also means every historical model version is preserved indefinitely. Old scores are only meaningful if the model that produced them remains accessible.

7. The Walk-Away Guarantee and data dignity

A personality logbook represents real time, honest self-reflection, and lived experience. That investment of attention belongs to the user, not to this service. We call this data dignity: your data should remain useful and interpretable on its own terms, independent of whether this product continues to exist.

How the guarantee is maintained:

• Every export file embeds the full scoring model documentation for every model version it references — weights, algorithm, archetype table, tie-breaking rules. No external lookup required.
• Scoring models are versioned and published under CC BY 4.0 from the moment each new version is released. No model version is ever deleted.
• The questionnaire is static HTML/CSS/JS with no runtime server dependency. It can be opened from a local file.
• Paid access features are layered on top of a fully functional free core. They are access mechanisms, not capability locks on the data itself.