Skip to content

Filter Stack Map

Mapping tool — instantiates Structural Filter Intersection Audit

Lays out every filter a system applies in parallel — what each screens for, who owns it, and what it optimizes — as a single map of the whole stack.

The Filter Stack Map is the inventory-and-diagram that makes an invisible screening pipeline visible on one page. It names every filter an output must pass before it becomes visible, funded, ranked, or treated as legitimate, and for each records three things: who owns it, what that owner is optimizing, and the rule that gets an output cut, softened, or delayed. Its defining discipline is that it is purely descriptive and static — it draws the filters side by side as parallel, co-equal gates and stops there. It says nothing about what jointly survives all of them (that is the intersection model) or whether the filters are secretly correlated (that is the independence check). The map is the substrate every other audit mechanism reads from.

Example

A metropolitan newsroom is convinced it has no censor, yet an investigation into its largest advertiser somehow never runs. A Filter Stack Map traces the path from "story idea" to "front page" and names each gate: the editor's news judgment, legal review for libel exposure, the ad department's sensitivities, the beat reporter's dependence on official sources, house style at the copy desk, and the finite space budget. For each gate it records the owner (who can say no), the incentive (ad revenue, legal safety, continued source access), and the pass/fail rule (what gets a story killed or watered down). Laid out together, the map shows the advertiser story independently disfavored by four different filters — before any single person has decided anything. No conspiracy is required; the map simply makes the standing arrangement legible.

How it works

The distinguishing move is that it treats filters as parallel and co-equal, not as one approval chain. For each filter it captures a fixed record — {what it screens for, owner, incentive, pass/fail rule} — and codes whether the filter rejects, softens, delays, or reframes. It deliberately refuses to compute the joint outcome; its job is to enumerate the gates completely and honestly, so the mechanisms that model survival, coupling, and omission all have a shared, agreed-upon picture to work from.

Tuning parameters

  • Granularity — one box per department, or per individual decision-point. Finer resolution catches sub-filters (a single editor's standing peeve) but bloats the map toward unusability.
  • Incentive depth — stop at each filter's stated purpose, or trace down to the real economic or career incentive behind it. Deeper is more honest and more contentious.
  • Scope boundary — where the pipeline is judged to start and end (idea→publish, or submission→rank→distribute). Too wide and the map is unreadable; too narrow and off-map filters hide.
  • Transformation coding — whether to log only kill/pass, or the full reject / soften / delay / reframe taxonomy per filter.

When it helps, and when it misleads

Its strength is turning "we have no censor" into a concrete, ownable list of gates and incentives — the precondition for every downstream audit, and the artifact that lets a team argue about the arrangement rather than about individuals' motives. Its failure mode is that a map is not a measurement: it can look complete while missing the filter no one will name aloud (the unwritten rule), and it invites the illusion that naming a filter governs it. The classic misuse is drawing it once and treating it as permanent while the real stack quietly drifts. The discipline that guards against this is to validate the map against evidence of what actually fails to appear — rejected-item and omission data — rather than against what people say they screen for.[1]

How it implements the components

The Filter Stack Map fills the descriptive, structural slice of the archetype — the parts a static inventory can hold:

  • parallel_filter_inventory — its core deliverable: the enumerated set of every filter acting in parallel.
  • filter_owner_and_incentive_map — each filter annotated with who controls it and what they optimize.
  • filter_pass_fail_criteria — each filter's recorded accept / reject / soften rule.

It does NOT model what jointly survives (surviving_intersection_model — that's Intersection Matrix), test whether the filters are genuinely independent (filter_dependency_graph — Filter Independence Check), or track what is systematically omitted (omission_and_homogenization_ledger — Omission Pattern Analysis). The map is the static substrate those consume.

Notes

The owner-and-incentive layer is where the map earns its keep and where it turns political: naming what a filter's owner actually optimizes — not its official rationale — is the step teams flinch from, and the one that makes the rest of the audit possible. Keep this descriptive map strictly separate from any judgment about which filters are legitimate; that judgment lives in the Filter Rationale Register, not here.

References

[1] The propaganda model of Herman and Chomsky (Manufacturing Consent, 1988) frames mass-media output as the product of several parallel filters — ownership, advertising, sourcing, flak, and a unifying ideology — no one of which is a censor. It is the canonical illustration of why the whole filter set, rather than any single gate, is the right unit of analysis. ↩