Enterprise Wikipedia

Build a knowledge base for yourself and your team. Rename your space, import URLs as Wikipedia-style article entries, pull documents in from your OpenCharts Drive (or Google Drive and Dropbox), and let Theo reference everything across every Theo surface (chat, Telegram, presentations, podcasts, etc.).

What you get

  • Personal space — auto-provisioned for every user. Private to you. Rename it anything you like — it doesn't have to stay “My Wiki.”
  • Organization space — one shared knowledge base per organization. Anyone on the team can author articles and upload files. Owners and admins can rename it.
  • Wikipedia-style article entries — imported URLs (especially wikipedia.org pages) render as a hero image + lead summary + sectioned body + infobox sidebar + table of contents, not a flat list row.
  • Semantic search — Theo finds the right article even when your question doesn't use the same words.
  • Auto-injection into every prompt — when you ask “what does our brand voice guide say?” Theo silently pulls the relevant excerpt and cites the source.

Rename your wiki

The header of every wiki space is editable. Hover over the title on /wiki/[your space] and click the pencil icon to switch the name and description into inline inputs. Press Enter to save or Esc to cancel.

  • Personal spaces. Only you can rename them. The default name (“My Wiki”) is just a starting point — rename it to anything (e.g. “Ari's Research Vault”).
  • Organization spaces. Only members with role admin or owner can rename. The pencil button is hidden for editors and viewers.
  • The new name applies everywhere the space is referenced — dashboard tiles, search results, Theo's citations.

Folders & navigation

Once a space has more than a handful of articles, group them into folders. The Articles tab on /wiki/[your space] renders a collapsible folder tree instead of one long list. Articles that aren't in a folder live in a pinned Ungrouped group at the bottom, so nothing is ever hidden.

  • Create a folder. Use the New folder button above the tree, give it a name and a color, and it appears as a collapsible section.
  • Move articles. Each article row has a Move to folder menu (the ⋯ button) listing every folder plus Ungrouped. You can also start a new article already inside a folder from the folder's menu.
  • Reorder folders. Drag a folder by its grip handle to change the order; the new order is saved automatically.
  • Rename, recolor, or delete. The folder's menu covers all three. Deleting a folder never deletes its articles — they simply move back to the Ungrouped group.
  • Who can organize. Folder management follows the same rule as authoring: the owner of a personal space, or members with role editor or higher in an organization space. Viewers see the tree but no management controls.

Spaces with no folders (and read-only viewers) keep the classic flat article list — folders are purely additive.

Wikipedia-style article entries

When you paste a URL into the “Add content” panel, OpenCharts imports the page as a structured article — not a clickable external link. Every imported article is rendered through the same Wikipedia-style reader so the look and feel is consistent regardless of the source.

Wikipedia URLs

URLs that match *.wikipedia.org (any language) go through a dedicated importer that talks directly to the Wikipedia REST API. We capture:

  • The lead paragraph as the article summary.
  • The original hero image (Wikipedia's originalimage, falling back to thumbnail).
  • The infobox rows on the right-hand sidebar (founded / location / fields / etc.).
  • The section structure — each h2 / h3 in the source page becomes a navigable section with its own anchor in the table of contents.
  • Per-section images, rendered in a small grid beneath the section body.

Wikipedia content is licensed CC BY-SA 4.0 — the reader's source footer credits the original article and the specific revision ID, with a link back to the live page.

Generic websites

Non-Wikipedia URLs go through a generic web extractor that combines OpenGraph metadata + an article-readability cascade + a sanitized markdown-to-HTML pass:

  • og:image (or twitter:image) becomes the hero.
  • og:site_name, author, and article:published_time populate the infobox.
  • Headings (#, ##, ###) in the extracted markdown become sections.
  • Images inside <article> / <main> are deduped, capped at 24, and shown alongside their parent section.

Reader layout

The article reader at /wiki/[spaceId]/article/[articleId] has:

  • A full-width hero image at the top.
  • The lead summary in larger typography.
  • A table of contents on the right (md+ only) with scroll-spy — the current section is highlighted as you read.
  • A Wikipedia-style infobox sidebar (md+ only) when the source has one.
  • A source footer with the original URL and attribution.

URL imports, project imports, and (when enabled) uploaded documents all populate the Wikipedia-style fields so the reader stays consistent across every entry point.

Writing & editing articles

You don't have to import to add content — you can author articles directly. The New article button on a space header (and in the empty state) opens a full rich-text editor; the article overflow menu (the kebab top-right of any article you can edit) has an Edit article entry.

  • Rich-text body. Headings, lists, tables, quotes, code, links, and images — the same block editor used in Notes. Headings become navigable sections with their own table-of-contents anchors, exactly like an imported article.
  • Everything in one place. Edit the title, body, an optional lead summary (auto-derived from the body when you leave it blank), tags, hero image URL, and visibility from the same screen.
  • Who can write. In a personal space, the owner. In an organization space, members with role editor or higher. Viewers never see the New article / Edit affordances.
  • Edit imported articles too. Opening the editor on a Wikipedia / web / project import loads its content into the rich-text editor so you can correct, trim, or expand it. After you save, the article is yours — the source attribution footer stays, but the body is whatever you wrote.
  • Search stays in sync. Every save re-indexes the article, so edits show up in wiki search (and Theo's answers) on the next turn.

Project imports (presentations, notes, charts, code)

The Projects tab on the Add Content card lets you import any existing OpenCharts project as a structured article. Theo organises the content into encyclopaedic sections instead of a flat text dump:

  • Presentations — every slide becomes a candidate section. Theo groups thematically related slides under shared headings, pulls slide imagery (Creator AI image, content- mode background, image elements) into the right sections, and uses the first slide image as the hero. The infobox surfaces slide count, aspect ratio, mode, visual style, and theme.
    Creator-mode (AI imagery) decks get extra work. The deck's original prompt, every slide's image prompt, and any cumulative AI edits get mined into the article. For slides that are mostly image with little text, Theo also scans the rendered slide image: a fast vision pass extracts the on-image text (titles, names, captions baked into the image) and a 1–2 sentence description of what the slide depicts. Both get folded into the section so the resulting Wikipedia article reads like prose — not an empty page. Image scanning is fail-open (a transient vision blip never blocks the import), capped at 30 slides per import, and gated by the server flag WIKI_PRESENTATION_VISION_ENRICH (defaults ON; set to false to disable).
  • Notes — heading blocks break sections. Inline image blocks stay attached to the section they were in. Sections / word count / created date land in the infobox.
  • Charts & whiteboards — node labels and edges render as an “Overview / Nodes / Connections” article. No imagery; the infobox covers node count, edge count, and canvas mode.
  • Code projects — the README (if present) becomes the intro; the rest of the files render as one section each, with language / framework / file count in the infobox.

Failure mode: if the structurer can't produce a usable article (very short content, model timeout, etc.), the import falls back to a flat plain-text article so the project still appears in your wiki and shows up in semantic search.

Upload promotions (PDF, DOCX, PPTX)

Uploaded files always land as wiki_files rows for download + vector search. When the WIKI_FILE_TO_ARTICLE_ENABLED server flag is on, eligible document uploads also produce a paired Wikipedia-style article: after Theo extracts the document into markdown, it is split on headings, image references are extracted, and the structurer organises everything into sections. The original file row stays intact — the article is a complementary reading surface.

Executive summary (Theo brief)

Every URL-imported article gets a 3–5 bullet executive summary generated by Theo and pinned to the top of the reader. It's the article's gist in plain English — the same brief Theo sees when answering questions about your wiki, so you and Theo always start from the same baseline understanding.

  • What it isn't. Not a copy of the lead paragraph. The brief is a synthesis: each bullet is a concrete claim or fact, written present-tense and self-contained.
  • How it's generated. Theo reads the lead summary plus the structured body excerpts and produces the bullets in one shot (~1–2 seconds). The bullets are persisted on the article so the reader hydrates them instantly on every visit.
  • Regenerate any time. Editors see a Regenerate button on the brief card and a Regenerate summary entry in the article overflow menu (the kebab top-right). Useful after a manual edit to the body or when the source article has been updated.
  • Empty briefs. If Theo can't produce a confident brief (rare — usually a network blip), the card collapses and editors can retry from the menu. Non-editors see nothing rather than an empty scaffold.

Article actions (edit, re-import, delete)

Every article reader has an overflow menu (the kebab icon top-right of the page) visible to anyone with edit rights. Three actions live there:

  • Regenerate summary — refresh the Theo executive brief. Cheap (~1–2 seconds, no re-fetch from the source).
  • Re-import from source — pull the article fresh from its original URL. We refresh the imported content fields (summary, hero image, sections, infobox, images, source metadata, reading time) AND regenerate the executive brief. User-controlled fields (title, tags, pinned, visibility) are preserved — a re-import never silently walks back a manual rename. Manual / project articles don't have a source URL to re-fetch, so this entry stays disabled for them.
  • Delete article — soft-delete the article and clear its search chunks. The article disappears from the per-space list, the reader, and from Theo's search immediately. We retain the row for 30 days for recovery — contact support if you need to restore one. Authorized for any editor on the article OR for a personal-space owner / org admin on the parent space.

Re-import is the right tool whenever a Wikipedia article gets new sections, an OG image gets updated, or a blog post you've cited gets a substantive edit. Delete is a soft delete — the bytes stay around for 30 days.

Version history & restore

Every save, import, re-import, and restore takes a full snapshot of the article's content, attributed to whoever made it. Open Version history from the article's overflow menu (the kebab top-right of the reader) to browse the timeline.

  • See what changed. Pick any version to view a diff of its title, summary, tags, and body against the current article.
  • One-click restore. Editors get a confirm-gated Restore this version button that rolls the content back. The restore is itself recorded as a new version, so you can always undo it by restoring the version right before it.
  • Content only. A restore replaces the title, summary, body, sections, tags, and hero image — it never changes the article's visibility, folder, pin, or published state.
  • Who can restore. Anyone who can read the article can open Version history and view diffs; only members who can edit (a personal-space owner, or an editor or higher in an organization space) see the Restore action.

Review workflow & ownership

Keep your knowledge base trustworthy by tracking which articles have been reviewed and who owns them. Every article carries a review status chip near its title, visible to every reader; editors get a Review dropdown to change it.

  • Draft — the starting point. No review has happened yet.
  • In review — submitted for someone to check. Any editor can move their own article here.
  • Approved — reviewed and signed off. Approving an article stamps the review date and starts a 90-day freshness clock.
  • Needs review — an approved article whose 90-day window has lapsed. OpenCharts flips it automatically and notifies the owner.
  • Stale — a needs-review article left unattended for another 30 days. A clear signal the content may be out of date.

Ownership. Assign an accountable owner from the Review dropdown (“Assign to me” or clear it). When an article is flagged for review, the owner gets a notification with a link straight to it.

Who can change it. Submitting for review needs edit rights on the article. Approving, flagging, marking stale, or reassigning an owner is open to anyone who can edit the article or manage the space (a personal-space owner, or an admin / owner in an organization space).

Reviewing is separate from publishing. A review status never changes whether an article is live on your public wiki. You can keep an internal draft Approved, or publish an article that's still In review — the two are independent.

Comments & @mentions

Discuss any article without leaving the reader. Click Comments in the chip row near the title to open the thread panel. Uploaded files get the same treatment: open a file from the Files tab and click Comments in the viewer's footer — the whole wiki is commentable, not just articles.

  • Comment & reply. Leave a top-level comment or reply to an existing one. Replies stay one level deep so threads remain easy to scan.
  • @mention a teammate (organization spaces) — type @ and pick from your space's members. The person you mention gets a notification linking straight to the article (or, for a file comment, to the space's Files tab). Personal spaces don't show the mention picker since there's no one else to tag.
  • Resolve & reopen. Mark a thread resolved once it's handled (and reopen it later if needed). Resolved threads stay visible with a badge so the history isn't lost.
  • Delete. Remove a comment you no longer need.

Who can do what. Commenting follows your effective permission level: anyone at Commenter or above can comment on an article or file they can see, while a member limited to Viewer can read but not post. Resolving, reopening, or deleting a comment is open to the comment's author OR anyone who manages the space — a personal-space owner, an admin / owner in an organization space, or a member whose permission level is set to Manager. Replies notify the parent comment's author and the article's (or file's) author, so the right people stay in the loop.

Activity log

Every space keeps an append-only activity log of who changed what, when. Open the Activity tab on the space view to see a newest-first timeline.

  • What's tracked. Article creates, edits, visibility changes, deletes, re-imports, restores, and publish toggles; review-status and owner changes; comments created, resolved, and deleted; file uploads; and custom-domain attach / detach.
  • Who can see it. The Activity tab is for space managers only (a personal-space owner, or an admin / owner in an organization space) — it's a governance surface, not a member-visible feed.
  • Load more. The log pages in batches; use Load more to walk further back in time.

Logging never blocks your work: an activity entry is written after each change lands, and a logging hiccup can never fail the underlying edit, comment, or upload.

Space insights

Space managers get an Insights tab with a read-only snapshot of how the space is doing.

  • At a glance. Total articles, total views, and how many articles currently need review or have gone stale.
  • Most & least read. The top and bottom articles by view count, so you can see what's landing and what might need a refresh or better discovery.
  • Recently updated. The latest edits across the space, newest first.
  • Search activity. Once people start searching inside the space, you'll see your top searches and your unanswered searches — queries that came back with zero results. Unanswered searches are the clearest signal of a content gap: they tell you exactly what your team went looking for and couldn't find, so you know what to write next.
  • Ask Theo activity. If your wiki is published with the public assistant enabled, you'll also see the top questions visitors asked Ask Theo and the unanswered questions Theo couldn't ground in a published article, plus the overall percentage of questions that went unanswered. Like unanswered searches, these are a direct to-do list for what to publish next.
  • Who can see it. Managers only (a personal-space owner, or an admin / owner in an organization space) — it's a governance surface, like the Activity tab.

View counts are tallied as people open articles (in the dashboard and on your published site) and are intentionally approximate — they're batched for performance, so a brand-new read may take a few seconds to show up.

Search activity is recorded only for searches run inside a space, and the top / unanswered lists reflect recent activity rather than all-time. The panels stay hidden until the space has logged at least one search.

Ask Theo activity covers questions asked by anonymous visitors on your published wiki (it stays hidden until the assistant has been asked at least one question). It's aggregate-only — there's no per-visitor inbox, and the public Ask Theo transcripts themselves are never stored beyond their short-lived session.

Long articles get a sticky table of contents on the right (md+ screens). It scrolls with you as you read — the section you're currently on is highlighted automatically, and clicking any entry jumps you to it (smooth-scroll, back-button preserves the section anchor). Wikipedia entries with 30+ sections add an internal scrollbar inside the TOC so it stays usable even when the article is much taller than the viewport.

Viewing files in-app

Uploaded files (PDF, Word, PowerPoint, Excel, images, and plain text) open right inside OpenCharts from the Files tab — no download round-trip just to glance at a document. Click any uploaded file to open the viewer.

  • PDFs & images render inline in the viewer.
  • Text, Markdown & CSV show their contents as formatted text.
  • Word / PowerPoint / Excel can't render natively in a browser, so the viewer shows the text Theo extracted during indexing as a quick preview — use Download for the original file with its formatting intact.
  • Anything else is download-only.

File contents are always access-checked: the viewer streams bytes through the same permission rules as the rest of your wiki, so a teammate only ever sees a file they’re allowed to read. Files imported from a URL keep opening their original source in a new tab.

Visibility levels

Every article and file has one of four visibility settings:

  • Private — only the author can see it. The default for new content.
  • Space — everyone in the wiki space can see it. In a personal space, this is still just you. In an org space, every team member.
  • Role-gated (org only) — only members with role editor or higher can see it. Use for HR docs, financials, leadership briefs.
  • Shared — visible to an explicit allow-list of members. In an organization space, pick Shared in the article editor's Visibility menu and choose exactly who can see it from the member picker. The allow-list can only be cleared after the article is switched to another visibility, so a shared article never loses its audience by accident.

Work with your team

Wikis are built for teams: every organization gets its own shared spaces, and you can promote a personal wiki into one. Team wiki features may need to be enabled on your deployment.

The Wiki tab in Teams

Open your organization in the Teams workspace and pick the Wiki tab. It lists every wiki that belongs to the organization, shows your effective role on each, and lets members with the manage wiki sources permission (admins and owners) create a new team wiki. Org members can use the org's wikis even if they don't have a personal wiki plan of their own.

Share a personal wiki with your organization

Any personal space you own (except your auto-provisioned default space) can be shared with an organization you belong to. Use the Share action on a space card in the wiki hub, or the Share with org button on the space header. Sharing moves the space into the organization, and org roles map onto wiki capabilities:

  • Viewers can read and comment on every article.
  • Editors can author and edit articles and upload files.
  • Admins and owners can additionally rename the space, manage folders and sources, publish it, and see the Activity and Insights tabs.

The mapping applies to every article and file in the space, and the move is one-way — the confirmation dialog spells this out before anything changes. You must own the space and hold the manage wiki sources permission in the target organization. These role mappings are the defaults — owners and admins can fine-tune what each member can do in a specific wiki from the Members tab.

Real-time co-editing

Articles in an organization space open as live collaborative documents: teammates with edit access see each other's cursors and selections, changes merge in real time, and the article body autosaves a moment after you stop typing — the editor header shows a live status chip (Live → Saving… → Saved). Use the Save button to capture everything else (title, summary, tags, hero image, visibility) in one pass. Personal spaces keep the classic explicit-save flow.

Per-member permission levels

Organization spaces get a Members tab (visible to managers) where you grant each teammate exactly the level of access you want them to have in this wiki — independent of their organization role.

  • No access — locked out of this space entirely.
  • Viewer — read-only: can open articles and files but can't comment.
  • Commenter — read plus comments, replies, and @mentions.
  • Editor — everything above, plus authoring and editing articles and uploading files.
  • Manager — full control of the space: rename it, manage folders, sources, members, and publishing, moderate any comment, and see the Activity and Insights tabs.

With no override set, a member's level comes from their organization role: org viewers default to Commenter, org editors to Editor, and admins / owners to Manager. An override can raise a member (give a trusted viewer editing rights in one wiki) or lower one (drop a contractor to read-only) per space, without touching their org role. Admins and owners always keep Manager access and can't be limited here — change their organization role in the Teams workspace instead. Use Reset on a member to clear their override and fall back to the role default.

Connecting sources (Sources tab)

Owners and admins get a Sources tab on the space view for pulling documents in from somewhere else — your own OpenCharts Drive first, then Google Drive and Dropbox. Once a folder is connected, a background job checks it every few minutes and indexes any new supported documents into the wiki automatically — no manual upload.

Folder sync accepts PDF, Word (.docx), PowerPoint (.pptx), plain text, Markdown, and CSV (Google Docs, Slides, and Sheets are exported to PDF/CSV automatically). Other file types are skipped. Picking files by hand accepts a wider list — the legacy Office formats (.doc, .ppt, .xls, .xlsx) and images (PNG, JPEG, WEBP) as well — because you chose those files one at a time instead of asking a background job to parse whatever it finds.

Each connected folder shows its status (idle, syncing, or error), the last sync time, and how many supported files the folder contains — that count is what's sitting in the folder, not what has been brought into the wiki.

Use Sync now to pull new files immediately instead of waiting for the next check. It runs while you wait and tells you exactly how many files it brought in. If the folder has nothing new in it, that's a success — not an error. Use Disconnect to stop syncing — disconnecting keeps the files already brought into the wiki.

Today the sync brings in new files; updating a file already in the wiki, or removing one after it's deleted from the source folder, is a planned enhancement. Folder sync is off by default and enabled per deployment.

Bringing in files from your Drive

Your OpenCharts Drive is the first source in the list, and the only one with nothing to connect — no sign-in, no third party, no permission prompt. Click Browse your Drive in the Sources tab and a picker opens on your own folder tree. Drill into a folder, then choose one of two things to do with it:

  • Add files now. Tick individual files and click Add to wiki — up to 20 at a time. Each one is copied in and indexed straight away. This is a one-off: those files don't keep syncing afterwards.
  • Connect the folder. Click Connect this folder and it joins the source list alongside Google Drive and Dropbox, with the same background sync picking up new files within a few minutes of you adding them. Tick include subfolders to bring in the whole subtree. You can't connect the root of your Drive — pick a folder, so a sync always has a defined scope.

Either way the wiki takes its own copy of the file. Editing or deleting it in Drive afterwards doesn't change or remove the wiki copy, and the wiki copy is what Theo searches. Each wiki entry links back to the original in Drive, so you can always see where it came from.

Adding the same file twice is safe: the picker reports it as already in this wiki instead of creating a duplicate. Files in your Drive trash are skipped, and anything the wiki can't parse is shown greyed out with the reason (unsupported type, or over 200 MB) rather than silently failing after you pick it.

Drive-as-a-source needs OpenCharts Drive enabled on your deployment; connecting a Drive folder for automatic sync additionally needs folder sync enabled. With folder sync off you can still add files by hand.

Connecting Google Drive

In the Sources tab, choose Google Drive and pick a folder with the Google Picker. The Picker asks Google for per-folder permission, so OpenCharts only ever sees the folders you explicitly select — we never request drive.readonly or browse your whole Drive. You'll need Google Drive connected in Settings → Integrations first. (If your deployment hasn't configured the Picker API key, you can paste a Drive folder ID manually instead.)

Connecting Dropbox

Dropbox connects through Pipedream Connect (OpenCharts' managed connector layer). In the Sources tab, choose Dropbox, click Connect Dropbox, and sign in. Then enter the folder path to sync (for example /Marketing, or leave it blank to sync your whole Dropbox). Dropbox access tokens live on Pipedream's servers — never in OpenCharts' database.

How Theo uses your wiki

Every Theo surface — chat, Telegram, Theo Desk, presentations, podcasts — can search your wiki on demand. Theo decides when to search; you don't have to ask.

Try asking:

  • “What does our brand voice guide say about tone?”
  • “Summarize the Q1 plan.”
  • “What's our policy on remote work?”
  • “Build a presentation about our Q2 launch using the brand guidelines from the wiki.”

Theo cites the source artifact (e.g. “From the Brand Voice Guide: …”) so you can verify every claim.

Smarter search: hybrid retrieval & section deep-links

Wiki search blends two signals so the right passage surfaces whether you remember the exact wording or only the gist:

  • Hybrid retrieval. Theo fuses semantic (meaning-based) matches with full-text keyword matches on article titles and bodies, so exact terms — product codes, acronyms, policy titles — stay reliable while conceptual questions still work.
  • Smarter ranking. Results are re-ranked with light signals: a literal term match climbs, and pinned, recently-updated, and review-approved articles get a gentle boost (while stale ones are nudged down).
  • Section deep-links. When a match lands inside a specific section of a long article, the citation links straight to that section's anchor — you jump to the exact passage instead of the top of the page. The Ask Theo assistant on a published wiki does the same with its citation chips.

Smarter search is on by default and degrades gracefully to semantic-only search if the keyword pass is ever unavailable, so results never disappear.

Living knowledge base: map, deep reads & saving from chat

Beyond on-demand search, the wiki can act as Theo's durable memory of your whole organization. These capabilities roll out per deployment:

  • Bulk upload. The upload zone accepts a whole folder's worth at once — drop up to 20 files per batch and they queue automatically with per-file status (queued → uploading → indexed), so seeding your knowledge base takes minutes, not an afternoon.
  • Knowledge Base Map. Theo carries an always-on map of every wiki space you can access — what each team's space contains, how big it is, and a short AI digest of its key topics. That's how Theo understands the difference between, say, the Ops wiki and the Marketing wiki, and searches the right one. Digests refresh automatically in the background as content is indexed.
  • Deep reads. When a search snippet isn't enough, Theo can open the full article or file (access-checked, like everything else) and answer from the complete document — “what does the onboarding SOP actually say?” gets the real SOP, not a 2-line excerpt.
  • Saving knowledge from chat. When a conversation produces something worth keeping (“add this to our wiki”, “save that as an SOP”), Theo can write it into the wiki as a structured draft article — tagged theo, attributed, audited, and routed through the same review workflow as human-authored content. Theo only saves when you explicitly ask; nothing lands silently.
  • Durable memory bridge. When you confirm a durable company fact in conversation, Theo can also store it as a personal memory that cites the wiki artifact it came from — so the knowledge base and Theo Memory reinforce each other instead of drifting apart.

Access control

Every wiki search runs through the same access check used by the article/file pages. Theo can never reference content you can't read — if a file is role-gated to admins, viewers will never see it surface in chat answers.

Publishing your wiki to the web

Every wiki space can be published as a Wikipedia-style public site at opencharts.com/w/[slug] (or your own custom domain). Owners and admins click Publish on the space header to open the publish modal.

  • Draft vs. active. Publishing a space creates a wiki_publications row with status: "active". Unpublishing flips it back to draft — the public URL immediately returns 404 (with cache invalidation handled by thepublishVersion bump).
  • Per-article toggle. A space being published does not automatically expose every article. Each article carries its own publishedAt timestamp, set from the article reader's overflow menu's Publish / Unpublish entry. Drafts stay private even on a fully-published wiki.
  • Frozen snapshots. Brand colors, fonts, logo, name, tagline, and assistant persona are snapshotted at publish time. Edits inside the dashboard never silently change the public-facing site until you re-publish. This is the canonical guard against half-broken live deploys.
  • SEO settings. Override the page title, meta description, OG image, and the “allow search engine indexing” flag in the publish modal's SEO tab.
  • Password protection. Optional — set a password on the General tab and visitors get a small unlock screen before the wiki is revealed. Stored as a bcrypt hash; the raw password never leaves the publish service.

Custom branding (Brand Studio)

Open the Brand tab on any space you can manage — it sits next to Articles and Files in the tab strip beneath the space hero. The Brand Studio takes over the full content area (no modal, no cramped scroll surface) and lets you customise everything visible on the public reader:

  • Extract from a website. Paste any brand URL (e.g. acme.com) and the studio pulls the palette, fonts, description, and a gallery of logos in one round-trip. Click any extracted logo to import it into the wiki's asset bucket — we proxy the download server-side so cross-origin restrictions never get in the way. The pulled brand fills every input below; you can fine-tune any field afterwards.
  • Logo upload. Drop a PNG, JPEG, WEBP, or SVG (up to 2 MB) and the studio renders a preview immediately. The file lives in the wiki-assets bucket; the public reader renders it via a CDN URL so no extra round-trip is needed at view time. If you don't have a logo, set a 1–3 character monogram and pick themonogram heading style instead.
  • Header banner. Upload a wide image (PNG / JPEG / WEBP / SVG, up to 5 MB) that sits above the public header. Pick a height (compact / medium / tall), an overlay tint (none / dark / light / brand-gradient), and the banner becomes the hero band on the published site.
  • Heading style. Toggle between three header treatments: Logo image (uses the uploaded logo with a monogram fallback), Monogram (always the 1–3 char square), or Wordmark (renders the brand name in your heading font without imagery).
  • Six-slot palette. The studio exposes dedicated swatches and hex inputs for primary, accent, background, surface, text, and muted-text colors. Hex inputs are tolerant of casing on entry but always persist lowercase — the public reader reads them via the--wiki-brand-primary, --wiki-brand-accent, --wiki-brand-surface, --wiki-brand-background, --wiki-brand-text, and --wiki-brand-muted-text CSS variables.
  • Typography. Pick heading + body fonts from a curated Google Fonts list. Brands extracted from a URL also surface their own typography in the picker, so your team's fonts land one click after the URL extract.
  • Theme toggle. Light, dark, or auto (follows visitor preferences). Maps to the existing dark / light palette swap on the reader chrome.

Live preview. A miniature reader header sits beside the controls (sticky on desktop, pinned to the top on mobile) and reflects every banner, logo, palette, and typography edit in real time before you save. The studio is deep-linkable too — sharing /wiki/<id>?tab=brand jumps a teammate straight into the right surface.

Snapshot at publish time. When you click Publish, the brand is frozen onto the publication'sbrandSnapshot. Subsequent edits in the Brand Studio do NOT roll forward onto a live published site — the public reader keeps showing the snapshot until you re-publish. This is the canonical guard against “I changed a colour and the live site went weird” support tickets.

Powered by OpenCharts badge. Free and Starter plans always render the small “Powered by OpenCharts” pill in the bottom-right of the public site. Pro and Teams plans can hide it via the Branding tab of the publish modal — the toggle is plan-gated server-side so a request body that flips the flag on a Starter wiki is silently coerced back to true.

The public reader at /w/[slug] renders a Wikipedia-style home: hero band, a curated featured-articles grid, category cards, a recently-updated rail, and (on long articles) a sticky table of contents. Curation lives in the publish modal's Featured tab:

  • Featured articles — pin up to 6 articles by ID; ordering is honored on the public home.
  • Featured categories — up to 6 manually curated category cards, each carrying a label, a tag filter, and an optional pinned article list.
  • Defense-in-depth. Even if a featured-list entry accidentally points at an article whose publishedAt is null, the public reader silently drops it. No draft can be exposed via curation.

Theo public assistant (Ask Theo)

Every published wiki ships with an Ask Theosidebar on the public site. Visitors can ask plain-language questions and get cited answers grounded in the wiki's published articles only.

  • Anonymous transcripts. No login required. The conversation lives in Redis under a client-generated session ID with a 24-hour TTL — we never write anonymous chats to Appwrite, and there is no “dashboard inbox” of visitor questions.
  • Scoped retrieval. The assistant runs a vector query against the dedicated wiki Upstash Vector index filtered to the exact wikiSpaceId, with a defense-in-depth re-check that every hydrated chunk's article has publishedAt != null. Cross-wiki leakage is impossible.
  • Refuse mode. When no chunk scores above 0.55, the assistant replies with a templated “I couldn't find this in {wiki name} — try search” instead of hallucinating. The same block fires when the retrieval call itself fails.
  • Citation chips. The first SSE event emitted by the assistant route carries a citations[]payload so the UI can render article chips BEFORE the model's first token. Each chip links straight to the cited article.
  • Persona override. Owners can set an assistantPersona on the space (e.g. “Speak like our customer support team.”). It's injected on top of the grounding rules — never instead of them.
  • Daily caps. Each published wiki has a plan-based daily query cap enforced in Redis (key wiki_assistant_cap:{slug}:{YYYYMMDD}). Free: 100, Starter: 500, Pro: 2,000, Teams: 5,000. When the cap is hit the route returns 429 and the UI surfaces a friendly “try again tomorrow” message.
  • Disable per wiki. Flip assistantEnabled off on the space (or the publication snapshot) to hide the launcher entirely.

Default URL

Every published wiki is reachable out of the box at https://www.opencharts.com/w/{slug} — the path-based reader on the main OpenCharts app. There is intentionally no dedicated wikis.opencharts.com subdomain: shipping a separate host would mean coordinating Cloudflare DNS, Vercel domain attachment, and a pass-through branch in the Ship Worker. The path-based default keeps publish-to-web working with zero ops overhead.

The URL is generated by getWikiPublishDomain() in src/types/wiki-publish.ts. You can override the reader prefix with NEXT_PUBLIC_WIKI_PUBLISH_DOMAIN (full URL, e.g. https://staging.opencharts.com/w) for staging / preview deployments. In local dev with the override unset, the modal falls back to ${NEXT_PUBLIC_APP_URL}/w/{slug} so npm run dev keeps working out of the box.

Custom domains

Pro and Teams plans can attach a custom domain (e.g. wiki.acme.com) to a published wiki via the publish modal's Domain tab. We use Cloudflare Custom Hostnames for SSL + cert issuance and a Workers KV mapping (wiki-domain:{host} → slug) for the edge middleware to resolve incoming requests.

The Domain tab gives you two ways to configure DNS once you click Attach:

  • One-click (Entri) — available when NEXT_PUBLIC_ENTRI_APP_ID is configured. Entri detects your registrar and pushes BOTH the CNAME and the Cloudflare verification TXT in the same pass. No copy-paste required.
  • Manual DNS — the modal shows the exact type, name, and value for the CNAME (target: www.opencharts.com) and the verification TXT Cloudflare returned. Add them at your registrar, then click Check status.
  1. Enter the domain (e.g. wiki.acme.com) on the Domain tab and click Connect (Entri) or Attach (manual). We register it with Cloudflare and surface the DNS records you need to add on your registrar.
  2. Add the records. CNAME {your-subdomain} → www.opencharts.com, plus the verification TXT Cloudflare returned (the modal shows the exact host + value). Cloudflare Custom Hostnames terminates SSL at the edge, forwards to Vercel with your tenant's host header preserved, and the middleware rewrites to /w/{slug}.
  3. Click Check status. We re-poll Cloudflare; once sslStatus is active, the wiki is reachable on your domain and the default OpenCharts URL keeps working as a canonical fallback.
  4. Detach any time to release the domain — we delete the Cloudflare hostname, clear the KV entry, and re-issue the publication's publishVersion so the CDN forgets the old mapping.

The deploy-time override is NEXT_PUBLIC_WIKI_CNAME_TARGET (bare host or full URL). Use it on staging when you want tenant CNAMEs to point at a non-prod fallback origin. Defaults to the hostname of NEXT_PUBLIC_APP_URL.

Behind the scenes the edge middleware in src/proxy.tslooks up the incoming host in KV. If it resolves to a slug, the request is rewritten internally to /w/{slug}/… before the page handler runs — visitors never see the internal URL, and every per-publication setting (brand, password gate, assistant) keeps working unchanged.

Fail-soft semantics. Cloudflare or KV outages never block publish — the domain row is written with sslStatus: "pending" and you can hit Check status again later. The wiki keeps serving on the default OpenCharts URL in the meantime.

Pricing & plan limits

The wiki dashboard is free for everyone. Publishing to the web is a paid-plan capability:

  • Free — private wiki only. Cannot publish, no custom domain, no branding removal. Each published wiki (if upgraded) gets 100 assistant queries / day.
  • Starter — publish to www.opencharts.com/w/[slug]. No custom domain. Powered by OpenCharts badge stays on. 500 assistant queries / day.
  • Pro — everything in Starter plus custom domain + branding removal. 2,000 assistant queries / day.
  • Teams — everything in Pro with 5,000 assistant queries / day per wiki, shared across all members of the org.

Plan checks are enforced inside the publish services and the assistant route, NOT in the UI — a tampered request body can't hide the badge or attach a custom domain on a free wiki. The matrix lives in PLAN_LIMITS (src/types/subscription.ts) with fields wikiPublishing, wikiCustomDomain, wikiRemoveBranding, and wikiAssistantDailyCap.

Setup (admins)

To enable Enterprise Wikipedia for your organization:

  1. Provision Appwrite collections: ./scripts/setup-wiki-collections.sh
  2. Add the Wikipedia-style article columns to wiki_articles for existing deployments: ./scripts/add-wiki-article-wikipedia-fields.sh (idempotent — safe to re-run).
  3. Add the executiveSummary column for the Theo brief: ./scripts/add-wiki-article-executive-summary.sh (idempotent).
  4. Provision a dedicated Upstash Vector index for the wiki (separate from the memory index) and set UPSTASH_VECTOR_WIKI_REST_URL and UPSTASH_VECTOR_WIKI_REST_TOKEN in your environment.
    The index MUST be created with a built-in embedding model. In the Upstash console: Create Index → Configure embedding model → pick a model such as mxbai-embed-large-v1 or bge-large-en-v1.5. Without an embedding model, every wiki ingestion call fails with “Embedding data for this index is not allowed” and semantic search returns no results. If you see that error in the server log, the existing index was provisioned without a model — recreate it and re-point the env vars at the new index id. The matching memory index (UPSTASH_VECTOR_REST_URL) has the same requirement.
  5. For Google Drive folder import: set NEXT_PUBLIC_GOOGLE_DRIVE_API_KEY (a browser API key for the Picker; not the OAuth client secret).
  6. For Dropbox folder import: configure the Dropbox app in Pipedream Connect and set the PIPEDREAM_* keys (see .env.example).
  7. Flip the feature flag: NEXT_PUBLIC_ENTERPRISE_WIKI=true.

Privacy & security

  • Vector embeddings are stored in a dedicated Upstash Vector index, isolated from the user-memory index.
  • Every chunk carries the article/file's visibility metadata — access checks are enforced both at query time AND post-query, so even a leaked vector ID can't bypass your permission rules.
  • Google Drive folder access is per-folder via the Picker — we never request drive.readonly or browse your whole Drive.
  • Dropbox access tokens live on Pipedream's servers, never in OpenCharts' database.
  • URL-imported article HTML is sanitized server-side against a strict allowlist (p, ul, ol, li, a, em, strong, blockquote, h3, h4, figure, figcaption, img, table) before it ever reaches the reader.

Ready to set it up? Head to /wiki.