Lead generation as an evidence pipeline, not a spray tool.

A sent email that cannot explain itself.

Outreach tooling optimizes for one number: how many messages went out. That number says nothing about how any individual message was produced, what it was checked against, or what would have stopped it from sending. When a recipient, a regulator, or the sender's own compliance function asks "why did this land in my inbox, and what did the system know when it decided to send it," the honest answer for most tools is a log line, if that.

SS Leader's own history documents this failure mode concretely before it documents the fix. Prior to a refactor the codebase calls "Prompt J," the entire outreach pipeline lived inline in one file, roughly 1,100 lines, that built the prompt, called the model, validated the output, critiqued it, refined it, gated the send, and rendered the email, all in one place, with no record of how a given draft was reached (docs/architecture/outreach-as-logic.md:11-16). That is the generic problem this paper is about, stated in the specific terms of one repository's own commit history: a working system that could send email, but could not account for any single send after the fact.

The fix the repository chose was not better prompting. It was structural: split the monolith into named, independently testable steps; write down what each step is contractually allowed to do; and make the contract fail loudly, at build time, if the code stops matching it. What follows is a mechanism-level account of that structure, and then an honest accounting of where the resulting system's evidence is strong and where it is thin.

One paragraph per email, produced by a fixed eight-step DAG.

A cold email in this system is not a model's free composition. It is a tenant's own, owner-written voice template with exactly two resolved slots: a deterministic greeting and one LLM-written trigger paragraph. Every other line is fixed by construction (README.md:13).

The runtime entry point, runOutreachLogic in src/lib/outreach/logic-runtime.ts:64-71, walks the same eight named steps on every send:

pre_check_suppression
  → resolve_greeting
  → draft_v1
  → critique_v1
  → refine_loop
  → send_invariant
  → render_email
  → deliver

Each step delegates to one of eleven covenanted skills under skills/<name>/. A covenanted skill is not just a function; it is a pairing of a human-readable contract (SKILL.md), a machine-checkable contract (COVENANT.md), an implementation (impl.ts), and fixtures. That pairing is what lets the pipeline's shape be described twice, once for humans and once for a checker, and cross-verified.

Refusal is a first-class outcome, not an exception

Every run of the DAG terminates in one of six recorded statuses. Four of those six are refusals:

A pipeline that only ever reports success is not evidence of anything; it is a black box that happens to be fast. A pipeline whose most common non-happy-path outcome is "I do not have enough signal to write this paragraph, so I am stopping" is a different kind of system. pre_check_suppression runs before any drafting happens at all, so a suppressed contact is caught at the door, not after a paragraph has already been written about them.

A prose contract that cannot silently drift from the code

The DAG's shape is mirrored in a human-readable LOGIC.md contract, logic/outreach.logic.md. A drift-detection test, tests/drift-detection.test.ts, parses that contract and compares its step names, dependencies, and branch conditions verbatim against the TypeScript runtime; the build fails if the two diverge. This is the mechanism, not a policy promise, that keeps the documented pipeline and the executing pipeline the same pipeline. A second, independently governed LOGIC.md contract, logic/voice-qualify.logic.md, applies the same pattern to a separate voice-agent qualify, decide, book flow that shares a Google Calendar client with the email and booking path.

Two validators, deliberately not merged

A tenant's validator_config (banned phrases and patterns, required phrases) is checked twice on the way to a send: once as the drafter's non-throwing advisory check (validateDraft), and again as a hard, throwing gate at send time (banned-phrase-validator). The project's own documentation describes this as "two validators, not merged" (CLAUDE.md:50), which is a small but telling design choice: an advisory check that can be overridden upstream is not treated as sufficient protection at the point where the email actually leaves the system.

Volume is capped by contract, not by discipline

The platform enforces one live send per business and a per-tenant daily send cap on live sends, implemented as two skills, outreach-live-lock and outreach-daily-cap (README.md:68-69). This is the paper's clearest evidence against the "spray tool" framing: nothing in the system depends on an operator remembering to throttle sends. The ceiling is mechanical.

Channel-scoped consent, not one blanket policy

Above the email pipeline, a separate specification, HARNESS.md, defines a cross-channel funnel: a per-lead journey state machine, per-channel consent gates, an inbound-signal routing table, and a callback-queue lifecycle, implemented in src/lib/orchestration/ and held in lockstep with that spec by tests/harness-drift.test.ts. The routing table treats channels differently rather than uniformly: email is the only channel with a cold path, run on a POPIA legitimate-interest basis with opt-out; WhatsApp (via Zernio) and voice calls require warm opt-in, with no cold path available in the routing table at all (CLAUDE.md:57-58). South Africa's POPIA framework does not ban legitimate-interest cold email outreach outright, but it does require an opt-out and a defensible basis; encoding that distinction into the routing table, rather than leaving it to a sender's judgment call per campaign, is itself a piece of evidence, not a marketing claim about compliance.

Where leads come from before any of this runs

The businesses table that feeds outreach is populated from two paths: a vendored, read-only Python stack under sa-lead-pipeline/ (Google Places discovery, then Playwright enrichment, then scoring), and a CSV importer, scripts/import-leads.mjs, with three-layer deduplication and a confidence-tiered name-write gate. A separate standalone Python worker (Python 3.12, asyncio, deployed independently to Render) runs its own claim-and-execute scrape loop against pipeline_jobs rows, independent of the vendored pipelines. The sa-lead-pipeline/ directory name is the dossier's only textual signal of the intended market; it is a South African small-business discovery stack, not a general-purpose scraper, though the dossier does not name a specific city or province for the data it holds.

Where humans actually enter the loop

Two documented decision points, and only two, put a human directly in control of what the pipeline does, as opposed to checking what it produced. First, tenant onboarding: a 2026-07-19 project decision states tenants are hand-provisioned rather than self-served, "for now" (STATUS.md:11-12). Second, scoring: mid-to-late July 2026 commits record an "operator-triggered backfill" of lead scores (score_v3, all seven axes), meaning a person, not a schedule, decided when that recompute ran. Both are real, evidenced human control points. Neither is a per-message approval step, a distinction this paper returns to directly in the Limitations section below.

What the dossier actually measures, in the dossier's own numbers.

Every figure below is drawn from a single source, the project's own evidence dossier (docs/dossiers/ss-leader.md), compiled from the repository's git history, file tree, and documentation on 2026-08-03. Cited inline as (ss-leader, metric).

The system is four months old by commit history: 325 commits total (ss-leader, total commits), running from a first commit on 2026-04-25 (5101508, "chore: initial commit — docs and reference materials", verbatim commit message) to a last commit on 2026-07-24 (a9e2a4a). Commit volume by month tells its own story of where the effort went: 14 in April, 122 in May, 159 in June, the largest month, and 30 in July (ss-leader, commits by month). Two authors appear in the history: Rainier Potgieter with 323 commits and an "Operator" account with 2 (ss-leader, commit authors). No git tags have been cut (ss-leader, git tags: 0); this is a system under continuous development, not one with dated releases.

By language, the tracked codebase (587 files total, ss-leader, tracked files) breaks down as 25,737 TypeScript lines across 207 files excluding type declarations (ss-leader, TypeScript LOC), 7,427 TSX lines across 55 files (ss-leader, TSX LOC), 7,316 Python lines across 48 files spanning the worker, voice, and legacy webscrape packages (ss-leader, Python LOC), 4,381 SQL lines across 53 migration files (ss-leader, SQL LOC), 20,803 Markdown lines across 154 files (ss-leader, Markdown LOC), and 3,491 JavaScript and MJS lines, including 16 build and operations scripts and one server entry point (ss-leader, JS/MJS LOC).

Test evidence comes from two independent counting methods that roughly agree: the project's own status file claims 593 Vitest tests as of 2026-07-24 (ss-leader, Vitest count, self-reported, latest), while an independent grep across every .test.ts and .spec.ts file in the tree counts 528 it( calls, 8 test( calls, and 2 it.each() groups across 61 files (ss-leader, Vitest call sites, grep-counted). The two Python packages add their own suites: 50 pytest functions in the worker package and 51 in the voice package (ss-leader, worker and voice pytest functions).

The live tenant lead-row counts above (11,874 for ss-leader itself, 1,305 for kamel-potteries, 3,614 for ccs-pos) are explicitly self-reported inside the project's own status documentation, not pulled from an independently queried production database (ss-leader, live tenant lead-row counts). This paper repeats that caveat rather than smoothing it into a plain fact, because the distinction between "the team says" and "we checked" is exactly the kind of thing an evidence pipeline is supposed to preserve.

Where this paper's own thesis is thinner than it sounds.

Honesty about a system's gates requires being equally precise about what is not gated. The following are stated without softening, because a whitepaper that hides its subject's rough edges is not evidence, it is marketing.

What a mechanically capped pipeline is actually good for.

The defensible claim in this paper is narrower than "AI-safe outreach" and stronger for being narrow: a pipeline where volume is capped by contract (one live send per business, a per-tenant daily ceiling) and where the model's freedom is reduced to one paragraph inside an owner-written template is measurably different from a system that lets a model compose freely and hopes a reviewer catches problems downstream. The four refusal states in the DAG's terminal outcomes are the clearest evidence of this: a system that can say "I do not have enough signal, I am not sending" by design, rather than by exception handling bolted on afterward, has made refusal a normal outcome rather than a bug.

For a South African small-business outreach context specifically, where POPIA's legitimate-interest basis for cold email carries a real opt-out obligation and where WhatsApp and voice sit under a stricter opt-in-only rule, encoding that split into a routing table that a drift test keeps honest against its own specification is a more durable compliance posture than a policy document nobody re-reads before a campaign ships. The gate is checked every time, not audited quarterly.

The drift-detection pattern itself, a human-readable contract and a machine-checked runtime, verified against each other, with a failing build as the enforcement mechanism, generalizes past this one project. It is already validated here in production use, which is a stronger claim than validating it in a demo: the same "Prompt J" monolith that used to hide how a draft was produced is the thing this pattern replaced.

The honest caution: treating this system's gates as "human approval" in the sense a compliance officer would expect, someone reviewing each outgoing message before it sends, would be a misreading. What is evidenced is governance at the tenant and operator layer, plus mechanical, contract-checked limits at the message layer. That is a real and useful shape for an evidence pipeline. It is not the same shape as a human moderation queue, and a buyer or auditor evaluating this platform, or one like it, should ask the specific question this dossier answers precisely: which gates are checked by code, and which decisions are still made by a person, because the two are not interchangeable and this paper's own thesis phrase risks blurring them if read too quickly.