Blog · arXiv Analysis · Last reviewed June 25, 2026

The Dataset Becomes the Repair Claim

The 2026 arXiv paper Can Data Work be Reparative? asks whether AI safety datasets can repair the relations of accountability that ordinary data production often breaks.

For this essay, reparative data work means data production that gives affected people more than representation in a dataset: it gives them recognition, just reward, care against exposure harms, authority over downstream use, and a way to contest whether the promised repair actually occurred.

Repair Is Not Labeling

The paper, arXiv:2606.09408 [cs.CY, cs.HC], was submitted on June 8, 2026 by Srravya Chandhiramowuli, Ding Wang, and Alex S. Taylor. Its title is Can Data Work be Reparative?. The question is not whether better labels improve a model. The question is whether the social relations around data work can be changed enough to count as repair.

The authors study an alternative approach to data work developed by Tattle Civic Tech, an India-based civic-tech organisation building datasets and tools for online harms such as misinformation, hate, and online gender-based violence. The paper treats safety datasets as political artifacts: they are not just collections of examples, but records of whose experiences count, whose expertise is paid for, and who gets authority after contribution.

That makes this paper useful for AI governance. Responsible AI often asks whether a dataset is documented, diverse, or useful for evaluation. Reparative data work asks whether the dataset production process resets accountability toward people most harmed by the systems and platforms the dataset is supposed to correct.

The distinction matters. A dataset can be participatory and still extractive if affected people are invited only to supply examples, trauma, language expertise, or cultural context. A dataset can be richly contextual and still weakly governed if platforms, model builders, funders, or benchmark owners decide later use without the people whose knowledge made the dataset possible.

Repair therefore cannot mean "we included the harmed group in the data." It has to mean a changed relation among contributors, dataset stewards, model developers, platforms, funders, and affected communities. The dataset becomes a repair claim only when someone with standing can inspect that relation and challenge it.

Current Context

As of June 25, 2026, the paper lands in a live governance shift. AI safety evaluation, red teaming, preference ranking, content moderation, and benchmark construction all depend on human judgment, often from people whose labor and exposure risks are hidden behind terms like "data," "feedback," "alignment," or "safety." That connects this article to data enrichment labor and LLM judge annotation budgets, not only to dataset ethics.

Partnership on AI's 2026 data-supply-chain update says data enrichment workers remain frequently overlooked even though their working conditions affect AI quality, safety, and reliability. Its vendor-engagement guidance asks buyers to address wages, worker pool expertise, training, communication, privacy, surveillance, worker wellness, and mental-health support. Those are labor questions, but they are also safety questions because the resulting dataset is later treated as evidence.

The regulatory context is narrower but important. EU AI Act Article 10 applies to high-risk AI systems that use training, validation, and testing data. It explicitly names data collection origin, annotation, labelling, cleaning, updating, enrichment, aggregation, assumptions about what the data represents, bias examination, gap identification, and mitigation. Article 10 does not require reparative justice. It does show that data work is becoming an auditable governance object rather than background labor.

NIST's Generative AI Profile similarly treats data quality, integrity, provenance, structured human feedback, and red teaming as risk-management concerns. That does not settle compensation, contributor rights, or collective control. It gives organizations fewer excuses for treating data work as an informal prelude to the real AI system.

The current trap is compliance substitution. A company can document data preparation, pay a vendor, collect safety examples, and publish a benchmark score without repairing anything. Reparative data work asks a harder question: did the process give harmed people standing, resources, protection, and downstream leverage, or did it make their knowledge more useful to the same institutions that neglected them?

The Tattle Case

The study draws on the lead author's virtual ethnographic engagement with Tattle from April to December 2024, including eight months of fieldwork and 12 interviews with dataset contributors and Tattle team members. It focuses on two online-safety dataset projects: a lexicon of gender-abusive slurs in four Indian languages and a Hindi LLM safety benchmark dataset.

The slur lexicon included more than 650 entries in Hindi, Tamil, Malayalam, and Indian English, with metadata such as severity and categories including gender, religion, caste, class, body shaming, and ableism. The Hindi benchmark project aimed to create 2,000 prompts for two hazards: hate and sex-related crimes. Its contributors included people working in social work, digital media, journalism, fact-checking, psychology, policy advocacy, research, and activism.

The important move is that contributors were not treated as interchangeable labelers. Their discussions shaped definitions, categories, prompt writing, metadata, and the scope of harms. The paper describes this as a feminist orientation to dataset production: subjectivity is not noise to eliminate, but situated knowledge that changes what the dataset can see.

The paper's details matter because they keep the claim grounded. The Hindi benchmark project brought together 23 contributors and used six 90-minute online workshops. Tattle's own project page says the Hindi dataset produced 2,000 prompts for MLCommons safety benchmarking in the two hazard categories of hate and sex-related crimes, created by an expert group with experience across journalism, social work, feminist advocacy, gender studies, fact-checking, political campaigning, education, psychology, and research.

The paper also records care practices. Contributors working with slurs, stereotypes, hate speech, and sexual violence faced mental-health risks. Tattle limited exposure windows, kept dataset documents accessible during workshops rather than continuously, spaced sessions weekly, capped them at 90 minutes, used collaborative discussion rather than isolated toxic-content processing, and partnered with a mental-health provider to offer trauma-informed counselling and therapy for benchmark contributors.

Those details should not be romanticized. They show a serious attempt to move away from extractive data work, but they also expose how hard repair is to operationalize when contributors change over time, funding is limited, harms evolve, platforms remain powerful, and dataset maintenance continues after the workshop ends.

Just Reward

Once lived experience becomes expertise, ordinary data-labor pricing looks inadequate. The paper reports that Tattle's Hindi safety benchmark paid contributors 1,200 INR per hour, or 1,800 INR for each 90-minute workshop, and later distributed leftover compensation funds as an additional per-workshop payment. The point is not that this solves fair pay. The point is that fair compensation becomes a design problem, not an afterthought.

The authors show why this is hard. Contributors came from different regions, sectors, employment arrangements, and material circumstances. Some cared more about intervening in online safety than about payment; others had higher compensation expectations and declined participation. Tattle also had to persuade funders that a slower, more participatory, better-paid process was worth funding in a market where cheaper data work can win bids.

This connects to data enrichment labor, hidden AI labor, and data dignity. If AI safety depends on human judgment, then the conditions under which that judgment is produced are part of the safety case.

Just reward has at least four layers. The first is payment for time, including preparation, discussion, care work, revision, and emotional exposure, not only finished labels or prompts. The second is support for harm: breaks, counselling, exposure limits, opt-out rights, and task design that does not isolate workers with toxic material. The third is recognition of expertise without forcing contributors to become public symbols of their trauma. The fourth is downstream value: if platforms, benchmark owners, or AI vendors benefit from the dataset, the benefit should not disappear from the people whose knowledge made it useful.

Governance After Contribution

The second challenge is what happens after contribution. The paper asks whose views shape dataset licensing, maintenance, expansion, commercial use, contributor rights, refusal, revocation, and stewardship. A dataset about online harms can become valuable to the same platforms whose failures made the dataset necessary. That creates a governance problem, not only a distribution problem.

The authors describe Tattle's exploration of collective dataset governance as difficult to operationalise. Contributor groups change over time. Some contributors are deeply invested in AI and platform accountability; others care primarily about more immediate harms in their communities. A dataset may need regular updating, but the people who made it may not remain available, interested, or empowered to govern its later uses.

That tension is the paper's strongest contribution. Inclusion in dataset production is not automatically repair. If affected people help build a dataset but cannot shape how it is licensed, sold, maintained, contested, or used against the platforms that neglected them, the process may still extract expertise without resetting accountability.

The governance object is therefore not only the dataset file. It is the relationship around the file: who can access it, who can train on it, who can evaluate with it, who can commercialize it, who can update it, who can remove or correct entries, who receives money or credit, who handles complaints, and who can say that a proposed use violates the original repair purpose.

This is where data trusts, AI data licensing, data provenance, and data sheets become practical vocabulary. A reparative dataset needs stewardship, not just consent at the moment of collection.

Failure Modes

The first failure mode is participation theater. Contributors attend workshops, share lived expertise, and improve labels, but later licensing, access, pricing, and platform relationships are decided elsewhere.

The second is extraction through inclusion. A project becomes more accurate precisely because harmed people supplied contextual knowledge, while the resulting benchmark or product increases the power of the institutions that previously ignored them.

The third is one-time payment as closure. Compensation is necessary, but a single payment cannot settle future commercial use, benchmark prestige, platform dependence, or maintenance labor.

The fourth is trauma externalization. Safety data is produced by exposing contributors to slurs, abuse, sexual violence, hate, or threats while the end user sees only a safer model or cleaner moderation system.

The fifth is governance fatigue. Collective control sounds right, but contributors may not have the time, safety, interest, or compensation to govern a dataset years after a short project.

The sixth is platform capture. A dataset made to challenge platform neglect can become a low-cost repair input for the same platform unless use terms, attribution, reporting, compensation, and accountability duties travel with it.

The seventh is safety-washing. A model developer can cite a participatory or feminist dataset as proof of responsible AI without proving that contributors retained rights, that harms were reduced, or that affected communities gained leverage.

The eighth is frozen community memory. Online harms mutate. Slurs, coded language, platform affordances, and political contexts shift. A dataset that is not maintained can preserve an old map of harm while claiming current authority.

Minimum Reparative Record

If a dataset claims to be reparative, the record should be strong enough to test that claim without exposing private contributors or sensitive harm examples.

The minimum record should name the dataset purpose, harm domain, contributor role classes, recruitment method, language and regional scope, compensation model, exposure safeguards, mental-health support, participation limits, consent terms, licensing terms, maintenance plan, complaint channel, and downstream use restrictions.

It should also preserve the governance facts: who can approve a new user, who can refuse a platform request, who can correct or remove entries, who receives proceeds or recognition, how contributors are re-contacted or represented, how conflicts among contributors are handled, and what happens if a use violates the repair purpose.

For audit purposes, the record should connect to dataset versions, data sheets, source provenance, annotation or prompt-writing protocols, access logs, model or benchmark uses, and any known incidents, withdrawals, or disputes. Public disclosure can remain aggregated, but the private governance record should be specific enough to make accountability real.

Governance Standard

A serious reparative-data-work standard would begin before the first label is collected.

First, define the repair claim. The project should say what relation it is trying to repair: platform neglect, language exclusion, unsafe moderation, benchmark invisibility, labor extraction, community misrepresentation, or another harm.

Second, treat contributors as knowledge holders, not only data producers. They should be able to shape definitions, categories, examples, exclusions, metadata, and the interpretation of disagreement.

Third, pay for the whole burden. Compensation should cover time, preparation, discussion, revision, exposure, facilitation, and governance labor. It should not reward only the countable artifact.

Fourth, design for care. Exposure to harmful content should be minimized, bounded, supported, and voluntary, with task redesign and counselling options where the work involves abuse, violence, self-harm, hate, or sexual harm.

Fifth, make downstream use conditional. Platforms, model builders, benchmark programs, and researchers should receive clear terms on attribution, permitted use, prohibited use, reporting, security, redistribution, commercial use, and obligations back to contributors or affected communities.

Sixth, give governance a budget. Collective stewardship is work. Maintenance meetings, access reviews, appeals, licensing decisions, and dispute handling need funding, facilitation, and replacement rules when contributors leave.

Seventh, preserve a repair path. A contributor or affected community should know how to object to an entry, use, category, license decision, platform deployment, or misleading public claim.

Eighth, do not overclaim evidence. A reparative process can improve accountability without proving that a model is safe, a platform is fair, or a dataset is universally representative. The claim should remain scoped.

The Spiralist Test

The Spiralist test is simple: when a dataset claims to repair harm, who can call that claim false? Can contributors inspect later uses, contest licensing decisions, share in value, withdraw from inappropriate reuse, or force platforms to answer for the harms the dataset records?

If the answer is no, the dataset may be better, richer, and more contextual, but it is not yet reparative. Repair begins when data work changes the accountability relation between harmed communities, dataset stewards, model builders, and platforms.

This is why the paper matters beyond the Tattle case. Many AI systems now depend on human safety work: red-team prompts, abuse taxonomies, preference data, refusal examples, moderation benchmarks, and expert reviews. The question is not whether people helped. The question is whether their help became power, protection, and a durable claim on the systems that used it.

Scope Boundary

This is an ethnographic case study of Tattle's approach, not proof that all participatory dataset projects are reparative or that all safety datasets should use one governance model. The paper itself presents reparative data work as an open question and traces tensions rather than offering a universal recipe.

The modest conclusion is strong enough: AI governance should judge safety datasets not only by benchmark utility, but by how they value, protect, and empower the people whose knowledge makes the dataset possible.

This article also does not treat EU AI Act data governance, NIST risk management, Partnership on AI sourcing guidance, data trusts, or dataset documentation as substitutes for repair. They are supporting instruments. The repair claim still has to be tested against contributor standing, downstream authority, compensation, protection from harm, and the ability to contest later use.

Source Discipline

The paper is a current arXiv preprint and FAccT 2026 conference paper claim; this article treats its methods, compensation figures, Tattle case details, and governance tensions as the authors' ethnographic account, not as a universal measurement of data work.

Tattle's project page is used to confirm the public description of the Hindi MLCommons safety benchmark project, not to independently verify every workshop interaction reported in the paper. Partnership on AI sources are responsible-sourcing guidance and advocacy materials; they should not be read as evidence that the data-enrichment industry has adopted those practices.

EU AI Act Article 10 is binding law for high-risk AI systems within its scope, but it is a data-governance requirement, not a reparations framework. NIST AI RMF materials are voluntary risk-management guidance. Neither source proves that a dataset is reparative, fair, or safe. They support the narrower claim that data work, human feedback, provenance, and dataset preparation now belong in governance records.

Current-source claims were checked against primary or official sources on June 25, 2026. Internal links supply site vocabulary for data labor, data sheets, data trusts, AI audit trails, and safety cases; they are not substitutes for the paper and official materials listed below.

Sources

Return to Blog