Executive Summary

Until now there has been no way to measure content moderation from outside the platform running it. The large platforms publish annual transparency reports with takedown counts and proactive-action rates, but every one of those numbers is a record of the side where action happened. How many posts were never acted on, and how many of those were actually harmful, is not in the report, and the underlying feed is closed so nobody outside can draw a sample either. Once you see moderation as a labeling pipeline, the shape of the problem is clear. You can measure whether the labels that got applied were correct. You cannot measure how many labels never got applied at all.

Bluesky is built differently. The AT Protocol it runs on publishes both streams: the posts coming in and the moderation labels going on. An outsider can line up what entered the platform against what got labeled over the same period, and that is the one arrangement in which this kind of audit works, because it needs the input side open as well as the output side.

The paper that did it is "Characterizing Bluesky Content Moderation Service: From Automation of Service to Landscape of Harms," posted to arXiv on 10 September 2026 by eight authors under cs.CY. The Comments field on the abstract page records acceptance at ICWSM 2027, a major venue for social media research. It circulates as a preprint, but it has been through review.

The audit covers every label Bluesky applied during 2025. The paper puts the total at 10.6 million; summing the 13 label rows in its Table 2 ourselves gives 10,681,824. The party applying those labels is the moderation service Bluesky operates itself, which the paper shortens to BMS. Third-party labelers that users can subscribe to separately are outside the scope. Every figure that follows describes that one default service, and the authors themselves leave extending the audit across the wider federated ecosystem as future work.

The audit rests on building two samples. One was drawn from posts that already carried a label. The other was drawn at random from the full post stream, without looking at whether a label was there. The two samples answer different questions.

The audit paper's sample design. The two figures are answers to different questions, drawn from different samples.

Humans did the annotation. Two co-authors judged each post independently, and a third broke ties. On the binary task of harmful or not, the two annotators reached a Cohen's kappa of 0.802, agreeing on 1,827 of the 2,000 posts. At that level of agreement in a label-quality audit, there is no reason to suspect the annotation design itself.

The audit has one limitation. Its data was collected after the fact, so any post deleted between the moderation action and the collection is missing from it. The authors state this themselves, and it matters again later, where the paper's counts sit next to the platform's own.

Precision and recall sound like a matched pair, as though one ruler produced both, but their denominators differ. Precision is the share of applied labels that were correct, so it only ever looks at what the system already touched. Recall is the share of warranted labels that were actually applied, so it has to look at what the system left alone. That is why precision can be measured from a sample of labeled posts while recall has to come from a sample of the whole stream, and it is why the auditors built two samples instead of one.

2.1Annotators agreed with 83.7% of the labels applied

Take the labeled side first. Across 1,000 labeled posts, the annotator majority matched the system's judgment 83.7% of the time. That number comes with a condition attached. Those 1,000 posts are a stratified sample, 111 from each of nine harm categories. The real population is nowhere near that even: porn alone accounts for 70.9% of those nine labels. Reported as "83.7% of Bluesky's labels were accurate," a balanced-sample figure has quietly become a population figure. The accurate phrasing is "0.837 on 1,000 posts drawn evenly across nine categories."

Precision is not even across label types, and 0.837 is an average over that spread. The paper's Table 4 splits the nine labels into an automated group and a manual group and reports precision for each, and the gap between the groups is wide. Because the sample holds at about 111 posts per category, a plain average of the row precisions lands on 0.837.

The audit paper's Table 4 (precision by label) in full. Figures in parentheses are the post counts for that cell. The grouping into automated and manual labels is the paper's own.

The bottom rows carry the table. Roughly one in two posts carrying the rude label was judged safe by the annotators, and intolerant split about one in three. All 111 porn posts, by contrast, agreed. The ordering here, with automated labels scoring high and human-judged labels scoring low, is not a pure read on system performance, because some of the disagreement may sit on the annotation side rather than the system side.

2.2In 1,000 random posts, people found 27 and the system caught 6

Measured in the other direction, the picture inverts. Annotators read all 1,000 posts pulled at random from the stream, without knowing which ones carried a label. They judged 27 of them harmful, and of those 27, the system had already labeled 6. That is recall 0.222. The 4.5× in the paper's abstract is the ratio between the 27 and the 6: on the same sample, human annotators flagged 4.5 times as much harmful content as the moderation system did. The remaining 21, which is 77.8% of what the annotators found, passed through the stream unlabeled.

The grid shows the audit's strength and its limit at the same time. The strength is that somebody outside the company established that only twenty-seven cells are colored. The limit is that twenty-seven is a small denominator. A single post moving either way swings recall between 0.185 and 0.259. The paper itself issues no warning about the sample size. So the right way to read 0.222 is as a direction rather than a precise estimate, and that is how this report reads it.

2.3The paper's limitations section argues for the system

Most of the limitations the audit paper states about itself work in the system's favor. Of the posts labeled intolerant, 79% were replies to another post; for rude the share was 97% and for threat 85%. Annotators read those replies one at a time, without the root post. In the paper's own words, this indicates a potential lack of additional context which Bluesky's moderators might have had.

The numbers back that up. The bottom row of the table above shows agreement between system and annotators running at 90.9% on root posts and dropping to 71.5% on replies, a gap of 19.4 percentage points. Human judgment wobbled where context had been cut away, which is different from saying the system was that much more wrong; and the labels with the weakest precision happen to be the labels with the highest reply share, which fits that reading.

The paper's qualitative analysis backs that up. Re-examining the 50 posts the annotator majority had called safe turned up two dominant patterns. In the first, a reply read on its own, with no parent thread, gave no way to judge tone or intent. In the second, the content was visually ambiguous: body art resembling self-harm imagery, film stills caught as graphic media, album covers with no sexual intent. Anyone who works on label quality will recognize that list, because how much context an annotator is given is itself part of label quality.

The auditors also measured the gap between when a post went up and when its label was applied. Every label leaves a delay behind it, so the distribution can be plotted per label type, and it comes out in two clumps. One clump has medians of a few seconds, the other medians of several days. That split is not this report's invention. It is the row grouping in the paper's Table 3, where the first block is headed "Potentially automated label" and the second "Labels with higher human oversight."

The empty middle is the point of the chart. Nothing at all lands between one minute and one hour. Sexual content and spam are handled within seconds of going up, while the nuanced, high-stakes labels such as hate and threats take anywhere from 8 hours to 13 days. Two separate processing paths live inside one system. For the record, Table 3 puts the median delay for porn at 5.5 seconds. The paper's introduction says 7.1 seconds, and we treat Table 3, which carries the full set of percentiles, as authoritative.

The fast side has long tails too. nudity has a median of 8.1 seconds and a 95th percentile of 32 days; self-harm has a median of 10.2 seconds and a 95th percentile of 10.3 days. Even inside the automatically applied labels, some share of the traffic is taking a human-handled route.

3.1The platform tells the same story about itself

Splitting automated from manual by delay is an outsider's inference. It gets stronger because the platform's own disclosure lines up with it. Bluesky's 2025 transparency report, published on 29 January 2026, lists volume by label alongside the share applied manually. That column, copied straight across, looks like this.

Top labels from Bluesky's 2025 transparency report (29 January 2026). The label names are the platform's own and differ from the names used in the paper.

The three labels the paper measured in days are the three the platform's table marks 100% manual. The labels the paper measured in seconds sit between 1% and 3%. The same report says 95.34% of applied labels come from automated systems, and that every uploaded image and video is sent to the third-party provider Hive for assessment. The paper, for its part, writes that its analysis corroborates Bluesky's official transparency report. The outside inference and the inside disclosure do not contradict each other. Neither source, though, can tell you whether any individual label was applied by a machine or a person.

One cell does not line up, and the paper resolves that one too. sexual-figurative is marked 0% manual in the platform's table yet carries a median delay of 10.8 days. Bluesky's 2024 moderation report closes the gap by clarifying that this label was predominantly applied when users appealed automated misclassifications. The human hand arrived through the appeals path rather than the initial decision.

3.294% of the labels sit on the fast side

The two paths are sized very differently. Summing the 13 label rows in the paper's Table 2 ourselves and splitting them by the paper's own two groups, the eight potentially automated labels are 94.2% of the total and the five human-oversight labels are 5.8%. Taken on its own, porn is 68.9% of the total, more than two thirds of everything; the four sexual-content labels together come to 93.7%.

Do not read this distribution as the real distribution of harm. It has this shape because every uploaded image and video goes through an automated check, and that check is best at catching sexual content. The chart shows a distribution of detectability. The easy-to-automate categories generate the volume, and their high precision pulls the overall average up. Whatever was missed in the hard-to-judge categories is never counted, so it appears in no metric at all.

Everything so far is an observation that recall is low. Where the audit paper parts company with other audits is what comes next. The authors reverse-engineered the pipeline to find the reason for that low recall. Bluesky's automated processing runs in two layers, and signal is discarded in the gap between them.

The upper layer is Hive AI, a commercial multi-head visual classifier. Given one image, or a video frame by frame, it returns a score for each of 128 classes spread across 54 heads. Those are organized into five domains: 26 heads and 59 classes for sexual content, 10 heads and 29 classes for violence and gore, 6 heads and 15 classes for drugs and vices, 5 heads and 10 classes for hateful imagery, and 7 heads and 15 classes for other image attributes. Classes within a head are mutually exclusive and their scores sum to one.

The lower layer is Automod, the open-source rule engine Bluesky released in April 2024. It translates Hive's scores into labels by testing them against hard-coded thresholds: yes_self_harm at or above 0.96 triggers self-harm, yes_sexual_activity at or above 0.90 triggers porn, and the sexual labels run through a priority cascade from porn to sexual to nudity. The problem is how many classes those rules read. In the paper's own sentence: in total, Automod acts on 16 classes across 10 heads out of 128 classes and 54 heads total; the remaining 112 classes across 44 heads are not used.

The authors attach a caveat to all of this. The published Automod code is the April 2024 version, and nobody outside the company can confirm that Bluesky still runs exactly these rules today. In the paper's framing, it is the best available approximation of what Bluesky itself has put into the open. That is also why the experiment that follows goes to the trouble of validating the approximation.

4.1The authors measured what the discarded signal costs

Reading a structure is one thing; measuring what it misses is another. The design in §5.2 of the paper does the second one, in four steps.

• From the 1,000 labeled posts, the authors kept those carrying one of the five automated labels and holding exactly one image, which left 336: 78 porn, 67 sexual, 72 nudity, 57 self-harm and 62 graphic-media.
• For each of those, they found the semantically nearest unlabeled post, giving 336 matched pairs. The search pool was 40 million posts from March to June 2025. The sample stops at 336, the paper explains, because the developer tier of the Hive API allows only 100 calls a day.
• Before drawing conclusions they checked whether Automod is a fair stand-in for the deployed system. Re-running the 336 already-labeled posts through Automod independently caught 311 of them, or 92.6%. The 25 that came out differently may reflect a developer-facing version of the Hive API that differs from the enterprise one, the paper notes.
• Then the 336 matched posts went through the same Automod. It caught 47, or 14.0%. Annotators re-read the remaining 289 and judged 36 of them harmful, with a two-annotator agreement of kappa 0.63.

Those 36 are 10.7% of 336. The authors call the figure a lower bound on recall loss for automated labels. It comes from probing exactly one nearest neighbor per post, so the real volume of missed content has to be larger.

4.2The 36 misses split into two kinds

This is the most practically useful part of the paper. The authors opened each of the 36 posts, checked its Hive scores, and sorted them into two failure modes. The two call for different fixes.

The failure-mode split from §5.2 of the audit paper. The counts in the evidence column add to more than 14 because a single post can score on several classes at once.

The first 22 are a threshold problem. yes_female_underwear and yes_male_underwear both sit at a threshold of 0.98, and the median gap to the actual score is 0.08 and 0.07. Lower one number and these get caught; lower the same number and false positives go up. The other 14 are a different animal. In the paper's words, the content passes through Automod entirely because no rule acts on the presence of these visual categories. A score of 1.000 changes nothing if no code reads it.

None of which means the authors want the rule engine torn out. The paper says plainly that the rigidity could be by design: having explicit rules is auditable, explainable, and deployable at scale. A model dropped straight into the rules' seat takes all three of those with it. The problem is not the decision to use rules. It is that nobody had counted how much signal that decision throws away.

If the rule engine throws scores away, why not use a model that reads the content directly? A paper answering that question went up on arXiv one day earlier. "Can Foundation Models Moderate Online Content?" was submitted on 9 September 2026 and introduces ModerationBench, a benchmark built from real Bluesky posts.

These two papers are not strangers to each other. Six authors overlap, making this a sister study from the same group, and the audit paper cites it in the body as the direction a solution might take. Reading the pair as two independent studies converging on one conclusion would be wrong. It is closer to one research programme splitting the problem and the candidate remedy between two papers.

The benchmark is built like this. From March to December 2025 the team collected 1.14 billion posts from the firehose along with 11.9 million labels from the default moderation service, plus 844,000 posts from 194 verified organizational accounts. From that pool they drew four subsets of 1,000 posts each, 4,000 in all, and annotated them by hand at an inter-annotator agreement of kappa 0.813. The four subsets are Random Posts, Moderated Posts (already carrying a label), Near-moderated Posts (semantically close to labeled posts but carrying no label), and Safe Posts from the organizational accounts.

Table 4 of the sister paper, ModerationBench. The 0.0 for the deployed BMS on Near-moderated Posts is structural rather than a performance reading: that subset is built entirely from posts carrying no label. The recall cell for the deployed BMS on Random Posts is left blank here. Neither paper states how that particular figure is computed, so we cannot confirm it was measured on the same ruler as the audit paper recall quoted in the previous section.

On the Random Posts subset alone the gap is wide: 0.60 F₁ for the best model against 0.22 for the deployed system. The reason that comparison needs a qualifier attached sits in the same table. On Moderated Posts the deployed system scores 0.91, effectively level with the best model's 0.92, and on precision alone it leads every model on Random Posts at 1.00. Without that qualifier, "foundation models beat the deployed system by three times" is a claim the paper does not make.

How Near-moderated Posts is built meshes with the audit result from the previous section. The subset holds only posts that are semantically close to labeled ones yet carry no label, and when annotators read them, 34.6% came back harmful. The human flagging rate on the same benchmark's Random Posts was 2.7%, so the difference is more than tenfold. The space immediately next to a label is not empty of harm, which points the same way as the 6 out of 27 above. The two figures come from the same research group sampling the same platform, though, so neither independently confirms the other.

The question the sister paper actually sets out to answer is not whether models beat the deployed system. It is which of two ways of guiding a model enforces a policy better: spelling the policy out in prose, or showing it prior moderation decisions. The paper calls the first instruction-driven and the second example-driven, and its subtitle is that comparison. Within the example-driven paradigm it tested three ways of choosing which examples to show. Prototypical selection takes the posts nearest each label's mean embedding. Contextual selection picks, for each post under judgment, the examples most similar to it. Random selection just draws at random.

At their best the two approaches came out almost level. In its strongest example-driven setting, gemini3.5 scored F₁ 0.59 on Random Posts, against 0.60 instruction-driven. They separate on stability rather than score. Aggregated across all ten models, the false-positive rate on Random Posts is 13.6% with prototypical examples and 17.2% with random ones, then jumps to 28.7% with contextual examples. The more look-alikes a model is shown, the more it flags. The false positives also pile up in one place. Of the 5,707 false positives across all example-driven models and settings, 2,470 came from rude alone, which is 43%. That is the same label the deployed system scored lowest on in the earlier table, at precision 0.509, and the same label the platform's own table marks 100% manual. Human or model, judgment splits in the categories whose criteria are hardest to write down.

5.1Purpose-built safety models lost to general-purpose ones

For anyone working on label quality, the result worth pausing on is elsewhere in the experiment. Models built specifically for safety judgments lost to general-purpose models on the same task. On Random Posts, llama-guard scored F₁ 0.14 under its own policy and 0.24 even when handed Bluesky's policy. Its own base model, the general-purpose llama4, scored 0.44 on the same subset. shieldstral managed F₁ 0.13 while flagging 34.21% of all posts. The authors conclude that specialized AI safety models are ineffective for out-of-the-box moderation.

Another result in the same paper suggests why. How much policy detail a model receives changes its behavior sharply. Given only the label names, models over-flag; once the policy adds why each thing is a problem and how to judge it, the flagging rate roughly halves while F₁ improves by up to 25%. A specialized safety model carries its own policy baked in, which leaves little room for that adjustment.

The paper also counted the policies themselves: Bluesky 3,014 words, X 9,412, TikTok 10,643, Meta 26,298. Bluesky's is the shortest of the four, and the shorter a policy is, the more room for interpretation opens up when someone translates it into rules.

5.2Throughput and cost rule out a straight swap

A benchmark score is not the same thing as a replacement. The throughput the paper reports is gemma4 handling text-and-image posts at roughly 49 per minute with the complete policy. The same paper collected 1.14 billion posts between March and December 2025, which works out to about 43 posts per second. One instance falls short of that by a factor of about 53.

Cost is the second constraint. The frontier-model API costs the paper reports are $26 to $49 for gemini and $17 to $63 for gpt per setup over the 4,000-post benchmark. That is $0.004 to $0.016 per post, and multiplying straight through by 1.14 billion posts gives $4.56M to $18.24M. Those 1.14 billion posts cover ten months, from March to December 2025, so a full twelve months would run correspondingly higher. It is a naive linear extrapolation with no batching, no caching and no pre-filtering, so treat it as a scale rather than a quote. It does establish one thing. The option on the table today is not replacing the rule engine with a model but layering the two. The paper lists its own failure to test in a live streaming setting as a limitation.

The example-driven route raises that wall further. With prototypical examples, gemma4 drops to about 10 posts per minute, roughly 6.5 times slower than with full policy details, because each example arrives with its own image and multiplies the visual input the model has to process. Labeling costs over the benchmark rise as well: 2.7 times for gemini3.5 and 32 times for gpt5.6. Since the scores are near-identical to instruction-driven and only the time and money go up, the paper does not push example-driven as the practical choice. Writing the criteria down in prose turns out cheaper than accumulating a library of past decisions.

It is easy to read this audit as a story about Bluesky performing badly. But there is nothing to compare it against. No other platform puts out the records that would let anyone produce these numbers from outside.

The metrics the industry does publish each carry a different denominator, and not one of them asks how much of what should have been acted on actually was.

Each denominator follows the publishing organization's own stated definition. The definitions of prevalence and proactive rate are Meta's, as worded in its transparency center.

Meta's prevalence is recall's nearest cousin. It measures how much of total viewing was viewing of violating content, so it does at least point at what got through. But its denominator is views, which means a post nobody saw is effectively never counted. Proactive rate, despite the name, is not a coverage metric at all. Its denominator is content that was acted on, so content the platform never acted on enters the calculation nowhere.

The regulatory record is no better. The European Union's Digital Services Act transparency database requires a platform to file a reason every time it acts, and the audit paper observes that the most common reason in that database is the uninformative catch-all of a violation of the provider's other terms of service. Collecting action counts and reasons still does not produce a coverage figure. For what it is worth, checking the list of 679 platforms that have filed to that database, Bluesky is not among them.

Pebblous diagnoses datasets and issues quality report cards. A social platform's moderation audit reaches that work through the act of measuring rather than through its subject matter. This audit is a worked example of how far a label-quality ruler reaches and where it stops, with numbers attached.

7.1DataClinic measures with the same ruler

DataClinic takes a customer's dataset and diagnoses whether its labels can be trusted. But the default motion of that diagnosis is inspecting labels that are already there. It catches the accuracy of what was labeled, while the stretches that were never labeled at all never enter the inspection, because there is nothing there to inspect. That is exactly the structure the Bluesky audit exposed. The labels that got checked score 0.837; widen the count to what was never checked and the figure falls to 0.222. The auditors could put both numbers side by side because they sampled the unlabeled side too. This is the argument for writing coverage, not only accuracy, into the definition of AI-Ready Data.

7.2A coverage gap is inherited by the model

Imagine training a safety classifier on these labels. Positive labels at precision 0.837 are usable training signal. The negatives are where the trouble is. Recall of 0.222 means a large share of the posts implicitly treated as not harmful are in fact undetected harm, and the model learns those misses as safe. This case is valuable because the direction of the gap is legible too. With 94% of labels concentrated on the side applied within seconds, the easy-to-automate categories are over-represented and the nuanced ones are under-represented.

The shape of the gap comes from section 4. The upper classifier produced the signal; the rule layer beneath it did not read 112 classes worth of that signal, so it was thrown away. Some data-quality incidents happen not because the model failed to see something but because the pipeline never read what the model saw, and on a dashboard those two causes look identical.

7.3A coverage check starts at 1,000 samples

The most practical gift this paper gives a practitioner is how cheap the method is. A thousand random items, two annotators plus a tiebreaker, a binary judgment of harmful or not. That produced a recall estimate. If a labeling dashboard is currently reporting only volume and accuracy, this is what adding one line of random-sample relabeling costs.

The restraint travels with it. A figure computed on a denominator of 27 gives a direction, not a precise estimate, so a coverage check should run on a schedule rather than once, until the readings accumulate. The lesson from the replies carries over intact as well: annotate items one at a time with no context and people get them wrong too. The gap between 90.9% agreement on root posts and 71.5% on replies is what that costs. How much context the annotation design supplies is itself label quality.

7.4Add a coverage column to the label-quality report

What Pebblous can offer here is not a new metric but a diagnostic line that has been missing. Put a coverage column next to precision in the label-quality report, and standardize the procedure that fills it: where the random sample is drawn from, how double annotation and agreement are reported, and where the level of context given to annotators is recorded.

Measure the production layer and the decision layer separately as well. In the Bluesky case the classifier did its job and the rules discarded the signal. Rolled into a single reported number, the two layers make it impossible to tell which one failed. Simply logging classifier scores and final decisions as separate records makes it possible to tell later whether a miss came from not seeing or from not reading.

Pebblous keeps refining the rulers it uses to measure data quality. This case adds two items, clearly enough: coverage next to accuracy, and the decision layer kept separate from the production layer. Thank you for reading.

The figures in this report come from two sources. Numbers internal to the papers were taken from the v1 HTML of both preprints, checked down to the table and section number, and any derived value is marked in the body as our own calculation. Platform figures come from the reports Bluesky published on its own blog, accessed 12 September 2026.

Backbone of this report

• 1.Pushpdeep Singh, Sayeh Jarollahi, Ayan Majumdar, Vabuk Pahari, Abhijnan Chakraborty, Krishna P. Gummadi, Ingmar Weber, Abhisek Dash. "Characterizing Bluesky Content Moderation Service: From Automation of Service to Landscape of Harms." arXiv: 2609.11373 [cs.CY]. Submitted 10 September 2026, 18 pages; the Comments field records acceptance at ICWSM 2027. Verified against this version: precision 0.837 and the per-label figures (Table 4), recall 0.222 and the 6 of 27 (§5.1), the 13 rows of labeling-delay percentiles (Table 3), the 13 rows of label volumes (Table 2), the Hive and Automod architecture (Appendix C), the missed-content experiment and its two failure modes (§5.2), and the reply-share and limitations passages.
• 2.Ayan Majumdar, Shounak Paul, Pushpdeep Singh, et al. "Can Foundation Models Moderate Online Content? Evaluating Instruction- vs. Example-Driven Policy Operationalization." arXiv: 2609.10410 [cs.CL]. Submitted 9 September 2026, 33 pages; the Comments field gives length only, with no publication information. Verified: the four-subset construction of ModerationBench and its annotator agreement, the per-subset human flagging rates (Table 2), the per-subset performance figures (Table 4), the example-driven results (Table 5 and §5.2), the false-positive rates (Appendix G.1), the specialized safety model comparison (Table 6), the policy word counts (Table 1), and the throughput and API cost passages. A sister study sharing six authors with reference 1.

Platform and policy primary sources

• 3.Bluesky. "Bluesky 2025 Transparency Report." 29 January 2026. bsky.social. Volume and manual-application share by top label, the 95.34% automated share, and the description of third-party screening for uploaded images and video.
• 4.Bluesky. "2024 Moderation Report." 17 January 2025. bsky.social. The statement that the sexual-figurative label was predominantly applied through the user appeals path.
• 5.Bluesky. Automod source (open-source rule engine). github.com/bluesky-social/indigo. The threshold rules that translate Hive scores into labels.
• 6.Hive. "Visual Content Moderation API" documentation. docs.thehive.ai. Head and class composition.
• 7.Meta. "Community Standards Enforcement Report" and the definitions of prevalence and proactive rate. transparency.meta.com. Denominator definitions for the metric comparison table in section 6.
• 8.European Commission. "DSA Transparency Database." transparency.dsa.ec.europa.eu. Cross-checked against the list of filing platforms.

Related Pebblous reading

• 9.Pebblous Blog. Political Affiliation Split the Harm Labels in AI Companion Chats. How annotator disagreement moves labels, worth reading against the kappa figures of 0.802 and 0.813 in this report.
• 10.Pebblous Blog. Provenance Tracking Cut Rule-Revision Relabeling to 14.7%. On the problem of deciding which labels have to be revisited when the rules change.