# Slik brukar coreAI entitetstypar til å skilje produkt, dokument og kontaktpersonar

Strukturerte entitetar gjev coreAI moglegheit til å skilje eit produkt frå ein PDF, ei stillingsannonse eller ein kontaktperson — noko ein flat tekstimport ikkje klarar. Når kjeldesystemet sender rett type, kan assistenten svare med rett kontekst, og dei same felta kan brukast som filter seinare.

## Kvifor strukturerte entitetar slår ein flat tekstimport

Viss alt som hamnar i kunnskapsbasen er rå tekst, må modellen gjette om ein passasje skildrar eit produkt, ein hjelpeartikkel eller ein person. Gjettinga treffer ofte godt nok til å svare omtrentleg, men ikkje godt nok til å vise eit produktbilete, ein pris eller rette kontaktopplysingar når brukaren faktisk spør om akkurat det.

Når dataene vert sende inn som typa entitetar, veit coreAI kva kvar rad representerer. Eit produktkort kan presenterast med pris og lagerstatus, ei stillingsannonse kan haldast utanfor eit generelt FAQ-svar, og ein PDF kan refererast som dokumentasjon i staden for marketing-tekst. Resultatet er svar som matchar spørsmålet både i innhald og form.

## Dei sju entitetstypane coreAI forstår

API v2 støttar sju entitetstypar, og kvar type har sine eigne påkravde felt:

- `products` — produktkatalog med namn, produktnummer, pris, lagerstatus og bilete. Krev `name` og `productNumber`.
- `contents` — artiklar, hjelpetekstar og redaksjonell marketing-copy. Krev `name` og `longDescription`.
- `documents` — PDF-ar og anna formell dokumentasjon.
- `events` — tidsstyrte oppføringar som arrangement, webinar og opne dagar.
- `educations` — kurs, studieprogram og opplæringsløp.
- `job_postings` — utlyste stillingar.
- `contacts` — personar og roller, med e-post, telefon og arbeidsstad.

Alle typane brukar same upsert-løype mot `/assistants/{assistantId}/sources/{contentImporterId}`, men `attributes`-blokka og settet med påkravde felt varierer. Det er `type`-feltet som avgjer korleis coreAI lagrar, indekserer og presenterer entiteten i eit svar.

## Properties gjer entitetane filtrerbare

Kvar entitet kan ha ein `properties`-blokk med korte, strukturerte verdiar — `categoryName`, `publishedAt`, `market` og liknande. Bruk camelCase-namn og éin av fire typar: `string`, `number`, `boolean` eller `date`. Properties er ikkje meint for langtekst; dei er metadata som skildrar entiteten på ein måte som kan samanliknast og sorterast.

Dei same nøklane vert filterfelt i chat- og søkjekall. coreAI støttar desse operatorane:

- `$eq` — eksakt likskap, til dømes `market = "no"`
- `$gt`, `$gte`, `$lt`, `$lte` — samanlikningar på tal og datoar, til dømes `publishedAt >= "2026-01-01"`
- `$in` — verdien er éin av ei gjeven liste, til dømes `categoryName in ["jakker", "buksar"]`

Filtra vert lagt på `filters`-feltet i eit chat- eller søkjekall, og coreAI brukar dei til å avgrense kva entitetar som er kandidatar for svar. Det tyder at du kan fylle kunnskapsbasen breitt — alle marknader, alle kategoriar, alle publiseringsnivå — og likevel be eitt bestemt kall om å svare frå berre eitt utval.

## Når ein filtrert assistent er rett svar

Eit typisk døme: ei verksemd driv nettbutikkar i fleire land med felles produktkatalog, men kvar butikk skal berre vise sine eigne produkt og prisar. I staden for å byggje éin assistent per marknad sender du alle produkta inn med ein `market`-property (`"no"`, `"se"`, `"dk"`) og let widgeten på kvar butikk passere `{ "market": { "$eq": "no" } }` i chat-kallet. Same mønster fungerer for å skilje publiserte frå interne dokument, eller for å la eit søk vise berre arrangement som enno ikkje har funne stad (`startDate` med `$gte` på dagens dato).

Den robuste integrasjonen er å typebestemme entitetane rett frå start, halde eit lite og gjennomtenkt sett med properties, og bruke filter i staden for å duplisere assistentar når éin logisk kunnskapsbase skal serverast til fleire kontekstar.