dynamisk-rettsstat/skills/simuler/SKILL.md

name

description

simuler

Kjører modellens simuleringer i notatet Den dynamiske rettsstaten med egne forutsetninger: fra et spørsmål («hva om …») til en scenariofil, en kjøring, en tabell med nøkkeltall og tilbud om figur. Dekker styringen (forsinkelse, reaktivitet, MPC), parameterne, beslutningsreglene for påtale og budsjett, sjokk, tiltak (andel ledet utenom, mer kapasitet i domstolen) og sveip over én eller to parametere, og gjenskaper notatets figurer. Bruk når noen vil prøve modellen med andre forutsetninger, sammenligne regler eller tiltak, se hvor grensen for svingninger går, eller lage notatets figurer på nytt. Utløses av «hva om forsinkelsen er seks måneder», «hva om politiet blir mer effektivt», «kjør et scenario», «simuler», «sammenlign reglene», «sveip over», «hva skjer med et større sjokk», «lag figuren i notatet på nytt», «run a scenario», «simulate the model with other assumptions».

Kjør modellen med egne forutsetninger

Ferdigheten går fra et spørsmål om modellen til en kjøring: hva om forsinkelsen er lengre, sjokket større, kapasiteten kommer tidligere eller beslutningsreglene er andre? Den skriver spørsmålet som en scenariofil, kjører modellens simuleringer i notatet Den dynamiske rettsstaten (avsnitt 8) med kjernens kode uendret, og viser nøkkeltallene. Den trenger Python 3 med numpy og scipy.

Brukeren kan være forsker eller arbeide i straffesakskjeden. Snakk vanlig norsk. Nevn ikke filnavn, kommandoer, feltnavn eller JSON med mindre brukeren spør etter dem, eller viser at de kjenner dem.

Regler

• Finn aldri på et tall. Forutsetningene er brukerens eller notatets. Alt scenariofila ikke setter, er notatets verdier; si hvilke som er brukt når det betyr noe for svaret.
• Vis scenarioet med ord, og få et ja før du kjører.
• Velg aldri på brukerens vegne hvordan en endret grunnparameter skal behandles (trinn 2).
• Gjengi skriptets tall ordrett. Regn aldri om, avrund aldri annerledes og «forbedre» aldri et tall. Vil brukeren vite hva som skjer med andre forutsetninger, endrer du scenarioet og kjører på nytt.
• Si hver gang at parameterne er notatets stiliserte verdier, ikke kalibrert på norske data, og at kjøringene viser modellens dynamikk, ikke prognoser.
• Installer aldri noe uten å spørre. Det gjelder også et bibliotek for figurer.

1. Finn ut hva som skal sammenlignes

Spør hva brukeren vil vite, med vanlige ord: hva skal endres, hva skal det sammenlignes med, og hva vil brukeren se på (kriminalitet, tillit, saksbehandlingstid, kø, kapasitet, andel ledet utenom, politiets innsats)? Ett spørsmål om gangen.

Oversett så spørsmålet til modellen. Les ${CLAUDE_PLUGIN_ROOT}/docs/scenarioformat.md før du skriver en scenariofil første gang: den sier hvilken simulator som dekker hva, hvilke felt og parametere som finnes, hva som er tillatt, og hvordan sveip virker. For hva en parameter betyr, hvilken ligning den står i og notatets verdi, les ${CLAUDE_PLUGIN_ROOT}/docs/modellkart.md. Gjengi ikke dokumentene for brukeren; bruk dem til å velge.

Et sveip er ofte det brukeren egentlig spør om: «hva om forsinkelsen er 3, 6 eller 11 måneder» er én kjøring med tre verdier, side om side. To parametere gir et rutenett.

Utgangspunkter som følger med. Tilby dem når de passer, og si hva de er. De ligger i ${CLAUDE_PLUGIN_ROOT}/eksempler/scenarioer/:

Fil	Spørsmål
avviklingstid_koordinert.json	hvor raskt bør restansen avvikles i den koordinerte regelen (fra 6 til 96 måneder og aldri)?
stabilitet_reaktivitet_forsinkelse.json	hvor går grensen for svingninger, over reaktivitet og forsinkelse?
sjokkstorrelse_kjede.json	hvor mye betyr størrelsen på sjokket når domstolen er en flaskehals?
kvalitetssloyfe.json	hva gjør kvalitetssløyfen med desentraliserte og koordinerte regler?
utvidelse_bolge.json	hva etterlater en forbigående bølge i kriminalitetspresset, med og uten flaskehals?
uten_sjokk_kjede.json	hvor mye driver modellen med kø i domstolen av seg selv, uten sjokk? Nullinjen for små virkninger (trinn 5)

I undermappa notatet/ ligger 21 scenariofiler som til sammen lager 20 av notatets 22 datafiler på nytt, det figurene i notatet tegnes fra (regimene i figur 4, scenario 1–5 med domstolen, robusthet, vippepunkt og de endogene reglene; de to siste datafilene er regnet analytisk, ikke simulert). Med dem kan brukeren se nøyaktig hvilke forutsetninger en figur i notatet bygger på, og endre én av dem. Tabellen i docs/scenarioformat.md («Eksempelfilene») sier hvilken fil som gir hvilken av notatets datafiler.

Eksemplene kjøres direkte fra pluginen. Skal et eksempel endres, kopierer du det til brukerens arbeidsmappe først og gir kopien et nytt navn.

2. Vis scenarioet og få et ja

Beskriv scenarioet med ord før du kjører:

• Hva som varieres, med verdiene (for eksempel «forsinkelsen i politiets styring: 3, 6 og 11 måneder»).
• Hva som holdes fast: modellen (for eksempel «domstolen som ledd med kø, avsnitt 8.2»), og hva som er notatets verdier (styring, sjokk, parametere, regel).
• Over hvor mange måneder, og hvor mange kjøringer det blir.

Når spørsmålet endrer en grunnparameter. Noen av parameterne bestemmer utgangspunktet modellen starter i: for eksempel politiets effektivitet (gamma), tilliten ved start, innsatsen ved start, det strukturelle pådraget og den naturlige avgangen (hele listen står under «startlikevekt» i docs/scenarioformat.md). «Hva om politiet blir 20 % mer effektivt» er en slik endring. Da står modellen ikke lenger i ro ved start, og uten et valg stopper kjøringen med en melding om det. Forklar de to veiene med vanlige ord, og la brukeren velge:

• Start i ro med de nye verdiene ("startlikevekt": "kalibrer"): utgangspunktet regnes om slik notatet kalibrerer sitt, så modellen starter i balanse også med den nye verdien. Da sammenlignes to verdener som begge starter i ro, og det er sjokket og tiltakene som skiller dem. Sammendraget sier hvilke verdier som ble regnet om, fra hva og til hva.
• Start i notatets utgangspunkt med den nye verdien ("startlikevekt": "ubalanse"): modellen begynner å bevege seg før sjokket kommer, fordi utgangspunktet ikke lenger passer. Det viser hva endringen gjør med en kjede som var i balanse. Sammendraget sier hva som er ute av balanse, og hvor langt modellen har drevet fram til sjokket.

Velg aldri selv. Vet du før kjøringen at spørsmålet endrer en grunnparameter, spør med en gang; stopper kjøringen med meldingen, spør da.

Beslutningsreglene for påtale og budsjett (simulate_endo) tåler ikke en annen strøm av saker ved start: der stopper kjøringen uansett valg når politiets effektivitet, tilliten, innsatsen ved start, eta eller ksat endres. Si det rett ut: i den modellen er det en endring i kjernen, og det er ferdigheten forbedre. Den koblede modellen uten beslutningsregler (simulate_chain) kan ofte svare på det samme spørsmålet; tilby den.

Spør: «Skal jeg kjøre dette?» Kjør ikke før brukeren har sagt ja. Spørsmålet står alene til slutt og skal kunne besvares med ja eller nei. Legg ikke et valg mellom varianter inn i det («de tre, eller alle fire?»): da er «ja» ikke lenger et svar, og kjøringen blir stående. Forslag til flere kjøringer kommer etter svaret, i trinn 7.

3. Skriv scenariofila

Skriv scenarioet som en JSON-fil i brukerens arbeidsmappe, med et kort navn uten mellomrom og en beskrivelse som sier spørsmålet med vanlige ord (den står øverst i sammendraget). Feltnavnene skrives nøyaktig som i docs/scenarioformat.md. Har brukeren valgt hvordan utgangspunktet skal behandles, står valget i startlikevekt. Finnes fila fra før, spør før du overskriver den. Gi en ny variant et nytt navn, så resultatet fra forrige kjøring blir stående.

4. Kjør

python3 "${CLAUDE_PLUGIN_ROOT}/modell/kjor.py" --data "${CLAUDE_PLUGIN_DATA}" scenario <fil> --ut <mappe>

• På Windows heter tolken python.
• <fil> er hele stien til scenariofila. <mappe> er resultater/<navn> i brukerens arbeidsmappe, med hele stien. Finnes mappa med et tidligere resultat fra kjøreren, erstattes de filene; andre filer blir stående. Finnes den med andre filer og uten et slikt resultat, stopper kjøreren uten å skrive noe.
• Bruk pluginens modell, med mindre brukeren har valgt en egen versjon (se under).
• Et scenario med noen få kjøringer tar noen sekunder. MPC er klart tregere, og et rutenett med mange kjøringer tar tilsvarende lenger.

En egen versjon av modellen. Har brukerens arbeidsmappe en mappe rettsstat-modell/ med modell/kjor.py inni, bruk den ikke uten å spørre: «Jeg ser en egen versjon av modellen i rettsstat-modell. Skal jeg bruke den, eller pluginens?» Velger brukeren den egne, kjør kontrollen på den først:

python3 "${CLAUDE_PLUGIN_ROOT}/modell/kjor.py" --data "${CLAUDE_PLUGIN_DATA}" --modell <hele stien til rettsstat-modell/modell> kontroll --rask

Si nivået til brukeren før du legger fram noe tall: linja som begynner med «Nivå» («bit for bit som notatet» eller «endret: …»). Kjør så scenarioet med --modell <hele stien til rettsstat-modell/modell> før scenario. Er versjonen endret, si sammen med svaret at tallene kommer fra brukerens egen versjon av modellen, ikke fra notatets.

Exit-koder:

• 0: kjøringen er gjort. Gå til trinn 5.

• 3: numpy eller scipy mangler. Si i én setning: «Simuleringene trenger to vanlige regnebiblioteker for Python, numpy og scipy. Skal jeg installere dem i en egen mappe for denne pluginen?» Installer bare hvis svaret er ja:

  python3 "${CLAUDE_PLUGIN_ROOT}/modell/kjor.py" --data "${CLAUDE_PLUGIN_DATA}" miljo --opprett
  

  Gjengi det kommandoen sier (blant annet om versjonene av numpy og scipy er notatets), og kjør på nytt. Feiler installasjonen, gjengi meldingen og si at diagnosen fortsatt kan brukes uten tilleggene.

• 2: skriptet har stoppet med en melding, og ingenting er skrevet. Les den:

  • Feil i scenariofila … startlikevekt: startpunktet er ikke en likevekt …: en grunnparameter er endret. Gjengi hva meldingen sier er ute av balanse, med vanlige ord, og la brukeren velge en av de to veiene i trinn 2.
  • Feil i scenariofila … parametere.P: simulate_endo i kjernen bruker 0,1 …: beslutningsreglene tåler ikke endringen (trinn 2). Det er en endring i kjernen; tilby simulate_chain eller ferdigheten forbedre.
  • Feil i scenariofila … ellers: meldingen nevner feltet og de gyldige verdiene, og foreslår det nærmeste ved en skrivefeil. Gjengi den med vanlige ord, rett fila, vis endringen og kjør på nytt. Er det brukerens forutsetning som ikke er tillatt (for eksempel en andel over 1), spør hva som var ment.
  • … er ikke gyldig JSON: rett fila og kjør på nytt.
  • Kjøringen … stoppet i kjernen eller Kjøringen … ga verdier som ikke er endelige tall: kombinasjonen av forutsetninger gir en regnefeil i kjernen eller en løsning som vokser over alle grenser. Si det med vanlige ord, og hvilken kjøring det gjaldt. Endre aldri en forutsetning bare for at kjøringen skal gå; spør brukeren.
  • --ut: mappa … finnes og har filer … eller Kan ikke skrive i …: velg en annen mappe og si hvilken.
  • Uventet feil i …: en feil i koden, ikke i scenarioet. Gjengi meldingen og si at kjøringen ikke ble gjort.

• Annen kode, eller python3 finnes ikke: gjengi meldingen og si at kjøringen ikke ble gjort. Gjett ikke på et svar.

5. Presenter svaret

1. Vis nøkkeltallene slik skriptet skrev dem. Kjøreren skriver sammendraget til skjermen og til sammendrag.md. Vis tabellen (eller tabellene) under «Nøkkeltall» uendret, med avsnittet «Slik leses tallene» under, og for beslutningsreglene budsjettvedtakene. Ikke avrund, regn om eller formater tallene på nytt, og ta ikke bort rader. Er tabellen svært stor, vis radene brukeren spurte om, og si hvor resten står.

2. Gjengi det sammendraget sier om utgangspunktet og om kjøringen, ordrett:

   • de omregnede verdiene, når utgangspunktet er kalibrert på nytt («Referansetilstanden er kalibrert på nytt …»);
   • linjene under «Slik har modellen drevet før sjokket»;
   • linjene under «Merknader (kjøringen er ikke stoppet)», for eksempel at kriminaliteten går langt utenfor området modellen er laget for, eller at sjokket kommer etter slutten av kjøringen. Si hva det betyr for hvor mye tallene kan brukes.

3. Les tabellen med vanlige ord, kort: hva endringen gjør i modellen, i hvilken retning og hvor mye, med skriptets tall. Pek på det som er verdt å se: høyeste mot slutt (har forløpet funnet en ny balanse?), vedvarende svingning (spennet de siste 60 månedene), saksbehandlingstid og tillit, og kapasitet og andel ledet utenom der de endres. Køen i domstolen står i måneder av innstrømningen før sjokket (4,6 betyr at køen tilsvarer 4,6 måneders saker inn), ikke i antall saker. Si ikke mer enn tallene viser.

4. Driften i modellene med kø. Modellene der domstolen har kø (den koblede modellen, modellen med to sakstyper, beslutningsreglene og utvidelser med kjede), står ikke helt i ro ved start, heller ikke med notatets verdier: det som faller fra køen, blir aldri trukket fra kriminaliteten, så kriminaliteten og saksbehandlingstiden kryper sakte oppover også uten sjokk. Sammendraget viser hvor langt fram til sjokket. Er virkningen brukeren ser på liten, tilby å sammenligne med en kjøring uten sjokk med samme parametere og horisont ("sjokk": {"faktor": 1}; for notatets koblede modell over 240 måneder er det uten_sjokk_kjede.json), og si at driften må trekkes fra før virkningen tolkes.

5. Forbehold som alltid tas med:

   • Parameterne er notatets stiliserte verdier (tabell 3 i notatet), ikke kalibrert på norske data, unntatt det scenarioet setter selv. Kjøringene viser modellens dynamikk, ikke prognoser. Rekkefølgen og retningen er poenget, ikke nivåene.
   • Kø, strøm og kapasitet er normaliserte størrelser, ikke saker eller årsverk. 1,00 er nivået ved start.
   • Bare ett ledd har kø i modellen (domstolen); politi, påtale og kriminalomsorg har ikke kø.

   Ta i tillegg med det som gjelder dette scenarioet, fra ${CLAUDE_PLUGIN_ROOT}/docs/forbehold.md (for eksempel at beslutningsreglene er stiliserte, eller at andelen som kan ledes utenom er et rettspolitisk valg).

6. Si hvor filene ligger: sammendraget, én CSV-fil per kjøring (én rad per måned) og resultat.json med alle parametere slik de ble brukt, versjonene og sjekksummene. Samme scenariofil gir samme filer, så kjøringen kan etterprøves.

6. Tilby en figur

Spør: «Vil du se dette som en figur?» Lag den bare hvis svaret er ja.

• Bruk tallene kjøringen skrev, uendret: CSV-filene i resultatmappa (med "format": "notat" er det .dat-filer, med mellomrom mellom feltene). Regn ikke ut nye størrelser for figuren, og glatt ikke kurvene.
• Lag figuren slik miljøet tillater uten å installere noe: med et plottebibliotek som allerede finnes, eller som en tegning du lager selv (for eksempel SVG eller en HTML-side). Mangler alt, spør før du installerer noe.
• Én kurve per kjøring, med kjøringens navn fra sammendraget i forklaringen (for eksempel «forsinkelse=6»).
• Aksene på norsk: «Tid (måneder)» og størrelsen, for eksempel «Kriminalitet K», «Tillit», «Politiets innsats T», «Saksbehandlingstid i domstolen (måneder)», «Kapasitet (1,00 = ved start)» eller «Andel til domstolen». Hva kolonnene betyr, står i docs/scenarioformat.md («Tidsseriene per modell»). Køen Q i CSV-filene er i modellens enheter, ikke i måneder som i sammendraget; kall aksen «Kø i domstolen (modellens enheter)».
• Ta med forklaringen på hva 1,00 betyr under figuren, slik sammendraget skrev den for denne kjøringen («Slik leses tallene: …»; den er annerledes for modellene med kø og når utgangspunktet er ute av balanse). Skriv i tillegg at tallene er modellens stiliserte dynamikk, ikke prognoser.
• Lagre figuren i resultatmappa og si hvor den ligger.

Hva scenariokjøreren ikke gjør

Si det rett ut når spørsmålet ligger utenfor:

• Egne tall i saker per måned (innstrømning, kapasitet og restanse per ledd) hører hjemme i ferdighetene diagnose (leddet som binder) og forlop (forløpet måned for måned med tallene dine). Scenariokjøreren bruker modellens normaliserte størrelser.
• En mekanisme modellen ikke har (for eksempel kø i flere ledd, målestøy, forskyvning mellom kategorier) kan ikke settes inn med en parameter. Den legges til som en utvidelse; det er ferdigheten forbedre.
• En annen startstrøm i beslutningsreglene (trinn 2) er en endring i kjernen, ferdigheten forbedre.
• Ingen kjøring kalibrerer modellen mot norske tidsserier eller lager prognoser.

7. Neste steg

Tilby det som passer:

• en variant med én forutsetning endret, kjørt med nytt navn og vist ved siden av den første, med skriptets tall;
• et sveip over forutsetningen brukeren er mest usikker på;
• en kjøring uten sjokk som nullinje, når virkningen er liten;
• notatets scenariofil for samme figur, for å se forskjellen mot notatets forutsetninger;
• ferdigheten forbedre, hvis spørsmålet krever en mekanisme modellen ikke har.