Object Invocation Protocol · protocol specification

OIP system: LEADS

#oip#object-invocation-protocol#protocol-specification#machine-native-json#system

Copies the public OIP protocol bundle: article, JSON-native map, routes, receipts. No owner token.

§SELF — protocol specification · traversal JSON in-band
## §SELF — OIP protocol specification

**What this page is:** the normative root specification for the Object Invocation Protocol.

**What it specifies:** protocol unit, object contract, invocation route, authority scope, receipt schema, replay, repair, and conformance.

**Read:** https://miscsubjects.com/a/oip-system-leads
**This page as JSON:** https://miscsubjects.com/api/articles/oip-system-leads
**Machine bundle:** https://miscsubjects.com/api/articles/oip-system-leads/bundle?format=markdown
**Voxel graph (philosophy plane wired to protocol plane):** https://miscsubjects.com/api/articles/oip/voxels
**Live object tree:** https://miscsubjects.com/api/dispatch?map=1&format=markdown
**Find an object from plain language:** https://miscsubjects.com/api/dispatch?ask=<what you want>
**Read one object:** https://miscsubjects.com/api/dispatch?key=<KEY>&format=markdown

**Proof rule:** an action is not proven by intent, description, or a 200. It is proven by the ledger and the OIP receipt for the invocation.

LEADS

A generated article for one OIP shelf. It lists every operation in this API/CLI/MCP/device/model/core subsystem, links each leaf article, and gives the ledger path for proof.

This page is the operating article for one build subsystem. It is generated from live directory rows. If a task belongs to this subsystem, scan the operations below, open the matching capability article, run only the exact object named there, and verify by receipt.

Kind: core. Capabilities: 9. Machine system map: /api/dispatch?map=LEADS&format=markdown. Root: /a/oip.

Operations

LEADS_DISCOVER

Find businesses likely to buy peptides wholesale or want white-label, by type and city. Free source (OpenStreetMap), no API key. Writes new rows to the leads table. Use when: start a new outreach batch for a place. Arguments: $1 = segment (medspa | clinic | wellness | gym | supplement), $2 = city, $3 = max results (default 40).. Human article: /a/oip-capability-leads-discover. Machine doc: ?key=LEADS_DISCOVER&format=markdown. Invocation history: /api/invocations?object_id=LEADS_DISCOVER.

LEADS_ENRICH

Visit one lead's website and pull the best contact email. Sets the lead to enriched or no_email. Use when: after discovery, to get an email to reach out to. Arguments: $1 = lead id.. Human article: /a/oip-capability-leads-enrich. Machine doc: ?key=LEADS_ENRICH&format=markdown. Invocation history: /api/invocations?object_id=LEADS_ENRICH.

LEADS_DRAFT

Write a wholesale + white-label outreach email for one lead. Saves the draft on the lead. DOES NOT SEND. Use when: after enrich, to prepare the message for Cyrus to approve. Arguments: $1 = lead id, $2 = which company it comes from (default miscsubjects).. Human article: /a/oip-capability-leads-draft. Machine doc: ?key=LEADS_DRAFT&format=markdown. Invocation history: /api/invocations?object_id=LEADS_DRAFT.

LEADS_LIST

List leads and a count by status (new, enriched, drafted, no_email, sent). Use when: see the outreach pipeline. Arguments: $1 = status filter (optional; blank = all).. Human article: /a/oip-capability-leads-list. Machine doc: ?key=LEADS_LIST&format=markdown. Invocation history: /api/invocations?object_id=LEADS_LIST.

LEADS_ENRICH_BATCH

Enrich the next batch of un-enriched leads in one call (finds emails + context). Bounded so it never fails; call repeatedly to work through the queue. Use when: after discovery, to fill in emails and context for many leads. Arguments: $1 = how many to do this call (default 8, max 10).. Human article: /a/oip-capability-leads-enrich-batch. Machine doc: ?key=LEADS_ENRICH_BATCH&format=markdown. Invocation history: /api/invocations?object_id=LEADS_ENRICH_BATCH.

LEADS_RUN_CITY

One call = discover a segment in a city, then enrich a batch. The fastest way to grow the pipeline. Use when: add a new city/segment to the pipeline. Arguments: $1 = segment (medspa|clinic|wellness|gym|supplement), $2 = city, $3 = discover limit (default 40), $4 = enrich count (default 8).. Human article: /a/oip-capability-leads-run-city. Machine doc: ?key=LEADS_RUN_CITY&format=markdown. Invocation history: /api/invocations?object_id=LEADS_RUN_CITY.

LEADS_DRAFT_AI

Grok writes the outreach email for a lead, grounded in the OUTREACH_DOSSIER (brand, team, offer, article+store links) and the lead's real site context. Saves the draft. DOES NOT SEND. Use when: draft a real, personalized email instead of the plain template. Arguments: $1 = lead id, $2 = brand (default LeoResearch).. Human article: /a/oip-capability-leads-draft-ai. Machine doc: ?key=LEADS_DRAFT_AI&format=markdown. Invocation history: /api/invocations?object_id=LEADS_DRAFT_AI.

LEADS_SEND

Send ONE lead's already-drafted email via miscsubjects email. Only works if the lead is 'drafted' and has an email. Use when: Cyrus approved sending and wants one specific lead emailed. Arguments: $1 = lead id, $2 = from local-part (default wholesale -> [email protected]).. Human article: /a/oip-capability-leads-send. Machine doc: ?key=LEADS_SEND&format=markdown. Invocation history: /api/invocations?object_id=LEADS_SEND.

LEADS_SEND_BATCH

Send a batch of drafted leads. HARD-GATED — refuses unless the first arg is the exact word CONFIRM. Cap 25. Use when: Cyrus explicitly authorizes a send run. Without CONFIRM it only reports how many are ready. Arguments: $1 = CONFIRM (literal), $2 = how many (max 25).. Human article: /a/oip-capability-leads-send-batch. Machine doc: ?key=LEADS_SEND_BATCH&format=markdown. Invocation history: /api/invocations?object_id=LEADS_SEND_BATCH.

9
capabilities
Evidence · 5 sources · swipe →chain oipinvocatio · verify chain · provenance

Key evidence

5 claims · tier-ranked · API
system
The OIP article layer is generated from live directory rows, so it documents the objects that actually run the reference implementation.
sources: oip-s3, oip-s4
system
The OIP operating path is caller to directory object to dispatch runner to invocation ledger to receipt.
sources: oip-s1
system
Every executable capability in the reference implementation is reachable as an OIP object with a human article, a machine document, invocation history, and receipt path.
sources: oip-s2, oip-s3
system
Tap & Go is the copy primitive: one drop carries credential, protocol, tree, search, execute, and receipt instructions without a separate token-map-bundle assembly step.
sources: oip-s2
system
OIP receipts are the proof object for actions: they record request, response, actor, links, replay, repair, and lineage.
sources: oip-s2, oip-s5
Talk to this article
Tap a phone. Ask anything about OIP system: LEADS. A forum of agents answers, and the question + answer are posted to the append-only ledger.
Questions queue for the coding-agent forum (one answer per cron tick). Real phone instead: iMessage +14245134626 · WhatsApp. Thread + proof: JSON · ledger.
oip-system-leads · posted 2026-07-02 · updated 2026-07-06
Ledger API & provenance
Provenance · 1 model pass · 0 tokens · $0 · 1 model
chain head virtual-oip
generate system/oip_articles · 2026-07-06 00:06 · 0 tok · virtual-oip
verify chain →
OIP REST + ledger
system shelf GET /api/dispatch?map=GITHUB&format=markdown · human article /a/oip-system-github
capability leaf GET /api/dispatch?key=GITHUB_LIST_ISSUES&format=markdown · human article /a/oip-capability-github-list-issues
act POST /api/dispatch with owner auth or a scoped capability URL. Public docs are open; mutating action is token-bounded.
token explain GET /api/dispatch?explain=1&share=TOKEN
receipt GET /api/dispatch?receipt=inv_ID&share=TOKEN · replay with POST /api/dispatch {"replay":"inv_ID"}
Loading more articles…