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. Only 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 / Personal. 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 all articles with publish_state='public' from the organization's corporate spaces
• 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 and personal 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). When creating a space, the available types are Corporate and Private; "Personal" is a system space.

#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 "Publish" button in the header

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.

#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: only on publishing (switching to public, anonymous access). It does not run for internal, draft, or inherit. It applies to every publishing path: the "Publish" button in the editor, "Make public" in the list/tree, bulk visibility changes, and publishing a collection/space.

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.

What the 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 (Owner and Admin always). 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 → Widgets:

#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:

• A list of allowed URLs (allowed paths) — where this api-key is valid. For example, https://yoursite.com/* and https://docs.yoursite.com/*. Requests from other domains are rejected (CORS + check).
• 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 → Widgets 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 → Properties
2. The collection's publish_state field:
   • inherit — inherits from the space (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) — 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.