The Bounty Command Centre

How submissions enter the system, how verifiers see them without seeing anything else, how duplicates die at the door, and how the sovereign gets the ping on the phone.

Sealed 18 Apr 2026. Companion to MD-269 (rates & doctrine). MD-269 says what the bounties are. MD-270 says how the work flows through the system. Both are required reading for any operator running the bounty programme.

1. The Rule (one line)

Fresh Gmail for intake. CircularOS for everything else. Verifiers touch the inbox and the dashboard. Workers never see the system. The sovereign's main email stays clean.

2. The Three Audiences

👷 Workers

Send submissions. Get a feedback link. Never log in. Never see other workers, other submissions, or any internal system.

🔍 Verifiers

PIN-gated dashboard. See pending submissions. Flip status only. Cannot see jobs board, registry, financials, or any other CircularOS surface.

👑 Sovereign

Full access. Payment queue. Phone-friendly ping inbox. Email account password. Verifier PIN. Everything.

3. The Pipeline

Worker submits — either via email to the dedicated bounty Gmail, or via the public form at /bounty-submit.
System ingests — the database creates a row, runs the duplicate check, and assigns a public token (the worker's status link).
Sovereign gets a ping — appears in /bounty-pings within seconds, with a sound and a vibrate on mobile.
Verifier reviews — opens /bounty-verifier, applies the two checks (work happened, result happened), flips status to APPROVED or REJECTED.
Worker sees feedback — at their bookmarked /bounty-status/<token>. If duplicate, they're told and invited to submit a different lead.
Sovereign pays — opens /bounty-payments, confirms the suggested amount, marks paid. Worker sees PAID at their token URL.

4. Duplicate Protection (automatic)

Bounty type	What makes it unique	What triggers DUPLICATE
FIND	Domain	Same domain already in PENDING / APPROVED / PAID
SEND	Domain + worker email	Same worker has already counted that domain
REPLY	Domain + thread hash	Same body content already submitted for that domain
CALL	Domain + day	Two CALL submissions for one company on one day

Detection runs before insert. The duplicate row is still saved (so the audit trail exists), but its status is DUPLICATE from the moment it lands and no payment is queued.

5. The Fresh Gmail (sovereign sets up externally)

Create a separate Gmail account, e.g. bounty.circularos@gmail.com. Then either:

Manual: verifier opens that inbox, copies submissions into /bounty-submit on the worker's behalf. Simple, works today, no setup.
Automated: attach a Google Apps Script trigger that POSTs every new email to /api/bounty/email-webhook with header X-Bounty-Secret: $BOUNTY_WEBHOOK_SECRET. The webhook auto-detects bounty type from the subject line and inserts a row.

Either way, the Gmail credentials are sovereign-only or shared with appointed verifiers at the sovereign's discretion. They never touch CircularOS source.

6. Phone Notifications

/bounty-pings is built mobile-first. Open it once on your phone, tap "Add to Home Screen" in the browser menu — it now opens like a native app. The page:

Auto-refreshes every 8 seconds.
Shows a red unseen badge in the header.
Plays a soft sound + vibrates when a new ping arrives.
Asks for browser notification permission so it can also push a system-level notification when the tab is in the background.

7. Access Control Matrix

Surface	Worker	Verifier	Sovereign
/bounty-submit	✅	✅	✅
/bounty-status/<token>	✅ own only	—	—
/bounty-verifier	❌	✅ (PIN)	✅
/bounty-payments	❌	❌	✅
/bounty-pings	❌	❌	✅
Bounty Gmail inbox	send-only	✅ (shared)	✅
Rest of CircularOS	❌	❌	✅

8. Database Tables

bounty_submissions — every entry, with status, dedupe_key, public_token, verifier notes, payment record.
bounty_pings — one row per system event (NEW · EMAIL · DUPLICATE · DECISION · PAID), used by the phone ping page.

9. Status Flow

PENDING → APPROVED → PAID · PENDING → REJECTED · (insert) → DUPLICATE

10. The Two-Check Rule (lifted from MD-269)

Check 1 — Work Happened: the activity meets the published quality bar. For REPLY: full thread, ≥30 substantive words, domain matches a Companies-House-registered company.
Check 2 — Result Happened: downstream outcome — supplier identified, call held, material on the floor, Carrot fed.
The rule: no verification = no pay. Check 1 only = base bounty. Both clear = base + bonus.

11. Appointment Clause (sealed)

"Verification Team roles are appointed by the sovereign. Appointment is flexible — family, trusted individuals, or hired verification staff. No names are recorded in the doctrine. The verification email account is shared with appointed verifiers at sovereign discretion."

12. Configuration Secrets

VERIFIER_PIN — the PIN appointed verifiers use at /bounty-verifier-login. If unset, falls back to SOVEREIGN_PIN.
BOUNTY_WEBHOOK_SECRET — header secret that the Gmail Apps Script must include when POSTing to the email webhook. If unset, the webhook is open (use only for testing).

13. Linked Doctrine

MD-269 — EGZ4 Bounty v2.0 (rates, two-check verification, referral layer, appointment clause)
EGZ4 Source v2.0 — full 250-line doctrine
Protocol 028 — Bounty Contractor operating protocol
Jobs Board — where each bounty becomes a tracked job row
18-Point Verification — the underlying quality spine

SEAL · 18 April 2026 · SCP-2701 · MD-270
The sovereign sees the ping. The verifier sees the dashboard. The worker sees the feedback link. No one sees what they shouldn't. The system is the gate.