Sanning över tid

Klockan 09.10 vet Matrix att 137 av Nordic-batchens 142 dokument har slutkvitto. Klockan 09.24 anländer två kvitton som säger att dokumenten togs emot redan 09.07.

Hur många dokument var mottagna 09.10?

Svaret kan vara 137 eller 139 utan att någon räknar fel. Det beror på om frågan gäller vad Matrix visste 09.10 eller vad Matrix senare fick veta om verkligheten 09.10. Ett system som inte kan uttrycka skillnaden kommer förr eller senare att skriva om sin egen historia.

1. Det finns inte en enda tid

Distribuerade system producerar flera tidsbegrepp som lätt får samma fältetikett. För en Matrix-post behöver åtminstone följande frågor hållas isär:

Fälten kan ibland ha samma värde, men de har inte samma betydelse. En probe kan observera och registrera nästan samtidigt. Ett importerat historiskt event kan ha år mellan händelse- och registreringstid. En giltighetsperiod kan omfatta många observationer.

Temporal databaslitteratur använder två särskilt viktiga dimensioner: valid time, när ett faktum gäller i den modellerade verkligheten, och transaction time, när databasen lagrar eller känner till versionen (jensen1992glossary). När båda representeras kan systemet besvara bitemporala frågor (CLAIM-TIME-001).

2. Tidsstämpel är inte kausalitet

Antag att system A loggar ett skickat meddelande 09.07.01 och system B loggar ett mottaget meddelande 09.07.00. Har B tagit emot meddelandet före A skickade det? Sannolikt visar klockorna olika, men de två siffrorna räcker inte för att avgöra orsaksordningen.

Lamports happened-before-relation formaliserar en partiell ordning: händelser i samma process kan ordnas; ett skickat meddelande föregår mottagandet; och relationen är transitiv. Händelser utan sådan kedja kan vara samtidiga i modellens mening (lamport1978time).

Konsekvensen för Matrix är att en sortering på occurredAt är praktisk men inte bevis för kausal ordning (CLAIM-TIME-002). Där kausaliteten spelar roll behövs exempelvis:

• stabilt korrelations-ID,
• explicit föregångare eller causedBy,
• producer- och sekvensinformation,
• aktivitets-/proveniensrelationer,
• regler för dubbletter och replay.

Logisk tid ersätter inte giltighetstid. Den hjälper oss ordna relaterade event; den säger inte under vilket verksamhetsintervall en konfiguration var aktiv.

3. Tidszon är nödvändigt men inte tillräckligt

Matrix eventkontrakt kräver occurredAt med explicit tidszon. ADR-0006 beslutar att naiva tidsstämplar ska avvisas i både schema och staleness-parser, inte tyst tolkas som UTC (MATRIX-EVENT-CONTRACT, MATRIX-ADR-TIMEZONE). Det är en sund fail-closed-regel: en tidsstämpel utan zon är en tvetydig observation.

Men en korrekt RFC 3339-liknande tidsstämpel garanterar inte:

• att källans klocka gick rätt,
• att eventet inte är en dubblett,
• att producenten rapporterar i kausal ordning,
• att observationen är fullständig,
• att eventet registrerades nära händelsetiden.

Formatvalidering löser representation. Källkvalitet, ordering och fullständighet är separata claims.

4. Sen data gör svar preliminära

Strömmande system måste svara innan de med säkerhet sett alla framtida data. Dataflow-modellen beskriver avvägningen mellan korrekthet, latens och kostnad för obegränsad, oordnad data och använder bland annat event time, windows, watermarks och triggers (akidau2015dataflow).

Matrix behöver inte kopiera en full stream processor för att lära av modellen. För varje tidskänslig bedömning behöver fyra frågor besvaras:

1. Vad beräknas? Exempelvis antal slutkvitton per batch.
2. I vilken tid? Kvitton vars händelsetid ligger före batchens deadline.
3. När publiceras svaret? Direkt, vid deadline eller efter en tolererad fördröjning.
4. Hur ändras svaret när sen data kommer? Uppdatering, ny revision, retraction eller manuell konflikt.

En watermark är en systembedömning av hur långt event time sannolikt har fortskridit, inte ett metafysiskt löfte om att inga äldre event kan dyka upp. Ett UI bör därför använda ord som preliminär, stabil enligt policy eller korrigerad, inte bara slutlig.

I Nordic-fallet kan policyn vara:

09.10  publicera preliminärt svar
09.20  markera svar stabilt enligt 10 minuters lateness-policy
senare  acceptera fortfarande korrektion, men skapa ny kunskapsversion

Detta gör latensen synlig som designval (CLAIM-TIME-003). Ett system som alltid väntar blir långsamt; ett system som aldrig omprövar blir fel.

5. Färskhet är ett kontrakt

En observation är inte färsk eller stale i absoluta termer. En dag gammal ägarskapsdefinition kan vara acceptabel. En minut gammal köobservation kan vara oanvändbar under en incident.

Matrix har redan ett starkt mönster för eventflöden. Staleness bedöms per (producerId, eventType). Policyn kräver antingen positiv maxAgeDays eller en explicit acceptedStale med skäl. En saknad producer, en obokad eventtyp eller ett förväntat flöde utan event blir fel; tyst stale är förbjudet (MATRIX-EVENT-STALENESS).

Detta stöder tesen att färskhet är claimspecifik (CLAIM-TIME-004). En mer generell profil bör minst ange:

• förväntad observationsrytm,
• maximal ålder för det aktuella beslutet,
• senaste lyckade observation,
• senaste observationsförsök,
• varför ett flöde avsiktligt får vara tyst,
• konsekvensen av att underlaget är stale.

Skillnaden mellan "senaste observation 09.00" och "senaste försök 09.09 misslyckades" är viktig. Det första kan se lugnt ut; det andra visar att observationsförmågan själv är degraderad.

6. Fyra sätt att ändra kunskap

När ny information kommer behöver Matrix skilja följande operationer:

Ny observation

En ny post beskriver ett senare eller ytterligare observerat tillstånd. Den gamla observationen förblir sann som historisk observation.

Supersession

En ny version ersätter en tidigare version för framtida current-frågor, men den gamla bevaras med supersededAt och relation till efterföljaren.

Korrigering

En ny post säger att tidigare lagrad kunskap om en historisk tid var fel eller ofullständig. Den tidigare versionen bevaras för known-at-frågor.

Retraction

Påståendet återkallas därför att källan eller härledningen inte längre får bära slutsatsen. En retraction är inte samma sak som ett motsatt faktum.

Tyst UPDATE är bara lämpligt för icke-historisk metadata där det uttryckligen saknar revisionsvärde. För claims som påverkat beslut ska korrigering skapa en ny kunskapsversion (CLAIM-TIME-005).

7. Bitemporala frågor

Två parametrar räcker för att göra skillnaden synlig:

• valid_at: vilken domäntid frågan gäller,
• known_at: vilket kunskapsläge som får användas.

För Nordic:

Den sista raden kräver en domänregel: ett avvisande är belagt negativt och ska inte ligga kvar i samma "okänt"-hink. Frågemotorn kan inte uppfinna den semantiken från tidskolumnerna.

8. Matrix nuläge

Matrix har flera bra tidsprimitiver, men de är inte en enhetlig modell:

• Coordinator-findings har observed_at och recorded_at (MATRIX-FINDING-STORE).
• Event kräver zonmedvetet occurredAt (MATRIX-EVENT-CONTRACT).
• Graf- och eventbundles kan bära generatedAt, men fältet är inte obligatoriskt i JSON-schemat (MATRIX-GRAPH-CONTRACT).
• Eventflöden har en fail-closed staleness-policy (MATRIX-EVENT-STALENESS).
• Grafens vanliga noder och kanter saknar ett generellt valid-/known-time- kontrakt.

Detta motiverar en pilot, inte en total migration. Forskningsspår RESEARCH-001 föreslår TemporalAssertion för tre typer av föränderliga claims. Piloten ska först visa att bitemporala frågor faktiskt ändrar beslut.

9. Databasstöd och domänansvar

SQL:2011 standardiserade centrala temporala tabellfunktioner och gjorde application time och system time till databasbegrepp (kulkarni2012temporal). Databasprodukter implementerar olika delar och syntax.

PostgreSQL 18 lägger till temporala constraints över ranges: WITHOUT OVERLAPS för temporal primary/unique och PERIOD för temporal foreign key (postgresql18temporal). För Matrix kan det vara användbart för att hindra överlappande giltighetsintervall för samma claimidentitet.

Det löser däremot inte full bitemporal historik, correction/retraction, watermarks eller proveniens (CLAIM-TIME-006). Ett möjligt lager ser ut så:

domänmodell     väljer valid-time-semantik och korrigeringsregler
databas         upprätthåller range- och referensintegritet
append history  bevarar knowledge-time-versioner
query API       kräver/visar valid_at och known_at
UI              förklarar preliminär, stale, korrigerad och conflicted

RESEARCH-010 ska avgöra om PostgreSQL 18 faktiskt förenklar Matrix. Ett nytt databasfeature är inte i sig ett skäl att ändra plattformsbaseline.

10. Gränssnittet måste visa tidsfrågan

En tidsresefunktion är farlig om användaren inte ser vilken axel som ändrats. Gränssnittet bör därför uttryckligen visa:

• Gäller vid: domäntiden (valid_at).
• Känt vid: kunskapsläget (known_at).
• Beräknad: när bedömningen skapades.
• Underlag till och med: watermark/färskhetsgräns och policy.
• Reviderad: om senare data ändrat svaret.

Standardvyn kan vara "gäller nu, känt nu", men dessa defaultvärden får inte vara osynliga. När användaren öppnar en historisk incident ska en tydlig indikator hindra att den gamla bilden förväxlas med nutid.

11. Vanliga felslut

1. Senast vunnen: högsta timestamp antas vara sannast utan käll- eller kausalitetsregel.
2. Ingestion är verklighet: recordedAt används som om det vore occurredAt eller valid time.
3. Eventlogg är bitemporalitet: append-only data finns, men frågan om vad som gällde har ingen domänsemantik.
4. Watermark är absolut finalitet: data efter gränsen ignoreras eller skrivs över tyst.
5. Global staleness: samma maxålder används för certifikat, köstatus och organisationsägare.
6. Tidszon löser ordning: korrekta offsets blandas ihop med kausalitet.
7. Historisk UI utan knowledge time: användaren ser dagens korrigerade bild och tror att operatören hade samma information då.

Praktisk checklista

För varje tidskänslig claim:

1. Definiera domänens valid time.
2. Ange observerad/händelsetid och registreringstid separat.
3. Definiera identitet, kausalitet och dubblettregel.
4. Ange lateness- och staleness-policy.
5. Bestäm när svaret är preliminärt respektive stabilt enligt policy.
6. Modellera supersession, correction, retraction och konflikt.
7. Testa valid_at × known_at med ett sent event.
8. Bevara källa, regelversion och producerande aktivitet.
9. Visa tidsvalet och revisionen i gränssnittet.
10. Mät om den extra komplexiteten ändrar ett verkligt beslut.

Sammanfattning

Tid i ett kontrollager är inte en sorteringskolumn. Händelsetid, observationstid, registreringstid, giltighetstid och genereringstid besvarar olika frågor. Fysiska tidsstämplar ger inte ensamma kausalitet. Sena event gör att snabba svar måste ha en synlig policy för omprövning och finalitet.

Matrix har redan strikta tidszoner, observed/recorded time i findings och en fail-closed stalenessgrind per eventflöde. Det som saknas är ett generellt, avgränsat kontrakt för claims som måste kunna besvaras både valid-at och known-at. Ett sådant kontrakt bör pilottestas där beslutsvärdet är tydligt och använda databasens temporala primitives som stöd — aldrig som ersättning för domänsemantiken.

Centrala begrepp

Event time, observationstid, registreringstid, valid time, transaction time, genereringstid, happened-before, logical clock, watermark, lateness, staleness, supersession, correction, retraction och bitemporal query.

FIG-03-01 — Samma valid time, olika known time

Visa diagramdefinition

flowchart LR
  E[Händelse 09.07] -->|observeras| O[Observation 09.08]
  E -->|sen leverans| R[Registrerad 09.24]
  V[Gäller vid 09.10] --> Q{As-of-fråga}
  K[Känt vid 09.10 eller 09.24] --> Q
  R --> K
  O --> V
  Q --> A1[137 vid known_at 09.10]
  Q --> A2[139 vid known_at 09.24]