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 én eiendom med adresse, areal, byggeår og eierdata. Alle andre entiteter tilhører en eiendom. Grunnlaget for multi-hus-støtte.

SpatialModel

Den romlige modellen av boligen. Inneholder etasjer, rom, uteområder og støtterom. Dette er koordinatsystemet som alle andre lag refererer til.

BuildingSystems

Tekniske systemer som definerer boligens infrastruktur: varme, ventilasjon, vann, avløp, elektro, drenering, fasade og pipe. 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.

---

Designprinsipper

Separasjon av begreper

Hvert lag representerer et distinkt perspektiv. Viktige skillelinjer:

Begrep A	≠	Begrep B
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