Intertween.*

Gemensamt bygglovsflöde

290 kommuner hanterar bygglov, och de flesta bygger samma grund var för sig. Det här fallet utforskar hur en gemensam processmodell kan växa ur många kommuners verkliga ärenden, hitta de luckor som ingen enskild kommun ser och ge tillbaka det den har lärt sig.

Kandidat för test · Verkligt underlag och simulerad delning

Del 1 · Grunden

Kommunerna vill samverka men saknar en gemensam grund att stå på.

Förstudie · Sammanfattning

Bygg inte samma grund 290 gånger

En genomgång av 17 kommunala svar om AI inom bygglov visar ett tydligt glapp mellan vilja och förmåga. De flesta ser behovet av samverkan, men få har kapacitet att bygga själva. Fyra mönster återkommer: samverkan är rationell men svår att mobilisera, AI begränsas av informationsgrunden, leverantörerna är både en väg in och en låsningsrisk, och nätverk finns men ingen äger produkten.

Förstudien föreslår en modulär målbild: en gemensam kärna för regler, begrepp och dokumenthantering, lokal konfiguration för varje kommun, och professionell bedömning som alltid stannar hos människor. En föreslagen första pilot gäller saknade handlingar.

Läs förstudien: abstract och sammanfattning →
Utdrag

”Bygg inte samma grund 290 gånger. Bygg en gemensam kärna som kan konfigureras lokalt och förvaltas gemensamt.”

65 %positiva eller öppna för samverkan
41 %saknar satsning eller är i tidigt skede
29 %avböjer eller kan inte prioritera

Indikativa andelar i ett urval om 17 svar. Kategorierna överlappar.

”Det bygger på att det finns bra grunddata i form av exakt kartunderlag, säkra fastighetsgränser och digitaliserade detaljplaner.”kommun i undersökningen

Förstudien beskriver vad som behövs. Resten av fallet visar hur det kan fungera i praktiken, med Gemensamma flöden i Intertween och ett exempel som följer med genom alla steg.

Del 2 · Konceptet

Gemensamma flöden: en process, många lokala versioner.

Gemensamma flöden i Intertween kartlägger en process som många delar. Den gemensamma modellen lär sig av varje kommuns verkliga ärenden och delar med sig av det den har lärt sig. Varje kommun väljer själv vad den tar emot.

Varje kommun kan använda en godkänd gemensam version lokalt, lägga till egna regler eller också bidra till lärandet. Den gemensamma modellen samlar det som har godkänts. När flera lokala modeller jämförs syns en lucka som ingen kommun ensam kunde se.

Lär av alla

Den gemensamma modellen lär sig

Varje kommun bidrar med det den har lärt sig: en checklista, en ordförklaring, ett mönster i processen. Bidraget går genom kommunens grind. Råa ärenden stannar hemma.

Lär ut till alla

Kommunerna tar emot

Den gemensamma modellen ger tillbaka komponenter som andra redan har prövat. En liten kommun kan få en fullständighetskontroll som en stor kommun har byggt. Den lilla kommunen väljer själv om den vill införa kontrollen, vänta eller anpassa den.

Överbrygga luckor

Strukturella hål blir synliga

När många lokala processer läggs bredvid varandra syns luckorna: ett steg utan belägg, en överlämning som saknas, två ord för samma sak. Varje lucka blir en intertween, en markerad fråga som en människa tolkar.

En modell för allas bästa

Granskade bidrag från flera kommuner kan ge ett bredare underlag för dokumentigenkänning. Om stödet blir bättre behöver visas på undanhållna testärenden, även för små kommuner och svåra dokumenttyper.

Lokal användning, granskade bidrag

Ärendespecifika kontroller föreslås köras i en nod som kommunen kontrollerar. Den håller godkända versioner av kunskap och regler, processstatistik och dokumentigenkänning. Lokal träning är valfri.

Kunskapsobjekt, statistik och klassificerarbidrag granskas i separata flöden. Kommunerna kan även bidra med förberedda handlingar som träningsdata genom en särskilt godkänd dokumentväg. Avidentifiering ensam ger inte rätt att dela eller träna. Läs om bidragsvägarna →

Modellen är också ett kunskapsobjekt

En AI-modell med öppna vikter kan ingå i de gemensamma flödena på samma villkor som en checklista eller ett begrepp. Den är versionerad, har ett träningsmanifest och redovisar sina resultat per kommun. Skillnaden är att den lär sig av bidragen i stället för att bara samla dem.

Gemensam kärna

En versionerad dokumentklassificerare

Gemensamma komponenter kan återanvändas. Metod och utvärdering föreslås vara öppna; publicering av vikter prövas separat.

Lokal konfiguration

Ett lokalt tillägg per kommun

Kommunen använder en godkänd version och kan lägga till lokala regler och trösklar. Lokal träning är en ytterligare möjlighet som behöver prövas.

Professionell bedömning

Granskade rättelser blir kandidater

Det modellen är osäker på avgörs av en handläggare. En granskad rättelse kan bli ett märkt träningsexempel, om användningsvillkoren tillåter det. Kvaliteten måste visas i nästa utvärdering.

Kandidatversioner jämförs på samma undanhållna ärenden med förutbestämda kvalitetskrav. Otillräckligt underlag ger begränsad prövning. Release och lokalt införande kräver separata godkännanden i piloten. Mer om risker och skydd finns i avsnitt 8 i förstudien.

Förhållandet är ömsesidigt. Den gemensamma modellen står inte över kommunerna. Den erbjuder, och varje kommun bestämmer.

Del 3 · Sju steg

Från en hög handlingar till en gemensam förbättring.

Samma sju steg gäller för all kunskap i Intertween. Här följer vi ett exempel genom alla steg.

Exemplet

Saknade handlingar. En ansökan kommer in utan alla ritningar. Handläggaren begär komplettering och ärendet står still. Kommun 1 i labbet har verkliga ärenden där handlingar begärdes. Tänk dig en andra kommun som har en lista över vilka handlingar varje ärendetyp kräver. Kan deras kunskap bli en gemensam kontroll?

  1. 1

    Samla in

    Lokal loop

    Källor läses in där de finns: filer, ärendehändelser, listor och processbeskrivningar. Vid varje inläsning registreras vad som lästes, vilken version av anslutningen som användes och en kontrollsumma, så att inläsningen kan upprepas med samma resultat.

    I exemplet

    Kommun 1 läser in 18 skannade handlingar från 9 ärenden. Den andra kommunen läser in sin lista över krav på handlingar per ärendetyp.

    WrapperConnector
  2. 2

    Paketera

    Lokal loop

    Varje uppgift läggs i ett kunskapsobjekt: ett märkt kuvert med typ, källa, sida, version och vem som får använda det. Påståenden sorteras efter sin typ. En begäran är inte ett bevis på att något har gjorts.

    I exemplet

    En begäran om fasadritning med marklinjer blir ett krav med okänd status, kopplat till den sida där det står.

    {
      "type": "InformationRequirement",
      "item": "fasadritning med marklinjer",
      "satisfied": "unknown",
      "source": { "page": 1 }
    }
    WrapperKnowledge Object
  3. 3

    Mappa

    Lokal loop

    Lokala ord kopplas till gemensamma betydelser. Kopplingarna är förslag tills en människa har granskat dem, och en mappning får aldrig ge fler personer åtkomst till uppgiften.

    I exemplet

    Kommun 1 skriver ”Fasadritning”, den andra kommunen taggar ”Fasad”. Båda föreslås peka på samma dokumenttyp. ”Inkomstdatum” och ”Ankomstdatum” pekar på samma betydelse: datum mottaget.

    MapperMappingProposal
  4. 4

    Upptäck

    Lokal loop

    Processen tas fram ur daterade händelser i stället för att ritas för hand. Händelser som inträffat samma dag får ingen påhittad ordningsföljd. Där ett led saknar belägg skapas en lucka med möjliga förklaringar.

    I exemplet

    Ärendena går ofta tillbaka till ”väntar på komplettering”. I ett ärende begärs en ritning som aldrig syns igen. Det blir en * intertween: skickades den men arkiverades inte, eller skickades den aldrig?

    Gemensamma flödenintertween
  5. 5

    Observera

    Lokal loop

    Varje mått redovisar täljare, nämnare och urval. Jämförelser görs bara när definitionerna är desamma. Tiden mellan två händelser redovisas som kalendertid, inte som arbetstid.

    I exemplet

    Tre mått följs: andel ärenden som behöver kompletteras, kalendertid från begäran till svar och andel handlingar som går till manuell kö. I ett tidigt AI-projekt för klassning av bygglovsritningar gick 15 % till manuell kö.

    ObserverTracker
  6. 6

    Väg samman

    Gemensam loop

    Godkänd kunskap lämnar kommunen genom grinden. På den gemensamma nivån stäms lokala ord av mot varandra, och mönster och luckor jämförs mellan kommuner. Där syns också hur många oberoende kommuner som står bakom en komponent. Nio ärenden från en kommun räknas inte som nio bekräftelser.

    I exemplet

    Den andra kommunens fullständighetskontroll passerar grinden som ett bidrag. Den prövas mot kommun 1:s material: förklarar den de fyra begärda handlingarna? Tillåtna bidrag kan bilda en kandidat för dokumentigenkänning. Förberedda träningshandlingar kräver separat prövning; rutinmässiga lokala ärenden skickas inte till en central kontroll.

    GatewayTrackerFederation
  7. 7

    Publicera och inför

    Gemensam loop

    Förslagen samlas i en versionsrapport som beskriver vad som ändras och varför, med belägg och undantag. Automatiska kontroller prövar kandidaten mot fastställda kvalitetskrav. I piloten godkänner ansvariga releasen; avvikelser utreds före publicering. Sedan väljer varje kommun själv om den inför den.

    I exemplet

    Version 2 av den gemensamma modellen publiceras inom policyn och innehåller kontrollen. Kommun 1 inför den för nya ärenden. En tredje kommun väntar. Pågående ärenden ligger kvar på den version de startade med. En klassificerarkandidat prövas separat på undanhållna ärenden. Release kräver dokumenterade kvalitetskrav och godkännande; otillräcklig evidens ger begränsad prövning.

    Release serviceGemensamma flödenRegistry
Och sedan börjar det om

Det som händer efter införandet, till exempel fler eller färre kompletteringar, observeras igen i steg 5. Så slutar varje varv där nästa börjar.

Del 4 · Lärloopar och funktioner

Tre loopar driver lärandet. Tio funktioner bär dem.

Lärandet sker på tre nivåer som hänger ihop: i varje kommun, mellan kommunerna och efter att en förändring har börjat användas.

Lokal loop · steg 1–5

Kommunen lär känna sin egen process ur sina egna ärenden. Den hittar luckor och mönster och bestämmer själv vad som kan delas. Allt sker inne i kommunens nod.

Gemensam loop · steg 6–7

Godkända bidrag och mätvärden från många kommuner möts. Den gemensamma nivån stämmer av lokala ord mot varandra, jämför mönster när definitionerna stämmer och hittar luckor som ingen kommun ser ensam. Den arbetar självständigt inom en godkänd policy och rapporterar avvikelser.

Uppföljningsloop · 7 → 5, på båda nivåerna

Ett infört förslag är en hypotes tills utfallet har följts upp. Kommunen följer sina egna ärenden, och den gemensamma nivån följer hur versionen fungerade i alla kommuner som införde den. Observationerna kopplas till den version som faktiskt användes.

Självständig inom en godkänd policy

Avgränsade beräkningar och kandidatförslag kan köras inom en godkänd policy. I pilotförslaget granskas releaser uttryckligen, och ändrade dokumentkrav behöver ansvarig granskare. Varje körning pekar på policy och använda versioner.

Typ av förändringExempelHur den styrs
SjälvständigOmräknade mönster och vikter, nya kandidater till kategorier och kopplingar, uppdaterade jämförelser, analytiska versioner inom policynIngen godkänner i förväg. Allt loggas och syns i rapporter.
AvvikelseOväntad förändring i en fördelning, bruten kvalitetsgräns, bidrag som krockar, förslag att slå ihop två begreppJust den förändringen pausas. En avvikelserapport går till policyns ägare.
Alltid människaJuridisk tolkning, utökad åtkomst eller export, ändrad handläggning i en kommun, myndighetsbeslutKan aldrig delegeras till policyn
Avvikelserapporten
  • Vad som ändrades och mellan vilka versioner
  • Varför: belägg, motbelägg och hur säker bedömningen är
  • Vilken regel i policyn som tillät det, eller vilken gräns som bröts
  • Vilka kommuner och sammanhang som påverkas
  • Vem som äger policyn och vem som ska agera
  • Hur förändringen rullas tillbaka
Ansvar som går att följa upp
  • Policyn är versionerad och godkänd av en namngiven ägare
  • Den anger tillåtna förändringar, data, metoder, gränsvärden och övervakning
  • Den löper ut och måste förnyas
  • Insamling, delning och releaseflöde kan pausas var för sig
  • Varje kommun beslutar själv om den inför en ny version
Det som aldrig delegeras

Självständigheten gäller kunskapen och modellen, aldrig besluten i enskilda ärenden. Myndighetsbeslut om enskilda fattas av människor, i linje med förvaltningslagen och GDPR artikel 22. Avvikelserapporter, insyn och möjlighet att ingripa är föreslagna delar av tillsynen. Tillämpliga krav, roller och rättslig grund behöver prövas för piloten; arkitekturen visar inte i sig regelefterlevnad.

Se den gemensamma loopen steg för steg

Följ hur tre påhittade kommuner delar kunskap. Välj ett steg eller använd Nästa för att följa hela förloppet.

Lärsteg räknar illustrativa varv. V-numret visar godkänd release och lokalt införande.

Din webbläsare saknar stöd för visualiseringen. Följ samma förlopp med stegens textbeskrivningar.
Steg 1 av 6

Två kommuner, en enkel modell

Se innehållet i den gemensamma modellen

    Intertweens funktioner i fallet

    FunktionVad den görI exempletSteg
    WrapperLäser in källor och skapar kunskapsobjekt med källankare18 skannade handlingar blir objekt med sida och kontrollsumma1–2
    MapperFöreslår kopplingar mellan lokala ord och gemensamma betydelser. På gemensam nivå stäms förslagen av mellan kommuner”Fasadritning” och ”Fasad” blir samma dokumenttyp3, 6
    Gemensamma flödenHåller isär upptäckta, avsedda och lokala modeller och binder kommunen till en versionDen upptäckta processen jämförs med den gemensamma4, 7
    ObserverMätvärden, jämförelser och avvikelser med uttalade definitioner, lokalt och mellan kommunerLokalt: andel ärenden som behöver kompletteras. Gemensamt: samma mått jämfört mellan kommuner med samma definition5–6
    ObservatoryVyn där belägg, motbelägg, bidrag och utfall syns över tidHur många oberoende kommuner som står bakom kontrollen och vad som hände efter införandet6–7
    TrackerUrsprung, relationer, bidrag och återanvändningVem som bidrog med kontrollen och var den används5–6
    GatewayPrövar och loggar allt som lämnar nodenKontrollen passerar, men råa ärenden stannar kvar6
    FederationTillit mellan noder, leverans och återkallelseBidraget tas emot, verifieras och kan dras tillbaka6
    Release serviceVersionsrapport, avvikelserapport och aktivering inom autonomipolicynVersion 2 publiceras inom policyn, och ett förslag som krockar pausas som avvikelse7
    RegistryIdentitet, versioner och behörighetsstyrd sökningVarje version av kontrollen har ett eget idalla

    Kärnan som gör det möjligt

    Knowledge Object

    Allt delas i samma märkta kuvert: typ, ursprung, version och användningsvillkor.

    intertween

    En lucka eller oklar koppling som markeras och tolkas av en människa, i stället för att gissas bort.

    Versioner

    Varje modell och komponent har versioner. Ett beslut kan alltid kopplas till exakt den version som användes.

    Publicering och införande

    Att publicera och att införa är två olika beslut. Publiceringen sker inom den gemensamma policyn, medan införandet beslutas lokalt.

    Syfte och behörighet

    Samma regler gäller för sökningar, grafen, exporter och agenter. Ingen kan ge sig själv mer åtkomst.

    Mönster ≠ juridik

    Hur ofta något sker säger inget om vad lagen kräver. Juridisk tolkning har en egen granskning.

    Del 5 · Summering

    Vad som hände och varför det är viktigt.

    Vad som hände

    1. Två kommuners underlag blev märkt och spårbar kunskap utan att lämna kommunerna.
    2. Den verkliga processen togs fram ur händelserna, och en lucka blev synlig: en begärd ritning utan spår.
    3. Två lokala ord för samma sak fick en gemensam betydelse.
    4. En kommuns fullständighetskontroll blev en gemensam komponent och prövades mot en annan kommuns verkliga ärenden.
    5. En kandidat validerades och en release godkändes med spårbar policy och ägare. Avvikelser gick till en människa. Varje kommun valde själv om och när den skulle införa den.
    6. Utfallet följs upp och matar nästa varv.

    Vad det kan ge

    FörNytta
    SökandeTydligare krav från början och färre kompletteringsrundor
    HandläggareEn flygande start: underlag samlat och förslag med källor
    Varje kommunBehöver inte bygga grunden själv, och den egna datan stannar hemma
    Små kommunerAI-stöd tränat på många kommuners exempel, inte bara egna
    Alla kommunerEtt gemensamt språk för människa och AI, och jämförbar statistik

    Återanvändning kan minska dubbelarbete, men total kostnad behöver mätas. Lokal integration, säkerhet, support, drift och gemensam förvaltning ingår i pilotens kostnadsbedömning.

    Läget i dag

    • ✓Inläsning och paketering av verkliga handlingar
    • ✓Processupptäckt med luckor och korrigerade läsningar
    • ✓Simulerad delning, publicering och införande mellan tre kommuner
    • ○Riktiga, separata noder för olika kommuner
    • ○Juridiskt granskade regler och uppmätt effekt

    Nästa steg

    Test och validering tillsammans med ett kluster av kommuner, med saknade handlingar som första pilot. Efter kartläggning och databedömning fattas ett uttryckligt beslut om piloten är redo.

    Det som inte ingår

    Piloten stödjer handläggaren och fattar inga beslut. Inget i fallet bedömer enskilda medarbetare.

    Fyra sätt att vara med

    1. Nivå 1UtvecklaBidra med data, testmiljö och personal från verksamheten.
    2. Nivå 2ValideraGranska juridik, behov och resultat.
    3. Nivå 3RefereraDela processkartor och lokala variationer.
    4. Nivå 4AnslutaInför prövade komponenter när det passar.

    Uppdaterat lösningsförslag · 27 oktober 2026

    Tre delar som arbetar tillsammans

    Den gemensamma modellen föreslås bestå av kunskap och regler, processstatistik och dokumentigenkänning. Delarna får egna versioner och prövas var för sig. Det här utvecklar lösningsförslaget; det är inte ett nytt resultat från kommunundersökningen.

    Kunskap och regler
    Godkända begrepp, dokumentkrav och lokala villkor med källor. Statistik kan föreslå en granskning, men avgör inte vad lagen kräver.
    Processstatistik
    Observationer om förlopp, kompletteringar och ledtider. Lokal statistik kan jämföras med gemensamma mönster utan att varje kommun måste träna en modell.
    Dokumentigenkänning
    Ett klassificeringsstöd för exempelvis plan- och fasadritningar. Osäker klassning går till manuell granskning; en okänd handling räknas inte automatiskt som saknad.

    Ärendespecifika kontroller föreslås köras i en lokal nod som kommunen kontrollerar, med godkända komponentversioner och lokala regler. Kommunen kan ansluta, konfigurera eller också bidra till lärandet. Ett stort språkmodellstöd är valfritt.

    Lärande skapar kandidater. Validering, godkänd publicering och kommunens lokala införande är separata steg. I piloten föreslås uttryckligt godkännande före en release. Faktisk nytta, kvalitet och driftkostnad behöver mätas.

    Läs teknisk bilaga och pilotplan →

    Flödesprofil · Utkast 0.1 · 4 november 2026

    Bygglov som ett normstyrt flöde

    Bygglovsexemplet kan nu beskrivas med samma flödesmodell som andra verksamhetsflöden. Syftet är process: ärendet jämförs med tillämpliga normer, samtidigt som varje kommun behåller mandatet över bedömning och beslut.

    Syfte
    processNormstyrd handläggning
    Det som rör sig
    BygglovsärendetHändelser och tillstånd över tid
    Referens
    Tillämpliga kravLag, detaljplan och lokala beslut
    Observation
    ÄrendehistorikenHandlingar, kompletteringar och beslut
    Ansvar
    Kommunens mandatHandläggare och behöriga beslutsfattare

    Tre läsningar av samma historik

    Discovery
    Visar hur ärenden faktiskt rör sig och vilka mönster som återkommer, även när de inte finns i den beslutade modellen.
    Efterlevnad
    Jämför ett ärende med den norm och den flödesmodellversion som gällde vid tidpunkten. En avvikelse är en signal för granskning, inte ett automatiskt rättsligt omdöme.
    Förbättring
    Observationer kan bli kandidater till en ändrad kravkatalog eller flödesmodell. Cultivator föreslår, människor granskar och kommunen beslutar om lokalt införande.

    Varje ärende bör hänvisa till den flödesmodellversion som användes. En ny version ersätter inte historiken och ändrar inte äldre bedömningar i efterhand. Om en verifierad observation motsäger ett antagande kan berörda delar flaggas för översyn.

    Läs hela utkastet till Flödesprofil → · Se pilotkrav och teknisk bilaga →

    Möjlig vidareutveckling

    En gemensam modell som fler kan ansluta till

    Den gemensamma process- och kunskapsmodellen skulle kunna användas även från kommunernas verksamhetssystem, andra plattformar och AI-agenter. Studio föreslås bli arbetsytan där anslutningar, uppdrag och behörigheter kan hanteras.

    Förslaget är ett versionerat API för system och en MCP-anslutning för AI-assistenter och agenter. Båda använder samma verksamhetstjänster och åtkomstregler som Studio. Ärendespecifika frågor föreslås gå till kommunens lokala nod, med dess godkända versioner och lokala regler. Gemensamma kunskapsfrågor kan gå till en gemensam tjänst. Externa anslutningar behöver alltså inte arbeta genom webbgränssnittet. AI kan hjälpa till att tolka frågor och använda verktyg; åtkomsten kontrolleras av tjänsten vid varje anrop.

    Med rätt mandat skulle en anslutning kunna ställa källbundna frågor, hämta tillåten aggregerad statistik, bidra med handlingar som träningsdata för granskning och använda modellen som stöd för bedömningsutkast. Kommuner kan använda gemensamma komponenter utan lokal träning. Godkända handlingar och granskade exempel behövs som en separat bidragsväg för att utveckla och utvärdera dokumentigenkänningen. Originalen kan stanna lokalt; endast särskilt förberedda kopior eller utdrag med prövade användningsvillkor föreslås föras över. Bidrag ändrar inte modellen direkt. Lokala underlag behåller sina åtkomstgränser, och människor ansvarar för bedömningar och beslut.

    Detta är en möjlig vidareutveckling, inte en driftsatt integration. Läs om anslutningar, behörigheter och ett möjligt första pilotsteg i Studio →