Example
How to publish a research dataset when useful detail and participant protection compete
A technically de-identified table can still expose people through the story its columns tell together.
AI assistance helped shape this fictional example from a structured editorial brief. It was reviewed for usefulness, distinctness, accessibility, and product truth.
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
Amara is an explicitly fictional portrait, not a customer or testimonial.
The Dataset release Board gives one mission a visible field; the Remove rare categories, aggregate them, or hold release for disclosure review Room keeps its evidence, conversation, state, and decision together.
Current You.one provides the Superboard structure and explicit, bounded Ava paths described here; broader proactive or external work is not a current promise.
Why Dataset release needs an operating picture
Amara is a fictional 34-year-old university research data manager in Durham, North Carolina. The team wants reusable data, several rare categories could reveal identities in combination, documentation is incomplete, the team has not yet requested another disclosure review, and a repository deadline is approaching.
The categories make the dataset more reusable one column at a time, yet their combinations can reconstruct a person the direct identifiers no longer name.
The repository deadline is approaching before the team has even sent another disclosure-review request, so speed and public usefulness cannot substitute for participant protection.
In You.one's Superboard view, Amara can give “Release the most useful dataset the team can support while making exclusions, transformations, and reuse limits visible” a Board of its own. That Board connects source evidence, unresolved questions, decisions, and accountable judgment; opening “Remove rare categories, aggregate them, or hold release for disclosure review” creates a Room for its evidence, discussion, state, and decision.
De-identified columns can still name a person when rare categories travel together
The mission is specific: Release the most useful dataset the team can support while making exclusions, transformations, and reuse limits visible.
The consequential choice is not something a board or an AI should quietly make: 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. The Owner boundary stays 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.
Available today
Dataset release: one Board shape to adapt
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.
Its Cards deliberately distinguish actions, evidence, and decisions while keeping unsent questions in owned work. A Waiting List would be premature until a named request or outside condition is actually in motion. That separation makes the current choice, evidence, and next move easier to scan.
| 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
The Cards make the operating picture concrete
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 a fake Waiting item. The point is recognition, not a perfect taxonomy.
| 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
Available today: Remove rare categories, aggregate them, or hold release for disclosure review becomes a Room
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.” Activity can preserve this attributed receipt: “Ava compared the options in Card Chat using the Release-boundary brief and this Card Room's visible notes and left “Remove rare categories, aggregate them, or hold release for disclosure review” with Amara.”
A useful Card Chat request would be: “Using only this Card Room, compare removing rare categories, aggregating them, and holding release for disclosure review. Cite only notes visible in this Room. Do not submit the dataset, contact the review authority, grant disclosure permission, or choose for me.” When live AI is configured, current Ava can respond to an explicit Card mention using supported Room context and can make limited reversible changes inside this Card Room after an explicit request. She uses only supported Room context; she cannot summarize the Board, watch other Lists, or act outside this Card Room. She does not gain authority over the decision merely because the context is organized.
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.
| 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 |
| Activity | Ava compared the options in Card Chat using the Release-boundary brief and this Card Room's visible notes and left “Remove rare categories, aggregate them, or hold release for disclosure review” with Amara |
What to ask Ava—and what not to assume
These requests use the visible supported context inside the “Remove rare categories, aggregate them, or hold release for disclosure review” Card Room. They do not imply that current Ava automatically surveys the whole Board or follows up on her own; Amara must provide the relevant facts and check the result.
Current Ava can reply in this Room to an explicit Card mention using supported Room context. She cannot summarize the Board, make the choice, represent Amara, watch other Lists, or act outside this Card Room.
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.
A release boundary where rare-category combinations are removed, aggregated, or held for review, with exclusions visible.
- Request idea: using only this Card Room, compare removing rare categories, aggregating them, and holding release for disclosure review. Cite only notes visible in this Room. Do not submit the dataset, contact the review authority, grant disclosure permission, or choose for me.
- Request idea: use only the Release-boundary brief and notes the Owner has placed in this Card Room to separate facts, assumptions, and unanswered questions
- Request idea: name which visible Room note could most change the comparison; do not watch other Lists or follow up autonomously
A repository deposit checklist may still be enough
A repository deposit checklist is enough when 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.
A starter recipe to adapt, not obey
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.
| 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 |
Direction
Direction, not a current promise
Later, if new evidence follows “Prepare the disclosure-review request”, Ava may bring Amara back to “Remove rare categories, aggregate them, or hold release for disclosure review,” show which part of the Release-boundary brief changed, and stop before choosing or acting. “List combinations that could identify a participant, not only direct identifiers” remains human-owned.
A future unified You.one experience could carry relevant context from “Remove rare categories, aggregate them, or hold release for disclosure review” across guidance and the Superboard view. Broad proactive coordination, cross-surface personalized memory, realtime shared editing, and general external execution are not available today. Any future action would still require the applicable capability, connection, grant, and human authority.
What this realistic example does not claim
- Amara is fictional and is not a customer, testimonial, research participant, or disguised real person.
- 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.