From knowledge to action

Executive thesis

Datahearts mest bärkraftiga roll är inte att bli ännu en workflowmotor, agentplattform eller reverse-ETL-produkt. Det bör vara kundens styrande kontrollplan för en obruten verksamhetskedja:

flowchart LR
    A["Observation"] --> B["Business interpretation"]
    B --> C["Recommendation or decision"]
    C --> D["Authorization and approval"]
    D --> E["Action gateway"]
    E --> F["External effect"]
    F --> G["Verification or compensation"]
    G --> H["Measured outcome"]
    H --> B

Den vendor-neutrala kärnan bör vara ett kundägt action episode: ett versionsbeständigt ärende som binder samman trigger, evidens, beslut, behörighet, mänskligt ställningstagande, exekveringsförsök, faktisk effekt, kompensation och utfall. Microsoft- respektive self-hostedprofilen realiserar samma kontrakt med olika produkter.

Fyra slutsatser är särskilt viktiga:

1. En rekommendation eller ett godkännande är inte en auktorisation att verkställa för all framtid. Action gateway måste återkontrollera identitet, policy, tillstånd och preconditions precis före varje skrivning.
2. “Exactly once” kan normalt inte garanteras över heterogena externa system. Målet är verifierbart “at most one business effect” genom idempotensnyckel, versionsvillkor, kvitto och avstämning.
3. Human-in-the-loop är en organisationsdesign, inte en knapp. EU AI Act kräver effektiv, riskproportionerlig tillsyn för high-risk AI; forskning visar samtidigt att mindre erfarna användare kan vara mest utsatta för automation bias. EU AI Act, artikel 14, Kücking et al. 2024
4. Process mining visar vad loggen registrerade, inte automatiskt vad som orsakade ett bättre utfall. Closed-loop learning kräver experimentdesign eller explicit kausal analys.

State of the art 2024-2026

Bedömning	Tillstånd 2026-08-23	Betydelse
Established practice	BPMN 2.0.2 för processutbyte; DMN 1.5 för beslut; durable workflow, user tasks, timeouts, retries, sagas, outbox/inbox, dead-letter queues, OAuth/OIDC, API gateways och policy enforcement	Stabil bygggrund, men standardiserad notation innebär inte portabel runtime-semantik
Established practice	CloudEvents som interoperabel event-envelope och IEEE XES 1849-2023 för traditionella eventloggar	Bra transport- och analyskontrakt, men varken auktorisation, leveransgaranti eller affärseffekt ingår
Emerging practice	OCEL 2.0 och object-centric process mining	Bättre för processer där samma händelse berör exempelvis kund, order, leverans och faktura; fortfarande högre modellerings- och verktygskostnad
Emerging practice	Prescriptive process monitoring med kausal effektmodellering, resursbegränsade interventionspolicys och outcome learning	Lovande, men ännu inte en generell autonom optimeringsmekanism
Emerging practice	Kontinuerlig behörighetsomprövning och säkerhetssignaler över systemgränser	Viktigt för långlivade action episodes, eftersom roller, risk och sessionstillstånd kan ändras efter ett godkännande
Vendor claim	Microsoft Fabric Activator kan upptäcka tillstånd i strömmar och utlösa Power Automate- eller Fabric-aktiviteter	Användbar Microsoft-native detektor, men inte ensam en transaktions- eller governance-gräns
Vendor claim	Reverse-ETL-leverantörer beskriver lagret som operativ “source of truth” och synkar modeller till CRM/SaaS	Praktiskt för bulkberikning; olämpligt som enda mekanism för riskfyllda eller irreversibla handlingar
Hypothesis	Ett eget action-episode-kontrakt och action gateway kan göra workflow-, approval- och connectorval utbytbara	Stark arkitekturhypotes, men måste bevisas genom profilövergripande conformance- och migrationsprov

Viktiga förändringar under perioden:

• DMN 1.5 blev formell standard i augusti 2024; DMN 1.7 är fortfarande beta. BPMN 2.0.2 från 2014 är fortsatt den formella BPMN-versionen. OMG BPMN, OMG DMN
• Fabric Activator gick GA i november 2024. Microsoft dokumenterar samtidigt bland annat 10 000 inkommande event per sekund och regel, stopp av regeln vid överskridande, begränsningar i deployment pipelines samt beroende av den användare som äger vissa Power BI-ingestioner. Det är driftvillkor, inte bara produktdetaljer. Fabric Activator limitations
• Power Automate har användbara first/all/sequential approval-mönster och lagrar approvaldata i Dataverse, men en enskild cloud-flow-run inklusive väntande approvals har en dokumenterad maxlängd på 30 dagar. Flowens prestandaprofil följer dessutom dess ägare. Power Automate approvals, Power Automate limits
• IEEE XES reviderades 2023. OCEL 2.0 publicerades 2024 som community specification för objektcentrerade loggar; dess egen specifikation beskriver hur traditionell flattening kan ge missvisande analyser. IEEE 1849-2023, OCEL 2.0 specification
• 2025 års forskning flyttade processrekommendationer närmare kausala interventionspolicys, men resultaten bygger fortfarande på avgränsade eventloggar och antaganden om confounding. Eshuis & Genga 2025

Load-bearing concepts

1. Action episode

Minsta bärande modell bör omfatta:

• episode_id, kund/tenant och berörda verksamhetsobjekt.
• Trigger-event, eventtid, källsystem, schema- och semantic-version.
• Evidensreferenser och hash över det underlag som visades.
• Rekommendation eller beslutsresultat, modell/rule-version och osäkerhet.
• Begärd handling, avsikt, förväntad effekt och riskklass.
• Initierande principal, verkställande principal/service och delegation chain.
• Policybeslut, policyversion, obligations och beslutstid.
• Approval: vem/roll, vilket underlag, beslut, skäl, delegation, jävskontroll och expiry.
• Target, adapterversion, idempotensnyckel, precondition/ETag och kompensationsplan.
• Varje dispatchförsök, target-kvitto, observerad effekt och avstämningsresultat.
• Outcome-definition, mäthorisont, experimenttilldelning och observerat utfall.

Tillstånd bör skilja på exempelvis proposed, awaiting-approval, authorized, dispatching, effect-observed, compensating, manual-repair, outcome-pending och closed. “Flow succeeded” får inte vara synonymt med “verksamhetseffekt bekräftad”.

2. Event, command, task, approval och effect

Dessa måste vara separata typer:

• Ett event säger att något har observerats.
• Ett command uttrycker en önskad förändring.
• En task allokerar arbete.
• Ett approval uppfyller en specificerad beslutspunkt.
• Ett receipt visar vad målgränssnittet accepterade.
• Ett effect-event visar vad som faktiskt blev sant.
• Ett outcome visar om verksamhetsmålet förbättrades.

CloudEvents standardiserar eventbeskrivning, men lämnar leverans, autentisering, behörighet och affärssemantik till andra lager. CloudEvents specification

3. Samma behörighetskedja utan samma credential

“Kedjan följer med” bör betyda att originator, acting service, ändamål, delegation och policybeslut förblir korrelerade. Det bör inte betyda att ett långlivat bearer-token återanvänds.

Vid dispatch ska gatewayn:

• Skaffa ett nytt kortlivat target-token, eller använda kontrollerad on-behalf-of-delegation.
• Kontrollera nuvarande access, separation of duties, action risk och ändamål.
• Kontrollera om tidigare approval fortfarande gäller för exakt denna payload och version.
• Avbryta vid policy-, evidens- eller resursförändring.

RFC 9700 sammanfattar aktuell OAuth 2.0 security best practice och avråder från flera äldre flöden. RFC 9700, januari 2025

4. Action gateway

Alla externa writes bör gå via en liten, explicit gatewayyta. Den ska inte vara en generell integrationsplattform utan en enforcement point med:

• Tillåtna action types och schemas.
• Policy decision point och deny-by-default.
• Payload- och destinationsvalidering.
• Risk-, belopps-, frekvens- och blast-radius-gränser.
• Preconditions och optimistic concurrency.
• Idempotensregister per mål och affärshandling.
• Dry-run/preview där mål-API:t tillåter det.
• Kvitto, verification probe och reconciliation.
• Automatisk eller manuell kompensation.
• Kill switch per action type, kund, process och adapter.

5. Human-in-the-loop som verksamhetskontroll

Ett korrekt approval-gränssnitt behöver visa:

• Vad systemet observerade och vad som är osäkert.
• Föreslagen handling, alternativet att avstå och förväntade konsekvenser.
• Exakt vad som kommer att skrivas, till vilket system och när.
• Policygrund och eventuella konflikter.
• Möjlighet att ändra, skjuta upp, eskalera och överklaga.
• Tid till expiry samt vad som händer vid uteblivet svar.

Högriskfall behöver ofta dual control eller oberoende granskning. Självgodkännande, delegering till samma organisatoriska linje och massgodkännande bör vara särskilt testade. Den empiriska automation-bias-studien med 210 deltagare fann att icke-specialister både kunde ha mest nytta av beslutsstöd och vara mest benägna att följa felaktiga rekommendationer. Kücking et al. 2024

6. Durable orchestration och kompensation

Durable workflow är etablerat för långlivade processer, men gör inte externa writes atomära. Sagan ska därför modellera:

• Kompenserbara steg.
• En explicit pivot/point of no return.
• Idempotenta steg efter pivot.
• Alternativ forward recovery.
• Manuell reparationsväg.
• Även kompensationens fel, retries och kvitton.

En kompensation återställer sällan exakt det ursprungliga läget; andra transaktioner kan ha inträffat. Microsofts egen arkitekturguidning betonar domänspecifik kompensation, idempotens, checkpoints och möjlighet till manuell intervention. Compensating Transaction pattern

7. Business cadence

Event-driven får inte betyda att allt ska ske omedelbart. Varje loop behöver en kontrollkadens:

• Real-time: säkerhetsincidenter, fysisk drift, lagerbrist.
• Intra-day: serviceärenden och kundinterventioner.
• Dag/vecka: prioritering av säljarbete, inköp och kvalitetsuppföljning.
• Månad/kvartal: policies, resursallokering och modelländringar.

Cadencen behöver backpressure, arbetstidskalender, SLA, review-kapacitet, hysteresis, suppression och max antal öppna action episodes. Annars omvandlas bättre detektion till alert fatigue och längre verklig responstid.

8. Outcome learning

Outcome bör deklareras när actiontypen versioneras, inte väljas efter att resultatet blivit känt. Logga även:

• Fall där ingen handling gjordes.
• Avslag, overrides, avbrutna actions och manuella åtgärder.
• Fördröjda eller saknade utfall.
• Samtidiga interventioner.
• Vilken policy eller experimentarm som valde handlingen.

Process mining och predictive scoring räcker inte för att tillskriva effekt. Randomiserade holdouts, stepped-wedge-utbyggnad eller kausala estimators behövs där randomisering inte är möjlig.

Reference patterns

Vendor-neutral invariants och profilval

Lager	Vendor-neutral invariant	Microsoft-native profil	Self-hosted/open profil	Primär lock-in-risk
Event ingress	Versionsatt event, källidentitet, eventtid, dedup-ID	Fabric Eventstream, Event Grid, Service Bus	CloudEvents över Kafka, NATS eller RabbitMQ	Proprietära event- och schemaregister
Detection	Regelversion, watermark/late-event-policy, hysteresis	Fabric Activator, KQL, Stream Analytics	Flink, Kafka Streams eller egen regelservice	Produktunika temporal operators
Decision	Separat beslutsmodell och beslutslogg	DMN-tjänst eller versionerad Functions/Power Platform-logik	DMN-motor eller policy/rule service	FEEL-/DSL- och extension-skillnader
Workflow	Durable state, timers, retries och kompensation	Power Automate/Logic Apps för standardflöden; Durable Functions för längre eller kodnära orkestrering	Temporal, Flowable eller annan licensgranskad BPMN/durable runtime	Execution history, workflow-DSL och worker-SDK
Human task	Task-ID, assignment, SoD, expiry, delegation och evidence snapshot	Power Automate Approvals, Teams, Dataverse	Egen task inbox eller BPMN-tasklist med OIDC	Task-UI, identity mapping och approvaldatamodell
Action gateway	Re-authorization, precondition, idempotens, kvitto och verify	API Management, Functions/Container Apps, managed identities	Envoy/Kong-liknande gateway, OPA-liknande PDP, OIDC/OAuth	Gatewaypolicy och proprietära connectors
Target adapter	OpenAPI-baserat action contract och explicit ownership	Dataverse, Graph och custom connectors bakom gateway	OpenAPI/gRPC-adaptrar med lokala credentials	Connectorsemantik och API-licenser
Evidence	Kundägt action journal; hashade snapshots och correlation IDs	Dataverse/Eventhouse plus Monitor/Purview-export	PostgreSQL/event store/object storage plus OpenTelemetry	Hosted retention och ej exportbara loggar
Process mining	Export till XES och helst OCEL; gemensam object model	Power Automate process mining eller extern analys	PM4Py/ProM/SQL-baserad analys	Proprietär processmodell och datakrediter
Outcome	Fördeklarerad metric, horizon och experimentarm	Fabric/Power BI med separat experimenttabell	Warehouse/lakehouse och kausal analysstack	Produktunika KPI- och experimentobjekt

Att self-hosta en durable engine eliminerar inte driftkostnad. Exempelvis kräver Temporal Service en persistence-databas och kan använda separat visibility/index-store; schemaändringar, nätverksisolering, backup, uppgraderingar och worker-versionering blir kundens ansvar. Temporal self-hosting guide

Fem användbara mönster

1. Recommendation-only: Dataheart skapar ett action episode men ingen write. Utfallet omfattar om rekommendationen användes och varför.
2. Event-to-work-queue: Detektion skapar en prioriterad task. Arbetet fördelas efter kompetens, kapacitet och SLA; inte direkt till en namngiven person.
3. Controlled automatic action: Endast låg-risk, reversibla och tydligt begränsade handlingar passerar automatiskt gatewayn.
4. Long-running saga: Workflow väntar på externa event eller människor, checkpointar state och modellerar pivot, forward recovery och kompensation.
5. Bulk writeback/reverse ETL: Tillåts för deklarerade fält där Dataheart är utsedd fältägare. Rader med konflikter eller riskfyllda effekter konverteras till individuella action episodes.

Hightouchs egna docs illustrerar både nyttan och gränsen: sync mode, matching, delete behavior och limits varierar per destination; en full resync kan skapa dubletter i insert-, event- och webhooklägen. Det är ett synkroniseringssystem, inte ett generellt säkerhetskontrakt. Hightouch Syncs, uppdaterad 2026-08-20

Failure modes and counter-evidence

Felmodus	Konsekvens	Nödvändig kontroll
Auktorisation görs bara vid rekommendation eller approval	En roll kan vara återkallad när handlingen körs	Re-authorization och färskt token vid dispatch
Shared connector/flow-owner credential	Confused deputy; initiatorns behörighet kringgås	Separera initiating och acting principal; per-action scopes
Dublett eller okänd timeout efter write	Dubbla betalningar, ärenden eller utskick	Idempotensregister, target lookup och reconciliation
Out-of-order event	Handling baseras på gammalt tillstånd	Version/precondition, watermark och stale-event-regel
TOCTOU mellan approval och write	Godkänt underlag motsvarar inte aktuell resurs	Hashad snapshot, ETag och omgodkännande vid materiell ändring
Approval fatigue eller automation bias	Mänsklig kontroll blir ceremoniell	Riskbaserad kö, oberoende evidensvy och regelbundna sentinel-test
Självgodkännande/delegationsloop	Separation of duties bryts	Grafkontroll över identitet, chefslinje och delegation
Alert- eller actionstorm	Mänsklig och teknisk kapacitet kollapsar	Hysteresis, debounce, budget, circuit breaker och kill switch
Saga når irreversibelt steg för tidigt	Permanent partiellt resultat	Explicit pivot och validering före pivot
Kompensation misslyckas	Systemet fastnar i okänd affärsstatus	Durable compensation, DLQ och manual-repair queue
Reverse ETL uppdaterar systemägt fält	Split brain och oscillation mellan system	Fältägarskap, versionsregler och enkelriktad write-policy
Processloggen saknar manuellt arbete	Felaktig processmodell och falsk compliance	Loggkvalitetsprov, mänskliga observationer och source coverage
Process mining tolkas kausalt	Ineffektiva eller skadliga interventioner skalas upp	Holdout eller kausal estimationsplan
Auditlogg innehåller känsliga inputs	Sekundär dataläcka	Fältmaskning, purpose-bound retention och åtkomstkontroll
Proprietär runtime är enda sanningskälla	Migration förlorar pågående ärenden och bevis	Kundägt journal, exporttest och shadow replay

Motbevis mot vanliga förenklingar:

• CloudEvents innebär inte exactly-once eller säker action delivery.
• BPMN/DMN-filer innebär inte identiskt beteende mellan motorer; extensions, timers, incidenthantering och connectorer skiljer sig.
• Durable execution garanterar inte att ett externt system bara har påverkats en gång.
• En saga är inte en distribuerad rollback.
• En approval betyder inte effektiv mänsklig kontroll.
• En trace är inte ett revisionsbevis; den kan samplas, tappas och saknar ofta policy- och verksamhetssemantik.
• Process mining återskapar loggad aktivitet, inte full verksamhetsverklighet eller kausal effekt.
• Reverse ETL gör inte ett analytiskt lager till legitim ägare av alla operativa fält.
• Managed Microsoft-drift flyttar ansvar, men tar inte bort kapacitets-, licens-, owner-, connector- och governancearbete. Power Automates 30-dagarsgräns är ett konkret exempel. Power Automate limits

Den största gemensamma kostnaden är sannolikt inte workflowmotorn. Det är modellering av verksamhetsobjekt, adapterunderhåll, kompensationslogik, review-kapacitet, evidenskvalitet och effektmätning.

Implications for Dataheart

1. Gör action episode och action journal till produktkontrakt; låt workflows vara utbytbara exekveringsdetaljer.
2. Låt aldrig agenter, dashboards, reverse ETL eller Power Automate-connectors skriva direkt till skyddade mål.
3. Publicera ett litet Action Contract SDK: schema, idempotens, preconditions, receipts, verification och compensation hooks.
4. Behåll policybeslut och approval evidence i kundens plan. Telemetri får referera till dem men inte ersätta dem.
5. Versionera action types tillsammans med riskklass, outcome-definition, target ownership och reversibility.
6. Kräv explicit fältägarskap för writeback. Bulk-synk och affärshandling ska vara olika modes.
7. Exportera XES för enkla case-flöden och OCEL för relationer mellan flera affärsobjekt. OCEL bör initialt klassas som emerging, inte som universellt internt lagringsformat.
8. Gör human workload till en first-class resource: kölängd, väntetid, override-rate, false-acceptance, delegation och fairness.
9. Kugghusets forward deployed engineers bör bygga mappings, action adapters, outcome definitions och kompensationsrunbooks som versionsatt kundkonfiguration. Kundunika grenar i kärnprodukten skulle snabbt återskapa konsult- och lock-in-problemet.
10. Kräv samma conformance suite för Microsoft- och openprofilen. Profilen får förändra drift- och produktval, inte evidens- eller säkerhetsgarantierna.

Connections to other domains

• Control theory: observation motsvarar sensor, decision controller, action actuator och outcome feedback. Hysteresis, delay och gain är relevanta för att undvika oscillerande automation.
• Accounting: intent, dispatch, receipt, effect och compensation påminner om åtskilda verifikat; reconciliation är lika viktig som exekvering.
• Safety engineering: action gateway fungerar som interlock. Riskklass, point of no return och manual repair motsvarar hazard analysis och safe state.
• CQRS/event sourcing: command och event separeras, men action journal bör inte blandas ihop med målens egna system-of-record.
• Clinical trials och causal inference: rekommendationens träffsäkerhet är inte samma sak som treatment effect. Kontrollgrupp och fördeklarerade outcomes förhindrar efterhandsrationalisering.
• Förvaltningsrätt: notice, skäl, beslutsfattare, proportionalitet, överklagande och versionsbeständigt underlag ger en bättre modell för high-impact approvals än en enkel approve/reject-knapp.
• SRE/incident management: action budgets, circuit breakers, dead letters, runbooks och error budgets behövs även för verksamhetsautomation.

Recommended experiments and conformance tests

Test	Genomförande	Godkänt resultat
C1 Duplicate dispatch	Skicka samma action 10 000 gånger med samma nyckel	Högst en affärseffekt; alla försök korrelerade
C2 Crash-window matrix	Krascha före write, efter write men före kvitto och efter kvitto	Ingen okänd permanent status; automatisk verify/reconcile
C3 Revoked authority	Godkänn, återkalla roll och försök verkställa	Gateway nekar och loggar färskt policybeslut
C4 Evidence drift	Ändra målresurs eller relevant evidens efter approval	Precondition misslyckas; materiell ändring kräver nytt approval
C5 Saga pivot	Injicera fel före och efter point of no return	Före pivot kompenseras; efter pivot går processen till forward recovery/manual repair
C6 Event disorder	Dubbletter, sen ankomst, clock skew och omordning	Ingen felaktig handling; policy för sena event synlig
C7 Human oversight	Plantera kontrollerat felaktiga rekommendationer	False-acceptance mäts; riskgräns definieras före pilot
C8 Review overload	Kör 2–5× normal belastning	Backpressure, prioritering och SLA fungerar utan massgodkännande
C9 SoD/delegation	Försök självapproval, cirkulär delegation och gruppöverlapp	Samtliga förbjudna vägar blockeras
C10 OCEL round trip	Exportera en order–leverans–faktura-loop från båda profiler	Samma objekt, relationer, qualifiers och action receipts
C11 Outcome causality	Randomiserad eller stepped-wedge-pilot	Effekt och osäkerhet rapporteras separat från prediktiv precision
C12 Cross-profile portability	Pausa ett pågående episode, exportera och återuppta i andra profilen	Ingen förlust av evidens, timer, approval eller kompensationsstate
C13 Target conflict	Låt människa och reverse ETL ändra samma fält	Ägarskaps-/versionskonflikt upptäcks; ingen oscillation
C14 Cost envelope	Kör samma realistiska last i båda profiler	Full kostnad redovisas: licenser/CU respektive drift/on-call, plus reviewarbete
C15 Tenant isolation	Manipulera tenant-, object- och idempotency-ID	Ingen cross-tenant läsning, dedup eller write är möjlig

Sources

1. OMG — BPMN 2.0.2 — antagen januari 2014.
2. OMG — DMN specification history — DMN 1.5 formell augusti 2024; 1.7 beta september 2024.
3. CNCF — CloudEvents specification — v1.0.2, 2022-02-05; CNCF Graduated 2024-01-25.
4. IETF — RFC 9700, OAuth 2.0 Security BCP — januari 2025.
5. EU — Regulation 2024/1689, AI Act — antagen 2024-06-13, publicerad 2024-07-12.
6. Microsoft — Fabric Activator limitations — uppdaterad 2026-07-23.
7. Microsoft — Power Automate approvals — uppdaterad 2026-04-29.
8. Microsoft — Power Automate limits — uppdaterad 2026-07-17.
9. Microsoft — Compensating Transaction pattern — uppdaterad 2026-04-20.
10. Temporal — Self-hosted deployment guide — aktuell version granskad 2026-08-23.
11. IEEE — IEEE 1849-2023 XES — publicerad 2023-09-08.
12. OCEL — Object-Centric Event Log 2.0 specification — publicerad 2024-03-04.
13. Kücking et al. — Automation Bias in AI-Decision Support — publicerad 2024-08-30.
14. Eshuis & Genga — Causal intervention strategies for business processes — publicerad 2025-07-25.
15. Hightouch — Syncs overview — uppdaterad 2026-08-20; first-party vendor documentation.