Regelkjøring — deterministisk, hybrid og KI-vurdering⚓︎

Content Understanding svarer på hva står det i dokumentet. Regelmotoren svarer på hva betyr det for saken. Denne siden er brua mellom de to: hvordan fakta fra CU blir til et Regelresultat, og hva som faktisk skjer i de tre regeltypene.

Åpne i fullskjerm

Kommer du fra Content Understanding?⚓︎

Da kjenner du venstre halvdel allerede. Det som er nytt starter ved FactsExtractor:

Facts-objektet er altså ikke rå CU-output — det er et typet snapshot som regelkjøringen evalueres mot, og CU er bare den ene av to kilder som skriver inn i det.

CU leverer to ting, ikke bare felt⚓︎

Dette er lett å overse: fakta-bloben er ikke bare uttrekte feltverdier. Classifier-svaret gir to slags innhold, og CuFactsSelector beholder begge i samme blob:

Begge lander i FaktaSegment (Markdown + Fields) og videre på Facts-recorden: feltene som typede properties, markdownen som Documents[].Text. Ekstraktoren velger markdownen fra det segmentet som spenner flest sider — altså det kategoriløse contents[0] — og kjører den gjennom DokumenttekstRens før den legges på recorden.

Hvem leser hva, konkret:

• Deterministiske regeluttrykk leser aldri dokumentteksten. Ingen av de 60 seedede RulesEngine-uttrykkene refererer Documents eller .Text — de leser typede felt (facts.Tilbud, facts.Soknad, facts.Registerfakta). Teknisk kunne de: hele facts-objektet sendes inn som RuleParameter. Ingen gjør det i dag.
• KI-vurdering får hele markdownen. JudgmentEvaluator serialiserer hele Facts-objektet — inkludert Documents[].Text — som brukermelding. Det er derfor promptene sier «Inputen er et JSON-objekt med saksfakta, inkludert «Documents» … «Text» (markdown)».

Fakta kommer fra to kilder⚓︎

Registerfaktaene kommer opprinnelig fra Mimir (production.gold.*, bygget fra ERS), men regelkjøringen leser dem ikke fra Mimir direkte — den leser Sak-replikaen i Postgres, som ReplikaSync fyller én gang i døgnet. Gold er immutable etter morgenens ETL, så hyppigere synk finner ingenting nytt. Se Kildesystemer og ADR-016.

Navnene på registerfeltene er bevisst ASCII (Soknadsdato, ikke Søknadsdato) fordi de refereres direkte i RulesEngine-lambdauttrykk.

Én bryter i YAML avgjør regeltypen⚓︎

En regel er én YAML-fil under src/Enova.Kai.Application/Rules/<Virkemiddel>/regel-*.yaml. Feltet evaluering er hele valget:

RuleConfigurationSeeder mapper evaluering → RegelType ved seeding, og KindDispatchingRuleEvaluator er den eneste dispatch-en i runtime — en switch på regel.Kind. Alle tre grener returnerer samme RegelEvalueringsResultat.

Deterministisk — RegelType.Structured⚓︎

DefinitionJson er en Microsoft RulesEngine-Workflow (pakken RulesEngine, se Directory.Packages.props). Uttrykket er en System.Linq.Dynamic.Core-lambda som evalueres mot én RuleParameter med navnet facts:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "WorkflowName": "UtslippsfrieAnleggsmaskinerR32",
  "Rules": [
    {
      "RuleName": "AllOffersInNok",
      "SuccessEvent": "Met",
      "ErrorMessage": "Ett eller flere tilbud er prissatt i annen valuta enn NOK.",
      "RuleExpressionType": "LambdaExpression",
      "Expression": "facts.Tilbud.All(t => t.TotalSalesCurrency.Trim().ToUpper() == \"NOK\" || …)"
    }
  ]
}

Aggregering i RulesEngineEvaluator: kastet exception under evaluering → Verdict.Error; minst én feilet regel → Verdict.NotMet med sammenslåtte ErrorMessage-er; alle passerer → Verdict.Met.

Et deterministisk Met kan i tillegg nedgraderes til NotAssessed av ProvenanceGate når regelens Inputkontrakt krever felt som CU-provenansen aldri fylte — bedre «ikke vurdert» enn et «oppfylt» bygget på tomme felt.

Hybrid — RegelType.Hybrid⚓︎

Hybrid er ikke «litt LLM». Det er deterministisk først, LLM bare når det deterministiske svaret er tvetydig. DefinitionJson har tre deler:

1
2
3
4

public sealed record HybridDefinition(
    string Deterministic,   // RulesEngine-Workflow-JSON — kjøres først
    string FallbackWhen,    // lambda over facts — gater LLM-kallet
    JudgmentDefinition Judgment);

HybridEvaluator kjører i denne rekkefølgen:

1. Deterministisk tier kjøres alltid.
2. Ble det Met? Da er det svaret — med ett unntak: er konfidensen Low (svakt lest CU-felt), gjøres et uavhengig LLM-kall for å bekrefte. Enig ⇒ konfidens heves til High og avgjortAv: "deterministisk+llm-bekreftet". Uenig eller LLM-feil ⇒ det deterministiske Met står urørt.
3. Ble det ikke Met? Da evalueres FallbackWhen som en egen ett-regels gate. Er gaten ikke Met, er svaret et ekte deterministisk NotMet — og LLM-en kalles aldri.
4. Er gaten Met? Først da kjøres Judgment-delen, og resultatet merkes avgjortAv: "llm-fallback".

Gaten er poenget — den skiller «leste en verdi, den var for lav» fra «klarte ikke lese verdien»:

1
2
3

facts.Tilbud.Any(t =>
    (t.VehicleType == "elektrisk" || t.VehicleType == "hydrogen" || t.VehicleType == null)
    && t.MachineWeightKg == null)

Leste vi 1800 kg, er NotMet et ekte utfall og LLM-en er unødvendig. Er MachineWeightKg null, kan vekten stå i dokumentteksten i et format CU ikke traff — da er det verdt et LLM-kall. ReasonDetailTolker.LøsHybrid leser avgjortAv tilbake ut av ReasonDetail når flaten skal vise hvilken vei som faktisk avgjorde saken.

KI-vurdering — RegelType.Judgment⚓︎

1
2
3
4

evaluering: llm
prompt: |
  Du vurderer om … Svar KUN med ett JSON-objekt på denne formen: {…}
utdata: MaskinTerskelVurdering

Prompten ligger inline i regelen, ikke i et eget promptregister — én kilde, og den versjoneres sammen med regelen via Regel.Version (ADR-013).

JudgmentEvaluator bygger kallet slik:

utdata slår opp en type i JudgmentOutputRegistry. Typen implementerer IJudgmentOutput (IsMet, Reason), og kan i tillegg implementere:

• IJudgmentFaktakontroll — modellens egen dekningssjekk. Har den ikke vurdert nok fakta, degraderes svaret til Verdict.Error, ikke NotMet.
• IJudgmentUtfall — utdatatypen regner ut sitt eget Verdict, slik at den kan svare et ærlig NotAssessed.

Et gjennomgående mønster er LLM ekstraherer, C# bestemmer: TilbudGyldighet lar modellen hente ut gyldighetsperioder og sitat pr. tilbud, mens IsMet regnes ut deterministisk i C# fra det den fant. Samme deling brukes i DrivlinjeKlassifisering.

Felles resultatform⚓︎

Uansett regeltype:

1
2
3
4

record RegelEvalueringsResultat(
    RegelId RuleId, int RuleVersion, RegelType Kind, Verdict Verdict,
    string Reason, JsonElement? ReasonDetail, string? AiCallAuditRef,
    string? Modell = null, Overstyringsspor? Overstyring = null);

Verdict har fem verdier, og de tre siste er ikke synonymer:

AiCallAuditRef (respons-id) og Modell fylles kun på LLM-veiene. Per kjøring lagrer Regelresultat i tillegg FactsSchemaVersion, FactsSnapshotHash (SHA-256 av de serialiserte faktaene) og EngineVersion — det er de tre feltene som gjør en kjøring etterprøvbar i ettertid.

Rekkefølgen reglene kjører i⚓︎

workflow.yaml pr. virkemiddel er en graf av regelnoder som WorkflowGraphRunner går gjennom. Kanttyper: direct, conditional, fan_out, fan_in. Sentinel-nodene heter __start__ og __end__.

1
2
3

- from: [R-UAM-VALUTA-NOK]
  to: [R-UAM-MVA-SAMSVAR]
  type: direct

To ting er verdt å vite:

• fan_out-grener kjører parallelt, hver i sitt eget DI-scope — DbContext er ikke trådsikker. Den sekvensielle ryggraden deler ett scope.
• depends_on sparer penger. Blokkeres en node av en uoppfylt forutsetning, kortsluttes den til NotAssessed og evalueres aldri. Derfor henger R-UAM-MVA-SAMSVAR på valutaregelen: finner valutaregelen utenlandsk valuta, kjøres den dyre hybrid-/LLM- evalueringen aldri.

I tillegg gater ERS-status pr. node (ers_statuser i regelen) hvilke regler som er aktuelle i stadiet saken står i.

Den valgfrie nøkkelen dokumentpakke: søknad | sluttrapport | begge overstyrer hvilken dokumentpakke regelen får dokumenter fra — uavhengig av ERS-status. Uten nøkkelen følger pakkevalget stadiet (ErsStatuspolicy.DokumentpakkeFor). Brukes av de sju sluttrapporteringsreglene (ers_statuser: [5]) som likevel leser søknadsdokumentet, se ADR-022.

Hva som trigger en kjøring⚓︎

Regelkjøring er siste steg i worker-pipelinen, som lenkede TickerQ-jobber:

1
2
3
4
5
6
7

SakSeleksjon → FetchDocuments → ExtractDocument → Evaluation
                                                      │
                                          RunCaseWorkflowJob
                                                      │
                                    RunCaseWorkflowCommand (Mediator)
                                                      │
                                            WorkflowGraphRunner

RunCaseWorkflowJob er den durable inngangen — også for manuell re-trigger og BulkReevaluationJob. Se Bakgrunnsjobber og ADR-012.

Det finnes en andre inngang, EvaluateCaseCommand, som kjører alle anvendelige regler som flat liste uten graf. Den skiller seg på EngineVersion (RulesEngine/6.0.0 mot WorkflowGraphRunner/1.0.0) og brukes programmatisk, ikke fra pipelinen.

Drift av LLM-kallene⚓︎

Dekoratørstakken rundt IChatClient, innerst til ytterst:

AzureOpenAIClient → OpenTelemetryChatClient (token-telemetri) → ThrottlingChatClient (MaxConcurrentCompletions) → TokenBudgetChatClient (TPM-budsjett, kun når TokensPerMinuteBudget > 0) → RetryingChatClient.

RetryingChatClient retryer 429/503 inntil 6 forsøk, med eksponentiell backoff eller serverens retry-after-header — den lengste av de to.

Hvilken type skal jeg velge?⚓︎

1
2
3
4

Kan spørsmålet besvares ved å sammenligne verdier som allerede finnes i Facts?
├─ Ja, alltid            → deterministisk
├─ Ja, men verdien lar seg ikke alltid lese ut av dokumentet → hybrid
└─ Nei, det krever at noen leser og tolker dokumentteksten   → llm

Hybrid er riktig valg når kriteriet er skarpt men inputen er upålitelig — «minst 2000 kg» er ikke en skjønnsvurdering, men vekten står ikke alltid i et felt CU treffer. Er selve kriteriet skjønn («er dette i realiteten en signert kjøpekontrakt?»), er det llm.

Praktisk oppskrift for å legge til eller endre en regel ligger i regelmotor-regel-skillet i repoet.

Slik oppdaterer du diagrammet⚓︎

Diagrammet genereres fra en typet spec i repoet — ikke rediger HTML-fila direkte (den er ~700 kB generert output).

1. Rediger docs/sourcefiles/arkitektur/kai-regelkjoring.workflow.json.

2. Regenerer artefakten med archify-skillet:

   Bash
   1	node .claude/skills/archify/bin/archify.mjs deliver workflow docs/sourcefiles/arkitektur/kai-regelkjoring.workflow.json docs/publisert/arkitektur/diagrammer/kai-regelkjoring.html --quality showcase

3. Commit både spec-en og den regenererte HTML-fila.

Videre lesning⚓︎

• ADR-013 — hybrid regelmotor og workflow-orkestrering
• CU-analyzere — fra portal via git til worker
• Runtime-arkitektur — hvor regelmotoren sitter i systemet
• Bakgrunnsjobber — pipelinen som trigger kjøringen