Gallery

SWEPrivacy TechRule EnginePolicyShippedMarch - April 2026

Brandeis: Privacy Technology Advisor

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

11
constraint dimensions
10
privacy technologies profiled
0
backend services required

01 / The problem

Why this was worth building

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.

02 / The build

How it works, and why it works that way

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.

03 / Outcome

What shipped

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.

04 / Lessons

What I'd carry forward

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.

Full technical breakdown (8 items)
  • 11-question decision framework covering goals, data types, sensitivity, trust models, regulatory regimes, and threat models
  • 10 privacy-enhancing technologies with detailed profiles: k-Anonymity, Local DP, Central DP, MPC, HE, TEE, PSI, Federated Learning, Synthetic Data, DUAs
  • Rule engine with 600+ lines of domain logic implementing multi-pass evaluation with cross-cutting constraint handling
  • Decision tree visualization showing the causal chain from user choices to technology recommendations
  • Explainable 'Why Not?' panel detailing why each non-recommended technology was excluded
  • Stack detection for known technology combinations (e.g., FL + Local DP, PSI + MPC)
  • Fully browser-based. No backend, no ML, no external APIs. Pure deterministic rule evaluation.
  • Responsive UI with progress tracking, contextual helper text, and real-time recommendation generation

Code sample

rules.js
javascript
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];
}

Built with

React 19ViteTailwind CSSJavaScriptRule EnginePrivacy Engineering