VettEDApplication Library Working prototype · V1

How vetting works

What the engine reads, the questions it asks, how the score is built, and how a verdict is reached. Every number below is a setting, written down, and the same for every vendor.
19 questions · 9 can block · rules v2.4
Read → answer → score → verdict → a person decides
1 · What the engine reads
The vendor's public policy set
The privacy policy, plus the security, sub-processor, terms and DPA pages it links to. Same company only, up to six pages. If the vendor moved its policy, the engine follows the move and records it.
Documents the vendor sent you
A DPA, a completed questionnaire, a SOC 2 or ISO summary, a statement. Stored on the record. Read first, before the public pages, on every check.
Three readings, one answer
The AI reads the text three times for the questions that can block. The answer two readings agree on is kept. Every answer carries a quote from the document, or it is marked as not answered. All of it is stored on the vendor's record: the three votes, the final answers, the quotes, and which documents were read. Each reading is also a line in the agent log and a trace in Application Insights.
2 · The 19 questions, in 11 groups
Every question has one good answer
Some are good when the answer is yes, some when it is no. Example: “Does the vendor limit collection to what the product needs?” is good at yes. “Is personal information ever sold?” is good at no.
9 of them can block an approval
These are the gates: data collection, sharing with third parties, contractual limits on those parties, selling data, who owns uploaded content, contact with strangers, targeted ads, data passed to advertisers, and AI training on student data. A bad answer on any gate stops the approval.
Three possible answers, four evidence tiers
Yes, no, or unclear. Unclear means the documents do not say. The engine never guesses. Every answer also says how strong its evidence is: T3, a quote from the vendor's public page; T2, a quote from a document the vendor sent you; T1, evidence verified by a third party, such as an audit report, reserved and not assigned yet; T0, nothing found. The tier is shown with the quote. It does not change the score.
3 · How the score is built
Score = quality of what was answered
Each answered question earns full marks for the good answer and a fifth of the marks for the bad one. The score is the share of marks earned, over the questions the vendor actually answered. The fifth comes from the school evaluation framework this engine descends from: a disclosed bad practice is still a disclosure, so it earns something, and the gates, not the points, do the blocking. It is a setting.
Coverage = how many of the 19 were answered
Printed next to every score as “addresses X of 19”. A policy can score high on few answers. Coverage is what tells you so.
Four bands
Best from 80%. Good from 70%. Average from 55%. Poor below that. One floor on top: a vendor cannot reach Best below 70% coverage, whatever the score.
4 · How the verdict is reached
Red · Do Not Approve
A bad answer on any gate. One is enough. The quote is on the card.
Green · Approved
No gate failed, no gate unanswered, band Best.
Yellow · Approve with conditions
No gate failed. Up to 2 gates unanswered. Band Best or Good. The unanswered gates are the conditions: confirm them with the vendor.
Orange · Round 2 required
No gate failed, but 3 or more gates unanswered, or band Poor. The public text is not enough. Ask the vendor.
Orange · Request the DPA
The documents are silent on 55% or more of the questions. That is a wrong-document signal, not a judgment on the vendor. Ask for the DPA and assess in Round 2.
5 · Where people come in
Waivers
A reviewer can set aside a finding that does not apply to the school, with a reason and a name. The score recomputes. The waiver stays on the record as a footnote.
Round 2
The vendor's own document answers what the public page did not. The record updates. The alert closes.
Rulings
When two readings disagree on a question, a person decides, in one word. The decision becomes a written rule for every vendor after it.
The watch
Every approved vendor is re-read on a schedule. A verdict that got worse raises an alert. The catalog never changes by itself.
6 · The Administrative Catalog: 19 questions of its own
Same engine, a second question set
Payroll, HR, security cameras, visitor management, payments, finance and facilities hold staff and school data, not student data. So they are read with a second set of 19 questions in 13 groups: what is collected, what it is used for, who it is shared with, whether it is sold, who owns it, how long it is kept, how it is protected, how a breach is reported, where it is stored, and whether a data-processing agreement is on offer. Same reading, same scoring, same bands, same verdict rules.
5 of them can block
Purpose limit, sharing limit, selling data, AI training on customer data, and consent for biometric data. The other questions score but never block on their own. Silence on them is a reason to ask for the DPA, not a stop.
3 questions switch on by product type
Biometric consent and reuse of video apply to cameras and visitor systems. The PCI DSS question applies to payment products. For every other product they are marked not applicable and leave the score, the coverage and the gate count.
The DPA is read first
For these vendors the engine reads the data-processing agreement, the sub-processor list and the security page before the general privacy policy, with a larger reading window. The commitments a school needs live in those pages.
All limits on this page are settings in one file per question set (round1.json and round1-ops.json): the questions, which ones can block, the bands, the tolerance, the coverage floor. Change the file, and every vendor is re-scored the same way. They were tuned on twelve vendors and will be re-tuned on the first fifty.