Semantic search for Modum kommune

Recommendation

BCW can build and operate an independent search API while Modum keeps its website, publishing workflow, and hosting in SiteVision. The recommended design is a small SiteVision connector, an external synchronization and indexing service, and a custom search WebApp on Modum’s existing /sok page. The search service should combine semantic retrieval with keyword matching and return ordinary links and useful excerpts.

This is technically supported by SiteVision’s documented extension points. It is not yet an integration verified against Modum’s authenticated CMS. An anonymous request to Modum’s /rest-api/doc returned HTTP 403 on 10 September 2026, so its actual API configuration, version, permissions, and content coverage remain to be checked with an authorized account. HTTP 403 does not establish that the API is disabled.¹

The central implementation decisions are:

Decision	Recommended approach
Where search runs	BCW-operated REST API and search index
What Modum keeps	SiteVision CMS, hosting, URLs, and editorial workflow
How content is obtained	SiteVision APIs through a narrow RESTApp connector; published content extraction plus metadata and file ingestion
How changes arrive	RESTApp events, a durable delivery mechanism, and scheduled reconciliation
How results appear	A WebApp replacing the results module at `/sok`, preserving `query` links
Ranking	Hybrid semantic and keyword retrieval; evaluate against Norwegian resident tasks
Initial scope	Approved public pages, articles, and documents; external systems by separate agreement
Native alternative	Benchmark SiteVision’s `aiAssistant.querySemanticIndex` before committing to the full operating cost of an independent index

The first release should provide search results. Generating answers is a separate product decision and is unnecessary to deliver semantic search.

Live search findings

These are exploratory observations from the public desktop website on 10 September 2026, using Modum’s search forms. The completed result count was checked after each submission. They describe this sample, not an overall success rate or a benchmark of SiteVision’s platform capabilities.

Query	Reported hits	Observed result and implication
`barnehage`	197	“Barnehage” ranked first. Individual kindergartens followed. The application page appeared below the first ten results.
`hvordan søker jeg barnehageplass`	3	“Barnehage” ranked first, followed by two PDFs. The exact question appears in the first result’s excerpt, so this is not evidence of semantic understanding.
`jeg trenger hjelp til å betale husleia`	0	The resident’s description of a need produced no results.
`bostøtte`	5	“Bostøtte” ranked first. This establishes that a relevant housing-support page is present despite the preceding zero-result query.
`barnehge`	0	No correction was displayed in the completed result state for this typo.
`søppeltømming`	0	No results for the tested term.
`når blir søpla hentet`	0	No results for the conversational question. Whether the required collection information is actually in SiteVision remains unverified.
`renovasjon`	82	A planning-regulations PDF ranked first; winter road maintenance ranked second. Several following results were planning documents.
`bygge garasje`	19	“Slik søker du” ranked first, followed by planning documents. Useful keyword behavior that a replacement should retain.
`building permit`	0	The English query did not find the Norwegian building-service content.
`legevakt`	56	“Vakttelefoner” ranked first. Preserve effective navigation for this kind of service query.

The queries can be reproduced on Modum’s search page. Useful comparison links are housing-support keyword, housing-support question, typo, and English query.

Additional observations:

The homepage form submits to /sok?query=...; a global header search dialog provides another entry point. Both need to remain consistent with the replacement.
Results include web pages, PDF, DOCX, and older DOC files. A page-only index would reduce existing coverage.
Some excerpts contain the site’s editor names, organization details, and other footer text. Others emphasize repeated legal/form links. Cleaning the searchable content is a material part of the improvement.
Several document results have generic or inconsistent titles. For example, one result was labeled “ÅRSMELDING OG REGNSKAP 2011” while its link ended in årsmelding_2017.pdf. Document-title rules and an editorial review are needed; changing the ranking model will not repair source metadata.
Pagination worked: selecting page 2 for barnehage displayed a different set of results, while retaining the reported total of 197. The first page contained 20 results.
Search suggestions were observed as a list of page titles for barnehage. Suggestion behavior is a separate integration surface from submitting the final query.
Some public document excerpts contain blank form labels and confidentiality wording. This alone is not evidence of a personal-data disclosure. Modum should identify which blank templates and older versions belong in the new index.

No load test, comprehensive accessibility audit, mobile-device test, or authenticated content test was performed. Ranking judgments here are qualitative. The findings justify a relevance evaluation; they do not prove that a particular embedding model will improve every query.

How Modum’s current search is connected

Public page markup identifies the results page as 4.2b2ef61194d8525c6b1202 and its search module as 12.2b2ef61194d8525c6b49d6. These are observed implementation identifiers, not contracts BCW should build its long-term API around.

The current search form advertises this asynchronous results URL:

/4.2b2ef61194d8525c6b1202/12.2b2ef61194d8525c6b49d6.htm
  ?state=ajaxQuery&isRenderingAjaxResult=true&query=...

It also advertises this autocomplete URL:

/4.2b2ef61194d8525c6b1202/12.2b2ef61194d8525c6b49d6.json
  ?state=autoComplete

A read-only request to the advertised results endpoint returned HTTP 200 with HTML, including the same barnehage count. It is a module-rendering endpoint, not the Model REST API. SiteVision’s Search template documentation exposes the corresponding result, query, autocomplete, and pagination concepts.²

Consequently, pointing the existing HTML loader at a new JSON search API will not be sufficient. BCW needs to own the result rendering and pagination, or build and maintain a compatibility adapter for the legacy HTML contract. A WebApp is the clearer supported integration.

The recommended change is to preserve /sok and the query parameter, replace the results module there, and update or replace suggestions in the homepage and header forms. Existing links to /sok?query=... can continue to work. There is no need to move Modum’s whole website or alter SiteVision’s internal search engine.

The SiteVision API families

“Public API” does not mean an unrestricted public HTTP endpoint. SiteVision uses the term for its supported programming interfaces within the SiteVision runtime.³

API family	What it provides	Role in the proposed solution
Public API: JCR Model	Read access to a tree of nodes and properties, under SiteVision permissions	Locate pages, archives, folders, files, metadata, and stable source IDs
Public API: Utilities	Helpers for data access, rendering, permission checks, search, HTTP calls, and other platform operations	Implement the connector without relying on unsupported internals
Model REST API	HTTP access to operations on the model; enabled separately per website	External enumeration, properties, headless content, and search-index reads
RESTApps	Custom HTTP routes and event handlers hosted in SiteVision	Narrow export API, synchronization events, and optional search proxy
WebApps	Custom modules with browser and server-side behavior	Render BCW search results within the existing website
Developer tooling	App scaffolding, types, packaging, signing, upload, and activation	Develop and deploy the connector and search UI

The JCR model implements read-only level-1 behavior; utility APIs provide other supported operations. BCW’s indexing integration needs read access to content, not permission to edit or publish pages. SiteVision recommends its utilities for forgiving node and property access rather than raw JCR operations that can throw exceptions.⁴

The Model REST URL format is:

https://<site>/rest-api/1/1/<node-id>/<operation>

The first 1 is the API version and the second selects the online/published model. Model version 0 exposes the editing/offline view. Use node identifiers rather than name paths. The tenant’s authenticated /rest-api/doc is the authority for its installed version; the public endpoint pages describe the latest version.¹

RESTApps use a different URL pattern:

https://<site>/rest-api/<addon-name>/<route>

The addon name forms part of that URL. Choose a stable name and manage future API versions explicitly.⁵

Access and authentication

Modum must enable and restrict the Model REST API if BCW will call it externally. Its documentation requires a logged-in user with the DEVELOPER permission. RESTApps have their own “Permit call,” HTTP-method permissions, and cross-origin restrictions. A custom RESTApp can invoke the built-in Model REST API internally even when that API is not exposed externally.¹⁶⁷

Use a dedicated integration identity, a narrow content scope, and server-held credentials. Modum’s actual authentication method must be confirmed. SiteVision supports configurable login filters, including BASIC, but the inspected documentation does not establish a universal incoming bearer-token or OAuth client-credentials flow for every customer installation.⁸

The SDK’s OAuth2 helpers mainly address obtaining and using tokens when SiteVision calls another service. They should not be mistaken for proof that BCW can automatically authenticate to Modum’s CMS with OAuth2.⁹

Keep deployment credentials, content-reading credentials, and the public search interface separate. A public search application cannot safely hide an API secret in browser JavaScript. CORS is a browser-origin control, not authentication.

Content extraction and completeness

Enumerating the source

Start from approved roots in the page tree and file repositories. Traverse folders and archives as well as pages; otherwise articles or deeply nested content can be missed. Files may reside in the global repository or a page’s local repository. ResourceLocatorUtil exposes helpers for both.¹⁰

Built-in operation	Relevant behavior	Recommended use
`nodes`	Child nodes; supports `includes`, `excludes`, selected `properties`, `skip`, and `limit`	Bounded tree traversal, including containers
`properties`	Selected properties for a node	Titles, canonical URLs, dates, locale, and approved metadata
`contentnodes`	Headless content for supported modules on a page	Structured headings, text, links, and media references
`headless`	Combines properties, child nodes, and content nodes	Convenient page export where all three are useful
`search`	Permission-filtered Solr results; selected fields, sorting, offset, and limit	Inventory comparison, stored text, and fallback retrieval

These operations are documented individually. nodes and headless default to very large child limits, so the connector should always set an explicit bounded batch size. headless is not a guaranteed recursive export of the entire website: includeContent and includeLinkedContent are false by default for subnodes.¹¹¹²¹³¹⁴

The search endpoint limits each response to 1–500 hits in documented versions since 2022.10.2. It provides offset pagination, not a documented durable synchronization cursor. It returns only hits the caller may read, which is not equivalent to “public” when the caller has privileged access.¹⁵

Preferred page-body extraction

There are three useful extraction paths, which should be tested against the same representative pages:

Indexable content extraction through a RESTApp. Since SiteVision 2026.03.1, IndexableContentExtractor can return online page content as HTML, text, or Markdown. This is particularly relevant to search ingestion because it targets indexable rendered content.¹⁶
Headless content. contentnodes and headless provide structured content with plain text, JSON, or Markdown text formats. Markdown is documented since 2025.07.1. JSON preserves structural elements such as headings, links, and tables.¹³¹⁴
Controlled rendered-page extraction or stored index text. Use as a fallback where headless coverage is incomplete, with explicit removal of navigation and unrelated shared text. The standard index’s summary is stored text; content.analyzed is an analyzed search field. Do not assume a UI excerpt, or every field named “summary,” is a complete clean article body.¹⁷

The extractor builder accepts published sv:page, sv:article, and sv:sitePage nodes. It requires READ permission, rejects the currently executing page, and defaults to the current user when rendering. Structure pages and other node types need their own tested handling. Online content and anonymous content are different conditions: content rendered as an editor or indexer may differ from what an anonymous visitor sees.¹⁸

Use an explicit public-audience extraction path. For example, obtain the final rendered body without authentication, or ensure the connector’s rendering context matches anonymous access. Apply hasAnonymousReadPermission(node) in addition to publication and scope checks; do not infer public eligibility from a successful service-account read.¹⁹

What headless export can miss

The documented content-node response includes standard headless modules and WebApps that implement a headless output. A custom WebApp needs headless.js to expose this data. Invalid output can cause its entire headless contribution to be omitted. Very old, unchanged Text portlets also have a documented omission case.¹³²⁰

Therefore, “the API returned JSON successfully” is not a completeness test. Compare extracted text against visible content for accordions, tables, linked layouts, reusable elements, embedded components, service cards, and custom WebApps. A main-content block may need a connector-specific adapter. Avoid duplicating linked shared content across every page.

SiteVision also documents  exclusions in rendered content. Respect deliberate indexing exclusions, and determine how each extraction path handles them. Headless extraction should not accidentally reintroduce content intentionally excluded from search.²¹

Documents and external services

File nodes expose URLs, metadata, modification dates, length, and download-protection information. Their binary content can be obtained separately. A file is not a publishable page, so applying a page-only published=true rule to every node type would be wrong.²²

Download approved files and extract their body in BCW’s worker environment. Include PDF, DOCX, and DOC support in scope; add OCR for scanned PDFs only where the content audit shows it is needed. Preserve document/page references, detect empty extraction, reconcile duplicate versions, and use the file’s current download URL. Make file eligibility and extraction failures visible to operators.

“All the data” must mean all approved searchable content, with a measurable inventory. It should not silently include editor comments, user accounts, submitted form answers, unpublished material, or restricted documents. Use a property allowlist rather than requesting and retaining every property.

Modum’s homepage links to external systems for maps, public records, issue reporting, and other tasks. SiteVision can expose the links it stores; it cannot automatically export those systems’ underlying records. Agree whether each external destination is a curated search shortcut, a separately synchronized source, or out of scope. The rubbish-collection question is a useful test of this boundary.²³

Keeping the index synchronized

Event-driven updates plus reconciliation

RESTApps can react to publishing, structural, trash, binary, and timer events. The following event coverage is relevant:²⁴

Event	BCW action
`sv:publishing:publish`	Re-fetch the current online representation and upsert if eligible
`sv:publishing:unpublish`	Suppress the document and its chunks; confirm current state
`sv:structure:move`	Re-check eligibility, URL, hierarchy, and affected descendants
`sv:trashcan:add`	Suppress the removed item and any affected descendants
`sv:trashcan:restore`	Re-check current publication/access before reindexing
`sv:binary:create`	Evaluate the new file against the approved scope
`sv:binary:update:*`	Re-fetch changed content, metadata, name, tags, or selected version
`sv:folder:update:metadata`	Re-evaluate inherited classification where applicable
Timer events	Drain a retry/outbox mechanism or trigger bounded reconciliation

Events are asynchronous and run in the OFFLINE model as the emitting user. Their timestamp is not guaranteed to equal the content’s publish timestamp. The documentation has inconsistent statements about cluster locality; design as though handlers may execute on any cluster node. Do not rely on process-local state.²⁴²⁵

Treat an event as an instruction to check source state, rather than as the canonical content revision. Event handlers should record a small durable change message and return quickly. Send identifiers and change information to BCW; let workers perform downloads, extraction, embeddings, and indexing.

Do not read content with ordinary RestApi inside an event handler and assume it is published content. RestApi uses the current execution version. Since 2024.04.2, VersionedRestApi, obtained through RestApiFactory.getOnlineRestApi(), provides an explicit online version using node identifiers. This is the documented alternative when an offline handler must read online data.⁷²⁶

No end-to-end, durable, ordered, exactly-once webhook guarantee was established by the inspected documentation. Implement retries, idempotency, and periodic reconciliation as BCW responsibilities. Nor was a comprehensive page-permission-change event identified in the documented event list. Changes to access, inherited rules, indexing policy, and custom modules require a reconciliation strategy and tenant-specific tests.

Recommended synchronization algorithm

This is a proposed BCW design, not a built-in SiteVision change-feed contract.

Establish a manifest of source identifiers under approved roots and begin capturing changes before the initial import.
Page through the inventory in bounded batches. Fetch current online properties, public eligibility, clean body, and attachment references.
Store the source ID separately from the URL. Compute a hash of normalized content and the extraction/model versions.
Re-embed only changed content. Replace all chunks for a document atomically so old sections cannot survive an update.
Process captured changes after the baseline import; repeated delivery must have the same eventual effect as one delivery.
Run incremental scans with an overlap window. If using the Solr index, allow for indexing lag and use a deterministic order with an ID tie-breaker where supported.
Complete periodic full manifests and compare IDs, URLs, hashes, and eligibility. Suppress records missing from a successfully completed inventory. Never infer mass deletion from an interrupted scan or an authentication failure.
Reconcile again after deploying a connector, changing extraction rules, changing access policies, or restoring a SiteVision backup.

Unpublish and access revocation deserve a fast suppression path independent of embedding jobs. For strict requirements, use a short eligibility lease or a current access check through a public-facing gateway. A background synchronization process alone cannot promise zero stale exposure during an outage. Agree a maximum permissible delay and a fail-closed behavior with Modum.

Events can be duplicated or arrive out of order. Always check current source state before making content searchable. A delayed publish event must not resurrect an item that has since been unpublished. Parent moves and removals must also trigger checks of descendants, links, breadcrumbs, and applicable local files.

SiteVision’s own indexes are eventually consistent: the indexing documentation says updates commonly propagate within a minute but can take longer under load. A search query issued immediately after publishing is therefore an unreliable sole change detector.²¹

Queues, timers, and transport limits

SiteVision’s data stores are suitable candidates for small connector state and outbox records, subject to validation of concurrent delivery and failure behavior. They support clustered data but are not documented as a transactional message broker. Records have 50 top-level properties, 100-character keys, and 5,000-character property-value limits; internal IDs/timestamps can change during export/import. Use your own event identity fields.²⁷

Timer intervals are 5, 15, and 30 minutes, hourly, and daily. They run as Anonymous unless deliberately configured otherwise. A handler that runs beyond its interval can cause timer events to be missed. Keep extraction and embedding workloads outside these handlers.²⁴

Outbound Requester calls share a limited pool. The documentation describes typical values of 100 connections and five-second timeouts, which are not a guaranteed tenant SLA. Send bounded messages to a fast receiver and persist delivery failures. Avoid long synchronous model calls from CMS event handlers or page requests.²⁸

The Cache API is volatile and limited to 600 seconds and 10,000 characters per entry. It cannot substitute for a durable queue, export manifest, or search database.²⁹

Polling-only and crawler alternatives

If Modum cannot install a RESTApp, BCW can begin with Model REST polling. This needs a full inventory reconciliation to discover removals and permission changes; timestamps alone are insufficient. Freshness will be lower and source load potentially higher.

SiteVision also supports sitemaps and external search-engine notifications. The documented sitemap location is /sitemapindex.xml; both that location and /sitemap.xml returned HTTP 404 during this inspection. This only establishes that those public URLs were unavailable. Sitemaps can include files, but are not a complete permission-aware synchronization feed.³⁰

The external notification settings document a service address, login details, and notification frequency, but the inspected help page is old and does not establish the payload, delivery guarantees, or removal semantics. Treat it as an option to clarify with SiteVision, rather than a ready-made webhook specification.³¹

BCW search API and retrieval design

The following endpoint names and response are a proposed contract. They are not deployed services or existing SiteVision endpoints.

Surface	Example	Access
Search	`GET /v1/search?query=...&limit=10&cursor=...`	Public approved corpus, or authenticated SiteVision gateway
Suggestions	`GET /v1/suggest?query=...&limit=5`	Same public corpus
Change receiver	`POST /v1/integrations/sitevision/events`	Authenticated connector only
Sync status	`GET /v1/admin/sync/status`	BCW/Modum operators
Reconciliation control	`POST /v1/admin/sync/reconcile`	Authorized operators

{
  "query": "hvordan søker jeg barnehageplass",
  "items": [
    {
      "id": "modum:sitevision:<source-node-id>",
      "title": "Søke/endre/si opp plass i barnehage og SFO",
      "url": "https://www.modum.kommune.no/tjenester/barnehage/soke-endre-si-opp-plass-i-barnehage-og-sfo",
      "snippet": "<excerpt from the current approved source>",
      "type": "page",
      "language": "nb",
      "breadcrumbs": ["Tjenester", "Barnehage"]
    }
  ],
  "nextCursor": null,
  "total": {"value": 1, "relation": "gte"},
  "mode": "hybrid",
  "requestId": "<request-id>"
}

The example illustrates the response shape and desired result type; it is not a measured semantic-search response. The source node ID and language mapping must come from the real export. Keep source locale and normalized language separately, because the public website currently identifies its language as no.

Use total.relation to distinguish exact totals from lower bounds. Semantic top-k retrieval does not naturally produce an exact total number of matches. Do not imitate the current exact-looking count unless the backend genuinely calculates it. Bind a cursor to the query, filters, ranking version, and result snapshot or define explicit expiry behavior.

Each document record should retain tenant/site ID, source node ID and type, canonical URL, title, locale, section hierarchy, file metadata where relevant, publication/modification information, eligibility status, content hash, extraction version, embedding model version, last successful synchronization, and source provenance. Store chunks beneath the document with heading and document-page references.

Recommended retrieval sequence:

Normalize whitespace and Unicode without destroying Norwegian characters, proper names, numbers, or identifiers.
Apply fixed tenant, public-eligibility, and approved-scope filters.
Retrieve semantic candidates and lexical candidates, including exact title/name matches and typo-tolerant matching where appropriate.
Merge rankings, deduplicate at document level, and optionally rerank a bounded candidate set.
Prefer the authoritative current service page for a service-navigation intent while retaining relevant plans, regulations, and historic documents for document-specific queries.
Return an excerpt from the matching section, with its source link and document metadata. Do not invent an answer.

This hybrid approach is a recommendation to evaluate. It preserves exact-name and identifier behavior while addressing the vocabulary gaps observed in testing. Select an embedding model using Norwegian Bokmål, Nynorsk, and cross-language examples from Modum, rather than assuming that a multilingual label guarantees sufficient quality.

Keep chunks aligned to headings and meaningful sections; preserve table context. Record model versions so a later model change can build a new index beside the old one and switch atomically. Store source content separately from embeddings so a model migration does not require reconstructing the content history.

Define bounded query length, allowed filters, timeouts, rate limits, cache behavior, and explicit error responses. Validate client parameters rather than forwarding arbitrary Solr syntax, URLs, or index names. Protect tenant isolation in the service, even if the first customer is Modum. Suggestions must obey the same eligibility rules as search results.

A vector search failure should be able to fall back to lexical retrieval. An API outage should produce an explicit recoverable state or the preserved SiteVision fallback. Zero results, partial service degradation, and a failed request must be distinguishable.

Integrating the results into SiteVision

Recommended WebApp

Build a WebApp 2 with TypeScript and the supported SiteVision tooling. It should accept the existing query parameter, render the search form and results, and update the URL for query and pagination changes. SiteVision’s client router and requester support this pattern.³²³³

Use scoped styles and Modum’s existing visual tokens. SiteVision provides CSS Modules and Envision integration, and recommends sharing its provided React instance. Verify the actual supported React version and rendering mode rather than copying a version from an old example.³⁴

Two request paths are possible:

Pattern	Advantages	Costs and limits
Browser → BCW API	Simple public search transport; no extra CMS request hop	Public endpoint needs abuse controls; configure CORS and Modum’s CSP; browser contains no secret
Browser → SiteVision WebApp/RESTApp → BCW API	Same-origin browser calls; BCW credentials remain server-side; easier server-rendered first response	Additional hop and SiteVision connection-pool usage; needs strict timeout and graceful fallback

Start with a thin same-origin gateway if Modum wants BCW’s API authenticated or requires a useful server-rendered initial page. A direct public API is also valid for an exclusively public corpus. Benchmark the gateway under expected traffic, and use short, deliberate caching rather than adding a slow dependency to every page render.

The WebApp must cover keyboard submission and suggestion selection, focus handling, an announced result count, meaningful links, loading/error/no-result states, browser Back/Forward, direct-link reload, and mobile layouts. Keep useful navigation available if JavaScript or the API fails. This is a proposed acceptance scope, not a claim that the existing site was comprehensively audited.

Other supported routes

Custom Search templates: useful for visual adjustments to SiteVision’s own results, but they receive a SiteVision SearchResult and its module-specific state. They do not document a general configuration switch to consume any external JSON search service. Replacing their scripts and result contract creates custom integration work.²

Intranet search integration: SiteVision documents a RESTApp /search adapter accepting query, skip, and max, returning items, hasMore, and effectiveCount. This adds an integration tab to its intranet search module. It is an option if that module is actually selected for the project, not evidence that Modum’s public Search module has the same extension point.³⁵

Proxy module: can integrate externally produced HTML with rewriting constraints. It is a legacy alternative with HTML/JavaScript limitations and is not the preferred way to render a new JSON API.³⁶

Search Enterprise/custom indexes and the SiteVision Crawler: these bring external content into SiteVision’s indexes. They are the reverse direction from exporting Modum content into BCW’s index. They may help a native solution, but are not automatically required for a BCW-hosted replacement.³⁷

MCP Server: relevant to future assistant/tool access. It is not required for the requested REST search integration and does not replace a durable synchronization process.³⁸

Native semantic search alternative

SiteVision already has semantic-index functionality. The AI Assistant SDK documents querySemanticIndex(assistant, {query, maxHits}), which returns matching content chunks and can be called without an authenticated current user. The SDK requires the appropriate license and an Assistant/knowledge configuration. Scores are documented since 2025.10.1.³⁹

BCW could wrap that function in a RESTApp and render the resulting links in a custom WebApp, without building its own embedding pipeline. Internal results provide node IDs and text; the adapter would need to resolve titles and URLs, group multiple chunks from the same document, and verify public-access behavior. The documented method does not offer the same full search contract as a custom engine: pagination, exact totals, rich filters, and ranking controls need investigation or additional implementation.

SiteVision’s own cookbook also describes inserting external text into a semantic knowledge base, with source identity and access information. That provides a path for a broader native solution. The cookbook’s linked SemanticIndex endpoint documentation returned an error during this review, so its full current HTTP contract was not verified.⁴⁰

Approach	BCW owns	Key benefit	Main constraint
Independent BCW search	Export pipeline, embeddings, corpus, API, ranking, UI	Maximum control and reuse across CMS platforms	BCW owns synchronization correctness and ongoing operations
SiteVision-native semantic adapter	Adapter and UI; possibly a BCW facade	Less duplicated content infrastructure	License, native retrieval contract, platform dependency, and less control
Improve existing lexical search	Configuration and selected templates/modules	Smaller scope; preserves existing search machinery	Does not establish equivalent semantic capability

Recommend the independent approach when BCW’s own REST API, model control, observability, or multi-client platform are requirements. If the immediate business goal is only better search for this one website, compare a small native prototype against the independent prototype on the same relevance set before committing.

Existing Searcher APIs support parsers, field boosts, filters, spellchecking, highlighting, permission strategies, and query monitoring. Norwegian stopwords are documented. The failures observed on Modum therefore describe its current configuration and content; they are not proof that SiteVision has no relevant search-improvement features.⁴¹

Deployment, prerequisites, and operating responsibilities

Production WebApps and RESTApps require a SiteVision-signed certificate trusted by the website. A developer must belong to a team to manage certificates. The published workflow covers signing, installing trust, uploading, and activating the version. Marketplace publication is not necessary to deploy a client-specific app.⁴²

Use versioned deployments and a staging site. SiteVision supports multiple versions under an addon and an active-version selection. Avoid overwriting an active production app: bundled-app protection is processed on deployment, and the new executable is unavailable until that processing completes.⁵⁴³

The connector’s configurable values should include source roots, approved content types, BCW receiver location, synchronization settings, and feature switches. Keep credentials in server-side configuration or an approved secret mechanism, and never serialize them into the WebApp’s client state. requirePrivileged must be declared and configured if service-user execution is needed; it is not a reason to grant the public result renderer broad CMS permissions.⁴⁴

SiteVision’s server-side scripting is sandboxed. Do not assume it is a general Node.js hosting environment for arbitrary file parsers, database drivers, or model inference. Keep computationally intensive ingestion in BCW’s environment and use supported platform APIs in the connector.⁴⁵

Needed from Modum / its SiteVision partner	Why it matters
Installed version/build and hosting arrangement	Verify newer extraction APIs and tenant limits
Authorized read-only developer access and staging	Inspect the real model and test content coverage
API exposure and authentication configuration	Choose direct Model REST versus narrow RESTApp export
Ability to install and activate addons and trust BCW’s signing certificate	Deploy the connector and WebApp
Current search module and template configuration	Preserve entry points, suggestions, and rollback
Content inventory and exclusions	Define public pages/files and external-source boundaries
Existing synonyms, promoted hits, and search reports	Preserve editorial intent and form the evaluation set
Publication/access-revocation expectations	Define freshness and suppression requirements
Expected query traffic and availability requirements	Size the API and test the SiteVision gateway
Hosting, retention, and processing agreements	Decide where content, query logs, and embeddings may reside

If a custom index contains useful synonyms or promoted results, SiteVision’s synonyms and elevations endpoints can read those configurations with the documented license and permissions. Their availability on Modum is unverified.⁴⁶

BCW should operate the API, index, workers, failure queues, backups, alerts, model versions, and deployment pipeline. Modum should own content approval and the relevance judgments for its services. Agree who handles source-data issues and failed document extraction.

Monitor synchronization lag, oldest pending event, failed source reads, extraction coverage, missing source IDs, permission suppressions, indexed document/chunk counts, zero-result queries, latency percentiles, and fallback frequency. Query text may contain personal information; minimize retention and logging and establish a documented policy. SiteVision’s logging documentation itself cautions against logging personal data.⁴⁷

Proof of concept and rollout

1. Establish access and the source contract

Confirm the tenant prerequisites above. Inspect a representative set of 30–50 pages and documents across services, news, archive content, linked layouts, and custom modules. Compare visible body text, headless export, and indexable content extraction where supported. Produce a manifest with included, excluded, failed, and unsupported records.

Exit condition: the team can explain where every selected page’s searchable text comes from, and demonstrate that drafts and private content are excluded.

2. Build the synchronization slice

Install a staging connector and ingest the sample into an external index. Test publish, republish, draft edits without publishing, scheduled unpublish, move, trash, restore, file replacement, file-version selection, permission restriction, and an inherited access change. Simulate duplicate delivery, a missed event, connector restart, temporary authentication failure, and a BCW outage.

Exit condition: every tested change reaches the correct final state; removal wins over an older queued update; a failed scan cannot delete the corpus; reconciliation recovers missed changes.

3. Evaluate retrieval

Create a judged set of at least 50–100 resident tasks with Modum. Include the observed queries, alternate wording, common mistakes, exact document titles, names, service identifiers, Bokmål/Nynorsk, and English queries if cross-language search is in scope. Record which pages should rank highly and which answers require an external service.

Compare the current search, a lexical baseline, the hybrid prototype, and optionally the native semantic adapter. Measure useful results within the first three or five positions, ranking quality, zero-result behavior, duplicate results, and latency. Do not equate “returns something” with “finds the right service.”

Exit condition: agreed relevance gains without material regression on important exact queries or inappropriate promotion of old documents.

4. Integrate and release

Replace the staging results component and connect all entry points and suggestions. Test accessibility, mobile behavior, browser history, bookmarked search URLs, paging, empty input, long queries, API failure, and the fallback. Verify deployed certificate trust, version activation, and rollback.

Expand to the full approved corpus, reconcile counts and extraction coverage, and run production-sized traffic tests against agreed targets. Enable the new search through a reversible configuration switch. Retain the old module/version or a prepared fallback page until the new service has passed the agreed observation period.

A sensible initial target to discuss is sub-second search response at the agreed traffic level and update propagation within a few minutes under normal operation. These are proposed product targets, not measured performance or SiteVision guarantees. Revocation needs its own stricter policy if required.

No reliable fixed implementation quote can be derived from the public website alone. The cost drivers are document volume and quality, module-specific extraction work, access handling, external sources, traffic, relevance tuning, and operational requirements. Estimate after the source-contract exercise; separate one-time ingestion, recurring model/API usage, hosting, support, and optional SiteVision license costs.

Documentation coverage and unresolved points

The developer sitemap supplied 410 pages under /docs/, all successfully retrieved for cataloguing and relevance screening. The investigation examined the material sections across Public API/JCR, content node types, Model REST endpoints, WebApps, RESTApps, events, search/indexing, storage, security, deployment, and native AI, then followed relevant Javadoc, help, release-note, and cookbook references.

The companion documentation inventory distinguishes the broad catalogue from references examined for this report. Retrieval and screening are not a claim that every method of every Javadoc class, every historical release note, or every unrelated platform feature was read line by line. The report covers the integration paths and material limitations found; it cannot certify “all potentially relevant documentation” in an open-ended, changing documentation site or substitute for the tenant’s protected API documentation.

The most consequential unresolved points are:

Point	Evidence and required resolution
Modum API availability	`/rest-api/doc` returned 403 anonymously. Inspect after authorized login.
Content-extractor availability	Public API says since 2026.03.1. Verify Modum’s version and render coverage.
Headless completeness	Depends on module support and valid headless output. Compare exports with visible pages.
Event delivery guarantees	Durable replay/order/retry guarantees were not established. Test and implement reconciliation.
Access-change detection	No comprehensive page ACL event identified. Agree reconciliation and revocation behavior.
Native semantic licensing and query semantics	Feature documented; Modum entitlement and production suitability unverified.
Native semantic HTTP endpoint	Cookbook target was unavailable. Obtain tenant-specific documentation.
Sitemap availability	Documented public location returned 404. Check site settings if a crawler is chosen.
Search content outside SiteVision	Linked systems require separate source agreements or curated links.
Documentation drift	Some guides contain old examples or inconsistent details. Use version-specific API references and staging tests.

The next concrete step is a staging access-and-extraction exercise. It will establish whether a narrow RESTApp using the newer indexable-content extractor can provide the complete approved corpus, and settle the remaining effort and deployment dependencies before BCW commits to a production build.

Sources

All sources are SiteVision’s official documentation or Modum’s public website, inspected on 10 September 2026 unless otherwise stated. Dates in URL paths often reflect a document’s original publication rather than its latest update.

SiteVision, Model REST API. Modum, tenant API documentation location, anonymous HTTP 403 observed. ↩ ↩² ↩³
SiteVision, Search custom template and Search field custom template. Modum, live search, form markup and advertised HTML endpoint inspected. ↩ ↩²
SiteVision, Public API and Utilities API. ↩
SiteVision, JCR Model API. ↩
SiteVision, Getting started with RESTApps. ↩ ↩²
SiteVision, RESTApp security, RESTApp addon management, and REST API settings panel. ↩
SiteVision, RestApi Javadoc. ↩ ↩²
SiteVision, Login configuration. ↩
SiteVision, OAuth2 SDK. ↩
SiteVision, ResourceLocatorUtil and node types. ↩
SiteVision, Nodes endpoint. ↩
SiteVision, Properties endpoint. ↩
SiteVision, ContentNodes endpoint. ↩ ↩² ↩³
SiteVision, Headless endpoint. ↩ ↩²
SiteVision, Search endpoint. ↩
SiteVision, IndexableContentExtractor. ↩
SiteVision, Standard Index. ↩
SiteVision, IndexableContentExtractorBuilder. ↩
SiteVision, PermissionUtil. ↩
SiteVision, WebApp headless.js. ↩
SiteVision, Indexing. ↩ ↩²
SiteVision, sv:file and sv:page. ↩
Modum kommune, homepage, public links inspected. ↩
SiteVision, System Event Options. ↩ ↩² ↩³
SiteVision, RESTApp events. ↩
SiteVision, VersionedRestApi. ↩
SiteVision, Data Storage, Key-value Data Store, and Collection Data Store. ↩
SiteVision, Requester guide and Requester Javadoc. ↩
SiteVision, Cache API. ↩
SiteVision, Search settings panel. Modum, documented sitemap location, HTTP 404 observed. ↩
SiteVision, Add search engine notification, page dated 28 February 2019. ↩
SiteVision, WebApps, Getting started, and TypeScript. ↩
SiteVision, Client router and Client requester. ↩
SiteVision, Styling, React, and Client-side rendering. ↩
SiteVision, Intranet search integrations. ↩
SiteVision, Proxy guidelines and restrictions. ↩
SiteVision, Custom Index, Index External Data, and SiteVision Crawler. ↩
SiteVision, MCP Server. ↩
SiteVision, AI Assistant SDK. ↩
SiteVision, Integrating external sources into a Knowledge base, July 2026; Working with AI Assistants, updated April 2026. ↩
SiteVision, Searcher, Stopwords, and Sorting. ↩
SiteVision, Certificates and signing and RESTApp signing. ↩
SiteVision, RESTApp deployment and Coming from RESTApps 1. ↩
SiteVision, RESTApp manifest, privileged SDK, and RESTApp configuration. ↩
SiteVision, Sandboxing in scripts. ↩
SiteVision, Synonyms endpoint and Elevations endpoint. ↩
SiteVision, Logging. ↩