# Lead handoff — reproducible local evidence

**Observed on 23 September 2026 at 13:16 UTC:** 10 checks passed. Eight fictional inputs produced **2 prepared payloads and 6 held records**. The original workflow was unchanged.

This executes the actual four Code-node sources from `lead-handoff-demo.n8n.json`, using n8n-shaped `{json: ...}` inputs and `$input.all()`. The harness verifies the five connections and IF condition, then emulates that equality to select each output branch. **This is a local Node.js harness, not an execution inside n8n or a CRM integration.** No CRM reads, writes or messages took place.

## Reproduce

Requires Node.js; this run used **v25.6.1, macOS arm64**. No packages, environment variables, credentials or running services are needed.

From the repository root:

```sh
node gtm/career-reset-2026-09-23/evidence/verify-lead-demo.cjs
```

The command writes `lead-demo-result.json` beside the harness. That generated file includes the timestamp, exact command, runtime, workflow and harness SHA-256 hashes, individual checks, actual normalized fields, payloads and hold reasons.

For a standalone download, place `verify-lead-demo.cjs` and the original `lead-handoff-demo.n8n.json` in the same writable folder, then run `node verify-lead-demo.cjs` there. The result JSON and this note can accompany those two files.

Workflow SHA-256:

```text
090b4a9cf954ee95e7720d15ca4e23a146678322cb1444d2f05ac809bd66e0f3
```

Before executing code, the harness requires that reviewed hash, checks the six expected local nodes, rejects credential entries, and verifies the branch structure. Code executes in a bounded VM context without host callbacks. This is a guard for this reviewed fixture, not a general-purpose sandbox for unknown workflows.

## Observed results

| Fixture | Result | Recorded reason |
|---|---|---|
| demo-01 | Prepared | Alex Morgan; normalized `alex@acorncloud.example`, Acorn Cloud, `acorncloud.example` |
| demo-02 | Held | `duplicate_email_in_this_batch`; canonical record `demo-01` |
| demo-03 | Prepared | Maria Costa; `maria@cedarlabs.example`, Cedar Labs, `cedarlabs.example` |
| demo-04 | Held | `missing_company` |
| demo-05 | Held | `missing_email` |
| demo-06 and demo-07 | Both held | `conflicting_company_for_same_email`; both IDs preserved |
| demo-08 | Held | `invalid_email_format` |

Reversing the input order preserved every decision, normalized field, reason and canonical duplicate. Changing only demo-02's name to the fictional “Casey Morgan” held both demo-01 and demo-02 with `conflicting_name_for_same_email`: **1 prepared, 7 held**. Additional checks reject unlabelled input, keep identical names with different emails separate, hold a malformed fictional website, and preserve every original record.

All records are fictional and addresses use reserved `.example` domains. An empty or intentionally malformed email is test data. “Prepared” means passing these demonstration rules; mailbox, identity and CRM verification remain false. Deduplication is limited to one input batch. No measured business outcome, production reliability or cross-run idempotency is established.

## Trainee exercise — predict, run, explain

Predict what happens when **only demo-03's `company` becomes an empty string**. Run the supplied scenario, which changes the input in memory and leaves the original workflow untouched:

```sh
node gtm/career-reset-2026-09-23/evidence/verify-lead-demo.cjs --scenario=missing-company
```

In a standalone folder use `node verify-lead-demo.cjs --scenario=missing-company`.

Expected: **8 inputs = 1 prepared + 7 held**. Demo-03 is held with exactly `missing_company`; demo-01 remains prepared. Four scenario checks pass, and `missing-company-result.json` records the actual result. Explain which field caused the transition, why every input must remain accounted for, and why a prepared mapping is not a completed CRM write. A real integration would also need agreed mappings, CRM lookup, durable idempotency, error handling and a controlled end-to-end test.