The theory this entire lab's system is built on — and why "who can see what" was never a fixed rule to begin with
notebooks/contextual_integrity.ipynb — manually tag real scenarios with the CI 5-tuple before seeing what the real extractor produced, then find the exact real case where two scenarios share an identical tuple but opposite verdicts.
You tell your doctor your diagnosis. You wouldn't tell your employer. You post your birthday publicly on social media. You would never post your Social Security number the same way.
Same person, same fact, sometimes even the same platform — completely different judgment about whether sharing it is okay. If privacy were just "secret vs. not secret," this wouldn't make sense. It isn't about the information. It's about where the information is flowing, and under what expectation.
| Information | This flow feels fine | This flow feels wrong |
|---|---|---|
| Your grade on an exam | Professor → you | Professor → posted publicly by name |
| Your medical diagnosis | You → treating physician | You → your employer |
| Your location right now | You → a close friend, casually | Advertiser → sold to data broker |
Notice: the information itself never changed across each row. What changed is who is sending it to whom, about whom, and under what norm. That's the whole theory, in a table.
Helen Nissenbaum's core claim: there is no such thing as information that is simply "public" or "private" in the abstract. Every flow of information is governed by norms of appropriateness tied to the context it flows within — not by the sensitivity of the information alone.
HIPAA, GDPR, and every privacy statute you'll encounter are society's attempt to codify context-relative informational norms for a specific domain (healthcare, in HIPAA's case) into enforceable rules. Laws don't invent privacy norms from scratch — they formalize norms that already existed informally, like the doctor/employer example.
Nissenbaum formalizes a flow as five parameters. Every one of your projects' data is built on exactly this structure.
Who is disclosing the information
Who receives it
Whose information it is
What type of information
The norm the flow claims to satisfy
"Transmission principle" is the least intuitive term — think of it as the reason the flow is supposed to be okay: "with consent," "as required by law," "confidentially, for treatment." It's not just a label, it's a claimed justification.
Every scenario this lab's pipeline extracts is exactly Nissenbaum's 5-tuple, with HIPAA-specific field names.
| CI Parameter | Field in DatalogScenario |
|---|---|
| Sender | sender, sender_role |
| Receiver | receiver, receiver_role |
| Subject | subject, subject_category |
| Attribute | attribute |
| Transmission Principle | purpose |
The paper states this directly: extraction "converts a natural-language compliance question into a structured Datalog fact set encoding the Contextual Integrity 5-tuple... plus 24 boolean oracle predicates." You'll see why the oracle predicates are needed starting next slide.
The same 5-tuple structure applies to GDPR, CCPA, COPPA, and GLBA — not just HIPAA. If your project touches GDPR generalization, this is precisely the claim you're testing: does the tuple structure transfer, even if the specific rules encoded on top of it don't?
Every HIPAA permission rule is fundamentally about who may send what to whom for what purpose. The statute is already organized around this shape — CI isn't imposed on the law from outside, it matches how disclosure-centric law is naturally written.
These are the actual design challenges this lab's paper documents (§"Design Challenges," C1–C4) — not hypothetical, these drove real architecture decisions.
Most reasoning about evidence is "open-world": if there's enough support, believe it. HIPAA's legal architecture is the opposite.
Permission requires an affirmative derivation. A disclosure is only PERMITTED if a specific statutory exception actually fires given the facts. Ambiguous or missing facts don't default to "probably fine" — they default to DENIED. An AI system that reasons probabilistically ("this looks 80% like a normal treatment disclosure") is already legally wrong in structure, before it even gets a fact wrong.
The 5-tuple tells you the shape of a flow. It cannot tell you facts about the world that determine whether an exception applies.
None of these are derivable from role and purpose strings alone — they require evidence beyond the 5-tuple. This is exactly what the 22–24 boolean oracle predicates (has_court_order, obtained_authorization_164_508, etc.) are for: they carry the transmission-principle detail Nissenbaum's framework calls for that a single purpose string can't hold.
Privacy rules aren't independent — one section can override another for the same tuple.
A purely positive-rule system says PERMITTED, because the §164.506 rule fires and nothing stops it. This is why the Datalog encoding needs explicit negation guards — rules can't just say what's allowed, they have to say what's allowed unless a more specific rule blocks it.
The sharpest limitation. Some violations are invisible at the level of the 5-tuple — two scenarios can share an identical tuple and still have opposite correct verdicts.
Classic version: a nurse disclosing records to a patient for treatment, vs. a nurse accessing her ex-husband's records — same roles, same attribute, same claimed purpose. The tuple can't tell them apart. The violation lives entirely at the instance level, in facts the tuple doesn't capture.
Both scenarios below have the identical CI 5-tuple: hospital → patient, adult, medical-record, treatment.
Patient requests own medical records from a state hospital — but the patient is an inmate, and the hospital operates under a correctional institution. HIPAA's access-request right can be limited for inmates (§164.524).
Patient's legal representatives request copies of his own records for a lawsuit against the records-copying vendor — a proper access request through a business associate, no restriction applies.
The 5-tuple is identical in both. The correct verdict depends entirely on facts like belongstorole(..., "inmate") and organization_member(..., "kansas_srs") — pure C2/C4 territory. You'll pull these two rows yourself in the notebook.
| Challenge | The problem | Architectural answer |
|---|---|---|
| C1 | Open-world reasoning is legally wrong here | Closed-world Datalog — permission requires affirmative derivation |
| C2 | Enabling conditions aren't derivable from role/purpose | 22–24 boolean oracle predicates |
| C3 | One section can override another for the same tuple | Explicit negation guards |
| C4 | Some violations are invisible at the tuple level | Oracle predicates + instance-level facts (rows 48/50) |
Live in class: open connector/hipaa_engine.py, find scenario_to_datalog(), and trace exactly which extracted field becomes which Datalog fact line for row 48 or row 50.
| Project | CI-framed research question |
|---|---|
| Red-Teaming / Adversarial | Which attacks succeed by spoofing the transmission principle (claiming a purpose/oracle) without changing sender, receiver, subject, or attribute? |
| GDPR Generalization | Does the 5-tuple structure transfer across regulations even when the rules built on top of it don't? |
| Error Taxonomy | Do errors concentrate in tuple extraction (wrong sender/receiver/purpose) or in oracle-predicate extraction (C2-style)? |
| Explanation Quality | Do explanations correctly cite which CI parameter or oracle made the difference — or do they just restate the verdict? |
| LLM Benchmark Comparison | Do smaller models fail more on tuple extraction, oracle extraction, or both? |
Every field you've read in DatalogScenario all summer has a name in a 20-year-old privacy theory. That's not a coincidence — it's the design.