Engineers often unblock a teammate or catch a bug in review, but the person who gets credit later is whoever closed the ticket. Witness finds that hidden work and gives credit where it’s due, confirming every finding against a second, independent source before it counts.
Maria — “looked into this, see ENG-412, should be a one-line fix”
#eng-help · 10:00am
ENG-412 — assigned to Chen
closed 2h14m later
Confirmed — Maria unblocked Chen
+1 creditedThis reproduces the real rule against the real seeded run: Maria referenced ENG-412 in Slack; ENG-412 is assigned to Chen; it closed 2h14m later. Turn Linear off.
This is the real thing — same finding, same data. Turn a source off and watch it react.
Maria Okonkwo
this run
Unblocked Chen on ENG-412 — her Slack message landed two hours before the ticket closed.
HydraDB resolves identities and pulls Slack, GitHub, and Linear into one normalized ledger — regardless of what a later run restricts.
confirm_attributions() joins the ledger against itself: who a ticket is really assigned to, and when it closed after the message that referenced it.
Restrict the sources and the join loses rows to join against — not a branch that decided to hide them. The response says exactly what it can no longer see.
Every finding has to clear the same three conditions. If a source is turned off, one of them simply can’t be checked anymore.
All three, every time, no exceptions built in for the demo.
Not a results table at the end of the pipeline — the part of the system that carries the argument.
confirm_attributions() runs the whole temporal join inside InsForge — the core of the demo, executing where you can read it.
Every read goes through visible_source_event / visible_ticket_state, gated on the run's enabled_sources. Disable Linear and the join has nothing left.
Keyed on message content, not message id. A live re-run after a source toggle re-costs nothing — the LLM never runs twice on the same text.
An engineer sees their own findings, a manager sees direct reports, nobody sees the org. Enforced by policy, not by the UI's good behavior.
Every run's raw pull can replay from a bucket — deterministic offline demo if the venue wifi or a rate limit gets in the way.
run_stage_event rows publish to a per-run channel as the pipeline executes — resolve, harvest, classify, attribute, rank, report, live.
A tool that produces performance-review-adjacent claims about named people is one prompt away from a surveillance product. The answer isn’t a promise about our UI — it’s Row Level Security, enforced at the database, that a manager cannot query around.
| Viewer | Sees | Enforced by |
|---|---|---|
| Engineer | Their own findings | auth.uid() |
| Manager | Direct reports only | reports_to() |
| Anyone else | Nothing | no policy grants it |
divergence = invisible / (visible + invisible)
WHEREconfirmed_count >= 2
— never rendered in the API response —
Four sponsors, each carrying a piece no other one could.
Unifies a Slack handle, a GitHub login, and a Linear assignee into one person. Confirmation is impossible without knowing they're the same human — nothing else in the stack can produce this.
The attribution engine, the degradation guarantee, the classification cache, access control, and run snapshots all live here — not a results table, the thing that decides what counts as proof.
The public endpoint, bounded-concurrency classification calls, per-message retry on malformed JSON, and stage checkpointing so a crashed run resumes instead of restarting.
Turns "this message mentions ENG-412" into "this message unblocked someone on ENG-412." Rule (a) confirms the link; Pipeshift characterizes the help.
Honest about the gap: schema and functions exist for these; the pipeline code that populates them doesn’t, yet.
Yes — that's the point. "This message referenced a ticket, it's assigned to someone else, and it closed inside the window" is a temporal join. Running it as a Postgres function inside InsForge, instead of application code, is what lets us prove the degradation instead of asking you to trust it.
Every read in the attribution path goes through a function gated on the run's enabled_sources — visible_ticket_state, visible_source_event. Disable Linear and the underlying rows are structurally absent from the query, not skipped by an if-statement. The function body is nine lines of SQL; we'll put it on screen.
Access is enforced by Row Level Security, not a UI promise. An engineer sees their own findings; a manager sees direct reports; nobody sees the org-wide view. There is no query path that returns it — that's a database guarantee, not a feature flag someone could flip.
We promise cited findings, not a score — a person is not rankable below two confirmed attributions, so a new hire with two Slack messages can't top a list. The number exists as an internal sort key. It never reaches the response, because a visible score is exactly the kind of dashboard number this project is arguing against.
The response includes a degraded block naming exactly which confirmation rules can't run and why, instead of silently returning fewer results. A tool that reports its own blind spot, not one that hides it.
Not yet. It stays in the source toggle so the degradation demo has a fourth lever, but no attribution logic reads from it. We'd rather say that plainly than pretend otherwise.
Classification is cached by message content hash, not by run. Toggling sources and re-running only recomputes the attribution join — milliseconds, not a fresh LLM pass over every message in the window.
That sentence used to be something you had to take on faith. Scroll up — it isn’t anymore.