Example
How to publish a research dataset when useful detail and participant protection compete
Removing direct identifiers does not protect participants when rare categories can reconstruct a person together. The team must remove those categories, aggregate them, or hold the release until an authorized disclosure review.
Release the most useful dataset the team can support while making exclusions, transformations, and reuse limits visible
The public-use promise: useful data without exposing rare participants or overstating reuse
Keep participant protection, reuse value, exclusions, and transformations as the release promise
Put the actual deposit date beside the disclosure boundary
Removal, aggregation, documentation, and repository-date work Amara can advance
Compare removing rare categories, aggregating them, and holding for disclosure review
Draft the data note only after the release boundary is chosen
Rare-category combinations, documentation gaps, and evidence that changes the release boundary
Show which category combinations could reconstruct a participant
List combination risks before treating direct-identifier removal as sufficient
Name what a responsible reuser still could not interpret
The disclosure-review authority and Amara's unsent request; no review is implied until it is requested
Prepare an unsent request for the authority who can grant disclosure review
Name who can grant the permission Amara cannot
In You.one’s Superboard view, the Dataset release Board separates the public-use promise, release actions, disclosure evidence, review authority, and what has genuinely been deposited.
Open Remove rare categories, aggregate them, or hold release as the Room with the Release-boundary brief and identifying combinations named before drafting the data note.
After an explicit request, Ava can organize only the visible risks but cannot determine disclosure safety, approve documentation, submit the repository deposit, or publish participant data. Amara, the research team, participants’ governing protections, and authorized reviewers own release authority.
De-identified columns can still name a person when rare categories travel together
This Board has one job: Release the most useful dataset the team can support while making exclusions, transformations, and reuse limits visible.
The decision still belongs to Amara: Whether to remove rare categories, aggregate them, or hold the release for another disclosure review.
You.one can keep the work, evidence, and “Remove rare categories, aggregate them, or hold release for disclosure review” decision visible through its Superboard view. Authority does not move to the software: Amara owns the release recommendation, data-note draft, and disclosure-review request. The designated review authority owns disclosure permission; Ava cannot grant it, submit the dataset, or act for the university.
Available today
Dataset release: one place for the mission
The Dataset release Board gives this mission one durable operating picture. Amara can use familiar language instead of translating the situation into project-management jargon. Its four Lists separate the kinds of attention this situation actually requires.
The Board is not a master task list. It keeps the live choice, the facts that could change it, and any reply or outside event already in motion visible without pretending every uncertainty is work in progress.
Swipe or scroll sideways to see every column.
| List | What belongs here |
|---|---|
| Public-use promise | The public-use promise: useful data without exposing rare participants or overstating reuse |
| Release actions | Removal, aggregation, documentation, and repository-date work Amara can advance |
| Disclosure evidence | Rare-category combinations, documentation gaps, and evidence that changes the release boundary |
| Review authority | The disclosure-review authority and Amara's unsent request; no review is implied until it is requested |
Available today
Cards that sound like the real work
These Card titles come directly from Amara's situation: “Remove rare categories, aggregate them, or hold release for disclosure review” is the live choice, “Rare-category combinations” holds evidence, and “Prepare the disclosure-review request” is still work Amara controls—not something already awaiting another person. The point is recognition, not a perfect taxonomy.
Swipe or scroll sideways to see every column.
| Card | List | Job |
|---|---|---|
| Release only what the team can defend; exclusions, transforms, and reuse limits stay visible | Public-use promise | Keep participant protection, reuse value, exclusions, and transformations as the release promise |
| Remove rare categories, aggregate them, or hold release for disclosure review | Release actions | Compare removing rare categories, aggregating them, and holding for disclosure review |
| Rare-category combinations | Disclosure evidence | Show which category combinations could reconstruct a participant |
| Draft the data note after the release boundary is chosen | Release actions | Draft the data note only after the release boundary is chosen |
| Prepare the disclosure-review request | Review authority | Prepare an unsent request for the authority who can grant disclosure review |
| List combinations that could identify a participant, not only direct identifiers | Disclosure evidence | List combination risks before treating direct-identifier removal as sufficient |
| Repository deadline | Public-use promise | Put the actual deposit date beside the disclosure boundary |
| Documentation gaps in field definitions | Disclosure evidence | Name what a responsible reuser still could not interpret |
| Designated disclosure-review authority | Review authority | Name who can grant the permission Amara cannot |
Available today
Keep the evidence with “Remove rare categories, aggregate them, or hold release for disclosure review”
Opening the Card gives the visible item durable depth. Stage can hold Release-boundary brief: Place reuse value, disclosure combinations, documentation gaps, deadline, and review authority together. Live choice: Whether to remove rare categories, aggregate them, or hold the release for another disclosure review. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show “Open decision: Amara will decide whether to remove rare categories, aggregate them, or hold the release for another disclosure review.”
A Card Chat request can ask Ava to prepare the specific comparison or extraction in “Remove rare categories, aggregate them, or hold release for disclosure review” from the visible evidence. Ava can work from the context Amara deliberately brings into this Card, List, or Board; she cannot monitor the rest of life, contact anyone, or inherit the decision.
Amara's call remains explicit: Amara owns the release recommendation, data-note draft, and disclosure-review request. The designated review authority owns disclosure permission; Ava cannot grant it, submit the dataset, or act for the university.
Swipe or scroll sideways to see every column.
| Surface | Job in this example |
|---|---|
| Stage | Release-boundary brief: Place reuse value, disclosure combinations, documentation gaps, deadline, and review authority together. Live choice: Whether to remove rare categories, aggregate them, or hold the release for another disclosure review |
| Chat | Keep Amara's request and Ava's attributed response with the work |
| Pulse | Open decision: Amara will decide whether to remove rare categories, aggregate them, or hold the release for another disclosure review |
Start small and rename what feels artificial
Amara should rename every List or Card that feels artificial. This recipe succeeds when “Remove rare categories, aggregate them, or hold release for disclosure review” becomes easier to decide and fewer open loops depend on memory—not when the Board looks tidy.
Swipe or scroll sideways to see every column.
| Step | Action |
|---|---|
| 1. Write the public-use promise | Put reuse limits, exclusions, and the repository date on Public-use promise |
| 2. Card disclosure evidence | Put combination risks and documentation gaps on Disclosure evidence |
| 3. Keep review authority explicit | Prepare the disclosure-review request on Review authority as unsent owned work |
| 4. Card the release paths | Remove, aggregate, and hold belong on Release actions |
| 5. List identifying combinations | Name combination risks, then open Remove rare categories, aggregate them, or hold release for disclosure review |
A repository deposit checklist can remain part of the system
A repository deposit checklist can be enough while the situation stays simple: rare-category combinations, field definitions, exclusions, review authority, and the repository date are already settled.
It starts to break when rare-category combinations and incomplete field documentation must inform the same release choice.
The Dataset release Board earns its place only when the familiar tool—a repository deposit checklist—can no longer keep the reason, Release-boundary brief, conversation, current state, decision, and history connected.
Where this example stops
- This is a fictional example, not a customer story.
- This fictional example is not research-ethics, privacy, disclosure, licensing, or statistical advice and contains no real participant data.
- It does not show Ava completing external actions or contacting anyone for Amara.
- It does not report a measured result, and this Board is a starting shape to adapt—not a universal prescription.