Sleuth campaign
The campaign ledger and funnel dashboard for AI Sleuth by a2ally: booking, contract drafts and the funnel that conversion runs on — with the reply rate as the headline, because replies are what the earlier funnel never produced.
Reply rate status: not_measured_no_sends_yet. Reply rate rule: the headline metric is the reply rate — inbox replies (AS-4 inbox records of kind reply, counted by sleuthSequenceUsage) divided by sends sent (AS-1 sends with status sent). While sends_sent is 0 the reply rate is null with status not_measured_no_sends_yet — never a fabricated 0%.
The baseline to beat
NDABox-era baseline (Oct 30): 47 accepted / 8 opened / 0 replied. That funnel sent and was opened, and produced no replies at all — the reply rate is therefore the metric this system is judged on, not send volume.
Target: reply rate of at least 2% positive-or-neutral replies on Touch 1–2 (first 30 days of live sending). The target is a goal, not a result.
The funnel, live at read
- Prospects recorded: 0 (0 screened, 0 suppressed)
- Pages minted: 0 · page views: 0 · call clicks: 0
- Sends prepared: 0 · sends sent: 0 · opened: 0 · clicked: 0
- Sequences enrolled: 0 · inbox replies: 0
- Bookings: 0 · contracts drafted: 0
Counting rules
Prospects. prospects_recorded counts prospect records stored for live accounts only, computed by the AS-3 usage helper (sleuthProspectUsage): prospects_total, split by status in prospects_screened and prospects_suppressed. Sandbox and other non-live accounts are excluded.
Pages. pages_minted counts per-recipient pages stored for live accounts only in the AS-2 page store, counted at read time; page_views counts viewed events stored on those pages' records and page_cta_clicks counts their cta_click events — the AS-2 counting rules, unchanged.
Sends. sends_prepared counts AS-1 sends with status prepared and sends_sent counts AS-1 sends with status sent, both for live accounts only; sends_opened counts opened envelope events and sends_clicked counts clicked envelope events stored on those sends' records — the AS-1 counting rules, unchanged.
Sequences and replies. sequences_enrolled counts sequence records stored for live accounts only, computed by the AS-4 usage helper (sleuthSequenceUsage); inbox_replies counts AS-4 inbox records of kind reply for live accounts, from the same helper's inbox_by_kind.
Bookings. bookings counts booking records stored for live accounts only in the sleuth_bookings store, counted at read time.
Contracts. contracts_drafted counts contract draft records stored for live accounts only in the sleuth_contracts store, counted at read time; every record stands with status draft.
Booking
Booking rule: a booking is a record of a requested 15-minute call window for one of the caller's own screened prospects, created with POST /v1/sleuth/bookings and listed with GET /v1/sleuth/bookings. No email is sent and no external booking service is called when a booking is created — the booking is a record only, with status booked, and nothing is confirmed with the prospect on this surface.
Contracts
Contract rule: a contract draft is prepared with POST /v1/sleuth/contracts from one of the caller's own bookings. The draft embeds the rung's template from the one agreement family, takes its amount from the published ladder, and stands with status draft. Draft rule: the contract templates are DRAFTS for the owner's review before first use. A prepared contract is a draft record only; nothing is signed, e-signed, or sent through this surface.
Payment links
Payment rule: a contract draft carries a payment link only from its rung's configured environment variable (one SLEUTH_PAYMENT_LINK_* variable per rung, named in the draft). When that variable is unset the draft's payment_link is null and the missing variable name is listed in missing_payment_dependencies — nothing is charged and no link is invented on this surface.
Surfaces
- GET /v1/sleuth/contracts/templates (free, no key) — the one agreement family and all four per-rung contract templates, derived from the published ladder: each template carries its rung's scope annex verbatim, the IP and client-ownership clause, its payment terms and the cancellation terms, with status draft
- POST /v1/sleuth/bookings (owner account key) — record one 15-minute call booking against one of the caller's own screened prospects: prospect_id, ladder_rung and a requested window; no email is sent and no external booking service is called
- GET /v1/sleuth/bookings (owner account key) — the caller's own bookings only
- POST /v1/sleuth/contracts (owner account key) — prepare one contract draft from one of the caller's own bookings; the payment link comes only from the rung's SLEUTH_PAYMENT_LINK_* variable and is null while that variable is unset
- GET /v1/sleuth/contracts (owner account key) — the caller's own contract drafts only
- GET /v1/sleuth/campaign (free, no key) — the campaign ledger and funnel dashboard: every funnel stage computed live at read time with its counting rule printed, the reply rate as the headline, the NDABox-era baseline to beat and the reply-rate target
- GET /sleuth-campaign (page) and GET /sleuth-campaign.md — the human-readable twin of the campaign document
Machine-readable index: GET /v1/sleuth/campaign · Contract templates: GET /v1/sleuth/contracts/templates · Sleuth home: /sleuth · Prospect engine: /sleuth-prospects · Sequence runner: /sleuth-sequence · Sending foundation: /sleuth-send. Markdown twin: /sleuth-campaign.md.