Connect GitHub, Slack, and Jira — without leaking them

Most of what your organization knows was never written down for a memory system. It is in merged pull requests, in the channel where the incident was actually debugged, in the Jira comment where someone explained why the workaround is still there. Illumina now connects to those systems directly: GitHub, Slack, and Jira.

The interesting engineering is not the ingest. It is that a private channel has to stay private after it becomes a memory.

Ingest is the easy half

Connect a source from Settings → Integrations, pick the repositories, channels, or projects you want, and history starts landing in the namespace you chose. GitHub is a self-serve app install; the post-install landing verifies the installation against the account that just installed it, and refuses an installation it cannot attribute. Slack and Jira use a deployment-held credential, and a workspace claims its team or site by proving which one it is.

Each connector runs both paths. Webhooks deliver events as they happen; a scheduled poll sweeps the same sources on a cursor, so an event dropped in transit is a late memory rather than a missing one. Sync is fair across sources — one enormous repository backfilling cannot starve the rest of a workspace's queue — and an installation belongs to exactly one workspace, with a documented way out.

Merged PRs, issues, channel history and thread replies, Jira issues and comments all land as ordinary memory: extracted facts, resolved entities, links into the graph. Recall does not know or care which connector a fact came from.

The hard half: a private channel is still private

The failure mode is obvious once you say it out loud. Ingest a private channel, and a fact from it can surface to someone who was never in that channel. Worse, an observation — a synthesized conclusion drawn from sources across the namespace — can leak what its sources said without ever quoting them. A leaked conclusion is more dangerous than a leaked chunk: confident, tidy, and detached from the provenance that would have shown it should not exist.

So the connectors do not just carry content. They carry the access boundary that content came from, as a namespaced group key:

Every document carries the set of keys that grant read. Every viewer carries the set of keys they hold, resolved from the same membership sync that keeps the content current. Visibility is one array-overlap test, which collapses three different permission models into a single predicate.

Enforced before anything is rendered

Enforcement is a per-namespace flag. Until you flip it, recall behaves exactly as it did before the feature existed — this is a switch you turn on deliberately, not a migration that changes your results overnight.

With it on, the filter runs at the recall orchestrator: after every retrieval arm returns, and before fusion, reranking, and any rendering of a response. Nothing restricted reaches the synthesis step, which means there is no filtered-the-answer-afterward story to explain in a security review. Observations are enforced by the same test, because an observation carries the intersection of its sources' groups — inherit the most restrictive, always.

Two more rules matter:

• Fail closed. Under enforcement, a memory with no ACL groups, or a viewer with no overlapping group, is dropped. Unknown means no.
• No side doors. Decision lineage, as_of history substitution, and the community arm are all filtered too. A restricted memory reachable by an indirect path is still a leak.

What this is for

Namespace isolation answers "should this team see this body of knowledge at all." It is the wrong tool for "everyone in engineering shares a memory, but the security channel is not in it." That is the question source-aware access control answers, and it is the question that decides whether org-wide memory is something you can actually turn on.

Connectors are available on every plan. See the setup runbooks for what each one needs, and turn enforcement on per namespace when you are ready for it.