Ein Bot für Krypto-Prognosemärkte braucht zwei schlüssige Verläufe: was über das Ereignis bekannt ist und was im Konto geschehen ist. Eine Quellenaktualisierung kann eine Prognose ändern, ohne Bestände zu verändern. Eine verspätete Ausführung kann Bestände ändern, ohne das Ereignis zu verändern. Beides in einem einzigen Status wie aktiv oder beendet zusammenzufassen erschwert die Entscheidung, was das System als Nächstes tun darf.
Dieser Leitfaden beschreibt eine Architektur für Lernzwecke anhand eines fiktiven Preisereignisablaufs. Er liefert keine reale Handelsintegration und behauptet nicht, dass ein bestimmter Handelsplatz jede veranschaulichte Funktion unterstützt. Tatsächliche Kontoteilnahmeberechtigung, Datenzugang, Orderbedeutung und Preisschritte müssen für das gewählte Produkt geprüft werden. Das Entwurfsziel ist, jede Beobachtung, Freigabe und finanzielle Verpflichtung nach Unterbrechungen ebenso wie im gewöhnlichen Betrieb erklärbar zu machen.
Der Ereigniszustand eines Bots für Krypto-Prognosemärkte beschreibt Belege
Die Ereignisaufzeichnung sollte Kontraktbedingung, Referenzquelle, Beobachtungsfenster, Schwellenwertoperator und Regelversion benennen. Anschließend erfasst sie, welche Belege eingetroffen sind und ob sie für die vorgesehene Prognose nutzbar sind. Eine Quelle kann aktuell, veraltet, fehlend oder im Konflikt mit einer anderen Beobachtung sein, ohne dass das Ergebnis des Kontrakts selbst festgestellt wurde.
Behandeln Sie nicht alle neuen Daten als gleich aussagekräftig. Eine Preisbeobachtung aus der benannten Referenz kann die Ereignisschätzung aktualisieren, während ein Preisangebot aus einem sachfremden Chart nur Kontext sein kann. Eine Regelklarstellung kann eine Zuordnungsprüfung statt einer numerischen Prognoseaktualisierung erfordern. Die Ereignisaufzeichnung sollte Änderungsart und praktische Wirkung bewahren.
Ein fiktives Ereignis könnte vom Warten auf sein Beobachtungsfenster zum Sammeln gültiger Referenzbelege, dann zu beobachtet, aber nicht offiziell festgestellt und schließlich zu einer bestätigten Feststellung übergehen. Das sind konzeptionelle Entwurfszustände und keine behaupteten Statusnamen des Handelsplatzes. Der tatsächliche Adapter sollte maßgebliche Aufzeichnungen einer dokumentierten Auslegung zuordnen.
Der frühere Leitfaden zum Bot für Ereigniskontrakte erklärt den vollständigen Lebenszyklus von Daten bis Abgleich. Ereignisbelege zu trennen ist eine nützliche Verfeinerung, weil sie verhindert, dass ein Bot allein aus einem neuen Meilenstein der Außenwelt auf eine erfolgte Kontohandlung schließt.
Der Kontozustand eines Bots für Krypto-Prognosemärkte beschreibt Verpflichtungen
Die Kontoaufzeichnung sollte Empfehlungen, freigegebene Anweisungen, übermittelte Versuche, angenommene Orders, bestätigte Ausführungen, verbleibende offene Mengen und abgeschlossene Abwicklungsunterlagen unterscheiden. Jede belegt eine andere Tatsache. Eine Empfehlung kann ohne Handelserlaubnis bestehen, und eine angenommene Order kann bestehen, ohne dass die vorgesehene Position ausgeführt wurde.
Die Aufzeichnung braucht außerdem Finanzierung und Reservierungen. Verfügbares Guthaben, gebundene Kaufbeträge, mögliche künftige Ausführungen und ungeklärte Übertragungen sollten nicht in einem Barmittelfeld vermischt werden. Ein Bot, der eine neue Handlung freigibt, muss wissen, was aus bereits gesendeten Anweisungen das Konto noch verändern könnte.
Polymarkets Dokumentation zum Orderlebenszyklus unterscheidet Orders vom nachfolgenden Handelsfortschritt. Andere Kontokontexte brauchen eigene aktuelle Zuordnungen. Der Bot sollte aus einer allgemeinen Erfolgsantwort keine Endgültigkeit ableiten und nicht annehmen, dass jede Teilausführung eine bestehen bleibende Restmenge hinterlässt.
Der frühere Leitfaden zur Bot-API für Prognosemärkte liefert die Schnittstellengrenzen hinter diesem Entwurf. Der Kontozustand ist keine lokale Vermutung darüber, was hätte geschehen sollen; er ist eine abgeglichene Auslegung maßgeblicher Order-, Ausführungs- und Guthabenbelege.
Die Verläufe über eine begrenzte Freigabe verbinden
Eine Prognose kann einen bestimmten Anspruch, eine Seite, Menge und Preisspanne vorschlagen. Eine Risikoentscheidung sollte dann Kontraktidentität, Belegaktualität, aktuelles Kontorisiko und verfügbares Kapital prüfen, bevor sie eine begrenzte Freigabe erteilt. Die ausführende Komponente erhält diese Freigabe und keine unbegrenzte Anweisung, auf jedes spätere Signal zu handeln.
Nehmen Sie Prognose- und Regelversionen, Höchstmenge, Gesamtkostengrenze und Ablaufzeit in die Berechtigungsaufzeichnung auf. Ändert sich eine wesentliche Eingabe vor der Übermittlung, sollte die ausführende Komponente prüfen, ob die bestehende Erlaubnis noch gilt, oder über den vorgesehenen Ablauf eine neue begrenzte Entscheidung anfordern. Eine Empfehlung sollte nicht unbegrenzt ausführbar bleiben.
Diese Trennung erlaubt dem Bot kontinuierliche Beobachtung, ohne kontinuierlich seine Befugnisse zu erhöhen. Die meisten Quellenaktualisierungen erfordern möglicherweise keinen Handel. Das System kann neue Belege erfassen, eine Schätzung revidieren oder verzichten und die Kontoverpflichtungen unverändert lassen. Untätigkeit kann die richtige Reaktion auf einen geänderten Ereigniszustand sein.
Der verwandte Leitfaden zu Software für Krypto-Prognosemärkte beschreibt die Bewertung von Belegen und Prüfbarkeit in einer Anwendung. Ein nützlicher Abnahmetest sollte die genaue Aufzeichnung zeigen, die eine Prognose mit einer freigegebenen Verpflichtung verband, einschließlich der sie begrenzenden Prüfungen.
Eine Kapitalfreigabe durchrechnen
Nehmen wir an, ein fiktives Konto habe eine Grenze für Strategieverpflichtungen von 120 $, von denen 20 $ bereits für eine andere mögliche Verpflichtung reserviert sind. Eine neue Empfehlung fordert bis zu 200 Ja-Einheiten zu höchstens 0,55 $ mit einem Spielraum für zusätzliche Kosten von 4 $. Der mögliche neue Bedarf beträgt 114 $, und die gemeinsamen Verpflichtungen könnten 134 $ erreichen. Die Anfrage überschreitet die Grenze.
Unter einer fiktiven Größenregel mit ganzen Einheiten für dieses Beispiel müssen die verfügbaren 100 $ Kaufausgaben und den Spielraum von 4 $ abdecken. Damit verbleiben 96 $ für Einheiten. Geteilt durch 0,55 $ ergibt das ungefähr 174,54, sodass höchstens 174 ganze Einheiten passen: 95,70 $ Kaufausgaben plus 4 $ zusätzliche Kosten, also 99,70 $, neben der bestehenden Reservierung von 20 $.
Das ist eine Entwurfsberechnung und keine Aussage über Mindestmenge oder Genauigkeit eines Handelsplatzes. Die tatsächliche Größenbestimmung muss die zulässigen Schritte des aktuellen Markts verwenden. Der Bot sollte die Empfehlung außerdem ablehnen, wenn der Spielraum von 4 $ für bestätigte anwendbare Kosten nicht ausreicht, statt ihn als Versprechen zu behandeln, dass Kosten ihn nicht überschreiten können.
Die Freigabe beschreibt nun 174 Einheiten und nicht die ursprünglichen 200. Beide Aufzeichnungen sollten sichtbar bleiben: Die Empfehlung erklärt den Modellvorschlag, die Freigabe erklärt, was das Konto erlauben konnte. Eine spätere Prüfung sollte die Verringerung nicht mit einem Ausführungsfehler verwechseln.
Tatsächliche Ausführungen bei ihrem Eintreffen bewahren
In der fiktiven Folge werden 100 Einheiten zu 0,52 $ für 52 $ und weitere 50 zu 0,54 $ für 27 $ ausgeführt. Die Kaufausgaben betragen 79 $, und die bisher bestätigten zusätzlichen Kosten betragen 2 $. Das Konto besitzt 150 Einheiten zu Gesamtkosten von 81 $. Vierundzwanzig der freigegebenen 174 bleiben unter dem bestehen bleibenden Orderverhalten des Beispiels unausgeführt.
Diese 24 können zum Limit von 0,55 $ noch bis zu 13,20 $ Kaufausgaben erzeugen. Behält der Entwurf die verbleibenden 2 $ Spielraum für zusätzliche Kosten für diese Verpflichtung bei, ergeben Position und mögliche Restmenge zusammen 96,20 $. Mit der getrennten Reservierung von 20 $ betragen mögliche Verpflichtungen unter den genannten Buchhaltungsannahmen 116,20 $.
Der Bot sollte diese Werte aus eindeutigen Ausführungen und dem verbleibenden Orderzustand ableiten. Doppelte Benachrichtigungen dürfen Menge nicht zweimal hinzufügen. Zustellung außerhalb der Reihenfolge sollte eine ältere Kontomomentaufnahme nicht ohne Abgleich eine spätere bestätigte Ausführung überschreiben lassen. Bewahren Sie die von der tatsächlichen Schnittstelle unterstützten Quellenidentitäten und Reihenfolgeinformationen.
Der frühere Leitfaden zum automatisierten Quotenhandel trennt Datenströme von Befugnissen. Diese Unterscheidung wird hier sichtbar: Dieselbe Ereignisprognose kann unverändert bleiben, während Kontobelege fortlaufend die gehaltene Menge und die für die nächste Entscheidung verfügbare Kapazität verändern.
Ein Quellenausfall darf die Position nicht auslöschen
Nehmen wir nun an, die benannte Ereignisdatenquelle sei nicht mehr verfügbar. Der Ereigniszustand sollte erfassen, dass die für neue Prognosen erforderlichen Belege unsicher sind. Der Bot kann nach seiner Regel neue Empfehlungen pausieren oder unausgeführte Erlaubnisse widerrufen. Er sollte die bestehende Position nicht auf null setzen oder annehmen, externe Orders seien verschwunden.
Der Kontoprozess läuft weiter. Er muss weiterhin Ausführungen abgleichen, offene Verpflichtungen untersuchen und die vorbestimmte Reaktion auf veraltete Ereignisbelege anwenden. Verlangt der Plan die Stornierung der Restmenge von 24 Einheiten, ist diese Stornierung eine Kontohandlung mit eigenen ausstehenden und endgültigen Zuständen. Ein Datenquellenausfall beweist nicht, dass die Stornierung erfolgreich war.
Diese Trennung hilft der bedienenden Person, den Vorfall zu verstehen. Das Quellenproblem beeinflusst das Vertrauen in neue Entscheidungen, während die Kontounterlagen das aktuelle Risiko feststellen. Eine klare Meldung sagt, welche Belege fehlen, welche Orders noch möglich sind und welche Handlungen blockiert sind. Ein einzelner Status „nicht verbunden“ kann nicht alle drei Aussagen vermitteln.
Der verwandte Artikel zu Krypto-Ereignismärkten untersucht vielfältige Ereignisbedingungen. Unterschiedliche Quellenausfälle können für diese Bedingungen unterschiedliche Folgen haben, sodass der Bot nicht auf jeden überwachten Markt dieselbe universelle Ersatzquelle oder Ergebnisannahme anwenden sollte.
Weiterempfehlen und USDC verdienen
Weiterempfehlen und USDC verdienenUnser Partnerprogramm zahlt in Echtzeit.
Stornierung kann mit Ausführung im Wettlauf stehen
Während des fiktiven Stornierungsintervalls werden zehn zusätzliche Einheiten zu 0,55 $ für 5,50 $ ausgeführt. Die endgültig ausgeführte Menge steigt auf 160, und die stornierte Restmenge beträgt 14. Nehmen Sie an, die bestätigten zusätzlichen Gesamtkosten der erworbenen Position lägen nun bei 2,20 $. Die Kaufausgaben betragen 84,50 $ und die Gesamtkosten 86,70 $.
Der Bot muss diese tatsächlichen Aufzeichnungen verwenden, selbst wenn seine frühere lokale Erwartung 150 Einheiten war. Sobald die endgültig stornierte Menge maßgeblich feststeht, kann er die ungenutzte Restmengenreservierung freigeben. Die getrennte Verpflichtung von 20 $ besteht weiterhin, sodass tatsächliche oder reservierte Beträge in diesem vereinfachten Beispiel zusammen 106,70 $ betragen und 13,30 $ unter der Grenze von 120 $ liegen.
Eine sofort teilweise ausgeführte Order würde eine andere Restmengenbehandlung erfordern. Fill-and-Kill-Verhalten storniert beispielsweise den unausgeführten Rest automatisch, statt ihn im Orderbuch zu belassen. Der Adapter sollte tatsächlichen Ordertyp und Endergebnis verwenden, statt jede teilweise ausgeführte Anweisung als bestehen bleibende Verpflichtung mit derselben notwendigen Stornierungsfolge zu behandeln.
Die Vorfallaufzeichnung sollte Ausführungszeit von Empfangszeit unterscheiden, wenn die Schnittstelle beide liefert. Eine spät eintreffende Meldung kann eine vor Wirksamwerden der Stornierung erfolgte Ausführung beschreiben. Dieser Beleg sollte das Konto aktualisieren, ohne zu suggerieren, der Handelsplatz habe nach endgültiger Stornierung einen neuen Handel ausgeführt.
Wiederherstellung eines Bots für Krypto-Prognosemärkte braucht die ursprüngliche Versuchsidentität
Eine verlorene Übermittlungsantwort erzeugt Unsicherheit über den ursprünglichen Versuch. Der Bot sollte dessen Identität, Freigabe und höchstmögliche Wirkung bewahren, während er die unterstützten Kontounterlagen abfragt. Eine neue unabhängige Order ist nicht gleichbedeutend mit Untersuchung oder sicherer Wiederholung des bestehenden Versuchs nach den tatsächlichen Regeln des Handelsplatzes.
Wiederherstellung sollte einen Prozessneustart überdauern. Bevor der neu gestartete Bot neue Anweisungen annimmt, muss er ungeklärte Versuche, aktive Orders und Bestände rekonstruieren. Eine Startroutine, die nur das zuletzt angezeigte Guthaben lädt, kann eine unmittelbar vor dem Absturz erzeugte Verpflichtung übersehen. Dauerhafter Kontoverlauf gehört zum Risikokonzept.
Unterschiedliche maßgebliche Befunde erfordern unterschiedliche nächste Schritte. Eine bestätigte Ablehnung kann reservierte Kapazität freigeben. Eine aktive Order erfordert Überwachung oder Stornierung. Eine Teilausführung verändert Bestände und kann eine Restmenge lassen. Eine vollständige Ausführung belegt eine Menge, die bis zu Ausstieg oder Abwicklung verwaltet werden muss. Eine allgemeine Wiederholungshandlung kann nicht alle vier korrekt behandeln.
Der verwandte Leitfaden zur Plattform für Krypto-Prognosemärkte bewertet, ob tatsächlicher Handelsplatz und Kontomodell den vorgesehenen Ablauf unterstützen. Wiederherstellungsentwurf sollte auf verfügbaren maßgeblichen Aufzeichnungen beruhen und nicht auf vorgestellten Fähigkeiten, weil diese die Architektur bequem machen würden.
Ereignisfeststellung von Handelsabwicklung getrennt halten
Der Handel selbst kann einen Abwicklungs- oder Bestätigungsprozess haben, während das Ereignis später die Anspruchsauszahlung bestimmt. Das sind unterschiedliche Stufen. Eine erworbene Position braucht gültige Kontobelege, bevor der Bot sie verwalten kann, und ein späterer Ereignisausgang braucht eine eigene maßgebliche Feststellung vor der abschließenden Auszahlungsbuchhaltung.
Beim fiktiven Bestand von 160 Einheiten zahlt ein gewöhnliches Gewinnergebnis 160 $ und ergibt bei angenommenen fehlenden weiteren Kosten 73,30 $ gegenüber den Gesamtkosten von 86,70 $. Ein Verlustergebnis zahlt null und verliert 86,70 $. Das sind die Zweige der Position; die getrennte Reservierung von 20 $ gehört zu einer anderen Verpflichtung und sollte nicht in die Gewinnberechnung dieses Handels eingesetzt werden.
Wird das Ereignis beobachtbar, während Kontounterlagen unvollständig bleiben, bewahren Sie beide Zustände. Der Bot kann die Belege für den erwarteten Ausgang erfassen, ohne eine gutgeschriebene Auszahlung zu erfinden. Umgekehrt bleibt eine bestätigte Ausführung ein realer Bestand, auch wenn die zur Ereignisschätzung benötigte Quelle nicht verfügbar ist.
Dieser Ansatz mit zwei Verläufen vermeidet eine häufige betriebliche Abkürzung: alles als abgeschlossen zu markieren, weil das Ereignis vorbei ist. Das System muss weiterhin verbleibende Orders, Mengen, zusätzliche Kosten und die tatsächliche Kontogutschrift abgleichen. Eine Kalendergrenze ist kein Buchhaltungsnachweis.
Die Datenaufzeichnung um Bedeutung herum entwerfen
Speichern Sie rohe Beobachtungen neben ihrer interpretierten Bedeutung. Ein Preis braucht Einheit, Quelle, Ergebniskonvention und Zeitpunkt. Eine Menge braucht ihre zulässige Genauigkeit. Eine Regelzuordnung braucht eine Version. Abgeleitete Werte wie geschätzter Vorteil oder reserviertes Kapital sollten die Eingaben benennen, die sie erzeugt haben.
Aktuelle Handelsplatzkonventionen müssen im Adapter bleiben. Kalshis Festkommadokumentation zeigt, weshalb Annahmen ganzzahliger Cent und ganzer Einheiten veralten können. Ein Adapter sollte die aktuell unterstützte Genauigkeit bewahren und tatsächliche Marktbeschränkungen validieren, statt Informationen wegzunormalisieren, die das Konto zum Abgleich braucht.
Ein nur auf Quellen beruhender Modellwert sollte ohne Belege nicht zu einer kalibrierten Wahrscheinlichkeit befördert werden. Ebenso sollte ein Marktpreis nicht allein durch ein Prozentzeichen in der Anzeige zu einer objektiven Wahrscheinlichkeit werden. Die Entscheidungsaufzeichnung des Bots sollte angeben, was jede Zahl bedeutet und welche Unsicherheit sie trägt.
Diese Definitionen machen Fehler diagnostizierbar. Weicht eine Kostenschätzung vom Buchführungsjournal der Ausführungen ab, kann eine prüfende Person Einheiten, Seitenumrechnung, Markttiefe und zusätzliche Kosten getrennt untersuchen. Ohne Herkunftsangaben meldet das System möglicherweise nur, dass zwei Summen nicht übereinstimmen, und lässt die bedienende Person die gescheiterte Annahme nicht erkennen.
Übergänge prüfen, die Geld oder Menge verändern
Abnahmetests sollten eine bekannte Folge mit unabhängig berechneten Antworten durchspielen. Die fiktive Freigabe über 174 Einheiten, die Teilausführung von 150 Einheiten und der endgültige Bestand von 160 Einheiten bieten eine solche Folge. Erwartete Kosten- und Reservierungswerte sollten nach jedem Übergang geprüft werden und nicht nur beim endgültigen günstigen Ausgang.
Ergänzen Sie Tests für eine doppelte Ausführung, eine fehlende Referenz, eine geänderte Regelversion und einen nach Neustart ungeklärten Versuch. Der Bot sollte unterschiedliche Unsicherheitszustände bewahren und die passenden Einschränkungen anwenden. Ein erfolgreicher Test kann die Weigerung sein zu übermitteln, wenn nötige Belege oder Befugnis fehlen.
Verwechseln Sie Simulation nicht mit Handelsplatzvalidierung. Ein lokaler Test kann belegen, dass der Bot die bereitgestellten Aufzeichnungen schlüssig behandelt, reproduziert aber möglicherweise weder Priorität beim Abgleich von Kauf- und Verkaufsorders noch echte Verzögerung oder jede außergewöhnliche Abwicklung. Benennen Sie den Umfang und ergänzen Sie Belege aus unterstützten reinen Lesetests oder angemessen begrenzten Kontotests nur, wenn sie tatsächlich durchgeführt wurden.
Die nützlichste Abnahmeaufzeichnung kann von jemandem verstanden werden, der das System nicht gebaut hat. Die Person sollte erklären können, was freigegeben wurde, was ausgeführt wurde und weshalb die nächste Handlung erlaubt war. Ein Test, der lediglich prüft, ob das Programm seine eigenen Eingabefelder wiederholt, bietet erheblich weniger Gewissheit.
Prüfen, welcher Verlauf aktuell ist
Erstellen Sie einen Test, in dem Ereignisbelege frisch sind, private Kontounterlagen aber verspätet. Das Modell kann eine neue Schätzung erzeugen, doch der Freigabeprozess kann nicht sicher annehmen, eine frühere Order sei gescheitert oder ihre reservierte Kapazität sei frei. Die richtige Reaktion kann sein, die Prognose zu bewahren und eine neue Verpflichtung zu blockieren, bis der Kontoabgleich aufgeholt hat.
Kehren Sie nun die Situation um. Kontounterlagen sind aktuell und zeigen einen bekannten Bestand, aber die benannte Referenzquelle ist veraltet. Der Bot kann weiterhin Ausführungen erfassen, offene Orders prüfen und einer bereits freigegebenen Wiederherstellungsregel folgen. Er sollte aus fehlenden Daten keine neue Ereignisschätzung erfinden. Aktuelles Kontowissen repariert keine nicht verfügbare Prognoseeingabe.
Stellen Sie schließlich eine bestätigte Ereignisfeststellung bereit, während die Auszahlungsaufzeichnung noch aussteht. Der Ereignisverlauf kann in seinen Endzustand übergehen, während der Kontoverlauf unvollständig bleibt. Neue Kapitalzuteilungen sollten bestätigte verfügbare Mittel und nicht den erwarteten Eingang verwenden. Diese Fälle zeigen, weshalb eine einzige allgemeine Kennzeichnung „funktionsfähig“ den gesamten Ablauf nicht genau beschreiben kann.
Die Oberfläche kann einfach bleiben und diese Unterscheidungen zugleich bewahren. Sie kann aktuellen Ereignisbelegzustand, aktuellen Vertrauensstand zum Konto und die praktische Folge für die nächste Handlung zeigen. Das Ziel ist nicht, jedes interne technische Detail offenzulegen. Es besteht darin, den Grund für Beobachtung, Verzicht oder fortgesetzten Abgleich so klar zu machen, dass eine bedienende Person das Systemverhalten beurteilen kann, ohne erraten zu müssen, welchem Verlauf es vertraut.
Der bedienenden Person eine konkrete zu klärende Unsicherheit geben
Kann automatische Wiederherstellung den Zustand nicht feststellen, benötigt die bedienende Person eine knappe Darstellung der ungeklärten Tatsache. Die Meldung sollte betroffenen Kontrakt und Versuch, geprüfte Belege, höchstmögliche verbleibende Verpflichtung und blockierte Handlungen benennen. So erhält die Person eine konkrete Entscheidung statt einer vagen Aufforderung, den Bot neu zu starten.
Halten Sie Ereignis- und Kontomeldungen getrennt. Fehlende Referenzbelege können Verzicht auf neue Prognosen erfordern. Ein unbekannter Orderzustand kann fortgesetzte Reservierung und Kontountersuchung erfordern. Ein Regelkonflikt kann Kontraktprüfung erfordern. Sie als ein einziges Verbindungsproblem zu behandeln fördert eine allgemeine Reaktion, die möglicherweise keines davon löst.
Bedienhandlungen sollten eigene Aufzeichnungen hinterlassen. Gibt eine Person eine begrenzte Wiederherstellung frei oder ändert eine Zuordnung, bewahren Sie Grund und Version. Ein manueller Eingriff gehört zur tatsächlichen Methode und sollte in späteren Leistungs- und Vorfallprüfungen sichtbar bleiben.
Ein Bot für Krypto-Prognosemärkte ist verständlich, wenn Ereignisbelege und Kontoverpflichtungen über Änderungen hinweg schlüssig bleiben. Die begrenzte Freigabe verbindet sie, ohne ihre Unterschiede auszulöschen. Dieses Konzept erlaubt dem System zu beobachten, zu verzichten, auszuführen und wiederherzustellen, mit Aufzeichnungen, die sowohl sein Wissen als auch die von ihm tatsächlich verursachten Kontohandlungen erklären.