{
  "version": 2,
  "exported_at": "2026-09-06T07:53:07.997430392Z",
  "research": {
    "name": "Dovod demo — choosing search for a support knowledge base",
    "description": "Public-content demonstration: a fictional support brief investigated using real primary documentation. No benchmark results or customer testimony are claimed.",
    "goal": "Decide what to test before replacing PostgreSQL search with Meilisearch or Typesense, and demonstrate a reviewable Dovod research workflow for the website.",
    "status": "active",
    "tags": [
      "dovod",
      "website-demo",
      "technology-evaluation"
    ],
    "created_at": "2026-09-06T07:42:41Z",
    "updated_at": "2026-09-06T07:42:41Z",
    "sections": [
      {
        "name": "brief",
        "display_name": "Brief \u0026 criteria",
        "description": "Explicit illustrative conditions and evaluation gates.",
        "status": "draft",
        "position": 0,
        "created_at": "2026-09-06T07:42:41Z",
        "updated_at": "2026-09-06T07:42:41Z",
        "entries": [
          {
            "title": "The trial must justify adding another service",
            "entry_type": "markdown",
            "content": "# The trial must justify adding another service\n\n**Illustrative brief, not customer testimony.** A support agent searches for “change billing email” and misses “Update invoice contact”. The sample knowledge base contains English and German articles and already stores content in PostgreSQL.\n\n## Decision and owner\nThe illustrative technical lead must decide whether to keep database search or trial Meilisearch and Typesense before introducing another service. The real deliverable is a reviewable website demonstration; no production engine migration is authorized or proposed.\n\n## Criteria fixed before comparison\nHard gates: preserve document access restrictions, support the sample English/German corpus, and demonstrate that edited content can become searchable. Missing evidence means an open gate, not a pass.\n\nPriority order: expected-article relevance first; freshness and recovery next; implementation and operating effort after those gates. No weighted score is assigned without observations. Keep PostgreSQL as the status quo; prefer it if the agreed tests pass and no documented gap justifies another service.\n\n## Unknowns\nActual corpus, traffic, latency budget, operating hours and budget ceiling are unavailable. The sample queries are test fixtures, not production logs. The comparison must not claim a cheapest or fastest engine.",
            "description": "Illustrative support-search brief: requirements, baseline and evidence needed before adding a service.",
            "status": "active",
            "tags": [
              "website-demo"
            ],
            "created_at": "2026-09-06T07:44:47Z",
            "updated_at": "2026-09-06T07:49:35Z"
          }
        ]
      },
      {
        "name": "sources",
        "display_name": "Sources \u0026 candidate findings",
        "description": "Primary documentation with checked dates and limitations.",
        "status": "draft",
        "position": 1,
        "created_at": "2026-09-06T07:42:41Z",
        "updated_at": "2026-09-06T07:42:41Z",
        "entries": [
          {
            "title": "PostgreSQL remains a viable baseline to test",
            "entry_type": "markdown",
            "content": "# PostgreSQL remains a viable baseline to test\n\n**Reported by primary project documentation; checked 2026-09-06.** PostgreSQL 18 documents full-text matching, ranking and language configurations. Its `pg_trgm` extension provides similarity matching, and the documentation describes using it alongside full-text search for misspelled words.\n\nSources: [Full-text introduction](https://www.postgresql.org/docs/18/textsearch-intro.html) and [pg_trgm, Text Search Integration](https://www.postgresql.org/docs/18/pgtrgm.html#PGTRGM-TEXT-SEARCH).\n\n## Implication for this brief\nDo not eliminate the existing database merely because typo handling is required. Include a documented PostgreSQL configuration in the trial. This is an inference from available mechanisms, not a measured quality result.\n\n## What the sources do not establish\nThey do not show that the expected article ranks in the top three for our sample queries, that our German content is handled well, or that the baseline is cheaper to maintain. The sample spelling-suggestion approach also needs its word list maintained.\n\n## What could change the decision\nReject the baseline if a fair configuration fails the agreed relevance or access tests and a candidate passes them with acceptable operating effort. See the criteria in [[E1]].",
            "description": "Primary PostgreSQL documentation supports testing a baseline with full-text search and pg_trgm; application relevance remains unmeasured.",
            "status": "active",
            "tags": [
              "website-demo"
            ],
            "created_at": "2026-09-06T07:44:53Z",
            "updated_at": "2026-09-06T07:49:38Z"
          },
          {
            "title": "Meilisearch documents typo tolerance, but relevance remains untested",
            "entry_type": "markdown",
            "content": "# Meilisearch documents typo tolerance, but relevance remains untested\n\n**Reported by vendor documentation; checked 2026-09-06.** Meilisearch documents configurable typo tolerance enabled by default. Its asynchronous-operation guide describes task states including enqueued, processing, succeeded and failed.\n\nSources: [Typo tolerance](https://www.meilisearch.com/docs/capabilities/full_text_search/relevancy/typo_tolerance_settings) and [Asynchronous operations](https://www.meilisearch.com/docs/capabilities/indexing/tasks_and_batches/async_operations).\n\n## Implication for the trial\nRecord the tested version and typo settings. For an article update, track the indexing task to completion and then check the search result; submission alone is not our freshness test.\n\n## Remaining evidence\nWe have not run this candidate on the sample corpus. Ranking quality, language behavior, authorization integration, update delay and recovery effort remain open. The documented mechanisms are not proof of performance or lower maintenance cost.\n\n## Regret to avoid\nChoosing an engine because a misspelled query works in a tiny example, while overlooking irrelevant results or stale restricted content. Evaluate it against the same gates as [[E1]] and the baseline in [[E2]].",
            "description": "Vendor documentation describes typo settings and indexing tasks. Our corpus, freshness and operating effort still need a trial.",
            "status": "active",
            "tags": [
              "website-demo"
            ],
            "created_at": "2026-09-06T07:44:57Z",
            "updated_at": "2026-09-06T07:49:43Z"
          },
          {
            "title": "Typesense exposes typo controls that need an explicit test configuration",
            "entry_type": "markdown",
            "content": "# Typesense exposes typo controls that need an explicit test configuration\n\n**Reported by vendor API documentation, version 29.0; checked 2026-09-06.** Typesense documents `num_typos` per query or field, minimum word lengths for typo correction, and token-dropping behavior.\n\nSource: [Search API — typo-tolerance parameters](https://typesense.org/docs/29.0/api/search.html#typo-tolerance-parameters).\n\n## Implication for the trial\nRecord the exact server version, schema, queried fields and search parameters. Inspect the returned articles as well as the result count: relaxed matching is not itself evidence that the answer is useful.\n\n## Remaining evidence\nNo Typesense benchmark has been run here. English/German relevance, freshness, access-control integration and operating effort have not been measured. This source describes API behavior for its named version, not a recommendation to deploy that version or a claim that it is the latest.\n\n## Regret to avoid\nComparing a tuned candidate with an untuned baseline, or reporting a successful request as a successful support search. Use the requirements in [[E1]] and document tuning effort for all candidates.",
            "description": "The version 29.0 API documents typo and token controls; record a fair configuration before comparing results.",
            "status": "active",
            "tags": [
              "website-demo"
            ],
            "created_at": "2026-09-06T07:45:01Z",
            "updated_at": "2026-09-06T07:49:46Z"
          }
        ]
      },
      {
        "name": "review",
        "display_name": "Review \u0026 trial",
        "description": "Challenged claims and a reproducible trial plan.",
        "status": "draft",
        "position": 2,
        "created_at": "2026-09-06T07:42:41Z",
        "updated_at": "2026-09-06T07:42:41Z",
        "entries": [
          {
            "title": "A lower hosting bill does not establish lower operating cost",
            "entry_type": "markdown",
            "content": "# A lower hosting bill does not establish lower operating cost\n\n**Hypothesis under review:** “A separate search service will be cheaper to operate.” This is an illustrative claim introduced to demonstrate review, not a vendor quote or a measured finding.\n\n## The review question\nWhat does “operate” include: hosting, synchronizing articles, indexing failures, backups, recovery drills, access filters, upgrades and engineering time?\n\n## Revised conclusion\nWe do not have comparable measurements for those items. The cost claim is unsupported and must not choose the engine. [[E3]] identifies an indexing task lifecycle to handle; [[E2]] identifies a baseline spelling-suggestion design that also has maintenance work. Neither source quantifies our costs.\n\n## Next evidence\nFor each tested configuration, record deployment work, update handling, recovery steps and the time spent by the person running them. Keep hosting charges separate from engineering time; do not combine them without an explicit rate and period.\n\n**Decision impact:** retain cost as an open question. The current proposal is a bounded trial, not a claim that one candidate wins.",
            "description": "Review of an illustrative cost hypothesis: hosting alone leaves synchronization, recovery and engineering time unresolved.",
            "status": "active",
            "tags": [
              "website-demo"
            ],
            "created_at": "2026-09-06T07:45:05Z",
            "updated_at": "2026-09-06T07:49:50Z"
          },
          {
            "title": "Run the same queries and update checks for every candidate",
            "entry_type": "markdown",
            "content": "# Run the same queries and update checks for every candidate\n\n**Proposed trial; not executed.** Use the same permitted sample articles and queries for PostgreSQL, Meilisearch and Typesense. Record versions, hardware, full configuration and tuning time. Seed fixtures are illustrative; add actual permitted queries before making a production decision.\n\n| Query | Expected article | Purpose |\n| --- | --- | --- |\n| change billing email | Update invoice contact | Different vocabulary |\n| reset pasword | Reset your password | Misspelling |\n| Rechnung herunterladen | Rechnung herunterladen | German exact-language baseline |\n\n## Acceptance proposal\nThe expected article should appear among the first three results for each agreed fixture. Inspect irrelevant results too. Change one article, observe when the changed text becomes searchable, then delete it and check removal. Test an unauthorized identity against a restricted article. Record observations as pass, fail or not run with supporting output.\n\nFreshness and latency thresholds require a real team requirement; leave them unset rather than inventing a service-level target. Repeat the tests with a representative corpus before extrapolating.\n\n## Decision gate\nIf the baseline passes the agreed requirements, keep it unless another evidenced constraint justifies replacement. If it fails, compare passing candidates and operating effort. If all fail, revise the approach. Link all results back to [[E1]], [[E2]], [[E3]] and [[E4]].",
            "description": "Proposed common trial with query fixtures, access checks and update observations. No trial results are claimed.",
            "status": "active",
            "tags": [
              "website-demo"
            ],
            "created_at": "2026-09-06T07:45:09Z",
            "updated_at": "2026-09-06T07:49:54Z"
          }
        ]
      },
      {
        "name": "decision",
        "display_name": "Decision record",
        "description": "Current decision and conditions for revisiting it.",
        "status": "draft",
        "position": 3,
        "created_at": "2026-09-06T07:42:41Z",
        "updated_at": "2026-09-06T07:42:41Z",
        "entries": [
          {
            "title": "ADR 001 — keep the baseline while preparing a search trial",
            "entry_type": "markdown",
            "content": "# ADR 001 — keep the baseline while preparing a search trial\n\n**Status: proposed next step. Engine selection remains open.** Prepared 2026-09-06 for an illustrative support-search scenario using real documentation research.\n\n## Context\nThe sample team needs better article discovery and already uses PostgreSQL. Its constraints and criteria are in [[E1]].\n\n## Options considered\nPostgreSQL full-text search with an explicitly documented typo-handling approach [[E2]], Meilisearch [[E3]], and Typesense [[E4]]. No candidate has passed the application-specific gates yet.\n\n## Decision\nKeep the baseline in place and prepare the common trial in [[E6]] before adding a separate search service. This is a research recommendation for the sample scenario, not an approved production change.\n\n## Reasoning\nDocumentation establishes mechanisms worth testing. It does not establish relevance on our corpus or total operating cost. The cost assertion was challenged in [[E5]] and remains unsupported.\n\n## Consequences\nA comparison can proceed without a premature migration. The next work is to supply representative content, agree freshness and latency expectations, and collect comparable observations. There is no engine winner or fabricated benchmark table.\n\n## Revisit\nThe illustrative technical lead reviews this record after the trial results and operating-effort notes are attached. Change the recommendation if the baseline fails an agreed requirement that another candidate meets. No calendar deadline is invented without a real trial owner.",
            "description": "Proposed next step: keep the baseline while gathering the evidence required to choose an engine.",
            "status": "active",
            "tags": [
              "website-demo"
            ],
            "created_at": "2026-09-06T07:45:13Z",
            "updated_at": "2026-09-06T07:49:58Z"
          }
        ]
      }
    ],
    "tasks": [
      {
        "title": "Run the representative search trial before choosing an engine",
        "description": "Follow E6. Supply permitted representative content and agreed freshness/latency gates; record versions, settings, relevance, access and operating-effort observations. This task is intentionally open; the website demo does not claim trial execution.",
        "status": "pending",
        "priority": "high",
        "created_at": "2026-09-06T07:45:39Z",
        "updated_at": "2026-09-06T07:45:39Z"
      },
      {
        "title": "Revisit ADR 001 when comparable trial results are attached",
        "description": "Review E7 after E6 has observations for each candidate. Keep PostgreSQL if it meets the agreed gates; reconsider only with evidence of a gap. Illustrative owner: technical lead; actual trial owner and date not assigned.",
        "status": "pending",
        "priority": "medium",
        "created_at": "2026-09-06T07:45:43Z",
        "updated_at": "2026-09-06T07:45:43Z"
      }
    ]
  }
}
