# tinbot-transport — Convergence SOP

**Status:** Draft #1 — Tinbot Transport canon
**Source:** Convergence of the published Tinbot proposal (v0.1), the GPT-5.5 Architectural Review seed, and the two Ghojualamanchu-style fractal seeds (`gholing-tinbot-0` and `tinbot-core-1`). The calmer SOP-style fractal seed is treated as the operational layer; cognitive / gholing framings are reduced to year-two or later suggestions so year-one stays boring.
**Intent:** One tight, executable SOP for the Corinth/Walton pilot. Anything that contradicts the proposal is dropped. Anything that adds rigor without adding ceremony is folded in. Anything that smuggles in surveillance, custom backend, or cross-region complexity in year one is parked.

---

## 0. North star

> **Tinbot takes in hardware and outputs trusted reuse. The waste between donor and recipient is friction, fraud, and freight.**

We remove that waste by **piggybacking existing infrastructure** (LFLs, mutual-aid routes, repair cafés, library systems, LTL carriers) before spending a dollar or a keystroke on new infrastructure. The system is *Little Free Library meets UberEats meets Boost Mobile* — donor-side storage, neighbor-side last-mile, aggregator-side freight — and the trust layer is *public ledger + wipe-before-label + plain-language liability*, not apps.

A box is **boring**: sealed, labeled, never opened, never plugged in, never tracked beyond its public ledger entry. **Boring boxes get carried.**

---

## 1. Convergence table — where each seed lands

| Concept | Where it lands in the canon |
|---|---|
| Three node tiers T1/T2/T3 + promotion rules | §2 Node tiers (kept) |
| Piggyback-before-build order | §3 Trust layer (kept, in priority order) |
| Hop card / single short hop commitment | §4 Volunteer model (kept) |
| Freight math (LTL, peer, individual) + break-even + budgets | §5 Freight (kept, marked working numbers) |
| Hub-and-spoke routing + sunset clause + "try before you ship" | §6 Routing (kept) |
| Wipe-before-label + 4-field attestation + donor line | §7 Data rule (kept, hardened) |
| Public append-only ledger hostile to identity | §8 Chain-of-custody (kept) |
| Plain-language liability + handoff norm | §9 Liability (kept) |
| Corinth/Walton 90-day pilot | §10 Pilot (kept) |
| Year-one budget / insurance / partnership asks | §11 Decision asks (kept) |
| Pilot council of 3–5 owners | §11.1 Pilot council (new) |
| Charter publication + handbook path | §12 Deliverables (new) |
| Partner map (LFLs / repair cafés / libraries / mutual-aid) | §3 Trust layer (folded) |
| 5 non-surveillance micro-metrics | §13 Metrics (new, kept short) |
| Year-two offline triage USB (nwipe/shred) image | §14 Year-two (parked) |
| Year-two biomimetic routing daemon | §14 Year-two (parked, with caveat) |
| Year-two public ledger mirror | §8.2 Ledger mirror (parked) |
| Multi-region / "Planetary Network" / "Specialist/Replicator" lifecycle | **Dropped from canon** — out of pilot scope |
| Four-layer Anthrocybernetics → TLIP stack claim | **Not asserted** here. Tinbot Transport canon stands on its own; the architectural review is its own document |

---

## 2. Node tiers

| Tier | What it is | Job | Trust needed |
|---|---|---|---|
| **T1 — Dropoff** | Porch, library drop bin, repair-café counter, church desk, laundromat counter | Receive + label + hold ≤ 14 days | Signed MoU + visible signage |
| **T2 — Cluster hub** | Room/garage/workshop that consolidates a metro | Intake wipe, intake QA, triage, light repair, prepare for onward leg | Named steward + posted hours + published checklist |
| **T3 — Freight depot** | Aggregation point that ships cross-region | Palletize, LTL book, receive freight, route | Lease + insurance + signed cargo handoff |

**Promotion rule.** T1 → T2 after ≥ 60 days with zero unresolved chain-of-custody gaps. T2 → T3 after ≥ 3 cross-region legs with verified handoffs.

**Hard rules across all tiers:**
- Tinbot accepts **hardware, not data**. No tier opens a device, plugs it into anything networked, or accesses storage without a documented wipe attestation. (§7)
- No tier tracks **identities** beyond a pickup window. (§8)
- A node is "in the network" only when its role, hours, and liability posture are public. Visibility is the immune system.

---

## 3. Trust layer — piggyback, don't build

Highest leverage per hour first. Anything we add ourselves is a loss.

1. **Little Free Libraries.** Register an existing LFL as a T1 drop if its steward opts in. 1-mile radius = pickup catchment.
2. **Mutual-aid delivery routes.** Overlay a weekly pickup sweep on existing circuits (food fridges, diaper banks, period supply). The partner gains a reason to keep running; we gain zero-cost legs.
3. **Repair cafés.** Natural T2 hubs. Triage in person, intake quality best-in-class.
4. **Library systems.** T1 dropoff at the desk + back-room overflow for T2. They understand inter-library mail paperwork better than any other civilian institution.
5. **Aggregator/Boost pattern.** For freight, don't own trucks. Tinbot's freight function is a router that picks the cheapest existing LTL lane + books a pickup window.
6. **What we DO NOT build year one.** No custom app, no custom matching engine, no custom identity layer, no custom backend. Use Discord / email / Signal + the public ledger in §8.

If a partner org says no, log it in `partnerships.md` and move on. Trust is built by accepting who says no.

**Partner map (kept as a working artifact, not a deliverable in year one).** A simple CSV / markdown table of candidate partners per region: LFLs, repair cafés, libraries, mutual-aid routes. Org names only. No individuals.

---

## 4. Last-mile volunteer model — the hop

The unit of commitment is **a hop**, not the program. A volunteer should be able to carry one box without reading a policy.

**Hop card (one page, per route):**
- From → To (with T1/T2/T3 tag on each)
- Window: "Tuesday 6–8pm, or push to next slot"
- Payload: 1–3 boxes, ≤ 30 lb total, pre-labeled
- Done condition: 1-photo handoff posted to the route thread
- Soft commitment: zero follow-up if a volunteer can't make a week. **No reliability score. Volunteers are not gig workers.**

**Sign-up (under 5 minutes):**
1. Tap the route card in Discord.
2. Fill 4 fields: name, contact, neighborhood, available slots.
3. Acknowledge the §9 liability note.
4. Added to the route thread. **That is the entire onboarding.**

**Why this works:** zero new software; low ceiling + low floor compound; we reuse people's existing rhythms (school pickup + box in the trunk, library visit + box in the bag).

---

## 5. Freight — working numbers

Cost per unit over a 500-mile leg (5 lb, laptop + adapter):

| Strategy | Per-unit (today) | At scale | Notes |
|---|---|---|---|
| Individual shipping (USPS Priority) | $22–30 | floor $15 | Donor/recipient pays; poor for ≥ 2 devices |
| LTL pallet pooled | $6–10 + $1.50 prep | $5–7 at 1 leg/mo, **$3.50–4.50 at 4 legs/mo** | Min cost/mi; pallet threshold matters |
| Peer round-trip carry | $3–5 | floor $2–3 | Fast, low ceremony, no freight insurance |

**Break-even rule of thumb (per region):**
- **< 30 devices/month:** individual shipping. Use peer carries opportunistically.
- **30–80 devices/month:** bi-weekly pallet per region. $50–80/leg materials.
- **> 80 devices/month:** monthly LTL pallet + parallel peer route for urgent/oversize.

**Year-one budget (working, pending §11):**

| Line item | Range |
|---|---|
| Pallet prep materials | $300–600/yr at 1 leg/mo |
| 1× LTL lane, 1 region, 12 legs/yr | $700–1,400/yr |
| Hop stipends (honor system) | $0–1,200/yr |
| Insurance rider | $0–500/yr |
| Handoff signage + tote bins × 6 | $300–500 one-time |
| Petty claims | $200–400/yr |
| **Floor** | **~$1,500** |
| **Realistic** | **~$3,000–4,000** |
| **Two-region** | **~$6,000–8,500** |

These are **working numbers, not the formal ask.** §11 is where the budget becomes real.

---

## 6. Hub-and-spoke routing — when a leg is earned

Default posture: **gear stays local. Most of the time, it shouldn't move.**

A long leg is earned when *one or more* of:
1. Local demand met, local supply not.
2. Scarcity lift (specific SKU, specialty part).
3. Donor concentration spike the home cluster can't absorb.
4. Geographically orphaned node (no T2 within 30 mi — escalate to T2 search before T3 freight).
5. Specialty repair routing (board-level, data-grade screen, only one hub in region).

**Routing rules:**
- *Try before you ship.* 48-hour "local first" window in the next-tier regional channel before any freight book.
- *Cluster-aware batching.* Don't ship 1 device. Hold to the next pallet unless §6(1)–(2) apply.
- *Always return-route.* If a device moves up a spoke and can't be re-homed, it goes back down. Nothing rots at a T3.
- *Sunset clause on pallets.* Anything held at a T3 > 60 days reverts to the originator's region (return leg at freight direction's expense).

This is the rule that prevents "garage in Wisconsin hoarding Kentucky laptops."

---

## 7. Intake data rule, in writing

> *"Tinbot accepts hardware, not data. We wipe the storage before it enters our system. We do not open, copy, or migrate anything from your device at any step."*

Operational rules — non-negotiable from day one:

1. **No reading of user storage, ever, anywhere in the chain.** Not "we wiped it." Not "we backed up your photos." Not "we extracted your contacts to migrate." None.
2. **Wipe-before-label.** A device does not get its intake label (and therefore its slot in inventory) until a documented wipe is completed. The wipe is the entry to the system, not an afterthought.
3. **Wipe attestation is a 4-field form** attached to the device's tag:
   - device class (laptop / desktop / router / …)
   - wipe method (DBAN / nwipe / vendor secure-erase / manual proof)
   - operator initials
   - timestamp (ISO 8601)
4. **Drive-out is donor-driven, not Tinbot-driven.** Donor wants the drive returned separately? Separate bag, separate label, never on our network.
5. **Network segregation during triage.** Repair benches are air-gapped or on a clean network. No donor device is the first thing on a home Wi-Fi.

That sentence gets the same prominence as donor hours. Maybe more.

---

## 8. Chain-of-custody — public, append-only, hostile to identity

**Goal:** at any moment, "where is device X" is answerable by anyone with read access to the public ledger. Goal is **not** to know who is carrying what.

**8.1 Ledger schema (year one).** Append-only CSV (`tinbot/ledger.csv` mirrored in a Discord channel):

```
timestamp, device_tag, from_node, to_node, hop_kind, carrier_initials_or_LTL
```

That's the whole schema. No device value. No donor name. No recipient identifier. No GPS. No carrier home address. No phone numbers. No email.

**8.2 Ledger mirror (parked for year two).** A read-only public mirror reinforces transparency. **Risk note:** confirm no personal identifiers ever enter the schema before mirroring. Schema-first, mirror-second.

**8.3 Device tag.** 6-char alphanumeric ID. Sticker on box + sticker on device, same ID. Peel-resistant marker on the device. Sticker lost? Re-tag at the next node and note the relabel in the ledger.

**8.4 Coarse on purpose:**
- The hop *window* (e.g. "Tue 6–8pm") is more visible than the carrier's identity.
- "Arrived" without naming the volunteer is fine for T1 hops; naming is optional and never required for record.
- Anomalies (skip in ledger, duplicate arrival, lost tag) are recovered by a human, not a sensor.

**8.5 Why no app yet.** A custom chain-of-custody app normalizes identity. The ledger is hostile to identity by construction.

---

## 9. Liability + handoff norms (the part nobody writes down)

A volunteer should carry a Tinbot box without reading an insurance policy first.

**A carrier is responsible for:**
- Keeping the box sealed and dry.
- Not opening, plugging in, or attaching donor storage to a personal device.
- Posting the 1-photo handoff into the route thread when delivered.
- Reporting damage on arrival with a photo, no cover-up.

**A carrier is NOT responsible for:**
- Donor pre-existing data, regardless of wipe status.
- Damage present at pickup (visible or not) — node labeled "received as-is."
- Loss or theft beyond their reasonable control during the hop.
- Outcome of subsequent repair at a T2/T3.

**The network is responsible for:**
- Publishing what was on the box at handoff ("received as-is" + wipe attestation).
- Maintaining the public ledger so the carrier's run is provable.
- A petty claims budget (§5) to make whole without litigation when it's the right thing.

**Handoff norm:**
- Pickup photo: sealed box + node label.
- Transit: closed bag/box, no stickers removed.
- Dropoff photo: sealed box + next node's label visible.
- A dispute starts with a photo, not a story.

The whole goal is to make the box boring.

---

## 10. Pilot geography — Corinth / Walton County, FL

**Pilot recommendation:** Corinth / Walton County, Florida, anchored on the existing schoolhouse host site.

Why:
- Existing on-ground infrastructure (schoolhouse easement → repair bench space, gathering room, community relationship).
- Branch interest in FL already public on `branches.html`; foothold isn't invented.
- Rural + small-town mix forces real last-mile design.
- Solar Link pilot stacks cleanly (school workshop = real T2 from week one).
- Failure bounded; success ports to TX/WI/NY.

**Pilot scope (90 days):**
- ≥ 2 T1 dropoff nodes (library + faith partner or community fridge).
- 1 T2 hub (schoolhouse workshop).
- 1 outbound freight leg, **only if local demand is met**.
- 1 ledger, 1 set of tote labels, 1 volunteer cohort ≤ 12 people.
- 1 public write-up at the end — what worked, what didn't, the actual cost.

**What we explicitly are NOT doing in the pilot:**
- No cross-state freight other than the planned single leg.
- No custom software. Discord + ledger sheet.
- No donor data collection beyond handoff window and box count.
- No expansion past the cluster until the write-up exists.

**Stop conditions (fail forward):**
- 1 missing box becomes a forensic problem instead of a write-off → re-design.
- 1 donor asks "what about my data?" and §7's sentence isn't ready → re-design.
- 1 volunteer drops out and we blame them → re-design.
- After 90 days, *no pallet* is justified → that's a success, not a failure.

---

## 11. Decision asks for Void / admins (when intake opens)

These are **not** the author's call. Flagged and ready.

1. **Year-one budget commitment.** Floor ~$1,500 / realistic ~$3,000–4,000 / two-region ~$6,000–8,500. Confirm the chosen tier.
2. **Insurance posture.** Confirm whether the existing umbrella policy covers a "volunteer logistics" rider, or whether we need a line item for it.
3. **TLIP-published liability note.** A 1-page plain-language version of §9 needs Void approval before it goes on `branches.html` or partner-facing materials.
4. **Wipe-at-intake checklist.** The §7 / 4-field form needs to be blessed by the branch with repair authority (DBAN / nwipe / vendor tools) before it goes live.
5. **Public ledger governance.** Who can read, who can append, retention, mirror cadence. Schema in §8 is the proposal; the **rule** is the ask.
6. **Cross-org partnerships.** Each formal partnership needs a single named TLIP contact. Not all at once — just enough to staff the pilot.
7. **End-of-pilot evaluation.** Who reads the 90-day write-up and decides whether §10 expands to a second region.

### 11.1 Pilot council (recommended, year one)

A 3–5 person council owns §10 and §11 decisions for the first 90 days:

- **Ledger steward** — append-only discipline, schema purity, weekly public mirror when ready.
- **Wipe protocol lead** — DBAN/nwipe/vendor secure-erase, §7 attestation enforcement.
- **Partnership liaison** — LFL / library / repair-café / mutual-aid MoUs.
- **Volunteer coordinator** — hop cards, route threads, retention observation.
- **(optional) Donor-facing lead** — owns the "we accept hardware, not data" line.

If the council can't be staffed, the pilot collapses to "peer-only, no freight, 90 days" — and that's a valid mode.

---

## 12. Deliverables (committed)

- **Tinbot Charter** — §§2–9 distilled into a 1–2 page public document for `branches.html` and partner materials. **Priority: high.**
- **Pilot Playbook** — 10–15 page operational playbook for Corinth/Walton:
  - Node setup checklist (T1/T2/T3)
  - Volunteer hop scripts
  - Wipe station setup
  - Ledger entry examples
  - Incident response (lost box, damaged device)
- **90-day Public Write-up** — what worked, what failed, what surprised volunteers and donors. Audiences: TLIP Discord, potential partners, future regions.
- **Tinbot Handbook** (post-pilot, 20–30 pages) — charter + norms + checklists + stories + failure modes, for new regions.

---

## 13. Micro-metrics (5, all non-surveillance)

1. Devices wiped and routed.
2. Successful hops (handoff photo posted within window).
3. Pallets justified vs. deferred.
4. Donor questions about data (a *volume* signal — high is good, it means the line is being read).
5. Volunteer retention after first hop.

**What we explicitly do not measure year one:** donor identity, recipient identity, carrier location, hop frequency per carrier, "reliability score." Nothing that could be aggregated into a profile.

---

## 14. Year-two parking lot (do NOT do this in pilot)

These are real suggestions from the seeds. They are **not** part of the Corinth pilot. They are listed so they don't get smuggled in via "while we're at it."

1. **Offline triage live-USB image.** Bootable USB using nwipe/shred that locks the device, executes the wipe, and generates the §7 4-field attestation as a local text file. Useful at remote T2s without network. **Year two.**
2. **Biomimetic routing daemon.** A lightweight Ghojualamanchu-style instance running on a Solar Link local server to process environmental variables and physical asset distribution. **Caveat:** the published SOP forbids custom backend year one. The daemon is a real engineering claim with a real maintenance surface — it should be prototyped offline and only adopted if a pilot partner wants it, not because the seed said so.
3. **Public ledger mirror.** A read-only public mirror of `tinbot/ledger.csv`, weekly cadence. **Risk note:** confirm zero PII in schema before exposing. Schema-first, mirror-second.
4. **Privacy review.** Have a privacy-conscious reviewer sanity-check §7 and §8 before public release.
5. **Wipe-protocol training run.** A 2-hour remote training for T2 stewards.
6. **Second-region expansion.** Only after the 90-day write-up exists.

---

## 15. What we are *not* claiming in this canon

- A four-layer architectural stack placing Tinbot downstream of Anthrocybernetics and TLIP. **The architectural review's stack is its own draft**, not asserted here. Tinbot Transport stands on its own.
- A "biomimetic organism" framing with named brain structures. **Cortex/Amygdala/etc. are not wired into this canon.** If they belong in a later cognitive-routing prototype, that's the year-two daemon — and it needs pilot-partner demand, not just a seed saying so.
- A multi-region / "Planetary Network" / "Specialist–Replicator" lifecycle. **Out of scope** until at least one pilot write-up exists.
- A donor identity layer of any kind. **Forbidden by §7 and §8.1.**

---

## 16. Concrete next steps for the Discord

- [ ] Pin §7 ("We accept hardware, not data") as the channel topic in `#tinbot-intake`.
- [ ] Open `#fl-pilot` for Florida-cluster logistics talk.
- [ ] Open `#freight` for LTL/peer-routing math (§5, §6).
- [ ] Open `#ledger` to start the append-only log.
- [ ] Drop this canon into `#tinbot-jam` marked "v0.1, edit freely."
- [ ] Identify the pilot council (§11.1). Without it, pilot collapses to peer-only.
- [ ] Identify the 2 T1 nodes + the schoolhouse T2 steward.
- [ ] Draft the 1-page Charter (§12) for partner-facing materials.

---

*End of Tinbot Transport canon v0.1. Edit freely. The pilot, not the canon, is the destination.*