Org Signal Feed

The store and the feed are two layers with opposite access models. intel_signals is shared, append-only and RLS deny-all — one objective row per event, no organization_id, no score. Scoring sits on the boundary and fans each row out to every org whose universe it touches; survivors materialize into intel_org_signal_feed, the only RLS-per-org table of the stack, which the launchpad, the inbox, the digest and downstream agents read. Signals reach the store by two ingest classes — a user's sonar pull or an automated push — and that class decides whether the gate applies (next section). Click any node to spotlight the paths it touches.

A signal reaches intel_signals by one of two classes, and the class — not the score — decides how it is treated. A pull is user-initiated: someone ran a sonar search, so every signal it finds is returned and shown, ungated. A push is automated: nightly agents and scrapers surface signals nobody asked for, so they are gated — only the strong ones get pushed, and a brief competitor-ICP check keeps a hot lead from going to rival agencies at once. Every discovery, either way, is logged in intel_signal_ingests — one row per find, many per fact — so a re-find never doubles the signal yet is still attributed to the run that found it.

The path from one shared signal to a ranked launchpad row, for one org. Ingest + ICP pair the objective fact with this org's relevance; Score collapses it to a scalar; the path-aware gate drops weak pushes (but never a pull); Materialize writes the intel_org_signal_feed row with its origin; Rank orders it; Deliver renders the launchpad, inbox and digest. Tap a stage to read what goes in, the transform, and what comes out.

The idea the whole layer turns on. One intel_signals row is scored separately for every org. The signal-type weight and the recency decay are the same for all of them — only icp_fit differs — so the same fact lands as three different scores and crosses different thresholds. Pick a signal, then age it to watch decay drag every score down through the same two gates.

Three factors, multiplied, on a 0–10 scale so the canonical thresholds (feed_threshold 4, digest_threshold 7) read directly. Weight is the intrinsic importance of the signal type; ICP fit is the per-org relevance; decay is a 90-day half-life applied to observed_at at read time — the store row is never rewritten, so the same signal scores lower simply by getting older.

One table — intel_org_signal_feed — holds the activation copy. It is the only org-scoped table of the signal stack: organization_id and the score live here, never on the shared signal. Every row points back at one immutable intel_signals row, so many orgs' feed rows fan from one fact.

Three surfaces read the one feed table. The launchpad shows the hottest rows ranked by score — a mix of both origins, each tagged sonar or proactive so the user knows whether they pulled it or the system pushed it. The always-on signal inbox renders every feed-tier row; the periodic digest batches only the strongest (≥ digest_threshold 7). seen_at tracks read state per row, so what is new stays marked.

The two layers invert their access model. The shared store is RLS deny-all — no client touches it, only the ac-python-api service role writes and reads. The feed is RLS allow-per-org: each org reads exactly its own rows, scoped by organization_id, and the same service role is the only writer (the materializer). One fact, isolated per tenant at the feed boundary. Pick an actor to watch RLS resolve every store and feed row, with the feed predicate evaluating live.