# Så använder coreAI entitetstyper för att skilja produkter, dokument och kontaktpersoner

Strukturerade entiteter ger coreAI möjligheten att skilja en produkt från en PDF, en jobbannons eller en kontaktperson — något som en platt textimport inte klarar. När källsystemet skickar rätt typ kan assistenten svara med rätt kontext, och samma fält kan användas som filter senare.

## Varför strukturerade entiteter slår en platt textimport

Om allt som hamnar i kunskapsbasen är råtext måste modellen gissa om en passage beskriver en produkt, en hjälpartikel eller en person. Gissningen träffar ofta tillräckligt bra för att svara ungefärligt, men inte tillräckligt bra för att visa en produktbild, ett pris eller rätt kontaktuppgifter när användaren faktiskt frågar om just det.

När datan skickas in som typade entiteter vet coreAI vad varje rad representerar. Ett produktkort kan presenteras med pris och lagerstatus, en jobbannons kan hållas utanför ett generellt FAQ-svar, och en PDF kan refereras som dokumentation i stället för marknadsföringstext. Resultatet är svar som matchar frågan både i innehåll och form.

## De sju entitetstyperna coreAI förstår

API v2 stöder sju entitetstyper, och varje typ har sina egna obligatoriska fält:

- `products` — produktkatalog med namn, produktnummer, pris, lagerstatus och bilder. Kräver `name` och `productNumber`.
- `contents` — artiklar, hjälptexter och redaktionell marknadsföringscopy. Kräver `name` och `longDescription`.
- `documents` — PDF:er och annan formell dokumentation.
- `events` — tidsstyrda poster som evenemang, webbinarier och öppna dagar.
- `educations` — kurser, studieprogram och utbildningar.
- `job_postings` — utlysta tjänster.
- `contacts` — personer och roller, med e-post, telefon och arbetsplats.

Alla typer använder samma upsert-väg mot `/assistants/{assistantId}/sources/{contentImporterId}`, men `attributes`-blocket och uppsättningen obligatoriska fält varierar. Det är `type`-fältet som avgör hur coreAI lagrar, indexerar och presenterar entiteten i ett svar.

## Properties gör entiteterna filtrerbara

Varje entitet kan ha ett `properties`-block med korta, strukturerade värden — `categoryName`, `publishedAt`, `market` och liknande. Använd camelCase-namn och en av fyra typer: `string`, `number`, `boolean` eller `date`. Properties är inte tänkta för långtext; de är metadata som beskriver entiteten på ett sätt som kan jämföras och sorteras.

Samma nycklar blir filterfält i chatt- och sökanrop. coreAI stöder dessa operatorer:

- `$eq` — exakt likhet, till exempel `market = "se"`
- `$gt`, `$gte`, `$lt`, `$lte` — jämförelser på tal och datum, till exempel `publishedAt >= "2026-01-01"`
- `$in` — värdet är ett av en given lista, till exempel `categoryName in ["jackor", "byxor"]`

Filtren läggs på `filters`-fältet i ett chatt- eller sökanrop, och coreAI använder dem för att begränsa vilka entiteter som är kandidater för svar. Det betyder att du kan fylla kunskapsbasen brett — alla marknader, alla kategorier, alla publiceringsnivåer — och ändå be ett enskilt anrop svara från endast ett urval.

## När en filtrerad assistent är rätt svar

Ett typiskt exempel: ett företag driver webbutiker i flera länder med gemensam produktkatalog, men varje butik ska bara visa sina egna produkter och priser. I stället för att bygga en assistent per marknad skickar du in alla produkter med en `market`-property (`"se"`, `"no"`, `"dk"`) och låter widgeten i varje butik passera `{ "market": { "$eq": "se" } }` i chattanropet. Samma mönster fungerar för att skilja publicerade från interna dokument, eller för att låta en sökning visa endast evenemang som ännu inte har ägt rum (`startDate` med `$gte` på dagens datum).

Den robusta integrationen är att typbestämma entiteterna rätt från start, hålla en liten och genomtänkt uppsättning properties, och använda filter i stället för att duplicera assistenter när en logisk kunskapsbas ska serveras till flera kontexter.