Bouncer-Promoter Quality Gate

The fastest way to break a KMS is to let everything in. The second-fastest way is to make the user decide what belongs. The bouncer-promoter pattern is the resolution: two distinct filters, applied in order, neither owned by the user.

The principle

Two passes on every inbound piece of material:

1. Bouncer — does this belong in the system at all? Reject duplicates, low-signal noise, transient state, things already covered. Most of what hits the inbox does not survive this gate.
2. Promoter — where does the surviving material go? Routes the bouncer-approved input to the right type, file, and links.

Two passes, not one. Mixing them produces a system that either lets in too much (when the gate is permissive about quality because it's busy thinking about destination) or rejects too much (when the gate is strict about destination because it's busy thinking about quality).

Why it matters

Without a bouncer, a KMS becomes a junk drawer. Even a well-routed junk drawer is still a junk drawer — every search returns five results, four of which are noise from the period when you forgot to clean up.

The cost of letting noise in is borne forever (every future search wades through it). The cost of rejecting it is borne once (the user sees a "skipped this because…" trace and can override). That asymmetry is what makes a strict bouncer worth the friction.

How it works

The bouncer applies a small set of explicit rules, stated in CLAUDE.md or a skill:

• Already covered? Search for existing entries on this topic. If a stronger version exists, reject and link.
• Substantive? Does this assert a fact, decision, observation, or pattern — or is it phatic noise?
• Stable? Is this knowledge (durable) or state (transient)? State goes to a different layer.
• Sourced? For external claims, is there a source? Unsourced assertions get flagged.

What survives the bouncer gets the full promoter treatment: typed, linked, summarised, surfaced where relevant.

In Claude primitives

• Skills like bouncer-check and promoter-route keep the two passes cleanly separable and testable.
• Subagents can run bouncer-check in parallel on a batch of inbox items, returning a verdict + reason.
• Hooks (PreToolUse on file-write skills) can enforce that nothing gets written without bouncer approval.
• CLAUDE.md holds the bouncer rules — short, explicit, easy to revise.

Where I've seen it

The pattern is named after an app-scoped second-brain KMS, where bouncer/promoter are first-class concepts in the ingest pipeline. The same pattern (under different names) runs in my personal KMS's session-import flow and in a team KMS's customer-signal triage.

The contrarian read

Strict bouncers reject things you later wish you had kept. The trade is real. The default should still be strict — recovering a rejected item from the inbox archive costs less than living with a polluted knowledge store.