Rice Purity Test Questions and Versions
Written and reviewed by Adrian Vale, Editor. Reviewed . Fact-checked .
Rice purity test questions do not form one fixed list. Dated versions have distinct totals, rules, terms, and contexts. Modern web lists also vary. Rice Purity Test Plus will build trust through new wording, stable IDs, a version ID, and a checksum.
Why question lists vary
A long-running campus tradition can change as editors revise it. Questions can be added, removed, reordered, or rephrased. Scoring rules can also change.
Web publishing adds more change. A site may revise words, repair missing text, add ads, or copy another site. Those edits may not have a public change record.
As a result, the phrase “the questions” needs a version. Without a date or list ID, readers may be comparing different lists under one name.
The history gives the detailed chronology. This page focuses on wording and version control.
Verified item-count differences
The 1924 newspaper survey had ten questions. It was not the common modern list.
The 1988 issue had 150 numbered items. Its score started from 150.
A separate 1990 issue exists. We do not publish an exact count because a fresh image review was unavailable.
The 1998 issue identified itself as a 100-question test. It counted No answers.
These records cannot all be one unchanged list. The differences are direct proof of versioning.
Scoring differences matter
The 1988 rules subtract completed items from 150. The 1998 rules add No answers across 100 questions.
Both approaches can produce a higher score for fewer marked experiences. Yet the totals and question sets differ. Similar direction does not make the results interchangeable.
A score depends on its denominator and items. Changing either can change the result. Two people with the same behavior could receive different numbers on different lists.
The future Plus 100 will use 100 minus checked items. That math will describe only the approved Plus 100 version.
Why current web lists differ
Modern implementations often show 100 scored entries. Their wording and presentation can still differ.
Some pages contain altered text. Some have gaps. Some add key outside the scored sequence. Others describe their list as original without a public lineage record.
We do not use those sites as factual authorities. We also do not copy their wording, headings, or explanations.
A shown web list can prove what that site displays today. It cannot prove who wrote the words or when each edit occurred.
Modern lineage remains unresolved
The approved proof does not connect each editing step between the past scans and the common modern web list.
The 1988 and 1998 pages show distinct states. The 1990 page adds another state. Archive notes confirm more 1990s records, but some access is restricted.
No complete chain in this project names an author, date, and consent record for each modern item. We therefore describe the exact lineage as unknown.
Unknown does not mean each claim is false. It means the proof is not strong enough for a definitive public statement.
The rights-safe Plus 100 choice
The project has no written consent or qualified legal clearance for exact third-party wording. That wording will not be used as the project list.
The safe path is a Rice Purity Test Plus 100 written by this project. Its wording will be new. Its public label will make that status clear.
This is a review choice to limit risk. It is not legal advice. We do not claim that any older list is free of copyright, in the public domain, or cleared by law.
The United States Copyright Office explains that copyright can protect original expression. Its fair use guidance provides no automatic safe percentage.
Original wording requirements
Future questions must come from an approved topic plan, not from a rival list. A person must edit each item and review it for harm.
Wording should be clear, neutral, and concise. It must avoid shame, praise, diagnosis, and moral labels.
New wording must also stay consistent. Similar ideas should use stable terms. Unclear time frames or labels must be fixed before the list is frozen.
No actual questions are written in this phase. Categories and category counts also remain undecided until the list is authored.
Stable item IDs
Each future item will receive a stable internal ID. The ID will not depend only on its shown number.
Stable IDs help tests find an item after a wording fix. They also support change records without exposing answers.
An ID is not user data. It belongs to the static list. User selections will remain in browser memory and will not be transmitted.
Duplicate IDs will fail checks. Display numbers must also cover one through 100 exactly once after the list exists.
Version IDs
The ordered list will receive a lowercase version ID. It will name one exact frozen wording and order.
A key edit will create a new version. It will not silently overwrite the meaning of an older score.
Pages tied to the list will state that version in their data. General history or policy pages can use null because their claims do not depend on one question file.
Version IDs make comparisons more honest. A score without a version can hide a changed denominator or list.
Deterministic checksums
A checksum is a compact fingerprint of the ordered data. The build will calculate it in a repeatable way.
If wording or order changes, the checksum changes. The public questions-and-versions record will show the active checksum after the list is approved.
A checksum does not prove that wording is good or lawful. It shows that a public fingerprint matches one exact byte sequence and sort method.
The checksum process must be documented. Hidden cleanup rules would weaken its value.
Public change log
Each key wording or order change will receive a dated entry. A spelling-only fix will also be logged after content freeze.
The entry should name the version, item ID, type of change, and reason. It should not repeat sensitive words when a short note is enough.
The log will not include user answers. It will not claim that two version scores are directly comparable without proof.
Silent changes are prohibited because they make old scores impossible to interpret.
Sensitivity review
The subject includes adult and sensitive topics. Wording must be necessary, neutral, and suitable for an adult audience.
Review should remove graphic detail that adds no value. It should flag unclear consent words. It should avoid examples aimed at children and moral labels.
The future test will begin with an adult content notice. That notice will not pretend to verify age or identity.
Review tags help editors check the list. They must never become a tracking or ad signal.
Inclusive-language review
Past sources use terms from their period. A modern independent set does not need to preserve outdated labels.
Inclusive wording should describe acts without assuming gender, orientation, or relationship type. It should stay clear enough for a consistent answer.
Past terminology may appear in a dated explanation. For example, the 1998 meaning of MPS belongs to that source context. It should not control modern wording.
Inclusive editing must not be used to claim that the new list is an official revision. It remains independent.
Score comparisons across versions
Equal scores can hide different questions. A 90 on one list does not automatically equal a 90 on another.
The number of items may differ. The covered experiences may differ. Wording thresholds may differ. The audience and completion method may differ.
We will not merge results across question versions. We will not present cross-version ranks without a sound study.
Past sample figures must retain their original site context. They cannot become benchmarks for the Plus 100.
Why this page does not publish the complete list
The future quiz will be the only full, interactive view of the approved Plus 100. This page records counts, lineage, controls, and change history.
Repeating a full list here would copy sensitive content. It would also blur the line between version notes and the live product.
Past lists are not reproduced because rights and lineage remain unresolved. Modern rival lists are not reproduced because rival wording is not our source.
Readers can review the source register and the method without encountering a copied list.
What version integrity can prove
Stable IDs, version IDs, checksums, and logs can prove that this project controls its own changes. They can show which independent list produced a score.
They cannot prove that a modern web list is past. They cannot grant consent for third-party wording. They cannot make different version scores equivalent.
The honest outcome is useful but limited. Rice Purity Test Plus can publish an open version of its own. It cannot invent a missing chain of proof.
A practical release record
Each approved list should have a short public record that can be checked without exposing answers. It should give the version ID, release date, item count, checksum, and a brief change note. It should also state whether the score rule changed.
A punctuation fix may receive a new patch version. A change that can affect an answer needs a clearer version change. Adding, removing, or replacing an item must never hide in a silent edit.
The record should identify the internal review completed for that release. It must not name a reviewer who did not participate or imply outside approval. If the project remains a one-person operation, the record should say so plainly.
Handling retired items
An item may be retired because it is unclear, too invasive, out of date, or much like another item. This does not erase its history. The log should keep the stable ID, name its last version, and explain why it left without needlessly repeating sensitive words.
A replacement receives a new stable ID. Reusing an old ID for new wording would break the audit trail and make stored version data false. The released list, not a recalled label, defines what a score means.
What readers will be able to verify
Readers should be able to tell the active Plus 100 from each prior Plus release and from past Rice records. They should be able to check that a shown version matches a public checksum. They should also see whether a later fix changes its meaning.
These controls make the work open, but they do not prove that the quiz is a science tool. The test remains a voluntary social quiz. Version notes make its limits easier to see; they do not remove them.
No release record will hold a person’s answers or link a result to an account. A version check needs only public list data and work in the browser. It does not need a user database.
If a checksum fails, the page must not claim the list passed its check. Work should stop until the file and set checksum agree. This shows a mismatch before it can blur two releases.