domain-model

Dette dokumentet er auto-synket fra kildefilene i boligassistent-repoet. Endringer her vil overskrives ved neste sync. Rediger kildefilen direkte.

Lagbeskrivelser

Property

Toppnivå. Representerer tomten med adresse, tomteareal og eierform. Alle andre entiteter tilhører en eiendom. Grunnlaget for multi-hus-støtte. Bygningsspesifikk informasjon (byggeår, BRA, type) tilhører Building.

Building

En fysisk bygning på eiendommen. En eiendom kan ha én eller flere bygninger (f.eks. hus, garasje, dukkehus). Etasjer, rom og tekniske systemer tilhører en konkret bygning — ikke eiendommen direkte.

SpatialModel

Den romlige modellen av boligen. Inneholder bygninger, etasjer, rom, uteområder og støtterom. Hierarki: Property → Building → Floor → Room. OutdoorSpace tilhører Property (tomtearealer). SupportSpace tilhører Building (nullable). Dette er koordinatsystemet som alle andre lag refererer til.

BuildingSystems

Tekniske systemer som definerer en bygnings infrastruktur: varme, ventilasjon, vann, avløp, elektro, drenering, fasade og pipe. Systemer tilhører en konkret bygning (Building). Systemer er overordnede kategorier — konkret utstyr modelleres i Assets.

Assets

Konkret teknisk utstyr (varmepumpe, varmtvannsbereder, elbil-lader). Skilles tydelig fra møbler og dekor (InteriorLayer). Et asset tilhører et bygningssystem og er plassert i et rom.

ConditionLayer

Tilstandslaget. Inneholder tre distinkte typer:

Issue — teknisk problem, avvik eller risiko (inkl. TG-koder fra takstrapport)
SafetyItem — sikkerhetsforhold, særlig relevant for barnesikkerhet
Measurement — konkrete målinger (radon, fukt, temperatur)

PlanningLayer

Planleggingslaget. Inneholder:

ImprovementIdea — ønskede forbedringer som ikke er feil (backlog). Fungerer også som «prosjekt» ved større tiltak.
ImprovementDependency — strukturert avhengighet mellom idéer (must_before / should_group / independent)
Task — konkret oppgave som løser et Issue eller implementerer en ImprovementIdea
MaintenancePlan — sesongbasert vedlikeholdsplan

ExperienceLayer

Erfaringslaget — kunnskap opparbeidet gjennom å bo i huset. Inneholder:

Observation — en erfaring fra daglig bruk, en sesong eller en hendelse
SeasonalNote — oppsummering av en sesong
DecisionNote — dokumentert beslutning med begrunnelse

DesignLayer

Designretningslaget. Inneholder DesignDirection per domene (interiør, eksteriør, hage). Designretninger er foreløpige og skal kunne revideres over tid.

InteriorLayer

Interiørlaget. Inneholder:

InteriorAsset — møbler, lamper, dekor, tekstiler, kunst, planter
LayoutIntent — ønsket rombruk og møbleringsprinsipp per rom

KnowledgeLayer

Kunnskapslaget. Inneholder:

Document — dokumenter (takstrapport, manualer, kvitteringer). Kan prosesseres gjennom Ingestion Engine.
Photo — bilder av rom, utstyr og avvik
ProductReference — produktlenker som informerer kjøpsbeslutninger
Manual — manualer for konkret utstyr

IngestionLayer

Inntakslaget — håndterer AI-drevet parsing og strukturering av opplastede dokumenter. Brukes ved onboarding og ved opplasting av nye rapporter.

Pipeline: Upload → Parse → Extract → Structure → Validate → Approve → Persist

Kritisk prinsipp: AI fyller aldri databasen direkte. Flyten er alltid: AI foreslår → bruker godkjenner → system lagrer.

ExtractionJob — én kjøring av AI-ekstraksjon mot et Document
ExtractedFact — ett enkelt faktum med confidence, kilde og brukerhandling (approve/edit/reject)

Dette laget er midlertidig infrastruktur — etter godkjenning persisteres data til de ordinære lagene (SpatialModel, BuildingSystems, ConditionLayer etc.) og ExtractedFact-radene beholdes kun for audit og gjenopptak.

AILayer

Semantisk søk-, samtale- og produktmeta-lag — aktiveres i Fase 5. Inneholder tre entiteter:

ContentEmbedding — vektor-representasjon (gemini-embedding-001, 1536 dims MRL) av én entitet fra boligdatabasen. Indekseres via HNSW i pgvector. Brukes av hybrid-søk (cosine + full-tekst RRF) for å hente relevant kontekst til AI-assistenten (se ADR-016, ADR-017).
ConversationMemory — nøkkelfakta ekstrahert av AI-modellen etter en chat-sesjon og lagret for injeksjon i neste sesjon (se ADR-020). Minner er per bruker, ikke per eiendom.
UserFeedback — produktfeedback fanget via AI-assistenten (Spec 048). Strukturert backlog-input for videre produktutvikling. Ikke boligdata — indekseres ikke i hybrid-søk.

Laget er infrastruktur for AI-assistenten og er ikke direkte synlig for brukeren utenom indirekte effekter (bedre søk, kontekstuell hukommelse, produktforbedringer over tid).

Designprinsipper

Separasjon av begreper

Hvert lag representerer et distinkt perspektiv. Viktige skillelinjer:

Begrep A	≠	Begrep B
Property (tomt/adresse)		Building (fysisk bygning)
Issue (teknisk avvik)		ImprovementIdea (ønske)
Equipment (teknisk utstyr)		InteriorAsset (møbel/dekor)
Observation (erfaring)		Task (oppgave)
DesignDirection (prinsipper)		InteriorAsset (konkrete objekter)
BuildingSystem (kategori)		Equipment (konkret enhet)

Kildebevissthet

Alle entiteter som kan ha usikker informasjon skal ha:

source_type — takstrapport, egen observasjon, fagperson, måling, produktlenke
confidence — høy / medium / lav

Gradvis modning

Systemet er bygd for revisjon, ikke bare registrering. Designretninger, observasjoner og prioriteringer skal kunne endres uten å miste historikk.

Relasjonell struktur, ikke graph-database

Modellen er naturlig en property graph (noder og kanter), men implementeres i PostgreSQL med fremmednøkler. pgvector brukes for semantisk søk i AI-kontekst. Relasjoner er dokumentert i docs/domain/relations.md.

Planlagte fremtidige entiteter (Post-MVP)

Disse entitetene er identifisert gjennom brukerbehovsanalyse, men ikke en del av MVP. De er dokumentert her for å sikre at arkitekturen ikke låser dem ute.

Entitet	Lag	Behov	Avhengighet
`LightingPlan`	InteriorLayer	Lysberegning per funksjonssone i rom (lux/lumen)	Fase 5 — krever ProductCandidate
`ProductCandidate`	KnowledgeLayer	Strukturert produktevaluering med dimensjoner, stilscore og romtilpasning. Vurderes sammenslått med `InteriorAsset(considering)` — se ADR-008	Brave Search API
`ShoppingTracker`	KnowledgeLayer	Prissporing på produktkandidater med varsling ved prisfall	Krever bakgrunnsjobb + varslingsinfrastruktur
`LayoutOption`	InteriorLayer	Et av flere mulige layoutalternativer for ett rom, med pros/cons og score	Fase 5
`DesignScenario`	DesignLayer	Visuelt designalternativ med stilvariant, layoutvalg og bildegenererte referanser	Krever DALL-E 3-integrasjon
`ProjectEstimate`	PlanningLayer	Kostnads- og tidsestimat for et forbedringsprosjekt basert på historikk og standardverdier	Historikkdata fra MVP-bruk

Merk: Project som separat entitet er vurdert og forkastet til fordel for å utvide ImprovementIdea med strukturerte avhengigheter (ImprovementDependency). Se ADR-009.

Skalerbarhet

Modellen er designet for å skalere fra én husstand til mange:

Alle entiteter er knyttet til en property_id
Brukertilgang styres per eiendom
Multi-hus-støtte er arkitekturelt ivaretatt, men ikke aktivert i MVP