Semantic Boundary, What We Built, Tested, and Learned
Nine disclosure strategies, two downstream purposes, and three findings from our CIKM 2026 research.
Suppose an AI assistant processes a sensitive conversation. Later, another system needs information from that interaction for debugging, monitoring or analytics.
Which representation of that conversation should it receive?
We explored this question in Semantic Boundary: A Framework and Benchmark for Policy-Constrained Semantic Disclosure, accepted at ACM CIKM 2026.
We built a benchmark to compare nine ways of representing the same information, measuring how useful each representation remained for downstream tasks and how much residual linkage remained under the study's registered assessors.
Three findings stood out:
- Hiding sensitive words may leave identifying patterns intact. One tokenization strategy achieved less than 1% sensitive-token recovery, yet our test could still associate entries with their originating personas about 84% of the time among the 20 held-out test personas from a simulated population of 100. Random guessing among those 20 would be right about 5% of the time.
- Different tasks favour different representations. A transformation that worked well for monitoring assistant failures performed poorly when identifying medication classes.
- One transformation for every recipient can be costly. Reusing one task's preferred representation for another task cost up to 0.51 in utility (on a 0 to 1 scale) in our benchmark.
Let's look at what we tested and why these differences matter.
One journal entry, several ways to share it
Our study uses a fictional medication-adherence application. People record their experiences with a prescription, and an AI assistant responds.
Consider this synthetic journal entry:
I started my 50mg sertraline yesterday evening, and today I woke up feeling extremely dizzy and nauseous. I'm dreading my shift at the hospital tonight.
The assistant replies:
Good work, keep logging.
Now imagine two downstream consumers.
An observability service needs to determine whether the assistant missed a possible safety escalation and at what stage the failure occurred.
An analytics service needs information about medication classes, side effects and adherence barriers.
Both have legitimate reasons to learn from the interaction. Their information requirements differ.
We could forward the original text, but that would disclose the medication, dose, symptoms, occupation and timing together. We could remove sensitive words, although doing so might also remove information the receiving service needs.
What other options do we have?
Nine disclosure strategies
Our benchmark compares nine representation conditions. Here is how they relate to the same journal event.
| Strategy | What the receiving system might see |
|---|---|
| 1. Raw text | The original journal and assistant response |
| 2. Bracket redaction |
I started my [MEDICATION] at [TIME] ... felt [SYMPTOM] ...
|
| 3. Tokenization |
Stable tokens such as MED_c813ab59 and
SYM_5b53be5a
|
| 4. Surrogate replacement | Sensitive values replaced with plausible alternatives |
| 5. LLM substitution | An LLM substitutes sensitive entities while retaining surrounding text |
| 6. LLM rephrasing | An LLM rewrites the passage |
| 7. Coarse semantic export | Broad indicators, such as whether a side-effect signal is present |
| 8. Medium semantic export | Typed fields such as medication class, symptom categories and failure mode |
| 9. Fine semantic export | A richer set of structured attributes |
The first three examples illustrate the paper's export formats. The remaining descriptions summarize the evaluated conditions; they are not literal outputs from this particular journal entry.
The semantic export strategies are particularly interesting because they can represent information directly in terms of what a recipient needs to learn. Figure 1 shows the same entry under two text strategies and as two purpose-specific exports.
Each receiving service can work with its fields without receiving the complete journal.
But a structured export is not automatically safer or more useful. It can still expose sensitive information, and it may omit details another task requires.
This is where the purpose and disclosure policy become important.
The Semantic Boundary framework
Before information leaves a system, three questions deserve explicit answers:
- Who is receiving it, and for what purpose?
- What information does the disclosure policy permit that recipient to learn?
- How will we check what was actually released?
Semantic Boundary describes this as a governed crossing between a trusted collection context and a downstream consumer.
The framework proposes three operations:
Declare: Register the recipient, its purpose and the disclosure policy.
Cross: Transform the source information into a representation appropriate for that purpose and policy, with provenance of how the export was produced.
Verify: Check the export against the declared policy and confirm that its provenance record is complete before release.
Provenance accompanies the export as evidence of the contract's execution, not as a general operational log.
The framework provides a way to reason about these decisions. It doesn't prescribe a universally preferred transformation or claim that the experimental benchmark implements a production-ready verification service.
What the benchmark actually measures
The Semantic Boundary Benchmark (SBB) lets us compare alternative disclosure choices under controlled conditions. The public artifact of the CIKM 2026 pilot is the Open Semantic Boundary Benchmark (Open-SBB).
Our pilot uses 100 synthetic personas generating 3,894 observations over 30 days. The evaluation includes 630 held-out events from 20 test personas drawn from that simulated population.
We apply the nine strategies to the same underlying events under two registered purposes: observability and pharmacologic analytics.
For each resulting representation, we measure two things:
Task utility: Can a downstream consumer still perform its intended task? We evaluate tasks including assistant failure classification, medication-class identification, side-effect detection, adherence-barrier identification and behavioural cohort classification.
Residual linkage: What information remains that could help an adversary associate records with personas, infer attributes or link events over time?
The benchmark then allows us to select the highest-utility representation among those meeting a declared linkage-tolerance threshold.
That gives us a practical question to investigate: if two consumers have different purposes, should they receive the same transformed information?
What the results show
1. Sensitive-word suppression can leave linkage intact
Stable tokenization almost eliminated recovery of the original sensitive words, yet persona re-identification reached approximately 0.84 in our closed-world evaluation. Shown a single entry and a lineup of the 20 held-out test personas, a simple attacker picked the right person about 84 times out of 100. Random guessing among those 20 would get about 5.
The recurring patterns in the remaining information still carried substantial identifying signal. In fact, under this simple attacker, tokenized text was easier to link back to a persona than raw text (0.32), most likely because the same tokens recur across a person's entries and act like a fingerprint. Structured exports aren't immune either: the fine semantic export, with its richer attributes, reached 0.64.
2. Utility changes with the task
Bracket redaction scored 0.67 macro-F1 on assistant failure-mode classification, slightly above raw text at 0.63.
For medication-class classification, the same bracket-redacted representation scored only 0.20, compared with 0.55 for raw text.
The semantic representations also performed differently across tasks. The medium and fine exports reached perfect or near-perfect scores on event-level tasks, partly because they were constructed from simulator ground truth, while the coarse export scored only 0.17 on failure mode. Behavioural cohort classification was hard for every strategy, topping out at 0.29.
The results give us no universal ranking of the nine strategies.
3. Purpose-specific selection can avoid measurable utility loss
At an illustrative linkage-tolerance threshold of 0.45, five evaluated tasks selected three different strategies: bracket redaction, surrogate replacement and coarse semantic export.
When we reused one task's selected strategy for another task, utility loss reached as much as 0.51.
The implication is worth considering: choosing a single sanitization strategy for an entire application may unnecessarily limit what some downstream consumers can accomplish.
Reading the figures together. Follow bracket redaction across all three. In Figure 2 it is one of the safest options: persona re-identification sits near chance. In Figure 3 the cost appears. Medication class falls to 0.20, side-effect detection to 0.56, and even its best task, failure-mode triage, reaches only 0.67. Under a strict linkage tolerance it still wins that task, because the exports that score higher are not permitted. Relax the tolerance from 0.45 to 0.50 and the medium semantic export becomes eligible, lifting failure-mode utility to its ceiling while accepting more linkage. That is the trade-off the benchmark is designed to expose: each gain in usefulness has a disclosure price, and the right price depends on the purpose.
What we haven't established yet
This is a deliberately limited first study.
The corpus is synthetic, the evaluation covers one domain, and the linkage tests use a simple closed-world adversary suite. The semantic representations are constructed from known simulator fields, so their scores don't measure the errors a real extraction system would make. Our combined linkage score is an evaluation measure, not a calibrated probability of re-identification.
We have also specified the framework's verification and provenance requirements without evaluating a production implementation of that process.
There is considerably more work to do with real-world traces, learned transformations, stronger adversaries, changing policies and different downstream applications.
Where we'd like your input
Our broader question is which representation should cross between components for each purpose.
If you're building agentic workflows, observability pipelines, analytics systems or applications that handle sensitive information, we'd be interested in your perspective.
How are you choosing what each downstream component receives? Have you encountered situations where redaction removed information your system needed, or where sanitized data still revealed more than expected?
We're particularly interested in feedback on the benchmark itself: additional transformation methods, evaluation tasks, threat models and application domains that would make it more useful.
If you find this interesting, talk to us.
Read further
- Series Part 1: The Right Information, for the Right Reason Part 3: Your AI Agent Has Access. What Does It Need to Know?
- Paper · ACM CIKM 2026 Semantic Boundary: A Framework and Benchmark for Policy-Constrained Semantic Disclosure doi.org/10.1145/3799682.3840076 ↗
-
Open-SBB The open benchmark from the study.Explore Open-SBB ↗
-
Short survey About three minutes. Where sharing gets difficult in your systems.Take the survey ↗
-
Does your system have this problem? gb@nimblenotions.caTalk to us
- ← Back to Semantic Boundary
The medication-adherence example and all experimental data are synthetic. No ProgressFlow user data were used.