# Slik bruker coreAI entitetstyper til å skille produkter, dokumenter og kontaktpersoner

Strukturerte entiteter gir coreAI muligheten til å skille et produkt fra en PDF, en stillingsannonse eller en kontaktperson — noe en flat tekstimport ikke klarer. Når kildesystemet sender riktig type, kan assistenten svare med riktig kontekst, og de samme feltene kan brukes som filtre senere.

## Hvorfor strukturerte entiteter slår en flat tekstimport

Hvis alt som havner i kunnskapsbasen er rå tekst, må modellen gjette om en passasje beskriver et produkt, en hjelpeartikkel eller en person. Gjettingen treffer ofte godt nok til å svare omtrentlig, men ikke godt nok til å vise et produktbilde, en pris eller riktige kontaktopplysninger når brukeren faktisk spør om akkurat det.

Når dataene sendes inn som typede entiteter, vet coreAI hva hver rad representerer. Et produktkort kan presenteres med pris og lagerstatus, en stillingsannonse kan holdes utenfor et generelt FAQ-svar, og en PDF kan refereres som dokumentasjon i stedet for marketing-tekst. Resultatet er svar som matcher spørsmålet både i innhold og form.

## De syv entitetstypene coreAI forstår

API v2 støtter syv entitetstyper, og hver type har sine egne påkrevde felter:

- `products` — produktkatalog med navn, produktnummer, pris, lagerstatus og bilder. Krever `name` og `productNumber`.
- `contents` — artikler, hjelpetekster og redaksjonell marketing-copy. Krever `name` og `longDescription`.
- `documents` — PDF-er og annen formell dokumentasjon.
- `events` — tidsstyrte oppføringer som arrangementer, webinarer og åpne dager.
- `educations` — kurs, studieprogrammer og opplæringsløp.
- `job_postings` — utlyste stillinger.
- `contacts` — personer og roller, med e-post, telefon og arbeidssted.

Alle typene bruker samme upsert-løype mot `/assistants/{assistantId}/sources/{contentImporterId}`, men `attributes`-blokken og settet med påkrevde felter varierer. Det er `type`-feltet som avgjør hvordan coreAI lagrer, indekserer og presenterer entiteten i et svar.

## Properties gjør entitetene filtrerbare

Hver entitet kan ha en `properties`-blokk med korte, strukturerte verdier — `categoryName`, `publishedAt`, `market` og lignende. Bruk camelCase-navn og en av fire typer: `string`, `number`, `boolean` eller `date`. Properties er ikke ment for langtekst; de er metadata som beskriver entiteten på en måte som kan sammenlignes og sorteres.

De samme nøklene blir filterfelt i chat- og søkekall. coreAI støtter disse operatorene:

- `$eq` — eksakt likhet, for eksempel `market = "no"`
- `$gt`, `$gte`, `$lt`, `$lte` — sammenligninger på tall og datoer, for eksempel `publishedAt >= "2026-01-01"`
- `$in` — verdien er én av en gitt liste, for eksempel `categoryName in ["jakker", "bukser"]`

Filtrene legges på `filters`-feltet i et chat- eller søkekall, og coreAI bruker dem til å begrense hvilke entiteter som er kandidater for svar. Det betyr at du kan fylle kunnskapsbasen bredt — alle markeder, alle kategorier, alle publiseringsnivåer — og likevel be ett bestemt kall om å svare fra bare ett utvalg.

## Når en filtrert assistent er riktig svar

Et typisk eksempel: en bedrift driver nettbutikker i flere land med felles produktkatalog, men hver butikk skal bare vise sine egne produkter og priser. I stedet for å bygge én assistent per marked sender du alle produktene inn med en `market`-property (`"no"`, `"se"`, `"dk"`) og lar widgeten på hver butikk passere `{ "market": { "$eq": "no" } }` i chat-kallet. Samme mønster fungerer for å skille publiserte fra interne dokumenter, eller for å la et søk vise bare arrangementer som ennå ikke har funnet sted (`startDate` med `$gte` på dagens dato).

Den robuste integrasjonen er å typebestemme entitetene riktig fra start, holde et lite og gjennomtenkt sett med properties, og bruke filtre i stedet for å duplisere assistenter når én logisk kunnskapsbase skal serveres til flere kontekster.