Module

Vierzehn Module. Drei Ringe. Ein Register.

Das geprüfte Maschinenregister definiert vierzehn Domänen in drei Ringen, derzeit alle mit Status ui. Tenant-Entitlements, Integrationsreife und Produktionsverfügbarkeit werden separat bestätigt; ein Registereintrag bedeutet nicht GA.

Entdecken Sie den Pfad zwischen den Sternen

Sechs Reisen durch einen Himmel.

Jedes Kapitel der Nacht durchquert dieselben vierzehn Module anders. Wählen Sie ein Kapitel, um seine Route zu zeichnen — Stern für Stern, vom ersten Signal bis zum Artefakt.

Inject
The ORION constellation · live contract traffic 03:17:08

Decision Record · live

press “◉ Follow”

◆ You are the checker · DOCKET gate

Held and step-up work waits for your distinct review. Self-approval does not exist here.

    Queue empty — the night is under control.

    Event ticker

      Fahren Sie über einen Stern, um zu sehen, welche Reisen ihn durchqueren. Wählen Sie ein Kapitel, um seine Route zu bereisen.

      03:17 03:17 — Der Continuity Room
      1. 03:17:08 — SWITCH erfasst die ausfallende Route und hält den 320er-Split sichtbar.
      2. 03:17:09 — SENTINEL wendet payment-continuity@demo-3.2 an: 48 Versuchen fehlt der Kontext.
      3. 03:17:20 — PULSE trennt geeigneten Traffic von Step-up-Kandidaten, mit Gründen.
      4. 03:21 — DOCKET eröffnet CASE-DEMO-0317 und führt den Maker–Checker-Austausch.
      5. 03:24 — VAULT verankert DR-DEMO-0317, damit die Nacht rekonstruierbar bleibt.
      6. 03:30 — PRISM hält Split, Holds und Ablauf für die Morgenprüfung sichtbar.
      7. 03:32 — FORGE trägt die Webhook-Spur vom Anbietersignal zur Entscheidung.
      8. Die Route endet im Kontinuitätsübungsbericht — Kapitel eins des Dossiers. Dieses Kapitel starten →
      09:00 Ein Händler — fünf Realitäten
      1. 09:00 — GATE fixiert den Identitätskontext von Lumen Digital, bevor eine Linse öffnet.
      2. 09:05 — SENTINEL screent die beantragte Änderung und zeichnet die Disposition auf.
      3. 09:12 — PULSE liest die Risikolage gegen den beantragten Korridor neu.
      4. 09:18 — SWITCH zeigt, für welche Routen die Änderung tatsächlich geeignet wäre.
      5. 09:24 — LEDGER trennt das laufende Settlement vom vorgeschlagenen Begünstigten.
      6. 09:30 — DOCKET hält einen Fall, während fünf Funktionen fünf Linsen anlegen.
      7. 09:40 — VAULT verzeichnet Bedingung, Owner und Review-Punkt in DR-DEMO-MERCHANT-084.
      8. Die Route endet im Gemeinsamen Händler-Entscheidungsvermerk — eine Wahrheit, fünf Linsen. Dieses Kapitel starten →
      14:00 Proof Lab — Stellen Sie die Entscheidung auf die Probe
      1. 14:00 — VAULT liefert die Sandbox-Kopie: TEST-DEMO-0317, das Original unberührt.
      2. 14:05 — DOCKET spielt nach, wer entschied und wer prüfte — bereit zum Brechen.
      3. 14:10 — SENTINEL legt die gepinnte Policy-Version offen, die ein Prüfer entfernen würde.
      4. 14:20 — FORGE zeigt den begrenzten 48-Stunden-Grant, der auf Abruf abläuft.
      5. Die Route endet im Nachweisprüfbericht — Vertrauen endet, wo die Evidenz endet. Dieses Kapitel starten →
      Tag 3 Tag 3 — Die Sperre
      1. H+2 — SWITCH begrenzt den Hold: Auszahlungen pausieren, Verkauf läuft ins Escrow.
      2. H+2 — STUDIO stellt die markierte Listung mit Einspruchsweg unter Quarantäne.
      3. H+3 — SENTINEL lässt prohibited-items@demo-4.1 über 1.240 Listungen neu laufen.
      4. H+8 — GATE frischt das KYB auf: Begünstigter unverändert.
      5. H+9 — PULSE bewertet den Händler neu, mit aufgezeichneten Gründen.
      6. H+10 — DOCKET bündelt jede Aktion in CASE-DEMO-2031.
      7. H+12 — LEDGER beziffert das Exposure: 182.400 € einbehalten (DEMO).
      8. H+40 — VAULT mappt alle vierzehn Fragen auf aufgezeichnete Evidenz.
      9. H+60 — PRISM stellt Exposure- und Screening-Summen für das Paket zusammen.
      10. H+70 — FORGE benachrichtigt den Händler über den aufgezeichneten Kanal.
      11. H+71 — HELM belegt, wer handeln durfte — und dass niemand sonst handelte.
      12. Die Route endet im RFI-Antwortpaket — 14/14 belegt in 72 Stunden. Dieses Kapitel starten →
      Tag 90 Erstellen Sie Ihre Control Map
      1. Tag 90 — GATE markiert, wo Identitätskontext in die Pilotstrecke einträte.
      2. PULSE markiert den Scoring-Hook — Regeln zuerst, Modell optional.
      3. SWITCH markiert den Routing-Read, den die Evaluation beobachten würde.
      4. LEDGER markiert Settlement und Steuerbasis, die die Strecke berühren kann.
      5. SENTINEL markiert die Policy-Packs als Ausgangshypothese.
      6. PRISM markiert die Wochenmessung gegen die vereinbarte Baseline.
      7. DOCKET markiert, wo Ausnahmen zu Fällen mit Owner werden.
      8. VAULT markiert das Evidenz-Gate, das das Tag-90-Urteil liest.
      9. HELM markiert die Entitlements, die den Pilotumfang begrenzen.
      10. FORGE markiert Sandbox-Keys und Webhooks für die Integration.
      11. Die Route endet im 90-Tage-Pilotplan — skalieren, anpassen oder beenden. Dieses Kapitel starten →
      04:12 04:12 — Die zweite Nacht
      1. 04:12:07 — SENTINEL trifft die Vorwurfsklasse (konzipierter Lauf).
      2. 04:12:08 — PULSE bewertet 0.94 mit Begründungscodes — konzipiert; das Registermodell ist ein Stub.
      3. 04:12:09 — STUDIO stellt die Listung unter Quarantäne, Einspruchsweg inklusive.
      4. 04:12:11 — SWITCH setzt den begrenzten Auszahlungs-Hold automatisch.
      5. 04:12:38 — GATE re-verifiziert den Begünstigten: unverändert.
      6. 04:13:02 — DOCKET stellt DCK-DEMO-2044 mit voller Korrelation zusammen.
      7. 04:13:04 — VAULT paketiert EVP-DEMO-2044, bevor jemand aufwacht.
      8. 04:13:05 — FORGE hält die Benachrichtigungs-Templates hinter dem menschlichen Gate.
      9. 04:15 — PRISM entwirft den Morgenbericht für die 09:00-Prüfung.
      10. 04:12–07:00 — HELM hält das eine Gate geschlossen: Nur der MLRO gibt frei.
      11. Die Route endet im Nachtprotokoll — die Maschine lief, der Mensch entschied. Dieses Kapitel starten →
      TrustStack Core — Registrierte Core-Domänen mit ui-/Leseflächen. Eine oder mehrere erst nach Funktions- und Integrationsvalidierung in den Umfang aufnehmen.
      GATE · Verifizieren
      Identitätskontext sichtbar machen, bevor sich der Umfang ändert.
      Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA

      GATE macht sichtbar, wer oder welche Partei geprüft wird, was tatsächlich aufgezeichnet wurde und welche Bedingung offen bleibt. Es belegt für sich weder ein vollständiges KYC/KYB-Programm noch einen UBO-Workflow oder einen allgemein verfügbaren Onboarding-Service.

      Aktuelle Oberfläche: gehostete KYC- und Parteien-Leseansichten; Review ist Feature-Flag-gesteuert; UBO-Erfassung fehlt im geprüften Stand.

      • Beobachtete gehostete KYC- und Parteien-UI-/Leseflächen
      • Review-Pfad hinter einem Feature Flag, nicht für jeden Tenant vorausgesetzt
      • UBO-Erfassung fehlt im geprüften Stand und bleibt eine Validierungsanforderung
      • Dafür konzipiert, aufgezeichneten Identitätskontext an Screening-, Policy- und Fall-Workflows weiterzugeben
      • Step-up, Re-Verifizierung und Dokumentnachweise erfordern eine Konfiguration für den jeweiligen Entscheidungsweg
      Im Handbuch lesen
      PULSE · Risiko
      Aufgezeichnete Signale in eine prüfbare Entscheidung übersetzen.
      Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA

      PULSE soll verfügbare Risikosignale mit einer anfechtbaren Entscheidung verbinden. Im geprüften Stand ist die ehrliche Proposition eine explorative UI mit partieller Begründung — kein vollständiges Echtzeit-Scoring, keine universelle Erklärung und kein belegtes Fraud-Ergebnis.

      Aktuelle Oberfläche: Decision Explorer mit partieller Begründung; der ML-Indikator ist ein Stub und kein Nachweis für ein aktives Modell.

      • Beobachteter Decision Explorer und partielle UI-/Leseflächen zur Begründung
      • Regelbasiertes Entscheidungsmuster; jede Modellnutzung ist optional und separat zu validieren
      • Der aktuelle ML-Indikator ist ein Stub und darf nicht als aktives Modell dargestellt werden
      • Konzipierte Aktionen umfassen Genehmigen, Step-up, Review und Hold, sofern konfiguriert
      • Fehlender Eingabe-, Schwellen- oder Versionskontext bleibt explizit, statt abgeleitet zu werden
      Im Handbuch lesen
      SWITCH · Zahlungen
      Zahlungspfad, Auswahl und Grenzen sichtbar machen.
      Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA

      SWITCH macht den vorgeschlagenen Pfad, gehaltenen Traffic und verfügbaren Pfadkontext prüfbar. Eine begrenzte Übung kann das Kontrollmuster testen; Live-PSP-Anbindung, Routing-Leistung, Resilienz und Service Levels müssen separat belegt werden.

      Aktuelle Oberfläche: partielle Routing-Konfiguration und Zahlungspfad-Leseansichten; daraus sind weder Live-Provider noch automatischer Failover abzuleiten.

      • Beobachtete partielle UI-/Leseflächen zur Routing-Konfiguration
      • Beobachtete Zahlungspfad-Leseansichten für verfügbare Fixture-Daten
      • Konzipierte Routing-Faktoren umfassen Provider-Status, Eligibility, Geografie, Kosten und Risikokontext
      • Payout-, Retry- und Fallback-Verhalten hängt von angebundenen Providern und validierter Policy ab
      • Die UI belegt weder Produktions-Traffic noch Provider-Redundanz oder automatischen Failover
      Im Handbuch lesen
      LEDGER · Steuern & Finanzen
      Bücher und Steuerannahmen aktenkundig machen.
      Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA

      LEDGER kann einen starken Finance-Anker liefern, wenn Quelle, Buchungsstatus und Rekonziliationskontext verfügbar sind. Das Steuerergebnis bleibt eingabeabhängig: Jurisdiktion, Satzquelle, Basisdatum und Berichtszweck müssen validiert und dürfen nicht vorausgesetzt werden.

      Aktuelle Oberfläche: Bücher sind der stärkste beobachtete Bereich; Steuersätze sind statisch und müssen mit dem Datum ihrer Berechnungsgrundlage gezeigt werden.

      • Beobachtete UI-/Leseflächen für Bücher und Finanzen
      • Statische Steuersätze im geprüften Stand; stets das Datum der anwendbaren Berechnungsgrundlage ausweisen
      • Dafür konzipiert, Steuereingaben, Grundlage und Ergebnis als datierten Entscheidungs-Snapshot zu bewahren
      • Rekonziliation, Wallet- und Exportverhalten bleiben workflow- und integrationsabhängig
      • Keine Aussage zu automatischer Abgabe, universeller steuerlicher Richtigkeit oder unveränderlichen Büchern
      Im Handbuch lesen
      SENTINEL · Policy
      Sichtbar machen, welcher Policy-Kontext die Entscheidung steuerte.
      Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA

      SENTINEL soll beantworten, welche Policy und Disposition eine Aktion beeinflussten. Die geprüfte Oberfläche kann dieses Kontrollmuster demonstrieren, aber weder Vollständigkeit von Sanktionslisten noch universelles Vier-Augen-Prinzip, automatische Durchsetzung oder regulatorische Compliance.

      Aktuelle Oberfläche: Screening- und Policy-Leseansichten nutzen eine DEMO-Liste; Listenabdeckung und Live-Feeds sind nicht belegt.

      • Beobachtete Screening- und Policy-UI-/Leseflächen
      • Die aktuelle Screening-Quelle ist eine DEMO-Liste und muss entsprechend gekennzeichnet sein
      • Der konzipierte Policy-Kontext umfasst Geo-, Produkt-, Alters- und Zahlartenbedingungen
      • Versionierung, Freigabe und Rollback hängen vom konfigurierten Governance-Workflow ab
      • Runtime-Regelbereitstellung und externe Screening-Feeds erfordern Integration und Validierung
      Im Handbuch lesen
      PRISM · Einblicke
      Verfügbare Betriebsdaten in eine begrenzte Sicht übersetzen.
      Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA

      PRISM kann in einer Evaluation prüfen helfen, ob dieselben aufgezeichneten Fakten eine nützliche Betriebs- und Nachweissicht ergeben. Reproduzierbarkeit hängt von vollständigen Quelldaten, Definitionen, Versionen und Exportlogik ab; die aktuelle UI belegt kein geplantes Produktionsreporting.

      Aktuelle Oberfläche: Dashboards und auf Abruf erzeugte Scorecards; geplantes Reporting, SLA-Monitoring und regulatorfertige Ausgaben sind nicht belegt.

      • Beobachtete Dashboard-UI-/Leseflächen für verfügbare Betriebsdaten
      • Scorecards werden im geprüften Stand auf Abruf und nicht automatisch nach Zeitplan erzeugt
      • Konzipierte Vergleiche erfordern vereinbarte Baseline, Definitionen und Berichtszeitraum
      • Fragebögen und Auszüge bleiben zweck-, rollen- und quelldatenabhängig
      • Kein öffentliches SLA-Monitoring, regulatorfertiger Bericht oder Kunden-KPI-Ergebnis wird behauptet
      Im Handbuch lesen
      Optionale Add-ons — Entitlement-gesteuerte Erweiterungen für spezifische Pflichten — aktiviert, wo machbar und lizenziert.

      MoR ist im geprüften Stand eine partielle ui-/Lesefläche; jede Bereitstellung hängt von Jurisdiktion, Lizenzierung, rechtlicher Prüfung und Vertrag ab. Registry-Status →

      Plattform-Ring — immer aktiv — Gemeinsame Fall-, Nachweis-, Administrations- und Entwicklerbasis in der Zielarchitektur. Zugriff und Verhalten bleiben rollen-, entitlement- und deploymentabhängig.

      Module komponieren über Verträge

      Die Zielverträge verbinden GATE-Identitätskontext mit SENTINEL-Screening, lassen PULSE gesteuerte Regel-Packs nutzen und Fälle in DOCKET eröffnen und führen verfügbare Audit-Ereignisse zu VAULT sowie Reporting-Daten zu PRISM. Exakte Produzenten, Felder und Durchsetzung werden je Workflow validiert; fehlende Nachweise werden nicht abgeleitet.

      Benutzerhandbuch öffnen