Public knowledge base

The Public Knowledge Base (Public KB) is the part of your knowledge base that is accessible without signing in via a direct link, a widget, or an iframe. The articles you have explicitly marked as public end up here.

Why:

• Customer self-service — customers find answers on their own, without contacting support
• SEO — public articles are indexed by Google and other search engines
• Demo — prospective clients read the documentation before purchasing
• Partners — access to technical documentation without needing to create accounts

#How an article becomes public

Publicness is enabled by two settings — one at the article level and one at the organization level. Until both are in place, anonymous visitors won't see the article.

There is no "public" space TYPE. Spaces are only Corporate / Private. An article becomes visible not by moving it into a special space, but via the publish_state=public flag (in a corporate space) together with the organization's public access mode being on.

#publish_state states (ADR 0029)

LiKE uses the publish_state field (it replaces the old visibility field). Four states:

In the UI, the state's color is shown by a dot indicator:

The same badges are visible in the article list in Article management.

#The virtual __public__ space

When an anonymous user opens the Public KB via a direct link or a widget, technically they are not in any of your spaces. Instead, LiKE uses a virtual "space" __public__ — a sentinel value that:

• Does not exist in the database as a real ArticleCollection.type='public'
• Includes articles that are public on their own or by inheritance from a public folder
• Is used for filtering in the anonymous user's RAG search
• Is shown in the SpaceSwitcher as " Public articles" (if the user also has private spaces)

If you are an authorized member, switch to __public__ in the SpaceSwitcher to see exactly the same set of articles that an anonymous visitor sees — this is handy for checking "what did I accidentally publish."

#Setup (step by step)

#Step 1 — Place articles in a corporate space

You can publish externally only from a corporate space (in private spaces publishing is blocked). If your articles are in another space, move them into a corporate one: one by one via the article's context menu → Move, or in bulk (checkboxes → Move). Space types are Corporate and Private; there is no separate "Personal" type — a space stays private until you invite someone.

#Step 2 — Make the articles public

Switch the articles you need to publish_state = public (see Article management):

• In bulk — select with the checkboxes → the globe () button on the actions bar → Public
• A single article — the "⋮" menu → "Visibility: …" → Public; in "Tree" mode — the context menu → "Make public"
• In the editor — the access badge next to the article title

After that, the status indicator turns green and a Public badge appears. If the article contains personal data, a confirmation dialog opens — see "Personal data check before publishing" below.

#Step 3 — Turn on the organization's public mode

Settings → Organization → Access mode → choose "Public".

• Public — anonymous users see, at the public address, articles marked as public; private spaces remain available by invitation only.
• Corporate — everything is available to signed-in members only; external users without sign-in see nothing, even articles marked public.

Without "Public" mode enabled, the public address is closed — this step is required.

Public mode works only on plans where it is included. If public access is not in your plan, the "Public" button is unavailable, with the hint "Public access is not included in your plan: anonymous visitors cannot see the portal." On a plan downgrade, the portal closes to anonymous visitors by itself, and on returning to a suitable plan it opens again — the selected mode is not reset.

#Step 4 — Public address and channels

There are three ways to open the ready public knowledge base:

• Public portal — the root of your address https://<your-slug>.lynkora.pro: search, AI answers and article reading without signing in. An individual article is at /kb/<article-slug>.
• JS widget — embedded on your website; the widget code is taken from Integrations → Channels (the "JS Widget" card).
• iframe — embedding the full search interface into a page.

There is no longer a separate "Public KB" tab in settings (ADR 0029): publicness is now set by the article flag + the organization mode, rather than a source whitelist. Widgets are managed in Integrations → Channels.

#Personal data check before publishing

When you switch an article to Public, LiKE automatically scans it for personal data (PII). If any is found, publishing is paused and a "Personal data detected" dialog appears — before the article becomes accessible to everyone without sign-in.

When it triggers: when an article becomes available anonymously — by switching it to public or via inherit inside a public folder. It does not run for internal or draft. It applies to every path, not just the "Publish" button: the access badge in the editor, "Make public" in the list and the tree, bulk visibility changes, publishing a folder (including together with its contents), moving an article or a folder into a public folder, copying, restoring from the trash, and turning an article back on.

What is detected (deterministic, pattern-based):

• Email
• Phone
• Payment card (Luhn checksum)
• IBAN (checksum-validated)
• IP address
• Date of birth

Special categories (health, biometrics, etc., GDPR Art. 9) are not detected automatically yet — the dialog only shows a caution about the heightened responsibility for publishing them.

A group of articles is asked about once. Bulk visibility changes, publishing a folder, moving and restoring show a single "Personal data in the articles being published" dialog: a summary by data type (how many occurrences and in how many articles), the list of articles with a search by title, "Tick all" / "Untick all", and a counter of ticked items.

• Ticked articles get published. Everything is ticked when the dialog opens — untick the ones you don't want published: they stay internal and do not follow the folder.
• The buttons are "Publish N" and "Cancel". On cancel nothing happens, and LiKE says so explicitly.
• An acknowledgment given in the group dialog is recorded in the log separately for each article.

Articles taken from the site connector do not require a per-article acknowledgment: when connecting, the owner confirms the rights to the site and the lawfulness of publishing personal data from it. Connect the site again with the "Internal" answer — the consent is withdrawn and the check works as usual again.

Background actions — connector sync, import, structure rebuild — cannot ask anyone, so they do not publish an article with unacknowledged personal data: it stays internal, and a record about it appears in the log. You can publish it manually by going through the usual check.

What the single-article dialog shows:

• The title "Personal data detected" and a list of the detected types with counts (aggregated across all articles being published).
• A mandatory acknowledgment checkbox: the tool helps detect PII but does not guarantee completeness; you, as the data controller, remain responsible for the lawfulness of publishing and for having a legal basis or consent.
• Cancel and Publish buttons (Publish is enabled only after the checkbox is ticked).

After confirmation: the article is published, and the acknowledgment is recorded in the activity log (pii_public_ack) with the detected data types — without storing the PII text itself (privacy-by-design). The acknowledgment is tied to the current version of the article: if you edit the text afterwards, you'll need to confirm again.

Who can acknowledge: the same roles that can publish — Editor and above in the article's space. The organization Owner — always; the organization Admin — in corporate spaces and in private ones where they are a member with the Editor or Admin role. Publishing all articles of a source in bulk is Owner/Admin only.

#Widgets for the Public KB (dual-auth, ADR 0032)

LiKE supports two authentication modes for widgets — chosen when you create a widget in Integrations → Channels → JS Widget:

#Mode 1 — Allowed paths (for public sites)

A widget embedded on the company's public site (a landing page, marketing pages, a help center). No authentication is required — the widget is available to any visitor.

Abuse protection:

• Site addresses — where the widget works. For example, yoursite.com, docs.yoursite.com (an address without a scheme gets https://). An asterisk is not accepted; requests from other addresses are rejected.
• Public umbrella scope — the widget has access only to the __public__ space + specific collections from that space, defined at creation.
• Rate limit on the api-key — protection against bots.

#Mode 2 — Session JWT (for a corporate site with authentication)

A widget embedded on the company's internal portal, where users already have authentication. The widget accepts a session JWT and sees exactly what that user sees.

Use cases:

• A widget on a corporate intranet → each employee sees their own spaces
• Embedding in a SaaS application (for example, in a CRM) — the user sees documentation for their role

#Multi-widget per tenant (ADR 0029 Stage 4)

Within an organization you can create several widgets with different scopes:

• One — public, for the marketing site (allowed paths)
• Another — corporate, for the intranet (session JWT)
• A third — for a specific collection (for example, only the FAQ for the support center)

Each widget has its own api-key, scope, and authentication mode. See Integrations and API and widget for details.

#What anonymous visitors see

Anonymous search by default uses a client-fingerprint cookie for basic rate limiting, but does not tie the request to a user account.

#Hiding individual collections

In a corporate space, not all collections necessarily have to be visible to anonymous users. You can hide specific collections:

1. The collection's context menu → "Make public" / "Make internal"
2. The collection's state:
   • inherit — follows the nearest parent folder that has an explicit state; if there is none — internal (default)
   • internal — hidden from anonymous users, visible to the team
   • public — explicitly public (only in a corporate space, otherwise blocked)

This gives flexibility: for example, in a corporate "Documentation" space you can keep drafts in an Internal Drafts collection with publish_state=internal — they are invisible to the outside but available to your editors.

#Embedding on a website

The Public KB can be integrated into a website in three ways:

Details on each — API and widget and Integrations.

#White-label and a custom domain

The public knowledge base is available at the default address slug.lynkora.pro. Advanced portal capabilities — white-label (without LiKE branding) and connecting a custom domain (Settings → Domain; in development) — are included in the plans where white-label is enabled. There is no separate paid add-on for this.

Which capabilities are available on which plans and at what price — see the Pricing page and your admin panel.