Governed Search Runtime

An App publishes Resource identity, searchable fields, and authorization through SDK contracts. Core decides search eligibility and reauthorizes candidate IDs before disclosure. Use Resource contracts for the App surface; operators choose an engine through Search Configuration Profiles. An index hit alone is never a visible result.

What it is

Nexia Search is a Core-owned authorization pipeline with a replaceable candidate retrieval step. Typesense is the preferred lexical engine, but it is not the source of permission truth and it is not the only supported candidate gateway. The database gateway can supply candidates for a self-contained deployment, and another engine can be added by implementing the same Core contract.

The central distinction is between a candidate and a result. A candidate gateway may return a public identifier and rank. Only CoreSearchService may turn that identifier into a browser- or Agent-visible result. It re-fetches the record from the active tenant database, applies current type and record authorization, and constructs presentation fields from that verified model.

How it fits into Core

Select an engine through Search Configuration Profiles. App code uses the same Resource contracts for either gateway.

Typesense tenant restriction

The Typesense adapter refuses to search without tenant context. It signs a short-lived child key from a configured search-only parent and also sends a mandatory tenant_key filter with the query. The parent is a real key created in Typesense with search-only permissions; it is not an arbitrary secret and it must not be confused with Scout's server-side administrative key.

These engine restrictions are defense in depth. CoreSearchService still re-fetches and authorizes every candidate because a scoped key cannot express all current Nexia policies and record scopes.

Boundaries

Search does not grant access. A Resource appearing in an index never makes it visible to an actor. Browser-direct Typesense queries are outside the supported product path because they would bypass Core revalidation.

The external index is not durable product truth. Rebuilding or replacing it must not change business records, permission grants, or audit history. Only deliberately allowlisted Resources are exported, and adding an App model to an index requires a stable Resource identity contract.

Knowledge semantic retrieval is another boundary. It is disabled by default, Knowledge-only, and selected through an immutable embedding profile rather than a generic provider name. A profile identifies the provider, model and version, vector dimension, extraction contract, and storage generation together. This prevents an operator from changing only a model name while persisted vectors still belong to an incompatible space.

The current release exposes only deterministic-local-test-vector-16-v1, which Core rejects outside local and testing. There is no production Knowledge embedding profile yet. Enabling Typesense lexical search does not enable semantic retrieval, and enabling either path does not expand the actor's authorization.

Worked example

An actor then searches for Q-1842. The Typesense gateway issues a tenant- filtered query and returns candidate public IDs with ranks. Core resolves the registered model for each Resource key, fetches each ID through the current tenant connection, checks type permission and record visibility, and builds the response from verified database rows. A stale candidate or newly revoked record is omitted. Changing the gateway to database changes the candidate ranking capabilities, not the authorization sequence.

Related

• Permissions and roles — defines the authority Search must re-evaluate.
• Tenant and context — explains why the selected database and actor must exist before a query.
• Resource contracts — supplies the stable Resource identities Search can register.
• Artisan commands — lists supported operational commands after changing an index configuration.