SKILL.md: Temporale Intervallschlussfolgerung (Allen 1983)
Wann Sie dieses Skill verwenden sollten
Laden Sie dieses Skill, wenn Sie auf Folgendes stoßen:
| Auslösesituation | Warum Allen zutrifft |
|---|---|
| „Endet Aufgabe A, bevor Aufgabe B beginnt?“ | Erfordert Klassifizierung von Intervallbeziehungen (vor, trifft, überlappt…) |
| „Ich weiß nicht genau, wann X passiert ist, nur dass es während Y war“ | Disjunktive Unsicherheit über die 13 Relationen |
| „Wenn wir diese Einschränkung hinzufügen, funktioniert der Zeitplan dann noch?“ | Constraint-Propagation + Inkonsistenzerkennung |
| „Ereignis A tritt täglich auf; Ereignis B jährlich – wie interagieren sie?“ | Referenzintervall-Hierarchie für Bereichsverwaltung |
Nicht verwenden, wenn Sie nur zwei absolute Zeitstempel ohne Unsicherheit vergleichen müssen – einfache Arithmetik genügt.
Entscheidungspunkte
Neue zeitliche Behauptung hinzugefügt
WENN Behauptung mit bestehenden Einschränkungen in Konflikt steht:
→ Leere Bogenmarkierung während der Propagation erkennen
→ SOFORT anhalten, inkonsistentes Intervallpaar melden
→ NICHT mit inkonsistentem Zustand fortfahren
WENN Behauptung konsistent ist:
→ Constraint-Propagation von betroffenen Bögen ausführen
→ Markierungen durch Schnittmengenbildung von Transitivitätsfolgen aktualisieren
→ Fortfahren, bis keine weiteren Verfeinerungen möglich sind
Umgang mit zeitlicher Unsicherheit
WENN Beweise nur mehrere Relationen stützen:
→ Vollständige disjunktive Markierung beibehalten {vor, trifft, überlappt}
→ Niemals ohne Beweise auf eine einzelne Relation reduzieren
→ Protokollieren, wann/warum sich der Constraint-Satz verengt
WENN unter Unsicherheit gehandelt werden muss:
→ Disjunktive Markierung wie besehen für die Planung verwenden
→ Alle Annahmen als widerlegbar kennzeichnen
→ Voreilige Festlegung vermeiden
Bereich der zeitlichen Schlussfolgerung eingrenzen
WENN mit Ereignissen auf sehr unterschiedlichen Zeitskalen umgegangen wird:
→ Referenzintervall-Hierarchie identifizieren (Jahr→Monat→Tag)
→ Getrennt innerhalb jedes Clusters schließen
→ Explizite Brückeneinschränkungen an den Grenzen erstellen
→ Vermeiden, alles in einen globalen Graphen zu packen
WENN lokales Schließen ausreichend erscheint:
→ Überprüfen, ob der Abfragebereich mit der Referenzintervallebene übereinstimmt
→ Nur innerhalb des relevanten Clusters propagieren
→ Clusterübergreifend nur eskalieren, wenn eine Abhängigkeit erkannt wird
Zustandspersistenz
WENN der Zustand ohne explizite Endbegrenzung fortbesteht:
→ Persistenzstandard anwenden UND als widerlegbar markieren
→ Jede zukünftige Endbegrenzungsbehauptung überschreibt den Standard
→ Niemals die Persistenzannahme als harte Einschränkung behandeln
WENN explizite zeitliche Grenze angegeben ist:
→ Alle bestehenden Persistenzstandards überschreiben
→ Neue Einschränkung normal propagieren
Fehlermodi
| Anti-Pattern | Symptom | Diagnose | Lösung |
|---|---|---|---|
| Punktifizierung | Reduzieren von Ereignissen auf Zeitstempel, Verlust von Überlappungs-/Enthalten-Informationen | Verwenden von time=14:30 anstatt Intervallen [14:30, 14:45] | Jedes Ereignis als Intervall mit Start/Ende modellieren, auch wenn die Dauer unbekannt ist |
| Voreilige Festlegung | Auswählen einer einzelnen Relation, obwohl Beweise mehrere stützen | Behaupten von „vor“ obwohl nur „nicht während“ bekannt ist | Vollständige disjunktive Markierung beibehalten, bis Beweise eine Verengung erzwingen |
| Globale Propagierungsbombe | O(N²) Kosten pro Aktualisierung, Leistung verschlechtert sich mit Wissensbasisgröße | Ausführen von Constraint-Propagation über den gesamten Graphen für eine lokale Abfrage | Referenzintervall-Hierarchie verwenden, um den Propagierungsbereich einzuschränken |
| Leere Markierungsverleugnung | Fortsetzen des Schließens, nachdem eine Inkonsistenz erkannt wurde | Unsinnige Ergebnisse, weil widersprüchliche Einschränkungen ignoriert werden | Leere Bogenmarkierung als ERFOLG behandeln (Inkonsistenz früh erkannt), sofort anhalten |
| Persistenzstarrheit | Annahmen „gilt bis auf Widerruf“ können nicht überschrieben werden | Neue zeitliche Grenzen werden abgelehnt, weil sie mit der Persistenz kollidieren | Alle Persistenzstandards als widerlegbar kennzeichnen, Überschreibung durch explizite Behauptungen zulassen |
Erkennungsregeln:
- Wenn Sie Zeitstempel ohne Dauer sehen → Punktifizierung
- Wenn Sie eine willkürlich gewählte einzelne Relation sehen → Voreilige Festlegung
- Wenn die Propagierungskosten mit der Gesamtgröße der Wissensbasis wachsen → Globale Propagierungsbombe
- Wenn das Schließen nach einer leeren Markierung fortgesetzt wird → Leere Markierungsverleugnung
- Wenn neue zeitliche Fakten abgelehnt werden → Persistenzstarrheit
Ausgearbeitete Beispiele
Beispiel 1: Erkennung von Terminkonflikten in Besprechungen
Szenario: Hinzufügen von „Team-Review“ in einen Kalender, der bereits „Kundenanruf“ und „Engineering-Standup“ enthält
Ausgangszustand:
Kundenanruf (I₁): [10:00, 11:00]
Engineering-Standup (I₂): [11:30, 12:00]
Bekannt: I₁ {vor} I₂
Neue Behauptung: Team-Review (I₃): [10:45, 11:15]
Ablaufverfolgung der Expertenlogik:
-
Neue Relationen klassifizieren:
- I₃ vs I₁: beginnt um 10:45, I₁ endet um 11:00 → {überlappt}
- I₃ vs I₂: endet um 11:15, I₂ beginnt um 11:30 → {vor}
-
Constraint-Propagation:
- Von I₁ {vor} I₂ und I₃ {überlappt} I₁
- Transitivität: überlappt ∘ vor = {vor, überlappt, trifft, beginnt, während}
- Neue Einschränkung: I₃ {vor, überlappt, trifft, beginnt, während} I₂
- Schnittmenge mit I₃ {vor} I₂: Markierung wird zu {vor}
-
Konsistenzprüfung: Alle Markierungen nicht-leer → Terminplan ist machbar, hat aber Überlappung
Anfänger würde übersehen:
- Könnte nicht prüfen, dass die Überlappung von I₃ mit I₁ einen Ressourcenkonflikt erzeugt
- Könnte nicht überprüfen, ob die Transitivität die Konsistenz aufrechterhält
- Könnte nicht zwischen „machbarer Reihenfolge“ und „keinen Ressourcenkonflikten“ unterscheiden
Experte erkennt:
- Überlappungserkennung sofort via Relationsklassifizierung gekennzeichnet
- Propagation überprüft die globale Konsistenz
- Klare Unterscheidung zwischen zeitlicher Machbarkeit und Ressourcenverfügbarkeit
Beispiel 2: Abhängigkeiten von Prozessphasen
Szenario: Bereitstellungspipeline mit unsicheren Aufgabenabschlusszeiten
Ausgangszustand:
Build-Phase (B): Dauer unbekannt, muss vor Deploy abgeschlossen sein
Test-Phase (T): überlappt mit Ende von Build, Dauer unsicher
Deploy-Phase (D): beginnt, nachdem sowohl B als auch T abgeschlossen sind
Constraint-Netzwerk:
T {überlappt, beendet} B (Test kann mit oder vor Build enden)
B {vor, trifft} D (Build muss vor Deploy abgeschlossen sein)
T {vor, trifft} D (Test muss vor Deploy abgeschlossen sein)
Neue Information: „Test hat kritischen Fehler gefunden, verlängert sich um 2 Stunden“
Expertenlogik:
- Aktualisierung betrifft den Bereich: Testverlängerung verschiebt den Endzeitpunkt von T nach hinten
- Propagation: Wenn T ursprünglich {beendet} B war, jetzt T {überlappt} B (erstreckt sich über Build-Ende hinaus)
- Konsistenzprüfung: T {überlappt} B erlaubt immer noch B {vor, trifft} D und T {vor, trifft} D
- Ergebnis: Bereitstellung verzögert, aber Pipelinelogik intakt
Anfänger würde übersehen:
- Könnte annehmen, dass der Testabschluss die Build-Deploy-Abhängigkeit nicht beeinflusst
- Könnte die Testverlängerung nicht durch den Zeitpunkt von Deploy propagieren
- Könnte „Test verlängert sich“ als isolierte Tatsache und nicht als Aktualisierung des Constraint-Netzwerks behandeln
Experte erkennt:
- Erkennt, dass die Test-Build-Beziehung neu bewertet werden muss
- Propagiert zeitliche Auswirkungen durch das gesamte Constraint-Netzwerk
- Behält Unsicherheit angemessen bei (Deploy könnte sofort nach Build ODER nach verlängertem Test beginnen)
Qualitätstore
Die zeitliche Schlussfolgerungsaufgabe ist abgeschlossen, wenn:
- Alle Intervalle mit expliziten Start-/Endgrenzen dargestellt werden (keine Punkt-Ereignisse)
- Jedes Intervallpaar eine nicht-leere Bogenmarkierung aus dem 13-Relationen-Vokabular hat
- Constraint-Propagation bis zum Abschluss durchgeführt wurde (keine ausstehenden Transitivitätsaktualisierungen)
- Alle disjunktiven Markierungen die aktuellen Beweise ehrlich widerspiegeln (keine willkürlichen Festlegungen)
- Referenzintervall-Hierarchie für mehrskaliges Schließen eingerichtet
- Persistenzstandards als widerlegbar gekennzeichnet, wo zutreffend
- Inkonsistenzerkennung verifiziert (leere Markierungen abgefangen und gemeldet)
- Bereichsübergreifende Brücken explizit definiert
- Alle zeitlichen Behauptungen auf eine Beweisquelle zurückgeführt
- Abfragebereich stimmt mit der Granularitätsebene des Schließens überein
NICHT-FÜR-Grenzen
Verwenden Sie Allen's Intervallalgebra NICHT für:
- Einfachen Zeitstempelvergleich → Arithmetik verwenden:
if (t1 < t2) - Metrische Dauerberechnung → Kalenderarithmetik verwenden:
end_date - start_date - Echtzeitplanungsoptimierung → Constraint-Erfüllung mit numerischen Domänen verwenden
- Probabilistische zeitliche Inferenz → Zeitliche Wahrscheinlichkeitsnetze verwenden
- Kontinuierliche Zeitdynamik → Differentialgleichungen verwenden
- Hochfrequente Ereignisströme → Stream-Processing-Frameworks verwenden
Stattdessen delegieren:
- Für metrische Einschränkungen: constraint-satisfaction-with-numeric-domains verwenden
- Für probabilistisches zeitliches Schließen: bayesian-temporal-networks verwenden
- Für Echtzeitsysteme: rate-monotonic-scheduling verwenden
- Für kontinuierliche Dynamik: temporal-logic-model-checking verwenden
- Für Ereignisstromverarbeitung: complex-event-processing verwenden
Allen zeichnet sich aus bei: Qualitativem zeitlichem Schließen unter Unsicherheit mit inkrementellen Wissensaktualisierungen und hierarchischer Bereichsverwaltung.