Interactive decision-support tool that analyzes 11 user-defined constraints across privacy goals, data sensitivity, trust models, and regulatory regimes to recommend optimal privacy-enhancing technologies with explainable reasoning.
Solo build. Columbia, Policy in Privacy Technology
Privacy-enhancing technologies are individually well documented and collectively baffling. Someone who needs to share data across organizations has to choose between k-anonymity, differential privacy in two flavors, secure multi-party computation, homomorphic encryption, trusted execution environments, private set intersection, federated learning, synthetic data, and plain legal agreements. The right answer depends on their threat model, their regulatory regime, their compute budget, and how exact their output needs to be.
Most guidance stops at describing each technology. That leaves the hardest part, the selection, entirely to the reader. Worse, the technologies interact: some combinations are standard practice and others quietly cancel each other out.
Brandeis, named for Justice Louis Brandeis, walks the user through 11 structured questions covering collaboration goal, data types, sensitivity, number of parties, trust model, data mobility constraints, output requirements, accuracy tolerance, regulatory regime, available compute, and adversary model. It then recommends a combination of technologies rather than a single winner, because real deployments stack them.
The engine is deliberately a deterministic rule system, not a model. Each of the 11 dimensions triggers rules producing primary and supporting recommendations with implementation sub-decisions. After deduplication, a second pass handles cross-cutting interactions: requiring exact accuracy alongside differential privacy generates a compatibility warning, and declaring minimal compute resources removes homomorphic encryption from consideration entirely.
It also recognizes known-good stacks by name: Federated Learning plus Local DP as "Privacy-Preserving Collaborative Learning", PSI plus MPC as "Private Record Linkage", so users get the recognized pattern instead of a bag of parts.
A rule engine was the right call over an LLM here for a specific reason: in a privacy context, a recommendation you can't trace is worthless. Every suggestion has to be auditable back to the constraint that produced it.
The tool renders a decision tree showing exactly which answers led to each recommendation, contextual explanations per technology, and a "Why Not?" panel explaining why each excluded technology was ruled out, which is often the more instructive half.
Roughly 600 lines of domain logic, entirely browser-based. No backend, no ML, no external API calls, nothing to deploy or secure. A privacy tool that transmits your privacy constraints to a server would be its own punchline.
The "Why Not?" panel started as a debugging view for myself and turned into the feature that actually teaches. Showing the excluded options and the reason for exclusion converts a recommendation into an explanation.
Constraint interactions were where the real domain knowledge lived. Single-dimension rules were mechanical; the multi-pass cross-cutting logic is what separates useful advice from a lookup table.
export function recommend(answers) {
const recs = [];
const { goal, sensitivity, trustModel, numParties,
canDataLeave, accuracy, regulatory, resources } = answers;
// Goal drives primary technology selection
if (goal === "train_ml") {
recs.push(makeRec("federated_learning", "primary", ["ml_requires_fl"]));
recs.push(makeRec("local_dp", "supporting", ["fl_needs_dp_gradients"]));
}
if (goal === "record_linkage") {
recs.push(makeRec("psi", "primary", ["linkage_psi"]));
recs.push(makeRec("mpc", "supporting", ["linkage_mpc_stack"]));
}
// Cross-cutting: exact accuracy + DP → warning
if (accuracy === "exact" && hasDifferentialPrivacy(recs)) {
warnings.push(makeWarning("DP adds noise, consider MPC or TEEs"));
}
// Deduplicate, detect known stacks, apply resource constraints
return [...deduplicateRecs(recs), ...warnings];
}