Skip to main content
Knowledgebase is built to collect as little as the job needs, keep that copy inside your team, and let you take it back out. It does not inherit per-file or per-page permissions from Drive, Confluence, Notion, or Otter. The privacy control is what you choose to connect — and who in Keldyn is allowed to open Knowledgebase. This page is for customers deciding what to index. Product setup for each source is on the connector pages.
Knowledgebase is available to Keldyn admins who also hold Read organisational context. Connecting a source is a Keldyn-admin action. External Auditor roles do not get this permission by default.

​
How privacy is preserved

You choose the boundary

Drive indexes one folder. Confluence indexes selected spaces. Notion indexes pages you share at consent. Otter indexes chosen channels. Until that choice is made, Keldyn indexes nothing — it does not fall back to “everything the account can see.”

Read-only connectors

Keldyn never creates, edits, moves, or deletes files in Drive, Confluence, Notion, or Otter. Disconnecting only affects the Keldyn index.

Narrow collection

Only text that can be searched is kept. Spreadsheets, slides, images, and files over 25 MB are skipped. Otter audio is never fetched or stored.

Tight product access

Indexed text is team-scoped. Only Keldyn admins with the dedicated permission can search or browse it. Credentials are encrypted and never shown again after you paste them.
Once a document is in the index, any Keldyn admin on the team who can open Knowledgebase can read it. A Confluence page restricted to four people, a Drive file shared with one group, or an Otter meeting shared with three becomes readable to those admins. Only connect sources you are willing to make visible to them.

​
Who can see indexed documents

There is no per-document access list inside Keldyn. Removing the unused permission-group field was deliberate: a column that stored share emails but never filtered reads would have looked like protection it did not provide. What you connect is the access boundary. Source-side restrictions inside that boundary — a hidden Confluence page, a Drive file shared with two people, an Otter conversation shared with the attendees — do not apply in Keldyn after the document is indexed.

​
What is stored, and what is never fetched

​
Indexed copies

These become searchable passages in your team’s index:
  • Org Library documents and use-case files you already keep in Keldyn
  • Supported files under a connected Drive folder
  • Pages (and supported attachments) in selected Confluence spaces
  • Notion pages shared with the integration
  • Otter conversation text from selected channels
  • Manual notes typed into the index browser
Each indexed item is stored as the document text, a heading outline, and smaller passages used for search. Optional embeddings (numeric representations of those passages) stay in your database so meaning search can run without sending the whole corpus on every query. Library and use-case files already in Keldyn are referenced, not duplicated as a second upload.

​
Read live, never copied into the index

Questions about the organisation itself — the profile, org chart, team roster, use case register, architecture summaries, audit rollups, and third-party register — are answered from the current Keldyn record. Those answers are not a snapshot from the last sync, and they are not written into the document index. Audit engagements are reported as counts of controls by status, not as control titles, auditor comments, or evidence filenames. The third-party register is a one-line list unless the question names a vendor.
Live records are visible on the same Knowledgebase permission as indexed documents. That is a wider door than some of those records’ own pages. Treat Knowledgebase access as access to a summary of the organisation, not only to uploaded files.

​
Never fetched or stored

Integration credentials (OAuth tokens, Otter API keys) are encrypted at rest and returned to the app only as [redacted]. See Data security.

​
Otter and personal data

Otter is the one source that routinely contains identifiable people, including people outside your organisation.
  • Keldyn stores conversation text (summary, outline, insights, action items, notes, transcript) and meeting metadata (title, date, channel, speakers, Otter link).
  • Participant and calendar-guest emails may be kept in metadata for attribution. They do not grant anyone access.
  • You remain responsible for your recording-consent posture. The connect screen states this before you paste a key.
  • Whole-workspace ingestion is a separate opt-in. Leaving channels unset indexes nothing.
Transcripts rank below written policy so a hallway disagreement does not outrank a signed-off document. That is a ranking rule, not an access rule — admins who can search can still open the transcript.

​
Taking content back out

Unpublish keeps enough of the row that an old citation can still resolve during an audit. It is not a way to hide a document from people who already have the link; use Remove from index when you need the passages gone.

​
What we ask you to decide

  1. Connect only sources that your Keldyn admins should be able to read. The folder, spaces, pages, or channels you pick are the only sharing decision Keldyn will honour.
  2. Keep restricted or personal material out of that boundary — or remove it from the index after the fact.
  3. Treat Otter channel choice as a personal-data decision, not only a coverage decision.
  4. Grant Read organisational context only to people who should search the corpus. It is a dedicated permission so you can leave it off for auditors and custom roles.

Knowledgebase

How search, browse, ranking, and sync work.

Google Drive

Folder boundary, read-only scopes, and skipped file types.

Otter.ai

Channel allowlist, text-only collection, and consent.

Security and privacy

Platform posture, encryption, and AI data handling.