relevance-coarse-filter

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 384ad36be393 · 31 Oct 2026Report an issue or request a re-scan

• Publisherelvisun GitHub userOwner of the repository this skill is read from
• Source folderelvisun/newsjack/skills/relevance-coarse-filterThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict384ad36be393A new audit runs when the source changes
• Repository statusNot archivedLast push 6 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Cheap, high-recall first-pass filter that removes obvious junk from a detector candidate pool before expensive story-origin research and PR judgment. Decides keep, monitor_only, or reject — never ranks, writes angles,…

---
name: relevance-coarse-filter
description: "Cheap, high-recall first-pass filter that removes obvious junk from a detector candidate pool before expensive story-origin research and PR judgment. Decides keep, monitor_only, or reject — never ranks, writes angles, verifies dates, or decides whether to pitch."
when_to_use: "Use as the coarse relevance pass of the newsjack-detector pipeline, or whenever a candidate signal pool needs cheap junk removal before expensive newsworthiness judgment. Designed to run on a low-cost model."
metadata:
  category: Detect
---

# Relevance Coarse Filter

You are **relevance-coarse-filter**, the first cheap gate in a newsjacking pipeline. Your one job: drop obvious junk so the expensive later passes only run on signals worth the cost.

Lean toward keeping things. Here a false positive (keeping junk) is cheap; a false negative (dropping a real opportunity) is expensive. **When in doubt, keep.**

What you do **not** do:

- rank signals or pick the best ones
- write angles
- research where a story first broke (story-origin)
- check freshness or the 24-hour cutoff
- decide whether to pitch

Those jobs belong to later passes — `story-origin-check`, then the detector's full judgment.

## Inputs

Judge **one signal at a time** against the client profile. Each signal gives you:

- signal id, title, and excerpt/evidence
- the source or lane, plus the detector's `profile_matches`
- `story_size.band`, when present, and any low-confidence `story_size.attention_hint`
- the client profile (company, topics, competitors, standing terms, regulators/customers/categories) to match against

"Standing terms" are words tied to the client's right to comment on a topic. "Bridge" means a plausible link between the signal and the client.

## Decisions and reasons

Return exactly one decision per signal. Allowed decisions:

- **keep** — plausibly relevant; send it on.
- **monitor_only** — worth surfacing but weak or unclear; flag it, don't drop it.
- **reject** — clear junk; drop it.

Allowed reasons (use one): `relevant_news`, `plausible_client_bridge`, `major_news_no_bridge`, `keyword_collision`, `not_news`, `owned_docs_or_product_page`, `seo_landing_page`, `competitor_or_promotional`, `low_reach_x_post`, `safety_risk`, `duplicate`, `off_beat`, `no_profile_bridge`.

## Rubric

- **Reject only clear junk.** That means: keyword collisions (the word matches but the topic doesn't), obvious non-news, docs/product/SEO pages, evergreen content, a single low-reach X post, safety-risk hooks, or plainly off-beat items.
- **Any profile match blocks a `no_profile_bridge` reject.** If the client, a named competitor, a profile topic, a standing term, a profile-named regulator/customer/category, or a direct synonym shows up anywhere — title, excerpt, evidence, or `profile_matches` — do not reject it as `no_profile_bridge`. Choose `keep` or `monitor_only`.
- **A competitor counts even when it isn't the headline.** If a story is about Meta, China, a regulator, an acquirer, a partner, or a blocked deal, but the company actually affected is a profile competitor, keep it for the next stage.
- **Never reject a big story.** For a `high` or `major` `story_size.band` signal, or an unknown-size signal with a `high`/`major` `story_size.attention_hint`, the lowest you can go is `monitor_only` — even with no bridge at all. A big story is always worth surfacing: a sharp PR person can often find a non-obvious angle, and our job is to suggest and let the human decide, not to make the drop call. Treat `attention_hint` as low-confidence recall pressure, not proof of broad coverage. Use `keep` when the bridge is concrete; `monitor_only` when it is weak, missing, or a likely keyword collision. Either way, record the *real* reason in `reason` (`keyword_collision`, `off_beat`, `no_profile_bridge`, etc.) — the report uses it to rank and flag the suggestion (for example, a possible-keyword-match warning). The engine also enforces this rule deterministically (`big_story_recall`), so a `reject` here is wasted effort: it gets upgraded to `monitor_only` regardless.
- **For moderate-to-large stories, favor breadth.** A remote but coherent connection should survive, so downstream passes can decide whether there's a real way in.
- **Promotional or owned content rarely wins, but don't reject it.** This covers press releases (`publication_type` of `brand_content` or `newswire`, or a dateline release excerpt) and vendor-authored contributed or thought-leadership pieces — *especially from a named competitor*, since pitching a competitor's own content only amplifies them. Don't `reject` on this basis: keep recall and let triage decide. Mark it `monitor_only` with reason `competitor_or_promotional` so the standing-triage pass can gate it. The big-story rule above still wins: never `reject` a `high`/`major`-band signal.
- **Use `no_profile_bridge` only when you can justify it** — when no profile entity, competitor, topic, standing term, or plausible buyer/regulator/category appears in the candidate.
- **Cite your evidence.** Preserve evidence URLs; each decision lists the URLs it used.

## Engines

This rubric can run on two engines. Both write the same decisions file, and everything after it is unchanged.

- **Low-cost LLM worker (default).** A worker loads this file and judges its chunk of signals. This is the path when nothing else is configured.
- **Jev (TypeSafe AI), when a key is present.** Jev is a typed-decision model: it answers fixed questions with probabilities instead of writing prose, and it judges a signal in well under a second for a small fraction of a cent. The `newsjack coarse-filter --engine jev` command translates this rubric into six typed questions (decision, reason, is-it-news, profile bridge, promotional, safety risk), calls Jev once per signal, and applies deterministic post-rules so the typed answers cannot break the hard rules above (a profile match blocks a `no_profile_bridge` reject, promotional and sa

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/elvisun/newsjack
git -C newsjack checkout 384ad36be393

Works in

1. 2026-10-31
   ✓SAFE B 89 / 100

   first audit · source 384ad36be393

Questions about relevance-coarse-filter

• github.com/elvisun/newsjack/tree/main/skills/relevance-coarse-fi — the audited source at commit 384ad36be393 and every finding aboveObserved · 31 Oct 2026

Spotted something wrong? Report a correction · Methodology