Introducing the Risk Scorecard: every launch now arrives already triaged

A reviewer's first twenty minutes are almost never spent reviewing. They're spent reconstructing. You open the PRD, skim for what data the feature touches, check whether any of it trips a DPIA, try to work out whether this is a genuinely new system or the fourth iteration of something you cleared last quarter. Only after all of that can you answer the question you actually needed answered: does this deserve an hour of my time, or five minutes?

Today we're shipping the Risk Scorecard, and it does that reconstruction for you.

The Risk Scorecard reads everything a launch contains — linked Google Docs and Notion pages, Jira tickets, contracts, and uploaded attachments — and produces a risk rating across three categories, with the reasons attached. It sits on the launch page. You don't request it, configure it, or fill anything in to get it. The only thing required of your team is that launches actually contain information, which is a thing they were already supposed to do.

This is the first time TerraTrue brings its own analysis to you rather than waiting for you to supply it. We think that's a meaningful line to cross.

What it looks at

The scorecard rates three categories, each on the same Low / Medium / High scale, so the whole thing is scannable at a glance.

Data Profile & Lifecycle. The data types, data uses, and data subjects described in the document, extracted and mapped to your TerraTrue taxonomy — so the risk levels applied are the ones your organization assigned, not a generic industry default. It also flags children's data specifically, and notes whether the document says anything at all about retention and deletion. Silence on deletion is itself a signal.

Governance & Regulatory. Whether the work triggers a DPIA (data protection impact assessment), an LIA (legitimate interest assessment), or a PIA (privacy impact assessment). Where the data is going, including cross-border transfers and the risk level of the destination regions. Whether the described approach lines up with the playbooks you already run.

Innovation & Context. Novel work versus iterative work. A brand-new service with new architectural components carries a different profile than a styling revamp or a performance optimization, and the scorecard reads for both directions.

Why one high-risk signal colors an entire category

The scorecard uses a high-water mark. A category inherits the risk level of its highest-risk signal, and certain findings — children's data, a required DPIA — escalate a category to High on their own, immediately.

This is a deliberate asymmetry, and it's worth being direct about the tradeoff. It means you will sometimes see a High Risk category driven by a single item in an otherwise unremarkable launch. We chose that because the two failure modes are not equally expensive. An over-flagged launch costs a reviewer a few minutes. A missed DPIA trigger costs considerably more.

What makes that tolerable is that the scorecard never makes you guess why. Every category rating carries a Primary Driver label — High Risk (Driven by: Children Data Detected), High Risk (Driven by: DPIA Required) — and the overall tier expands into the full breakdown: "High Risk: driven by 3 high-risk data types and an outstanding DPIA trigger." You see the conclusion and the reasoning in the same place, and you can disagree with it in about four seconds.

It tells you when it doesn't know

The scorecard can return Inconclusive, and it does so on purpose.

If the underlying document doesn't give enough to infer a data use or a data type, the category says so rather than defaulting to Low. A confidently wrong "Low Risk" is far more dangerous to a lean team than an honest "not enough information here" — the first one quietly removes a launch from your attention, the second one tells you exactly what to go ask for. Same principle for a launch with nothing attached: instead of scoring an empty page, the scorecard shows a neutral prompt to link a document before triage can run.

It stays current, and it remembers

Launches change. Someone attaches the security design a week after the PRD. A data flow gets rewritten in the linked doc.

When that happens the scorecard re-scores itself. You don't re-run anything, and you don't have to remember that the assessment you read on Tuesday was based on a version that no longer exists. The risk picture on the launch page is the risk picture as of now.

But the old picture doesn't disappear, and this is the part we think is quietly the most valuable thing in the release. Every scorecard carries a full version history: the timeline of every revision, what the scorecard looked like at each point, and the trigger that caused it to change.

Which means the question that has always been hard to answer well — when did we know this? — now answers itself. You can see that a launch was Medium Risk for three weeks, and that it went High the afternoon a subprocessor agreement was attached. You can show a regulator, an auditor, or your own leadership not just the current risk position but how it was arrived at, with the evidence that moved it.

For a lean team, that's the difference between a score and a record. A score tells you where a launch stands today. A record tells you the story of the launch, and stories are what you actually need when someone asks you to account for a decision six months after you made it.

What it doesn't do yet

Being useful here matters more than sounding finished, so: the Risk Scorecard informs your decision. It does not make it.

It won't auto-close a low-risk review or route a high-risk one on its own — that's coming, and it's the natural next step, but today the decision stays with you. Manual overrides of a score, encoding your own internal playbook into the scoring rules, and automatic EU AI Act tiering are all on the roadmap rather than in this release. And we've started where our expertise is deepest — privacy risk. Application security and product counseling come after.

We'd rather ship a narrow thing that's right than a broad thing you have to double-check.

Who can see it

The scorecard is off until an admin turns it on, and it's visible only to people holding the Scorecard Viewer permission. Existing review teams get that permission by default, and from there you can widen it to everyone, restrict it to specific reviewers, or keep it to reviewers only while product teams see the launch without the score. The version history sits behind the same permission, so the risk narrative of a launch stays with the people responsible for it. Like all TerraTrue AI functionality, it requires the "Enable TerraTrue AI" setting to be on.

Where this fits

The whole case for reviewing at design time is that a finding is cheap while a decision is still open and expensive once it's made. That only works if the review can actually happen early, and a review only happens early if it's fast. Twenty minutes of reconstruction before you can even decide whether something deserves attention is how reviews end up batched, deferred, or skipped. Removing the reconstruction is what makes an early review affordable rather than aspirational.

Last year we described a framework we called Doc to Decision: find out about work early enough to influence it, spend your review time only where it's warranted, and get through the assessments faster.

Phase one was the pipeline — reviews that start from the document itself, in Google Docs and Notion, with no new tools for product teams to learn. The Risk Scorecard is phase two. Internally we call it the Brain, because it's the part that reads. Phase three is the part that writes: data specs that fill themselves, and DPIAs, LIAs, and TIAs (transfer impact assessments) that arrive drafted and waiting for a signature rather than blank and waiting for an afternoon.

The through-line is the same one we started with. Lean teams shouldn't have to choose between being the department of no and accepting risk they can't see. They should just get to the decision faster.

Questions we've been asked

What triggers a High Risk rating in the Risk Scorecard? A category inherits the level of its highest-risk signal. Two findings escalate a category to High on their own: children's data detected, and a required DPIA. Every rating shows the Primary Driver behind it.

Can the Risk Scorecard auto-close low-risk reviews? Not today. It informs the decision and the decision stays with the reviewer. Auto-closing low-risk reviews and routing high-risk ones are the next step on the roadmap.

Does the scorecard use my organization's data taxonomy? Yes. Data types are mapped to your TerraTrue taxonomy, so the risk levels applied are the ones your organization assigned, not a generic industry default. The same document can score differently at two companies, correctly.

What does an Inconclusive rating mean? The document didn't contain enough to infer a data use or a data type. It doesn't mean the risk is low. It tells you which piece of information to go and ask for.

Does the Risk Scorecard cover the EU AI Act? Not yet. Automatic EU AI Act tiering is on the roadmap. Today the scorecard covers privacy risk, where our expertise is deepest.

What does the Risk Scorecard read? Linked Google Docs and Notion pages, Jira tickets, contracts, uploaded attachments, and the launch's own answers. Nothing needs to be filled in for it to run.

Build trust. Build fast. Build with TerraTrue.