Every requirement carries three tags:

• ID — stable reference (WIN-01, PAY-03…). Use these in feedback, tasks, and the decision log.
• Priority — P0 (MVP, must exist for the OS to be useful) · P1 (fast follow) · P2 (later / nice-to-have).
• Status —
• CONFIRMED — backed by a vault document Jonathan has already approved.
• ASSUMPTION — reasonable inference; needs Jonathan's yes/no.
• OPEN (Qx) — depends on an unanswered discovery question in QUESTION-BANK; the ID in brackets is the question.

Honesty rule: no client names, revenue figures, or pipeline facts appear in this PRD because none are confirmed in the vault (VAULT-GAP-AUDIT: Sales pipeline, client roster and revenue side are 🔴 critical gaps). Anything numeric that IS here traces to a vault doc.

1.1 Product definition

MyStash OS is the operating system that runs My Stash Rewards end-to-end: from winning a local business client, to launching their loyalty card, to growing their program, to getting paid — with AI agents (Riddick client-facing, Lara ops) as the back office, and Jonathan doing only what humans must do: relationships, site visits, decisions.

It is not a dashboard bolted onto Boomerangme. It is the money-lifecycle spine the whole business runs on (pattern proven by esti-mate.app — see ESTIMATE-ANALYSIS):

WIN THE CLIENT → LAUNCH THE CARD → GROW THE PROGRAM → GET PAID → RUN THE BUSINESS

1.2 Why now

• Boomerangme exposes a full REST API v2 (80 endpoints), ~40 webhook events, and a native MCP server (BOOMERANGME-API-MAP). The card platform is automatable end-to-end — no browser automation needed. CONFIRMED
• MSR holds a lifetime deal: $0/mo platform cost, unlimited sub-accounts, 100% of client revenue retained (Pricing, confirmed by Jonathan 2026-03-13). Gross margin per client is effectively the subscription price minus ~$25–50/mo shared overhead. CONFIRMED
• The vault documents the machine (48 systems, costs, logins) but not the business (pipeline, clients, targets) — VAULT-GAP-AUDIT. The OS is how that gets fixed and stays fixed. CONFIRMED
• Jonathan runs MSR alongside trade work, phone-first, with dyslexia — the OS must compress the business into big-text, plain-English, voice-first surfaces or it will not be used. CONFIRMED (persona) / OPEN (F3) (actual hours available)

1.3 Vision statements (to be ratified by Jonathan)

ID	Statement	Priority	Status
VIS-01	12-month picture: a portfolio of paying local-business clients run day-to-day by AI, with Jonathan spending his MSR hours only on selling and relationships.	P0	OPEN (F1)
VIS-02	The ONE number the whole OS optimises (client count vs MRR vs Jon's income vs hours saved) — chosen by Jonathan, displayed everywhere.	P0	OPEN (F2)
VIS-03	Income intent: replace trade income vs side income, and on what timeline — this sets roadmap aggressiveness.	P0	OPEN (F6)

1.4 North-star metric & guardrails (proposed)

ID	Metric	Definition	Priority	Status
MET-01	North star: net MRR — sum of active client subscriptions ($99/$149/$199 tiers per Pricing).	P0	ASSUMPTION (pending F2 — Jon may prefer client count or personal income)
MET-02	Guardrail: Jonathan's MSR hours/week ≤ his declared capacity. The OS exists to shrink this, not grow it.	P0	OPEN (F3)
MET-03	Guardrail: client churn — target 0 losses/quarter early; annual-plan close strategy (Pricing) is the main churn defence.	P0	CONFIRMED (strategy) / OPEN (C1, C6) (baseline)
MET-04	Guardrail: cost base — monthly opex stays near the ~$350.42/mo baseline; every new tool must justify itself against it.	P1	CONFIRMED (VAULT-GAP-AUDIT; note Business Model corrected source baseline AUD 261.87/mo — reconcile in discovery, M5)
MET-05	Health metric: per-client engagement — installs, scans, redemptions per client per month (from API stats), because client results drive renewals.	P1	CONFIRMED (data available via API) / OPEN (E2) (which 3 numbers clients care about)
MET-06	Health metric: speed to launch — days from "yes" to card-live per client. Platform supports ~15-min setup; our real cycle time unknown.	P2	OPEN (C2)

1.5 Success criteria for the OS itself (6 months post-launch)

ID	Criterion	Priority	Status
SUC-01	Jonathan checks ONE surface (morning brief) and trusts it as the truth of the business.	P0	OPEN (E8 — what must be on that one screen)
SUC-02	No client-facing deliverable (proposal, report, chase message) is hand-made; all are AI-generated, Jon-approved.	P0	ASSUMPTION
SUC-03	Zero missed payment failures or renewal dates — every billing event lands as a task within minutes (webhooks).	P0	CONFIRMED (webhook events exist)
SUC-04	The vault stops being stale: SCOREBOARD/PIPELINE/CLIENTS files are living views updated by the OS, not stubs.	P1	CONFIRMED (gap documented)

2.1 Personas

User	Role	What they touch	Design law
Jonathan	CEO / seller. Tradesperson, phone-first, voice-first, dyslexia.	Morning brief, approvals, pipeline, money screen. Big text, plain English, ✅/❌, voice in & out. Never sees raw API/JSON/jargon.	If Jon needs a manual, we failed.
Riddick	Client-facing AI.	Comms drafts, proposals, campaigns, chase messages, client check-ins. Sends only within decision-rights matrix (§8).	Sounds like MSR (Branding DNA voice), never robotic.
Lara	Ops AI.	Research, tracking, delivery pipeline, reporting, vault upkeep, API/webhook plumbing, monitoring.	Boring reliability. Escalates by exception.
Michael	CTO (volunteer, ad hoc — Business Model).	Technical surfaces: API keys, webhook receiver, MCP config, infra.	Task-specific involvement, should trend to zero (L4 — formalise the arrangement).
MSR clients	Local business owners (ICP: F&B, salons, retail, medical, hospitality — Target Market).	No-login links only: proposal page, monthly report page, feedback. WhatsApp/SMS-first. Optional Boomerangme dashboard via SSO magic link.	One tap or it doesn't ship.
Cardholders	End consumers.	Apple/Google Wallet passes via Boomerangme. Never touch MyStash OS directly.	Out of OS scope except as data (scans, installs).

2.2 Role requirements

ID	Requirement	Priority	Status
ROL-01	Jon's surfaces render at minimum 18px body / 28px+ headings, sentence case, Forest Green/Gold/Cream palette, ✅/❌ status markers, no tables of raw numbers without a plain-English sentence above them.	P0	CONFIRMED (Branding DNA + persona)
ROL-02	Every Jon-facing item offers voice: brief read aloud; replies accepted as voice notes.	P0	ASSUMPTION (mechanism — Telegram voice notes assumed; confirm O4/E3)
ROL-03	Decision-rights matrix (§8) is machine-readable config both agents load; no agent action outside its granted rights.	P0	OPEN (O1–O5)
ROL-04	Clients never need a password for anything MSR sends them. Where dashboard access is wanted, use Boomerangme GET /companies/{id}/sso-link magic links.	P0	CONFIRMED (API supports) / ASSUMPTION (clients want dashboard access at all — C3)
ROL-05	Michael-only technical console kept separate from Jon's surfaces (never mixed).	P1	ASSUMPTION

Everything from "who should we talk to" to "they said yes". EstiMate analogue: AI quote writer + no-login accept page + CRM.

3.1 Prospect CRM & pipeline

ID	Requirement	Priority	Status
WIN-01	Prospect pipeline with plain-English stages. Proposed: Spotted → Chatted → Demo sent → Thinking → Yes → Launched (rename per Jon's real sales motion). Card view on phone; one prospect = one card with next step + owner.	P0	ASSUMPTION (stage names) / OPEN (S1 — current pipeline contents; S3 — natural motion)
WIN-02	Every prospect has exactly one next step with a date; brief flags any prospect with no next step or an overdue one.	P0	ASSUMPTION
WIN-03	Pipeline data lives in the vault (canonical store, per §9) as structured markdown; OS renders it. Kills the PIPELINE.md stub problem permanently.	P0	CONFIRMED (vault-canonical principle)
WIN-04	Lead capture from the field: Jon voice-notes "met Sam at the bakery on Beaufort St, keen, wants stamp card" → Lara parses into a prospect card, Riddick drafts the follow-up.	P0	ASSUMPTION (workflow) / OPEN (S2 — where leads actually come from)
WIN-05	Business-type triage on every new prospect (existing skill: client-business-model-triage): vertical fit ranking per Target Market (F&B #1 … Prof services #6), disqualify e-commerce-only / enterprise / no-repeat businesses.	P1	CONFIRMED (ICP + skill exist)
WIN-06	Conversion tracking per stage and per lead source, once ≥10 prospects have flowed through.	P2	OPEN (S2)

3.2 No-login demo & proposal link (the closer)

ID	Requirement	Priority	Status
WIN-07	Texted demo link: one URL per prospect showing their own card mocked up with their branding (loyalty-card-mockup skill), what customers see on their phone, and pricing. Jon sends it from the van by SMS/WhatsApp. No login, mobile-first, MSR-branded.	P0	ASSUMPTION (EstiMate pattern; E1 asks Jon if this closes deals and what must be on the page)
WIN-08	Proposal shows the three plans from Pricing ($99 / $149 target / $199 per location) with the close strategy baked in: lead with Plan 2 annual ($1,788/yr) + Plan 3 features as bonus + onboarding fee (~$899) waived on annual signup.	P0	CONFIRMED (pricing + close strategy, Jonathan-approved Apr 2026)
WIN-09	No free trials offered anywhere in the flow (Pricing philosophy: kills urgency). ROI framing uses Boomerangme's calculator links, in plain English ("digital relationship", not "leverage ROI" — Branding DNA).	P0	CONFIRMED
WIN-10	One-tap actions on the proposal page: ✅ Yes, let's go / 📞 Call me / ❓ Question — each notifies Jon instantly and creates the right task.	P0	ASSUMPTION (EstiMate accept/decline pattern)
WIN-11	Optional extras menu with live total: extra card designs, managed push campaigns, additional locations, etc. — client self-selects, price updates.	P1	OPEN (E4 — should clients self-pick add-ons; what add-ons to offer)
WIN-12	Proposal engagement signals (link opened, time on page) fed to the brief: "Sam opened your proposal twice yesterday — good time to call."	P1	ASSUMPTION

3.3 Sales enablement

ID	Requirement	Priority	Status
WIN-13	Objection playbook in the OS: the top recurring objection with Jon's best plain-English answer, on his phone mid-conversation.	P1	OPEN (S5 — what the recurring objection actually is)
WIN-14	Sub-account creation on "yes" is one action: POST /companies + tariff via API — no manual Boomerangme signup for the client.	P0	CONFIRMED (API endpoints exist; self-registration route tested Jul 2026)
WIN-15	Referral engine: existing clients get a referral offer; referred prospects tracked to source. Platform has referral mechanics (CustomerReferralCreated webhook) for cardholder level; client-level referral deal needs design.	P1	OPEN (S8, E6 — whether/what reward)
WIN-16	New-client intake capped by delivery capacity: OS warns when signups/month exceed Jon's declared onboarding capacity.	P2	OPEN (S6)

From "yes" to a card in real customers' wallets, fast and repeatable. EstiMate analogue: contracts + programme + snag-free handover.

4.1 Onboarding pipeline

ID	Requirement	Priority	Status
LCH-01	Launch checklist per client instantiated from a master template (the 10-step customer setup believed to exist in the Operational Register — verify). Each step: owner (Jon / Riddick / Lara / Client), status ✅/⏳/❌, due date.	P0	ASSUMPTION (10-step exists) / OPEN (C2, C3 — verify steps + who does what)
LCH-02	Card template built and activated via API (POST /templates → PATCH → activate), using the existing boomerangme-client-card-creation skill and card-type reference (8 types: Stamp/Cashback/Multipass/Coupon/Discount/Gift/Membership/Reward). No browser wizard.	P0	CONFIRMED (API + skills exist)
LCH-03	Card type recommended by vertical per Target Market mapping (e.g. F&B → Stamp; salons → Membership/Stamp; retail → Cashback/Gift). Jon approves the pick.	P1	CONFIRMED (mapping) / OPEN (P2 — which types actually get used)
LCH-04	Locations + staff scanner accounts provisioned via API (POST /locations, POST /managers + permissions).	P0	CONFIRMED (endpoints exist)
LCH-05	Client-side setup packaged as one no-login page: "3 things we need from you" (logo, offer, staff names) with tap-to-upload. Chased automatically by Riddick if stalled >48h.	P1	ASSUMPTION

4.2 Launch-day kit

ID	Requirement	Priority	Status
LCH-06	Auto-generated launch kit per client: counter signage with QR, staff one-pager ("how to scan"), sign-in screen images (existing skill: boomerangme-signin-screen-image), social announcement pack — all in client's branding.	P0	CONFIRMED (skills exist for mockups/sign-in images) / ASSUMPTION (full kit contents — validate with C7)
LCH-07	"Card live" confirmation to client: congratulations message + their first wallet install milestone + what happens next.	P0	ASSUMPTION
LCH-08	First-week check-in auto-scheduled: day-7 message with first numbers (installs, scans from API stats) and one tip. Flags to Jon if week-1 installs = 0.	P0	ASSUMPTION (cadence)
LCH-09	Onboarding fee (~$899, or waived per close strategy) invoiced/recorded at launch — hand-off to GET PAID module.	P1	CONFIRMED (fee exists) / OPEN (M4 — are we actually charging it)
LCH-10	Launch SLA measured (days from yes → live); target set after baseline known.	P2	OPEN (C2, C5 — promises already made)

Keeping every client's card alive and visibly working — because client results are our renewals. EstiMate analogue: progress reports clients love + warranty tracker.

5.1 Client performance reporting

ID	Requirement	Priority	Status
GRW-01	Monthly branded report per client, auto-compiled from API (GET /operations, /cards, /customers, template statistics): installs, scans/visits, redemptions, repeat-visit trend. Delivered as a no-login link by WhatsApp/SMS/email. Plain English: "212 customers now carry your card."	P0	CONFIRMED (data endpoints exist) / OPEN (E2 — the 3 numbers clients must see)
GRW-02	Report includes one recommended action per month (e.g. "send a quiet-Tuesday push") that the client approves with one tap — which Riddick then executes via API.	P1	ASSUMPTION
GRW-03	Reports carry MSR branding per Branding DNA (professionalism sells — EstiMate lesson 7).	P0	CONFIRMED

5.2 Campaigns & automation

ID	Requirement	Priority	Status
GRW-04	Campaign calendar per client: planned pushes/SMS by month (seasonal, quiet-day, win-back). Riddick drafts content in client's voice; sends via POST /pushes / POST /sms after approval per decision rights.	P0	CONFIRMED (API) / OPEN (O2 — whether client or Jon approval is needed per send)
GRW-05	Workflow automations per client via /workflows suite (triggers, filters, actions + execution logs): welcome series, lapsed-customer win-back, reward-earned congratulation. OS keeps a library of proven journeys per vertical.	P1	CONFIRMED (API supports) / ASSUMPTION (journey library contents)
GRW-06	RFM segment movement (GET /segments, CustomerSegmentLinked webhook) drives win-back triggers: customers sliding into "at risk" → campaign suggestion.	P1	CONFIRMED (data exists)
GRW-07	UTM links + per-UTM stats per template track which channel fills each client's card (counter QR vs Instagram vs Google). Feeds report + advice.	P2	CONFIRMED (API supports)

5.3 Health & lifecycle

ID	Requirement	Priority	Status
GRW-08	"Card is quiet" alert: no scans in N days (default 7 — tune per vertical) → task for Riddick to check in with client + surfaces in Jon's brief.	P0	ASSUMPTION (threshold)
GRW-09	Anniversary/renewal triggers (warranty-tracker pattern): 30 days before annual renewal → refresh offer + price-review prompt + upsell suggestion. 12-month card refresh play.	P1	OPEN (E7 — what should happen at 12 months)
GRW-10	Feedback loop: FeedbackCreated webhook → route to client + Riddick drafts response; happy feedback → review-request nudge.	P1	CONFIRMED (webhook exists) / ASSUMPTION (review flow)
GRW-11	Upsell detection: client near tier customer limits or multi-location signals → propose plan upgrade ($99→$149→$199).	P2	CONFIRMED (tier anchors per Pricing) / ASSUMPTION (trigger logic)

Money visible in real time, not after the fact. EstiMate analogue: overdue flags + one-tap chase + margin analytics.

6.1 Billing & collections

ID	Requirement	Priority	Status
PAY-01	Recurring billing tracker per client: plan, amount, cadence (monthly/annual), next payment date, status ✅ paid / ⏳ due / ❌ overdue.	P0	ASSUMPTION (how clients actually pay is unknown — M2)
PAY-02	Payment method + invoicing flow defined per client (invoice vs direct debit vs Stripe link) and executed by the OS; Stripe exists in the stack (Business Model).	P0	OPEN (M2, M3 — who pays what, how, and real charged amounts vs Pricing.md)
PAY-03	One-tap chase: overdue → Riddick drafts a friendly chase (WhatsApp/SMS/email per client preference) → Jon approves with ✅ → sent. Escalation ladder for repeat non-payment.	P0	ASSUMPTION (flow) / OPEN (L2 — what we do when a client stops paying)
PAY-04	Boomerangme payment webhooks (PaymentCompletedFailed, RecurrentPaymentCompletedFailed, TariffExpired*, SubscriptionCancelled) → instant task + Jon alert. Churn defence in minutes, not month-end.	P0	CONFIRMED (webhooks exist; applies where clients pay through platform billing) / ASSUMPTION (billing route — M2)
PAY-05	Money owed to us / by us captured at discovery and tracked to zero.	P1	OPEN (M7)

6.2 Profitability & finance view

ID	Requirement	Priority	Status
PAY-06	MRR & margin dashboard: total MRR, cost base (~$350.42/mo baseline — reconcile against corrected AUD 261.87/mo), net margin. Given $0 platform cost, contribution ≈ price minus $25–50/mo shared overhead per Pricing.	P0	CONFIRMED (cost side) / OPEN (M1 — revenue side)
PAY-07	Per-client profitability: revenue minus attributable costs (SMS spend, delivery time) — "which clients make us money" visible at a glance.	P1	OPEN (E5 — Jon wants this?; missing cost items per Business Model)
PAY-08	Cash position & runway number on the money screen.	P1	OPEN (M5 — buffer unknown)
PAY-09	Xero linkage: invoices and reconciliation flow into Xero ($80/mo, in stack — note payer/entity mismatch: currently billed to JD Painting, fix at L5). Accountant/BAS owner recorded.	P1	CONFIRMED (Xero exists) / OPEN (M8 — bookkeeping owner; entity fix)
PAY-10	Jon's personal "worth it" threshold displayed against actual monthly net — the honest line the business must beat.	P2	OPEN (M6)

The command deck. EstiMate analogue: Copilot morning brief + compliance kit + business advisor.

7.1 Jon's morning brief (the flagship surface)

ID	Requirement	Priority	Status
RUN-01	Daily brief, voice + big-text card, containing at most: 💰 money needing action (overdue, failed payments) · 🤝 prospects to chase (with the one next step) · 🎴 cards needing attention (quiet cards, launches in progress) · ✅ what the AIs did yesterday · ▶️ today's ONE next best action. Max 60 seconds spoken.	P0	CONFIRMED (pattern + event feed exist) / OPEN (E3 — daily vs exception-only; E8 — the one trusted screen; O4 — rhythm)
RUN-02	Brief is fed by the webhook event bus in real time (installs, scans, payment failures, cancellations) — not scraped or manually compiled.	P0	CONFIRMED (BOOMERANGME-API-MAP event list)
RUN-03	Every brief item is one-tap actionable: ✅ approve · ⏭ skip · 🎤 voice-reply. No item without an action.	P0	ASSUMPTION
RUN-04	Bad news delivered per Jon's stated preference (straight up vs cushioned; O7) — configured, not guessed.	P1	OPEN (O7)

7.2 Work management

ID	Requirement	Priority	Status
RUN-05	Vault task board (TASKS.md) is the single work queue for Riddick, Lara, and Jon-items. Every OS-generated task lands there with owner + due date; agents work from it; Jon sees a filtered "needs Jon" view only.	P0	CONFIRMED (vault-canonical principle) / OPEN (O6 — how Jon wants to see work)
RUN-06	Weekly review artefact: one page — the ONE number, wins, worries, decisions needed. Cadence per O4.	P1	OPEN (O4)
RUN-07	Risk register + decision log (already exist in vault) wired into cadence: new risks/decisions from any module append automatically; standing decisions (e.g. pricing rules) are enforced by agents.	P1	CONFIRMED (docs exist)

7.3 Compliance & admin

ID	Requirement	Priority	Status
RUN-08	Compliance kit: client agreement/T&Cs template, privacy policy, cancellation terms — sent with every proposal, signed/acknowledged before launch (even a one-tap acknowledgement). Current contract status unknown.	P0	OPEN (L1 — do clients sign anything today)
RUN-09	Non-payment policy (pause card? grace period?) codified so PAY-03 escalation is automatic, not improvised.	P1	OPEN (L2)
RUN-10	Admin calendar: ASIC annual review ($310/yr), insurance renewal ($1,450/yr), trademark milestones, domain expiry (TPP, Mar 2028, no auto-renew) — all as dated tasks with lead time.	P1	CONFIRMED (items + amounts in Business Model)
RUN-11	The Michael arrangement documented (volunteer CTO — anything written down?).	P2	OPEN (L4)
RUN-12	Outstanding legal/tax nags (ASIC, entity separation, Xero payer mismatch, suspended Google Cloud billing) tracked to resolution.	P1	CONFIRMED (issues listed in vault) / OPEN (L5)

Riddick + Lara are the back office. This section makes that formal, safe, and auditable.

8.1 Decision rights matrix (to be filled by O1–O5; proposed starting point)

Zone	Meaning	Proposed contents	Status
🟢 AI-autonomous	Do it, log it	Vault upkeep, report compilation, stats pulls, drafting anything, monitoring, scheduling reminders, chasing internal checklist items	ASSUMPTION (O2)
🟡 AI-proposes, Jon approves	One-tap ✅ required	Anything client-visible (messages, campaigns, reports going out), pricing shown on proposals, chase messages, new automations per client	ASSUMPTION (O1, O2)
🔴 Jon-only	Never automated	Pricing changes (per Pricing rules → Decision Log), signing new clients, discounts below $39/mo (explicit rule), spending over the AI limit, firing a client, anything legal	CONFIRMED (pricing rules) / OPEN (O1)

8.2 Operating rules

ID	Requirement	Priority	Status
AIM-01	Machine-readable decision-rights config; both agents load it at session start; violations impossible by construction, not by promise.	P0	OPEN (O1–O3 for contents)
AIM-02	AI spend limit: dollar ceiling an agent may commit without approval (proposed default: $0 until Jon sets one).	P0	OPEN (O3)
AIM-03	Escalation rules: what wakes Jon immediately (proposed: payment failure, client complaint, anything legal) vs waits for the brief vs never reaches him.	P0	OPEN (O5 — the "never contact me about" list)
AIM-04	Cadence config: brief frequency (daily vs exception-only), weekly review day/format.	P0	OPEN (O4, E3)
AIM-05	Full audit trail: every AI action (API call, message sent, file changed) logged with timestamp + acting agent + authority used. Reviewable by Michael.	P0	ASSUMPTION (good practice; confirm depth)
AIM-06	Riddick writes in MSR brand voice (Branding DNA: sharp, warm, real; never corporate/salesy; "digital relationship" not "loyalty program" in marketing copy). Voice linting on outbound drafts.	P1	CONFIRMED (voice guide exists)
AIM-07	Agent handoff protocol: Riddick (client-facing) and Lara (ops) share state via the vault; no side channels; conflicting edits resolved via task queue.	P1	ASSUMPTION
AIM-08	Kill switch: Jon can say "pause the AIs" (one message) → all autonomous actions halt, queue preserved.	P1	ASSUMPTION

Backbone facts from BOOMERANGME-API-MAP (researched 2026-08-08, live OpenAPI v2.0.0). All CONFIRMED as platform capabilities; items needing verification are listed in INT-08.

8b.1 Access & architecture

ID	Requirement	Priority	Status
INT-01	REST API v2 at https://api.digitalwallet.cards (80 endpoints), auth via X-API-Key. White-label host works identically. All OS card-platform operations go through API/MCP — no browser automation.	P0	CONFIRMED
INT-02	MCP server (/mcp, Streamable HTTP, OAuth 2.1/Bearer, scopes mcp:read/mcp:write) registered in both agents' configs → natural-language platform ops for Riddick/Lara; raw REST fallback for gaps.	P0	CONFIRMED (server exists) / ASSUMPTION (registration pending)
INT-03	Webhook receiver hosted by MSR; subscribes to ~40 events (card/customer lifecycle, sub-accounts, 💰 payments, subscription lifecycle). Events → OS event bus → brief, tasks, alerts.	P0	CONFIRMED (events) / OPEN (receiver hosting decision — Michael)
INT-04	Module wiring: Win = POST /companies, SSO links, GET /tariffs, games/UTM · Launch = templates CRUD+activate, cards, locations, managers · Grow = 18 transaction endpoints, pushes, SMS, segments, workflows, promotions, UTM stats · Get paid = revenue stats, operations log, payment webhooks · Run = white-label branding/domains, profile/agency, external services.	P0	CONFIRMED
INT-05	Card type IDs standardised in OS config (Stamp 0 · Cashback 1 · Multipass 2 · Coupon 3 · Discount 4 · Gift 5 · Membership 6 · Reward 7).	P1	CONFIRMED
INT-06	Event-driven client health: CardInstalled counts, RFM movement (CustomerSegmentLinked), FeedbackCreated feed GRW alerts and reports without polling.	P1	CONFIRMED
INT-07	Degradation plan: if API/webhooks are down, OS queues actions and flags staleness on affected surfaces (never silently shows old data as fresh).	P1	ASSUMPTION
INT-08	Verification checklist (pre-build, owner Michael/Lara): ① confirm plan includes API access + generate key ② test GET /api/v2/templates ③ choose webhook receiver host/port ④ register MCP in both agent configs + verify scopes ⑤ confirm agency-level vs sub-account-level key behaviour.	P0	CONFIRMED (checklist stands, unexecuted)

ID	Requirement	Priority	Status
NFR-01	Jon UX law: voice-first, ≥18px body text, plain English (reading age ~10), ✅/❌ markers, sentence case, one idea per screen, phone-first (small-screen tested before desktop).	P0	CONFIRMED (persona + Branding DNA)
NFR-02	Brand: all surfaces use Forest Green #1B3A2D / Gold #D4AA5F / Cream #F7F3EC, Gilroy-ExtraBold-style headings, Inter body; never pure black backgrounds, never purple/blue SaaS palettes.	P0	CONFIRMED (Branding DNA)
NFR-03	Client UX law: no logins, no app downloads, one-tap actions, WhatsApp/SMS-first delivery.	P0	CONFIRMED (blueprint) / OPEN (C4 — clients' actual preferred channel)
NFR-04	Data architecture: the vault is the canonical store (clients, pipeline, money, decisions, tasks — markdown, wikilinked, git-backed); Boomerangme is the card platform of record (accessed only via API v2/MCP). OS surfaces render vault + API data; they never own data.	P0	CONFIRMED
NFR-05	Cost ceiling: new tools/services must justify against the ~$350.42/mo baseline; anything recurring requires a Decision Log entry.	P0	CONFIRMED
NFR-06	Privacy & data care: client and cardholder data handled per privacy policy (RUN-08); no client data in third-party tools outside the approved stack; API keys never in the vault in plaintext.	P0	ASSUMPTION (no formal policy yet — L1/L5)
NFR-07	Reliability: brief delivered by 7:00am local daily (or per O4); webhook-to-alert latency < 5 min for payment failures; missed-event detection via daily reconciliation pull.	P1	ASSUMPTION (targets — tune with Jon/Michael)
NFR-08	Auditability: every outbound client message and every money-touching action traceable (who/what/when/authority) — see AIM-05.	P0	ASSUMPTION
NFR-09	Simplicity bias: static/no-build surfaces where possible; boring tech; anything Michael must maintain gets a runbook. Michael's involvement trends down (Business Model).	P1	CONFIRMED (Michael arrangement)
NFR-10	Accessibility: dyslexia-aware typography (generous line-height ≥1.5, short lines, no justified text, no italics for emphasis), voice alternatives for all text surfaces.	P0	CONFIRMED (persona)

Sequenced on the honest dependency: discovery answers gate everything. Capacity-gated by F3 (Jon's hours) once known.

NOW (weeks 0–2) — Discovery + plumbing + first trust surface

ID	Item	Depends on	Status
RMP-01	Run the discovery interrogation (QUESTION-BANK Phases 1–8) → fill SOUL/SCOREBOARD/PIPELINE/CLIENTS stubs; resolve all OPEN tags in this PRD.	Jon's time	OPEN (all)
RMP-02	Execute INT-08 verification (API key, test call, webhook receiver, MCP registration).	Michael	CONFIRMED (checklist ready)
RMP-03	Stand up the event bus + morning brief v1 (RUN-01..03): even a thin brief from real webhooks beats a perfect brief later.	RMP-02	ASSUMPTION
RMP-04	Populate the pipeline + client roster in the vault from discovery answers (WIN-01, WIN-03; C1, S1).	RMP-01	OPEN
RMP-05	Billing truth pass: who pays, how much, how (M1–M8) → billing tracker v1 (PAY-01) + overdue flags.	RMP-01	OPEN
RMP-06	PRD v0.2 ratified with Jon (X1–X3) using the visual MVP walkthrough for feedback.	RMP-01	OPEN

NEXT (weeks 3–8) — The money-lifecycle MVP

ID	Item	Depends on	Status
RMP-07	No-login proposal/demo link (WIN-07..10) with pricing + mockup + one-tap accept. First real prospect gets one.	RMP-01 (E1), mockup skill	OPEN (E1)
RMP-08	Launch checklist + API-driven card creation end-to-end on the next new client (LCH-01..07).	RMP-02	ASSUMPTION
RMP-09	Monthly client report v1 (GRW-01, GRW-03) for every live client; first send reviewed by Jon.	RMP-02, E2 answer	OPEN (E2)
RMP-10	One-tap chase flow (PAY-03) + payment-failure alerts (PAY-04) live.	RMP-05	OPEN (M2, L2)
RMP-11	Decision-rights config v1 + audit trail (AIM-01..05).	O1–O5 answers	OPEN
RMP-12	MRR/margin money screen (PAY-06) with real numbers.	RMP-05	OPEN (M1)

LATER (months 3–6) — Growth engine & polish

ID	Item	Depends on	Status
RMP-13	Campaign calendar + workflow-automation library per vertical (GRW-04..07).	RMP-09	ASSUMPTION
RMP-14	Quiet-card alerts, renewal/anniversary engine, upsell triggers (GRW-08..11).	Event bus maturity	OPEN (E7)
RMP-15	Optional-extras menu on proposals (WIN-11) + referral engine (WIN-15).	E4, E6, S8 answers	OPEN
RMP-16	Per-client profitability + runway view (PAY-07, PAY-08); Xero automation (PAY-09).	Cost-item completion (M-phase)	OPEN
RMP-17	Compliance kit shipped with every proposal (RUN-08..09); legal nags cleared (RUN-12).	L1–L5 answers	OPEN
RMP-18	Weekly review artefact + full cadence automation (RUN-06); objection playbook (WIN-13); conversion analytics (WIN-06).	Cadence config	OPEN

Explicitly NOT in scope (v1)

• A client-facing self-serve SaaS product (freemium ladder is an EstiMate idea parked for much later).
• Cardholder-facing features beyond what Boomerangme provides.
• Multi-agency / reselling MSR's OS to other agencies.
• Any browser-automation of Boomerangme (superseded by API/MCP).

1. Everything branded, everything professional — clients take us more seriously. 2. Zero-friction client actions — no logins, one tap, WhatsApp/SMS-first. 3. The OS surfaces "next best action" daily — it thinks, Jon decides. 4. Money visible in real time, not after the fact. 5. AI as staff, not feature — Riddick and Lara are the back office, formalised in §8.

Question	Blocks
F1, F2, F6	VIS-01..03, MET-01
F3	MET-02, roadmap pacing
E8, E3, O4	RUN-01, AIM-04, NFR-07
S1–S8	WIN-01, WIN-04, WIN-06, WIN-13, WIN-15, WIN-16
E1, E4, E6	WIN-07, WIN-11, WIN-15
C1–C7	MET-03, LCH-01, LCH-05, LCH-06, LCH-10, NFR-03
E2, E7	GRW-01, GRW-09
M1–M8	PAY-01..10, MET-04 reconciliation
E5	PAY-07
L1–L5	RUN-08..12, NFR-06, PAY-09
O1–O7	§8 entire, ROL-03, RUN-04..06
X1–X3	PRD ratification (RMP-06)

Date	Version	Change
2026-08-08	v0.1	First full draft from vault evidence, pre-discovery. All unverified items tagged ASSUMPTION/OPEN. Companion visual MVP deployed for Jon's feedback.

Next step: Jon walks the visual MVP, fires feedback via the Telegram button, then we run the interrogation (QUESTION-BANK Phase 1) and cut v0.2.

Related: PRD-BLUEPRINT · QUESTION-BANK · BOOMERANGME-API-MAP · ESTIMATE-ANALYSIS · VAULT-GAP-AUDIT · BUSINESS-OS-DISCOVERY-LOG