Ein n8n-Flow, der jede eingehende NDA, die bei einem dedizierten nda-intake@-Postfach ankommt, abfängt, das Risiko-Tier der Gegenseite aus einem Postgres-Registry klassifiziert, das Dokument durch Claude Sonnet 4.6 gegen Ihr NDA-Playbook leitet und entweder den Vertrag automatisch in Ironclad genehmigt oder ihn an einen benannten Prüfer in Slack mit der klauselweisen Zusammenfassung im Anhang routet. Konzipiert für Inhouse-Teams, die 50+ NDAs pro Monat bearbeiten, wo die Triage beim Eingang — nicht die Verhandlung — die Rechtsstunden verbraucht.
Das herunterladbare Bundle befindet sich unter apps/web/public/artifacts/nda-intake-triage-n8n/ und enthält die vollständige Workflow-JSON plus ein Setup-README. Das Bundle ist das Lieferobjekt; diese Seite erklärt, wann und wie es zu verwenden ist.
Wann verwenden
Verwenden Sie diesen Flow, wenn drei Dinge gleichzeitig zutreffen. Erstens: Ihr Team verarbeitet genug NDAs, dass das Volumen selbst das Problem ist — typischerweise 40+ pro Monat, wo die marginale NDA im Wesentlichen identisch mit der vorherigen ist und das Rechtsteam als Flaschenhals für die kommerzielle Geschwindigkeit agiert statt als strategisches Gate. Zweitens: Sie haben ein tatsächliches Playbook — eine schriftliche Liste von Klauselfamilien, Ihre Standard-Papier-Position zu jeder, Ihre autorisierten Fallback-Positionen und den Walk-Away-Schwellenwert. Wenn das Playbook im Kopf von jemandem lebt, hat der KI-Schritt nichts zum Vergleichen und Sie erhalten hochkonfidentes Rauschen. Drittens: Sie haben ein Gegenseiten-Registry in irgendeiner abfragbaren Form — Postgres, Airtable, sogar ein nächtlich exportiertes Google Sheet — das E-Mail-Domains auf ein Risiko-Tier abbildet. Ohne es fällt jede Gegenseite in „unbekannt” und der Flow tut nichts Nützliches.
Der Flow glänzt bei eingehendem Gegenseitenpapier von bekannten kommerziellen Partnern — die klassischen Fälle Lieferanten-NDA-vor-RFP und Interessent-NDA-vor-Preisanruf. Er ist auch als Erstdurchgangs-Filter bei ausgehenden NDAs nützlich, die Ihr Vertriebsteam aus einem Salesforce-getriggerten Template heraus startet, wo die einzig mögliche Abweichung die Redline der Gegenseite zurück zu Ihnen ist.
Wann NICHT verwenden
Überspringen Sie diesen Flow für jede Vertragsart, die keine Vanilla-NDA ist. Die Klausel-Taxonomie im System-Prompt ist nur für Vertraulichkeitsvereinbarungen kalibriert — ihn mit einem MSA, DPA oder Dienstleistungsvertrag zu füttern produziert konfidente Ausgaben gegen die falsche Checkliste, was das schlimmste mögliche Fehlermuster ist. Bauen Sie einen separaten Flow pro Vertragsfamilie, wenn Sie erweitern möchten.
Überspringen Sie ihn für M&A-NDAs, Government-Contracting-NDAs und jede NDA, die mit einem Litigation-Hold verbunden ist. Diese benötigen von der ersten Minute an die Aufmerksamkeit des GC, und die Zeit, die der Flow bei der Triage spart, wird durch die politischen Kosten eines verpassten Eskalations-Signals überwogen. Diese über eine separate Intake-E-Mail routen, die die Automatisierung vollständig umgeht.
Überspringen Sie ihn im ersten Monat nach einer wesentlichen Playbook-Änderung — Klauseln hinzugefügt, neue Fallback-Positionen, ein Tier-Rebalancing im Registry. Der Claude-Prompt kodiert das Playbook implizit durch die System-Nachricht; Sie benötigen ein manuelles Prüffenster, um zu erkennen, wo das Modell und die neue Policy nicht übereinstimmen, bevor Sie der automatischen Genehmigung wieder vertrauen.
Überspringen Sie ihn völlig, wenn Sie weniger als ~15 NDAs pro Monat verarbeiten. Die Setup-Zeit (60 Minuten plus die Playbook-Kodifizierungsarbeit, die die eigentlichen Kosten sind) amortisiert sich bei diesem Volumen nicht innerhalb eines Jahres. Ein gemeinsames Postfach und ein Rechtsanwaltsfachgehilfe mit einer Checkliste ist die bessere Antwort.
Setup
Folgen Sie dem README unter apps/web/public/artifacts/nda-intake-triage-n8n/_README.md für den vollständigen Credential- und Tabellenschema-Walkthrough. Die 30-Sekunden-Version: das dedizierte nda-intake@-Postfach einrichten, die Postgres-Tabellen counterparty_registry und nda_audit_log erstellen (DDL ist durch die Spaltenlisten im Credentials-Abschnitt des README impliziert), drei Ironclad-Workflow-Templates vorab erstellen (nda-review, nda-escalation und einen nda-Datensatztyp), einen Slack-Bot in #legal-ops-firehose, #legal-nda-queue und #legal-gc-escalations einladen, dann nda-intake-triage-n8n.json in n8n importieren und die fünf Credentials nach Namen binden.
Die fünf Smoke-Tests im Abschnitt „First-run verification” des README ausführen, bevor Sie den Workflow aktivieren. Der fünfte Test — den Claude-Prompt vorübergehend unterbrechen, um zu bestätigen, dass der Parser-Fehler-Fallback eskaliert statt still automatisch zu genehmigen — ist der, den die meisten Teams überspringen und am meisten bereuen.
Was der Flow tut
Der Trigger ist ein Gmail-Poll, der einmal pro Minute gegen das Intake-Postfach feuert, gefiltert auf Nachrichten mit PDF- oder DOCX-Anhängen und noch nicht mit nda-processed beschriftet. Ein Code-Knoten (Normalize Intake) extrahiert den Absender, base64-kodiert den Anhang und gibt einen typisierten Envelope aus; Nachrichten ohne nutzbaren Anhang werden in einen no_attachment-Status umgeleitet, den nachgelagerte Zweige angemessen behandeln statt den Workflow zum Absturz zu bringen.
Ein Postgres-Knoten (Counterparty Lookup) fragt das Registry nach Absender-Domain ab und gibt Risiko-Tier, bevorzugtes Papier und Freitext-Notizen zurück. Ein zweiter Code-Knoten (Merge Counterparty Context) standardisiert fehlende Zeilen auf risk_tier = 'unknown' statt zu scheitern — das konservative Override später fängt diesen Fall auf.
Der Claude-Aufruf (Claude — Playbook Check) sendet das Dokument als base64-Block an Sonnet 4.6 neben einer System-Prompt, die zehn Klauselfamilien nennt (Gerichtsstand, Laufzeit, Gegenseitigkeit, IP-Carve-Outs, Residuals, Non-Solicit, Freistellung, Ausschluss von Folgeschäden, Definition vertraulicher Informationen, Verletzungsbenachrichtigung) und striktes JSON-Output mit per-Klausel position, quote, suggested_redline und confidence sowie einem Top-Level recommendation von auto-approve, lawyer-review oder escalate verlangt.
Der nächste Code-Knoten (Apply Risk Rules) ist der Sicherheitsgurt. Er wendet drei Overrides in Prioritätsreihenfolge an: jede Walk-Away-Klausel erzwingt escalate unabhängig davon, was Claude gesagt hat; Gesamtkonfidenz unter 0,7 stuft jedes auto-approve auf lawyer-review herab; und jedes Nicht-Low-Risiko-Tier stuft auto-approve auf lawyer-review herab. Der Override-Grund wird in der Audit-Zeile gestempelt, damit Sie messen können, wie oft jede Guard auslöst.
Ein Switch-Knoten routet zu einem von drei Zweigen — Ironclad-Datensatz-Erstellung (auto-approve), Ironclad-Review-Workflow + Slack-Anwalts-Queue-Post mit Block-Kit-Zusammenfassung (lawyer-review) oder Ironclad-Eskalations-Workflow + GC-Kanal-Alert (escalate). Jeder Zweig konvergiert bei Audit Log Write, das eine einzelne Zeile mit dem Gmail-Nachrichten-ID als Schlüssel einfügt (sodass Retries idempotent sind), und dann Mark Gmail Processed, das das nda-processed-Label hinzufügt, damit der Trigger nicht erneut feuert.
Die erwähnenswerten Engineering-Entscheidungen: Sonnet 4.6 statt Haiku, weil Haiku Fallback-Klauseln verpasst (günstiger pro Aufruf, aber teurer pro falscher Genehmigung); base64-Dokumentanhang statt Text-Extraktion, weil PDF-Text-Extraktion Formatierungshinweise verliert, die die Klauselbedeutung ändern; konservatives Override auf Code-Knoten-Ebene statt im Prompt, weil Nur-Prompt-Sicherheiten durch adversariales Gegenseitenpapier umgehbar sind; idempotentes Audit-Insert via ON CONFLICT (message_id) DO NOTHING, weil n8n bei transienten Postgres-Fehlern wiederholt und Sie keine doppelten Zeilen wollen; und Switch statt IF, weil Switch die Verbindungstopologie jedes Zweigs im n8n-Canvas visuell offensichtlich hält.
Kostenrealität
Die Anthropic-Kosten pro NDA sind die dominierende variable Ausgabe. Eine typische 4-seitige NDA serialisiert zu etwa 6.000–9.000 Input-Token (das Dokument plus System-Prompt und Gegenseiten-Kontext) und die strukturierte Antwort landet bei 800–1.200 Output-Token. Zu Sonnet 4.6 Listenpreisen von $3 pro Million Input-Token und $15 pro Million Output-Token sind das $0,018–$0,027 Input + $0,012–$0,018 Output, also ungefähr $0,03–0,045 pro NDA. Bei 100 NDAs pro Monat sind das $3–$5 API-Spend. Bei 1.000 NDAs pro Monat sind es $30–$45. Selbst mit einem 3x-Multiplikator für Retries bei langen Dokumenten und der gelegentlichen 10-seitigen MSA, die fälschlicherweise als NDA klassifiziert wird, bleibt die Monatsrechnung bei typischen Volumina unter $200.
n8n-Hosting ist die andere Position. Selbst gehostet auf einem $20/Monat-VPS verarbeitet Tausende von Ausführungen pro Tag. n8n Clouds Starter-Tier ist $24/Monat für 5.000 Ausführungen; wenn Ihr Intake-Postfach mehr als 5.000 Polls + verarbeitete Nachrichten-Ausführungen pro Monat auslöst (wird bei 200+ NDAs/Monat mit Einminuten-Polling so sein), benötigen Sie das Pro-Tier bei $60/Monat oder Self-Hosting.
Die tatsächlich relevante Kostenstelle sind die Legal-Stunden, die Sie vermeiden. Ein Rechtsanwaltsfachgehilfe, der eine NDA manuell triagiert, benötigt im Schnitt 12–15 Minuten pro Vertrag nur für den Lesen-Klassifizieren-Routen-Schritt. Bei einem $90/Stunde voll belastetem Fachgehilfen-Satz sind das $18–$22 pro NDA an menschlicher Zeit. Der $0,03 API-Spend des Flows ersetzt $20 Fachgehilfen-Zeit — ein 600x-Kostenverhältnis — aber nur, wenn Ihr Team der Auto-Approve-Branch tatsächlich vertraut und aufhört, jeden Vertrag dahinter erneut zu lesen. Teams, die jede Auto-Genehmigung doppelt prüfen, verlieren die Einsparungen; der Flow wird zu reinen Kosten. Planen Sie den Vertrauensaufbau-Rollout (Punkt 2 unter Fallstricke unten) bewusst.
Erfolgsmetrik
Verfolgen Sie zwei Zahlen wöchentlich. Zykluszeit vom Eingang bis zur Disposition (auto-approve, lawyer-review in Queue oder Eskalation in Queue) sollte für jeden Zweig unter 5 Minuten landen — Slack-Alert in der Queue, Ironclad-Datensatz existiert, Audit-Log-Zeile geschrieben. Wenn es über 5 Minuten driftet, ist Ihre Anthropic-API langsam oder n8n queued Ausführungen; untersuchen. Auto-Approve-Präzision ist die zweite Zahl: Von jeder NDA, die der Flow automatisch genehmigt hat, welcher Prozentsatz hätte ein menschlicher Prüfer unverändert genehmigt? Ziel 99% innerhalb von 60 Tagen nach Go-Live. Die wöchentliche False-Positive-Prüfung fragt nda_audit_log WHERE recommendation = 'auto-approve' AND overall_confidence < 0.85, sampelt 10 Zeilen und geht sie manuell durch das Playbook. Alles unter 99% Präzision bedeutet, dass der Playbook-Prompt oder die Override-Schwellenwerte verschärft werden müssen, bevor Sie das Volumen erhöhen.
Eine nützliche Begleitmetrik: Eskalationsrate. Unter 5% bedeutet, dass der Flow echte Arbeit leistet. Über 15% bedeutet, entweder ist das Registry zu klein (zu viele „unbekannte” Gegenseiten) oder das Playbook ist zu aggressiv bei der Klassifizierung von Klauseln als Walk-Away. Über 30% bedeutet, der Flow agiert als teures Routing für das, was im Wesentlichen manuelle Triage ist; entweder die Inputs reparieren oder den Flow abschalten.
Vergleich mit Alternativen
vs. manuelle Triage durch einen Rechtsanwaltsfachgehilfen. Ein erfahrener Fachgehilfe mit einer schriftlichen Checkliste kostet $18–$22 pro NDA und dauert 12–15 Minuten. Der Flow kostet $0,03 und dauert 90 Sekunden. Der Fachgehilfe ist bei Grenzfällen (Rechtsstreit-Trigger, ungewöhnliche Jurisdiktionen, neuartige Klauselstrukturen) dramatisch besser und bei Konsistenz und Volumen dramatisch schlechter. Die richtige Architektur ist beides — der Flow behandelt die 80% Vanilla-NDAs, die exaktes Papier oder eine-Klausel-Fallback sind, und der Fachgehilfe besitzt die Lawyer-Review-Queue mit seinem Urteil, das für die Verträge freigesetzt ist, die es wirklich brauchen. Den Fachgehilfen vollständig zu ersetzen ist das Fehlermuster; ihn zu augmentieren ist der Gewinn.
vs. einem Off-the-Shelf-CLM-Intake-Modul. Ironclad, Icertis, ContractWorks und ähnliche liefern alle Intake-Routing-Funktionen. Sie sind ausgezeichnet bei der „speichern, versionieren, an Genehmiger routen”-Hälfte des Problems und schwach bei der „gegen unser spezifisches Playbook klassifizieren”-Hälfte — ihre eingebaute KI tendiert zu einem generischen Klausel-Extraktor, der gegen eine generische Klauselbibliothek kalibriert ist, nicht gegen Ihre spezifischen Fallback-Positionen. Der Flow tauscht die Bequemlichkeit eines integrierten Produkts gegen die Präzision eines playbook-spezifischen Prompts. Wenn Ihr Playbook echte Vanilla-NDAs ist (Sie akzeptieren jede vernünftige gegenseitige NDA), ist das Off-the-Shelf-Modul in Ordnung und Sie sollten das nicht bauen. Wenn Ihr Playbook spezifische Positionen zu Residuals, IP-Carve-Outs oder Non-Solicits hat, die wichtig sind, ist der Prompt des Flows das, was es seinen Aufwand wert macht.
vs. einer manuellen Salesforce-zu-Ironclad-Routing-Regel. Ein Salesforce-Flow, der einen Ironclad-Workflow erstellt, wenn eine Opportunity ein Stadium erreicht, ist rein deterministisch — gleiche Routing, gleicher Prüfer, unabhängig vom Vertragsinhalt. Das ist in Ordnung für ausgehendes Papier, wo Sie das Dokument kontrollieren, aber nutzlos für eingehendes Gegenseitenpapier, wo die Routing-Entscheidung davon abhängen sollte, was der Vertrag tatsächlich sagt. Beides verwenden: Salesforce für ausgehende Trigger, diesen Flow für eingehende Klassifizierung.
Fallstricke
Gegenseitenregistry-Abdeckung treibt die Auto-Approve-Rate; ohne sie degradiert der Flow zu Lawyer-Review-on-everything. Fehlermuster: Registry-Abdeckung liegt unter 60% der eingehenden Absender, also landen 40%+ der NDAs beim non_low_risk_tier-Override und routen zur manuellen Prüfung, selbst wenn sie sauber sind. Schutz: Counterparty Lookup mit einer wöchentlichen Abfrage instrumentieren (SELECT count(*) FROM nda_audit_log WHERE counterparty_id IS NULL AND processed_at > now() - interval '7 days') und die Liste unbekannter Domains an denjenigen zurückgeben, dem das Registry gehört. Registry-Pflege als benannte Rolle behandeln, nicht als Nebenprojekt.
Playbook-Drift verursacht stille Fehlkalibrierung, wenn sich Policy schneller ändert als der Prompt. Fehlermuster: Legal aktualisiert die Residuals-Position, aber der System-Prompt in Claude — Playbook Check kodiert noch die alte Position, und Claude genehmigt Klauseln automatisch, die Ihr Team gerade als inakzeptabel entschieden hat. Schutz: Jede Playbook-Änderung hinter einem 30-tägigen manuellen Prüffenster absichern. Der Override, der jedes auto-approve bei risk_tier != 'low' auf lawyer-review herabstuft, mildert teilweise durch das Funneln von mehr Verträgen durch menschliche Augen; die härtere Absicherung ist eine vierteljährliche Diff-Prüfung zwischen den Klausel-Beschreibungen des Prompts und dem kanonischen Playbook-Dokument.
Parser-Fehler müssen immer eskalieren, nie auf Genehmigung standardisieren. Fehlermuster: Eine lange oder ungewöhnliche NDA veranlasst Claude, seine Antwort in Markdown-Fences zu kapseln, das JSON.parse in Apply Risk Rules wirft, und eine naive Implementierung könnte auf einen Standardzweig fallen und falsch routen. Schutz: Der Apply Risk Rules-Code-Knoten fängt die Parse-Ausnahme explizit ab und stempelt recommendation = 'escalate' mit escalation_reason: 'parser_error'. Diese Schutzmaßnahme nicht herausbearbeiten, und den Smoke-Test #5 des README jedes Mal ausführen, wenn Sie den Claude-Prompt ändern, um zu bestätigen, dass der Catch noch feuert.
Privilegierter Inhalt kann in den Anthropic-API-Aufruf einleaken, wenn Absender das Intake-Postfach mit dem allgemeinen Counsel verwechseln. Fehlermuster: Eine Geschäftseinheit leitet einen E-Mail-Thread, der ausstehenden Prozesskontext plus eine angehängte NDA enthält, an nda-intake@ weiter, und der gesamte Thread (Betreff, Body-Snippet, Anhang) landet in einem Anthropic-API-Request. Schutz: Der Code-Knoten begrenzt body_snippet derzeit auf 2.000 Zeichen, entfernt jedoch Body-Inhalt nicht; den Flow mit der KI-Policy für Legal-Teams kombinieren, um den Datenfluss explizit zu autorisieren, und einen Pre-Claude-IF-Knoten in Betracht ziehen, der Nachrichten mit Betreffs, die auf /litigation|privileged|attorney-client/i passen, in den GC-Eskalationszweig ohne LLM-Aufruf umleitet.
E-Mail-Kanal-Disziplin bestimmt, ob der Flow die Arbeit jemals sieht. Fehlermuster: Geschäftsteams ignorieren das Intake-Postfach und senden NDAs direkt an Anwälte, weil der Flow nur schneller ist nach der ersten NDA, und die erste NDA immer so gesendet wird, wie sie immer gesendet wurde. Schutz: Ein Autoresponder auf jedem individuellen Anwalt-Postfach (legal-bd@, gc@ usw.), der sagt „danke, bitte erneut an nda-intake@” senden kombiniert mit einer Weiterleitungsregel, die alles mit NDA-förmigen Anhängen automatisch routet. Die Kanal-Norm in den ersten 30 Tagen vorantreiben; überdenken, wenn das monatliche Volumen des Flows unter der Schätzung stagniert.
Stack
n8n für Orchestrierung, Claude Sonnet 4.6 für Klausel-Klassifizierung, Ironclad (oder Ihr bevorzugtes CLM) für Datensatzführung und nachgelagerten Signatur-Workflow, Slack für die Reviewer-Queue, Postgres für das Gegenseiten-Registry und das Audit-Log, Gmail für das Intake-Postfach. Siehe die Legal-Ops-Vertical für verwandte Workflows einschließlich der Contract-Review-SOP, in die dieser Flow als Tier-1-2-Triage-Schicht einsteckt.
# NDA intake triage — n8n flow
## What this flow does
This flow watches a dedicated `nda-intake@yourcompany.com` inbox once per minute and processes every inbound message that carries a `.pdf` or `.docx` attachment. For each message the flow extracts the sender domain, looks the counterparty up in your Postgres `counterparty_registry`, sends the contract document to Claude Sonnet 4.6 with the company NDA playbook in the system prompt, parses the structured clause-by-clause output, applies a conservative-tier override (any walk-away clause or sub-0.7 confidence forces escalate; non-low-tier counterparties never auto-approve), then routes to one of three branches via a Switch node — auto-approve (Ironclad record + audit Slack message), lawyer-review (Ironclad review workflow + Slack queue ping with summary and SLA tag), or escalate (Ironclad escalation workflow + GC channel alert). Every path writes to a `nda_audit_log` table for the weekly false-positive review and labels the Gmail message `nda-processed` to keep the trigger query idempotent.
The flow is deliberately one-way — it never sends mail to the counterparty itself. Outbound communication (executed copy back, redline negotiation) stays in Ironclad where the audit trail, version history, and signature workflow already live.
## Import
1. In n8n, go to **Workflows → Import from File** and upload `nda-intake-triage-n8n.json`.
2. Open the imported workflow. Every node will show a red badge against its credential field — that is expected. Bind credentials in the next section before you switch the workflow on.
3. Open **Settings → Timezone** for the workflow and confirm it matches the inbox owner's working hours. The bundled JSON sets `America/New_York`; change to your own.
4. Leave the workflow in **Inactive** state until you have verified the first-run flow below.
## Credentials
### Gmail — `nda-intake` mailbox (`PLACEHOLDER_GMAIL_CRED_ID`)
Used by the trigger node and the final `Mark Gmail Processed` node. Create a Gmail OAuth2 credential authorized against the dedicated intake mailbox (not a shared inbox alias — the trigger needs its own message store). Required scopes: `https://www.googleapis.com/auth/gmail.modify`. The credential must be able to add labels — read-only scopes will fail at the last node. After you connect, create a Gmail label called `nda-processed` in the intake mailbox; capture its label ID from `https://gmail.googleapis.com/gmail/v1/users/me/labels` and replace `Label_NdaProcessed` in the `Mark Gmail Processed` node parameters with the actual ID.
### Postgres — counterparty registry (`PLACEHOLDER_POSTGRES_CRED_ID`)
Used by `Counterparty Lookup` and `Audit Log Write`. Point at the Postgres instance that holds your counterparty registry. The flow expects two tables — `counterparty_registry` with at least the columns `counterparty_id`, `counterparty_name`, `primary_domain`, `secondary_domains text[]`, `risk_tier` (one of `low`, `mid`, `high`, `unknown`), `preferred_paper`, `notes` — and `nda_audit_log` with `id serial primary key`, `message_id text unique`, `thread_id text`, `sender text`, `sender_domain text`, `counterparty_id text`, `counterparty_name text`, `risk_tier text`, `recommendation text`, `override_reason text`, `overall_confidence numeric`, `clauses_json jsonb`, `summary text`, `processed_at timestamptz`. Grant the n8n role `SELECT` on the registry and `INSERT` on the audit log only — no `UPDATE` or `DELETE` rights, so a misbehaving flow cannot rewrite history.
### Anthropic — `x-api-key` (`PLACEHOLDER_ANTHROPIC_CRED_ID`)
Used by `Claude — Playbook Check`. Create an HTTP Header Auth credential in n8n with header name `x-api-key` and value set to your Anthropic API key. Use a workspace key scoped to this single workflow — don't reuse a personal key. The bundled prompt targets `claude-sonnet-4-6`; downgrade to Haiku only after you have measured the false-auto-approve rate at Sonnet (Haiku misses fallback clauses more often).
### Ironclad — API token (`PLACEHOLDER_IRONCLAD_CRED_ID`)
Used by all three Ironclad nodes. Create an HTTP Header Auth credential with header `Authorization` and value `Bearer <your token>`. The token needs `records:write` and `workflows:write` scopes. Pre-create three workflow templates in Ironclad named `nda-review` and `nda-escalation`, plus a record type `nda` with the property fields named in the node bodies (`counterparty`, `risk_tier`, `contract_type`, `status`, `intake_email`, `ai_confidence`, `summary`, `escalation_reason`, `override_reason`, `sla_hours`, `ai_summary`). The HTTP request bodies are written against Ironclad's `properties` shape — if you use a different CLM, replace the three Ironclad nodes wholesale and keep the Switch outputs and audit log path intact.
### Slack — bot token (`PLACEHOLDER_SLACK_CRED_ID`)
Used by `Slack — Audit Log`, `Slack — Lawyer Queue`, and `Slack — GC Escalation`. Create an HTTP Header Auth credential with header `Authorization` and value `Bearer xoxb-...`. The bot needs `chat:write` and must be invited to three channels: `#legal-ops-firehose` (auto-approve audit), `#legal-nda-queue` (lawyer review queue), and `#legal-gc-escalations` (GC alerts). The lawyer queue payload is built with Block Kit so the reviewer gets a one-click "Open in Ironclad" button — replace the placeholder URL in the `Slack — Lawyer Queue` node with the Ironclad workflow URL field returned by the API.
## First-run verification
Run these five smoke tests in order with the workflow still **Inactive** and the trigger swapped for a manual run on a single Gmail message ID. Use your own real-paper NDA samples, not synthetic ones — the playbook check is calibrated against actual paper.
1. **Auto-approve happy path.** Send an NDA from a domain you have inserted into `counterparty_registry` with `risk_tier = 'low'` and a contract that uses your standard mutual paper unmodified. Trigger the flow. Expect: `Routing Switch` fires output 1, an Ironclad record appears with status `Executed — Auto-Approved`, a `:white_check_mark:` message lands in `#legal-ops-firehose`, and `nda_audit_log` has one row with `recommendation = 'auto-approve'`, `override_reason IS NULL`.
2. **Lawyer-review on fallback clause.** Send the same low-tier counterparty an NDA where the term clause is 5 years instead of your standard 3. Expect: `Routing Switch` fires output 2, an Ironclad `nda-review` workflow exists with `sla_hours = 24`, the Slack lawyer queue post shows `override_reason: none` and the summary references the 5-year term, audit log row has `recommendation = 'lawyer-review'`.
3. **Conservative override on unknown counterparty.** Send a clean standard-paper NDA from a domain that does NOT exist in the registry. Expect: even though every clause is acceptable, the audit row shows `override_reason = 'non_low_risk_tier'` and the message routes to the lawyer queue, not auto-approve. This is the guard against silently approving anything from an unknown sender.
4. **Escalate on walk-away clause.** Send an NDA that includes a non-mutual indemnity that is outside your fallback library. Expect: `Routing Switch` fires output 3, the `nda-escalation` workflow exists in Ironclad, `#legal-gc-escalations` receives a `:rotating_light:` post, `has_walk_away = true` in the audit row.
5. **Parser-error fallback.** Temporarily edit the `Claude — Playbook Check` system prompt to ask for prose instead of JSON, then re-run any sample. Expect: the flow does not auto-approve. `Apply Risk Rules` catches the JSON parse failure and forces `recommendation = 'escalate'` with `escalation_reason: 'parser_error'`. Revert the prompt before activating the workflow.
Once all five behave as expected, label the original Gmail messages with `nda-processed` (so the trigger does not re-fire on them), switch the workflow to **Active**, and watch the audit log + `#legal-ops-firehose` for the first 30 days. Treat any auto-approve with `overall_confidence < 0.85` as a manual-spot-check candidate during that window.