A plain-language walkthrough of how the platform is built so your identity can never be connected to your review, even in a data breach or legal proceeding.
Most platforms protect your identity with a policy: "We promise not to share your information." Upward Review takes a fundamentally different approach. Your identity is never stored in the system in the first place. There is no account, no profile, no email address, and no name attached to your review in the database. The protection is architectural: it is built into how the system works, not bolted on as a promise.
This means your anonymity does not depend on anyone keeping a secret. It depends on the fact that there is no secret to keep. The system simply does not contain the information that would be needed to identify you.
Think of it this way: a locked filing cabinet protects your information with a lock. Upward Review protects your information by never putting it in the cabinet at all.
Before you can submit a review, Bryson verifies that you actually worked at the firm you're reviewing. This happens through a casual LinkedIn conversation, completely separate from the review database. The two systems have no connection whatsoever.
Your LinkedIn conversation with Bryson is just that: a conversation on LinkedIn's platform. It is not logged, recorded, or stored by Upward Review. The review database has no field for "reviewer identity," no foreign key linking to a person, and no reference to the verification conversation. They exist in entirely separate worlds.
The verification conversation and the review database exist in completely separate systems with no connection between them.
Here is a concrete breakdown of what information exists in the review database and what does not. This is not about what we "choose" to keep private. These fields literally do not exist in the system.
There is no "user" table. There is no "reviewer" column. The review exists in the database as a standalone piece of content with no link back to any person.
When Bryson verifies your identity, he generates a submission token, a random alphanumeric string like a7f2c9e1-3b4d-.... This token is locked to a specific firm (so you can only review partners at the firm where you worked) and has an expiration date.
The critical point: the token is generated randomly by the system. It is not derived from your name, email, or any personal information. Once Bryson sends you the link containing the token, the system has no record of who received that link. The token connects to the firm name, not you. And after you submit your review, the token value itself is permanently deleted from the database, so even the URL can never be traced back to any specific review.
The token exists only long enough to submit the review. Immediately after, it is permanently erased from the database. No URL, no token value, no link back to the review.
Once your review is submitted, the system permanently erases all traceable metadata from the database in a single operation. This includes the token value, any internal admin notes or code words used during verification, and all timestamps associated with your submitter record and your review. The system does not simply mark these as "used." It deletes them entirely. This means that even if someone later discovers the original token URL (for example, through a discovery request targeting LinkedIn messages), there is no way to look up that token in the database. And because timestamps are also erased, there is no way to correlate when a link was sent with when a review appeared. The link between the URL and the review no longer exists. It has been destroyed, not hidden.
Even the platform operator cannot reverse this. Once erased, there is no mechanism, query, or workaround that can reconnect a token URL to a specific review. No token, no timestamps, no code words, no trail. The data simply does not exist.
Even though the database does not contain identifying information, the review data itself is still protected by multiple layers of security. Here is how those layers work, from the outside in:
The administrative audit log records every approval, rejection, and deletion: who did it, when, and what was affected. This ensures accountability for anyone with administrative access, while still keeping reviewer identities unknown because those identities were never recorded in the first place.
This is the question that matters most, and the answer is straightforward: even if someone gained full, unrestricted access to the entire database, they would not be able to determine who wrote any given review.
Here's why. A typical platform stores user accounts linked to content. If that platform is breached, an attacker can see: "User john.doe@email.com wrote this review." Upward Review has no user accounts. There is no email field, no name field, no login history, no session logs tied to a person. The review simply exists as an anonymous piece of content linked to a random token.
An attacker with full database access would see reviews, partner names, and firms. They would not see tokens (erased), timestamps (erased), verification code words (erased), or any information about who wrote the reviews, because that information was either never collected or has been permanently destroyed.
You cannot steal what was never there. A breach of the Upward Review database would reveal the reviews themselves, but not who wrote them.
If you've worked in Big Law, you know how discovery works. A subpoena can compel a company to produce documents and data in its possession. This is a legitimate concern, and it's one the platform was designed to address at the architectural level.
The legal principle is simple: you cannot be compelled to produce what you do not possess. Upward Review's database does not contain reviewer names, emails, IP addresses, or any other personally identifying information. If a subpoena were issued demanding the identity of a reviewer, there would be nothing to produce. The information does not exist in the system.
This is not a matter of policy or privilege. It is a matter of technical fact. The database schema has no column for reviewer identity. There is no lookup table mapping tokens to people. Even Bryson himself cannot determine who wrote a specific review once it has been published, because the system was never built to track that relationship.
A court can order you to open a safe. It cannot order you to produce something the safe was never designed to hold.
What about the token URL itself? Even if a discovery request targeting LinkedIn messages revealed the submission link Bryson sent you, it would lead nowhere. The token value is permanently erased from the database after your review is submitted. There is no record to match it against. The URL is a dead end.
What about the code words used during verification? Those are also erased from the database the moment your review is submitted. Even if someone found a code word in a LinkedIn DM, there would be no matching record in the system to connect it to. The same applies to timestamps: because all timestamps are wiped on submission, there is no way to correlate when a link was sent with when a review was created. The timing trail simply does not exist.
Additionally, the LinkedIn verification conversation is an informal direct message exchange on a third-party platform. It is not a formal record maintained by Upward Review, and a code word exchange in a LinkedIn message that looks like a normal recruiting outreach would not, on its face, identify someone as a reviewer of any particular partner.
For associates who want the highest possible level of protection, particularly if the experience they want to share involves especially sensitive conduct, there is an additional option: submit your review over a phone call with Bryson.
In this scenario, you share your experience verbally. Bryson writes an anonymized review on your behalf and publishes it with the same verification standards as any other review. There is no transcript, no recording, no written record of the conversation, and no documentation linking you to the review in any way. The only digital artifact is the published review itself, and as described above, that review contains no identifying information about who provided it.
This option exists because some experiences are too sensitive for any digital paper trail, and we want associates to be able to share those experiences without hesitation.
To set up a phone review, reach out to Bryson on LinkedIn.
Your identity is protected by architecture, structurally and technically. Share your experience and unlock the full database.