Before/After Content Audit¶

Audit — instantiates Structural Filter Intersection Audit

Compares the same outputs before and after they pass through the filter stack — draft versus published — to measure what was cut, softened, delayed, or reframed.

The Before/After Content Audit works on matched pairs: the same item in its pre-filter form and its post-filter form. It is not concerned with what the stack rejected outright, nor with the whole set of survivors, but with how the survivors were changed on the way through. That is the filtering that hides in plain sight — the claim that got hedged, the number that became a qualitative aside, the recommendation that was deferred — in outputs that did get published and therefore leave no rejection trail. By preserving and sampling the pre-filter versions, the audit reconstructs the population of what existed before the stack acted and holds it against what came out.

Example¶

An environmental agency scientist's draft risk assessment states that a chemical is "likely carcinogenic at current exposure levels." The published assessment reads "may pose risks under certain conditions; further study is warranted." No one lied, and each edit — legal caution, interagency review, sensitivity smoothing — was locally defensible. The Before/After Content Audit lines the draft up against the published text clause by clause and codes each change: a firm causal claim became conditional, a quantitative estimate became a hedge, a recommendation was deferred. Repeated across a sample of thirty assessments, a pattern emerges — systematic softening in one direction — that is invisible in any single document and visible only because the audit kept the "before."

How it works¶

The distinguishing requirement is that pre-filter artifacts must be preserved and matched to their published forms. The audit then codes each paired change by type — cut / softened / delayed / reframed / unchanged — and, crucially, by direction (toward or away from a stance). It is a diff for content, run across the filter boundary, and its signal is the base rate and directional skew of transformations, not any single dramatic edit.

Tuning parameters¶

Pairing unit — whole document, claim, or sentence. Finer units catch subtle softening but cost labor.
Change taxonomy — how many transformation categories to code (binary changed/unchanged, versus cut/soften/delay/reframe). A richer taxonomy reveals mechanism but adds subjectivity.
Baseline capture point — which "before" counts (first draft, pre-legal, pre-executive). Earlier baselines show more filtering but fold in ordinary editing.
Directional coding — whether to record merely that something changed or which way it moved. Direction is where structural bias shows, and it is also the most contestable call.

When it helps, and when it misleads¶

Its strength is that it catches the filtering that leaves no rejection record — the softening inside things that still ran — which makes it the only mechanism that sees inside survivors. Its failure mode is that not every change is a filter: good editing also cuts and tightens, so the audit can over-read ordinary craft as suppression. The classic misuse is parading a few vivid before/afters as proof of an agenda. The discipline that guards against this is to code a representative sample and report base rates and direction rather than anecdotes, and to distinguish improvement-edits from stance-edits explicitly.

How it implements the components¶

candidate_output_universe — by preserving and sampling the pre-filter drafts and submissions, the audit materializes the population of what existed before the stack acted — the "before" against which all filtering is measured.

It does NOT sample outright-rejected items (rejected_or_transformed_output_sample — Rejected-Item Sampling), consolidate the overall pattern of what's missing (omission_and_homogenization_ledger — Omission Pattern Analysis), or model the surviving intersection (surviving_intersection_model — Intersection Matrix). Its matched before/after pairs feed those.

Instantiates: Structural Filter Intersection Audit — supplies the direct evidence that survivors were transformed, not merely selected.
Consumes: Filter Stack Map — to know which filters sit between the draft and the published form.
Sibling mechanisms: Rejected-Item Sampling · Omission Pattern Analysis · Intersection Matrix · Filter Stack Map · Shadow Review Board

Notes¶

This audit depends entirely on the "before" existing and being retained. In many pipelines drafts are discarded, edits happen in conversation, or the raw submission is never recorded — and where that is true, the mechanism cannot run. There the baseline has to be manufactured instead by a held-out or shadow stream (Shadow Review Board), against which the published output is compared.