AiM Kvalitetssäkring

Kraven i ett byggprojekt ligger utspridda i AMA, BBR, AFS, TDOK, svenska standarder och plan- och bygglagen. Att leta reda på vilken regel som gäller, och sedan dokumentera att den följts, är administration som tar tid från själva arbetet.

Där finns också fällan. Ett system som läser kraven åt dig sparar ingen tid om du ändå måste kontrollera varje svar. Då har arbetet bara flyttats.

Det kravet styrde hela arkitekturen: om systemet säger att något är verifierat ska det gå att visa vilken källträff statusen bygger på.

Användaren klistrar in en kravtext, laddar upp en PDF eller fotograferar ett dokument. En språkmodell extraherar krav och referenser ur underlaget.

Varje kravreferens går sedan genom en separat källgrind som slår upp den mot en källbas.

Modellens egen status används inte som verifiering. Verifierad status sätts av den separata, deterministiska källmatchningen.

Fyra flöden är byggda: arbetsberedning, egenkontroll, kontrollplan och kvalitetsredovisning.

Systemet kan exportera dokumenten som PDF med källstatus och härledning per krav.

1. Modellens egen bedömning är inte verifiering.

Modellen föreslår. En deterministisk uppslagning avgör källstatusen.

Modellens egen statusangivelse skrivs över av grindens resultat. Modellens egen konfidens används bara när resultatet fortfarande är en tolkning, och begränsas då.

Det enklare alternativet hade varit att behandla modellens egen säkerhet som ett mått på verifiering.

Det valdes bort.

En konfidenssiffra är inte en källhänvisning.

Samma princip styr hur status sprids genom systemet: ett fält får sin styrka från sin svagaste kod, aldrig från sin bästa träff.

Är tre av fyra referenser verifierade och den fjärde fortfarande en tolkning får den starkaste träffen inte maskera den svagaste.

2. Exakt och ankrad matchning, ingen fuzzy och ingen semantik.

Uppslagningen är deterministisk hela vägen.

Inga embeddings, ingen fuzzy-matchning och inget modellanrop används i själva matchningsledet.

Samma indata mot samma källbas ger samma resultat, och träffen går att härleda till regeln som satte statusen.

Semantisk sökning hade kunnat hitta fler närliggande träffar, men hade samtidigt introducerat ytterligare en bedömningsnivå i det led som ska avgöra om en referens faktiskt kan beläggas.

Här är målet inte att hitta något som liknar rätt källa.

Målet är att kunna visa varför en viss status sattes.

3. En människas intyg läggs ovanpå statusen, aldrig i stället för den.

En användare kan attestera ett krav manuellt.

Det skriver inte över källstatusen utan läggs som ett separat lager. Läsaren kan därmed skilja mellan vad systemets källgrind har kunnat belägga och vad en människa har gått i god för.

Källbasen versionsidentifieras. När ett sparat dokument öppnas kan dess källstatus bedömas om mot den aktuella basen.

Det betyder att en tidigare status inte behöver behandlas som permanent bara för att dokumentet en gång sparades.

Alternativet hade varit att frysa statusen vid skapandet och låta dokumentet behålla samma bedömning även när källunderlaget förändras.

Grön status betyder att källgrindens deterministiska regler har hittat en träff som uppfyller villkoren för verifierad status i en namngiven källa.

Det betyder inte att systemet juridiskt intygar att kravet är korrekt tillämpat i det aktuella projektet.

Den bedömningen ligger hos människan.

Modellen påverkar vilka krav och referenser som extraheras ur underlaget. Kvaliteten på extraktionen sätter därför ett tak för vad nästa steg i kedjan kan verifiera.

AI-genererade tolkningar av AMA-koder har en egen status och behandlas inte som officiell AMA-text.

Vi upplyser, vi intygar aldrig.

Tekniskt granskat mot kod och testsvit 2026-10-07.