# FREE SAMPLE — The Auto-Delivery Rules Template

### From *Solo Operator Agent OS* (Tobywater Digital)

**Why this piece is free, and why it's complete:** Our house rule for samples is that a sample must be a real, complete piece of the product — not a teaser. So here is one full module of the pack, standalone: the rules document our store uses to deliver digital orders automatically. If you sell digital files and take payment through links (crypto or otherwise), you can implement this today, with your own AI agent, in under an hour. The paid pack adds the other four systems (money radar, open-source scouting, content pipeline, the sample standard) plus our annotated real-world issues — this one is yours regardless.

**How to use it:** fill in the `[brackets]`, keep the rules as they are until you've run them for a week, and hand the document to your agent as a standing instruction alongside two companion files you'll create: a *mapping table* (template in §2) and a *delivery log* (template in §4). The agent re-reads all three at the start of every run.

---

## §1 — The Rules Document (copy-ready)

### Auto-Delivery Rules — [Your Store]

**Executor:** the scheduled delivery task. Every run: read this file, then `mapping.md`, then `delivery-log.md`. Follow them exactly. Any situation these rules don't cover: **do not deliver — report only.**

**1. Scope**
- Mailbox: `[orders@yourstore.example]` — inbox **and** spam folder (processor notifications land in spam often enough to matter).
- Process only unhandled mail. "Handled" is determined by the delivery log and prior reports, never by memory.

**2. Trigger evidence (either one starts matching)**
- **(a) Processor's payment-completed notification** — the official email showing a payment/invoice as *finished/confirmed*. Statuses like `waiting`, `confirming`, `partially_paid` are **not** triggers.
  Extract: payment-link ID or product identifier, amount, buyer email (required at checkout, so it exists in the record).
- **(b) Buyer email with payment proof** — the buyer writes in with a receipt / transaction screenshot / transaction hash and names the product.
  The proof must show: amount paid, product (or its payment link / ID), and a completed state.

**3. Matching (all three must hold — no exceptions)**
1. **ID matches:** the payment-link ID in the evidence equals a mapping row. If the evidence has no ID, the product name must resolve to exactly one row.
2. **Product matches:** the evidence's product is the row's product (bundles are not their components).
3. **Amount matches:** amount paid equals the row price (USD). For crypto, a conversion residue of ≤1% counts as matched; anything beyond 1%, or an unreadable/ambiguous amount, is an anomaly.

If any item fails or can't be read: anomaly path (§5 of these rules). **Never guess. Never "close enough."**

**4. Delivery**
- **Recipient:** the buyer email — from the processor record for (a); for (b), the sender's address (if the buyer names a different delivery address in the body, use it but flag the discrepancy in your report).
- **Attachments:** exactly the files in the mapping row, all of them, in one email. Never split, never omit, never attach a different edition.
- **Dedupe — one delivery per order, ever:** before sending, search the delivery log. If the same order (processor order/payment ID; fallback key: buyer email + link ID + amount) already has a `sent` row, **do not resend**. If both (a) and (b) evidence exist for one payment, the first triggers delivery; the second is logged `duplicate-skipped`.
- **Log immediately after sending** — an order isn't closed until its log row exists.

**5. Anomalies (never deliver — report with the original evidence)**
- Amount mismatch (>1%, missing, unclear currency).
- Product unidentifiable, or one piece of evidence plausibly matches two rows.
- Repeat request: same buyer asking again for the same order. Check the log first — if already delivered, reply asking them to check the original email; do **not** re-attach files. If never delivered but evidence is complete, deliver once through the normal path.
- Suspect proof: visibly altered screenshot, transaction hash that doesn't resolve, notification from a non-official sender domain, buyer email contradicting the payment record with no explanation.
- Payment incomplete (`waiting`/`confirming`/not settled) while the buyer demands immediate delivery.
- Buyer claims payment but neither evidence type holds.

Report anomalies factually — which check failed and what the evidence says — without accusing anyone of anything.

**6. Delivery email template**

Subject: `Your [Your Store] order: <Product Name>`

```
Hi,

Thank you for your order — payment confirmed. Your file(s) are attached to this email:

• <one line per file: name, format, size/pages>

Please download and save them somewhere safe right away; email inboxes are easy to lose track of.

Lost the attachment or can't open a file? Just reply to this email or write to
[orders@yourstore.example] and we will re-send it — no charge, no questions asked.

<ONLY for products that include an update period:>
Note: this pack includes 12 months of updates. If the rules change during that
period, the updated edition will be sent to this email address.

Thanks again,
[Your Store]
[https://yourstore.example]
```

---

## §2 — The mapping table (create `mapping.md` in this shape)

One row per product. Verify each file path on disk the day you write it.

| Payment-link ID | Product name (as shown in store) | Price (USD) | Deliverable files (absolute paths) | Delivery |
|---|---|---|---|---|
| `[link-id]` | `[Product A]` | $15 | `/path/to/a.pdf` + `/path/to/a-source.md` | Email attachment (all files, one email) |
| `[link-id]` | `[Bundle = A + B]` | $45 | All files of A and B (list every one) | Email attachment (one email) |
| `[link-id]` | `[Service — NOT auto-delivered]` | $149 | — | Manual. Sweeper: report the order, never improvise. |

Rules: bundles get their own row listing every file (the agent must never infer bundle contents); anything over ~20 MB total switches delivery method in its row; services are excluded *by name* so the agent never guesses.

## §3 — The sweeper task (schedule it)

- **Cadence:** every 5–15 minutes. Ours: 5.
- **Instruction to the agent:** "Read the rules, the mapping, and the log — fresh, every run. Scan the orders mailbox (inbox + spam) for unhandled trigger evidence. Execute the rules. Report one line per delivery, one consolidated message per anomaly batch, and nothing at all when there's nothing to do."
- **Permissions:** read the orders mailbox; send from the same identity, delivery template only.
- **First week:** run report-only (the agent shows you what it *would* send) until its matches match yours. Then go live.

## §4 — The delivery log (create `delivery-log.md`)

Append-only. One row per handled order:

| Time (your timezone, YYYY-MM-DD HH:mm) | Product (name + link ID) | Buyer email | Order ID | Result |
|---|---|---|---|---|

Result ∈ `sent` · `duplicate-skipped` · `anomaly-reported`. Anomalies get rows too — that's what stops the next run from reprocessing the same mail.

---

*This document runs a real store. As of 2026-10-23 that store is pre-revenue — the system is live, sales pending — and we say so in the pack too, because a system you can inspect beats a revenue screenshot you can't. The full Solo Operator Agent OS (all five modules + annotated real issues) is at Tobywater Digital: https://tobywater.pages.dev*