You understand the theory (Contextual Integrity). Here's how to actually run your project against real code, on real infrastructure, this week.
The CI 5-tuple, why it alone isn't enough (C1–C4), and how to reframe your own research question in that vocabulary.
The operational path from "I have a research question" to "I have real numbers and a poster" — repo orientation, running things on the cluster, pulling results back, and a concrete checklist for this week.
The two gold boxes are today's focus — everyone gets stuck there first, and getting comfortable with that loop early is what makes the rest of the week possible.
| Path | What it is |
|---|---|
| data/ | Your input CSVs — scenarios + ground truth go here |
| app/batch_runner.py | The script that runs your data through the pipeline |
| connector/llm1_extractor.py | Extraction prompts (the AI/NLP layer you're studying) |
| connector/hipaa_engine.py | The verifier interface — you call this, you don't need to read it |
| datalog_engine/*.dl | The formal rules — infrastructure, not your research surface |
| experiments/results/ | Where your output CSVs land |
| scripts/ | Reusable analysis scripts — check here before writing your own |
The SLURM cluster has GPUs (for the LLM) but no Souffle installed. Your laptop has Souffle but no GPU. So the pipeline splits cleanly across the trust boundary you already learned:
Run batch_runner.py. The LLM call happens here. The output CSV's verdict column will say ERROR — that's expected, not a bug. scenario_json is what you actually need, and it's fully populated. (souffle_facts is not populated on this path — it's only written once Souffle actually runs, so it stays blank here. Don't build anything that depends on it from a SLURM CSV.)
Pull the CSV back. Re-run verification locally using the already-extracted facts — no LLM call needed here at all, just Souffle. Seconds, not minutes.
Haven't done the Extraction Warm-UpCompliance QA Playground yet? Do that first — 15 minutes, no cluster needed, and the script below stops being a black box once you have. Full connection walkthrough (SSH keys, host, first-time setup) is in Cluster Access and SLURM Quick Connect. The short version:
Always test with --limit 10 first. A typo in a column name fails the same way whether you run it on 10 rows or 500 — find out on the 10-row version.
Once the CSV is back on your laptop (with Souffle installed):
Notice: HIPAAEngine.check(), not a strategy class with an explainer attached — you don't need natural-language explanations for most analysis, and skipping that step means zero LLM calls, zero chance of hanging on a misconfigured model.
| Symptom | Likely cause | Fix |
|---|---|---|
| Every row's verdict is ERROR | Ran on SLURM (no Souffle) and never re-verified locally | Expected on SLURM — run Step 4 locally |
| Job fails instantly | Model not pulled, or wrong --question-col name | Test on --limit 10 first, check column names match your CSV exactly |
| Script hangs for a long time | Used a strategy class that calls an LLM explainer, and no model is configured | Use HIPAAEngine.check() directly for verdict-only analysis |
| Extra CSV columns disappeared | batch_runner.py only outputs its fixed schema | Re-merge your extra columns back in on row_id afterward |
Once you have real verdicts, compute the metric your research question actually asks for — don't just report raw accuracy if your question is sharper than that.
The red-teaming adversarial project uses exactly this two-phase flow: 56 real scenarios extracted on SLURM, re-verified locally with HIPAAEngine.check(), analyzed for attack success rate by category. If you want a concrete worked reference while building your own pipeline, ask to see it.
Before you leave: get one row of your own data through the full pipeline — SLURM extraction, pulled back, verified locally, one printed verdict. Not ten rows. Not the final analysis. One row, all the way through. Everything after that is repetition.
You know the theory and you know the pipeline. The only thing left is doing it.