DOVOD IN PRACTICE / TECHNOLOGY EVALUATION

How to choose search for a support knowledge base.

Follow a team from “our search needs to improve” to a documented next step. See what you provide, what your AI assistant does and what stays in Dovod.

Open live project ↗Read-only · no account needed

Illustrative support brief, real documentation research. Eight linked materials, two simulated sessions and a roadmap were saved in Dovod; sources checked September 6, 2026. The engine trial remains open.

OPEN THE ACTUAL WORK

From the brief to a source you can check.

The project contains the brief, findings for three candidates, a reviewed cost claim, an interactive evidence matrix, a trial plan and a proposed decision record — plus two simulated sessions and a roadmap that shows what is done and what is not. These are actual Dovod screens with demonstration data.

Actual Dovod project showing its brief and four research sections
The project holds the work in one place. Select a screenshot to inspect it at full size.

THE SETUP

Your assistant investigates.
Your team decides.

You work in a connected AI client, such as Codex, ChatGPT or Claude. Dovod holds the project’s research materials, sources and findings so you can review the work and continue later.

For this example, bring a description of your knowledge base, a few unsuccessful searches and your technical constraints. The first outcome is a clear evaluation plan; a final technology choice needs evidence from your own trial.

Connect your AI client

A FINDING THAT CHANGES THE SHORTLIST

Keep PostgreSQL
in the comparison.

It would be easy to assume typo handling requires a new engine. PostgreSQL’s documentation describes using pg_trgm with full-text search for misspelled input. That gives us a baseline to test, rather than a reason to replace it immediately.

Meilisearch documents typo tolerance and indexing tasks. Typesense documents query-level typo controls. None of those pages tells us which engine ranks our articles best.

Check the PostgreSQL source ↗

Dovod finding with PostgreSQL sources, checked date, implications and remaining unknowns
A saved finding separates what the source says from what we infer.

STEP 01 / 05

Describe the problem before choosing a tool.

You bring the context

A support agent searches for “change billing email” but cannot find the article titled “Update invoice contact”. Our knowledge base has English and German articles. We already use PostgreSQL and want to avoid adding a service unless it improves the results.

Your assistant asks for missing details

Which languages do the articles use? What do failed searches look like? How quickly must edits appear? Who will maintain the service?

Saved in Dovod

A research brief: the question, requirements, constraints and unanswered questions.

STEP 02 / 05

Compare options against the same requirements.

You set the criteria

Use real support queries to judge relevance. Include content updates, access restrictions and the work needed to operate each option.

Your assistant gathers evidence

Build a shortlist: PostgreSQL full-text search as the baseline, plus Meilisearch and Typesense as candidates. For each, investigate language handling, relevance and content updates. Save the documentation behind findings; do not assume a candidate meets a requirement before checking it.

Saved in Dovod

Candidate notes and sourced findings organized around the same evaluation criteria.

STEP 03 / 05

Challenge a conclusion that is missing evidence.

You review a claim

“A separate search service will be cheaper to operate.” Does that estimate include synchronizing articles, monitoring, backups and maintenance?

Your assistant revises the finding

The hosting price alone does not establish total operating cost. Keep the cost comparison open and record the missing work instead of presenting a winner.

Saved in Dovod

The original claim, the reason it is incomplete and the questions that need investigation.

STEP 04 / 05

Test what documentation cannot tell you.

You provide a representative test

Try “change billing email” against “Update invoice contact”, “reset pasword” against “Reset your password”, and “Rechnung herunterladen” against the German invoice guide. In this sample trial, the expected article must appear among the first three results. Check an edited article too.

Your assistant helps organize the results

Use the same queries for each candidate. Bring the observations back into the project and separate measured results from impressions. Your team runs and approves the trial.

Saved in Dovod

Test observations, remaining gaps and the evidence needed to justify a choice.

STEP 05 / 05

Write down the decision and its limits.

You make the decision

Review the evidence and decide whether it is sufficient. In this illustrative scenario, the team chooses to run a trial before committing to a new engine.

Your assistant prepares the record

Summarize the context, alternatives, reasoning, consequences and next steps. Link the supporting findings so the team can revisit the reasoning later.

Saved in Dovod

A decision record that explains the current position and what would change it.

THE CLAIM AFTER REVIEW

“Cheaper” is still
an open question.

The saved review explains what the cost claim leaves out and what evidence would resolve it.

Actual Dovod review documenting why a hosting bill does not establish operating cost
The review links back to candidate findings, rather than losing the caveat in a chat.

THE CONVERSATION BEHIND THE CRITERIA

Two sessions,
with the open questions kept.

Simulated stakeholder conversations for the demonstration — not customer interviews.

Before any candidate was read, a clarification session fixed the gates: German is a hard requirement, access restrictions must hold, and nobody names a freshness number the team has not agreed. After the findings, a review session asked whether the documentation justified a choice. It did not — and that is recorded, answer by answer, with links to the material each answer rests on.

One question is deferred and one is still pending. A session that ends with everything answered would be a script; this one ends where the evidence does.

Dovod session with answered, deferred and pending questions linking to the saved findings
The review session in the public project. Answers link to the findings they rely on.

EVIDENCE YOU CAN FILTER

Documented, inferred,
or not tested.

An interactive HTML artifact saved in the project. Filter by evidence status; every cell links to its source.

The matrix puts the three candidates against the agreed criteria and refuses to score them. Each cell says one of three things: the vendor's documentation describes the mechanism, we inferred it, or nobody has tested it. Most of the relevance and cost rows are “not tested” — which is the honest state of the project, and the reason the decision record asks for a trial.

Interactive evidence matrix in Dovod with documented, inferred and not-tested cells for PostgreSQL, Meilisearch and Typesense
The evidence matrix, rendered from the saved HTML document. Sources are the same pages cited in the findings.

WHAT IS DONE AND WHAT IS NOT

A roadmap
from gates to a reopened decision.

Stages, dependencies and links back to the material.

Criteria, sources and review are done. The trial is not, and the decision record cannot be revisited until it runs. Each step on the roadmap points at the document, session or task it stands for, so the plan and the evidence are the same project — not a slide and a folder.

The same project also draws itself as a knowledge graph and a mind map: which findings the ADR cites, which questions a finding answered, which tasks are waiting on which document. Open the live project and choose Views.

Dovod roadmap in stages view: criteria, sources and review done; trial and revisit pending
The roadmap in stages view. Done on the left, the trial nobody has run on the right.
Knowledge graph of the demonstration project showing documents, sessions, questions and tasks connected by cross-references
The knowledge graph of the same project, as a visitor sees it through the public link.

THE RESULT YOU CAN REVIEW

A decision record,
with the open questions intact.

Sample record after the initial investigation, before the trial.

Search for the support knowledge baseSample
STATUS / TRIAL NEEDED
Question

Improve existing search or introduce a dedicated engine?

Current decision

Run a representative trial before choosing an engine.

Reason

We have not yet measured relevance on our content or established the full operating effort.

Evidence needed

Results for real support queries, update behavior and a maintenance estimate for each candidate.

Revisit when

The team has reviewed the trial results against the agreed requirements.

THE DOCUMENT IN DOVOD

Follow the reasoning
back to the evidence.

The ADR links to the brief, candidate findings, challenged claim and trial plan. Engine selection remains open.

See how to start your own project
Actual Dovod ADR with linked evidence and the condition for revisiting the decision
The decision record in Dovod, with its supporting findings.

SOURCES YOU CAN OPEN

Documentation,
with a checked date.

Reviewed September 6, 2026. Documentation establishes available mechanisms; quality and cost in this scenario remain unmeasured.

TRY IT WITH YOUR OWN QUESTION

Start with a brief.

Connect your assistant to Dovod, copy this prompt and adapt it to your team.

Choose an integration
STARTER PROMPT
Help me choose search for our support knowledge base. Create a research project in Dovod. First ask about our content, languages, common queries and operating constraints. Compare our existing database search with dedicated search engines. Save sources and findings, distinguish assumptions from verified facts, and prepare a decision record with the tests we still need to run.