# BRIEF.md — Banno Plugin Console Regrounded from the v2 design prompt (originally written to run inside `trabian-mesh-apps`). The prototypes now live here, in `junod-prototypes`, so they publish to GitHub Pages. The source material stays where it is — read it, don't copy it. --- ## What this is A mock of the **bank-facing** experience for the **Banno Plugin Console** — the product a bank buys to control, build, and safely publish the plugins that appear inside its Jack Henry Banno digital banking app. **Audience.** The buyer is a community-bank digital banking leader; users include a compliance approver. Calm, trustworthy, bank-grade back-office. Confidence comes from **visible safety** — approvals, audit, rollback — not dashboard density. Targeting especially must read as a compliance-grade control, because a wrong rule puts the wrong product in front of the wrong member on the most-viewed screen in the bank. --- ## Source documents (on this machine, read — don't work from memory) Base: `/Users/tranqy/projects/mesh/trabian-mesh-apps` | Order | Path | What it gives you | |---|---|---| | 1 | `docs/banno-console-concept.md` | The decisions. Four-part loop (Connect / Create / Publish / Observe), why the bank buys, success metrics. Most authoritative product statement. | | 2 | `docs/banno-console-design-brief.md` | Personas, the five experiences, publish states, deliverables. | | 3 | `.claude/skills/create-banno-extension/SKILL.md` + `references/jackhenry-docs.md` | What a Banno plugin *is*: sandbox/iframe rules, card face vs. Expanded View, JH-confirmed vs. our stance. | | 3b | `.claude/skills/create-banno-extension/references/banno-people-and-secrets.md` | The manual JH registration steps Connect must wrap and live-verify. | | 4 | `.claude/skills/extension-router/SKILL.md` | The router: one Banno URL, many plugins, one live. Where targeting rules evaluate. | | 5 | `memories/banno-fi-theming.md` | FI theming pipeline + Garden's real palette. → `DESIGN.md` | | 6 | `memories/banno-view-only.md` | The view-only rule and its attribution. | | 7 | `memories/banno-plugin-demo.md`, `docs/banno-hosting-product-plan.md` | Skim: what's live, business context. | Design system tokens and components: `/Users/tranqy/projects/mesh/mesh-platform/apps/hub/ui/src/` — see `DESIGN.md`. **Precedence when documents disagree:** this brief > `banno-console-concept.md` (2026-08-07) > design-brief > hosting-product-plan > demo runbook/memories (accurate but demo-era). `docs/banno-console-design-prompt.md` in that repo is **v1 and superseded** — it invites you to propose a console identity. Don't. --- ## Two things v2 settled 1. **The console uses the Mesh Hub design system.** Not a new identity. See `DESIGN.md` — that decision is locked and does not reopen. 2. **State-based plugin targeting exists.** The slot model is no longer "one card, many plugins, exactly one live." It is **"exactly one default live plugin, plus ordered targeting rules."** Where the concept doc or brief say otherwise, this supersedes them. --- ## The five experiences + targeting **Connect** — guided sync with live verification. There is *no JH API* for this; copy-paste is acceptable, uncertainty is not. The console generates each value verbatim and checks it. **Console home** — the slot model, targeting-aware. A slot reads "Live: 3 rules → 3 plugins (default: Accounts overview)", not a single name. **Create** — Upload (point the router at hosted code, or ship a bundle Mesh deploys) and Studio (compose view-only primitives bound to governed read ops, with AI-assist and live FI-theme preview). **Publish** — draft → preview → approval → go-live → verified → rollback. Solo-light or maker-checker-strict, schedulable, audited. **Observe** — governed activity feed with correlation IDs legible to a non-engineer. Scope drift loops back into Connect. **Targeting** — the newest surface, designed with the same care as Publish. ### Targeting mechanics you can rely on (so the design stays honest) - Rules evaluate **server-side in the router at session time**. No member data reaches the browser to decide this. Targeting does not weaken the delegated-token posture. - Vocabulary v1 is small and enumerable, grounded in governed read ops: **account type held** (checking / savings / mortgage / loan / CD) and **balance comparators** on an account type (below / above / between), combinable with AND. No free-form expressions, no external data. - **Ordered, first-match list with a required default.** One plugin renders. No blending. - **A targeting change is a publish.** Add, edit, reorder, or remove → the same governed workflow, the same audit trail (rule content, actor, timestamps). Rules version with the release; rollback restores the prior rule set. - View-only is unaffected. Targeting selects *which* view-only plugin renders, never what a plugin may do. ### Guardrails — keep v1 honest No percentages we cannot compute. No date/campaign scheduling *of rules* (the publish workflow has scheduled go-live; that is different). No per-member overrides. No A/B framing. This is **state-based selection**, not a marketing targeting tool. --- ## Open questions — recommendations (stated, not left open) These were required deliverables. Each is now a decision; reopen deliberately. | Question | Recommendation | |---|---| | "Plugins" vs. "extensions" | **"Plugin"** in all bank-facing UI, everywhere, no mixing. "Extension" stays internal to the router code. | | How much JH copy-paste to expose in Connect | **Expose all of it, verbatim and checked.** Four values pasted into Banno People, each verified. Hiding the seam would be dishonest — there is no registration API. | | Card metadata ownership | Title, description, icon, and initial height are bank-visible but live in JH's back office. **Mirror and preview them; generate a copy-paste block.** Never pretend to own them. | | AI-assist entry shape | **A chat composer inside Studio**, not a magic button. It composes view-only primitives bound to governed read ops and *cannot* emit an action. | | Theme overrides in Studio | **No.** The frame renders the bank's real theme, pulled. An override would be the first crack in the boundary. | | Alerting in v1 | **No alerting.** Observe is a governed feed with correlation IDs shared verbatim with the Banno support ticket. | | Match-rate estimates on rules | **Qualitative only.** Show "Matches N of 4 preview members" and flag "No preview member matches this." Never a population percentage — we cannot compute one. | | Canned personas vs. editable | **Canned for v1.** Four synthetic members with stated facts. Editable persona facts invite the admin to treat preview as proof of coverage; it isn't. | | Maximum rule count | **No hard cap; soft pressure.** Order legibility degrades past ~6. If a bank needs more, the card is answering two questions and wants splitting. | | One card or two | Most banks run one. A second is warranted when the two answer **different questions** (money at a glance vs. borrowing), never to split one card's content. | --- ## Deliverables and build status | # | Deliverable | Status | |---|---|---| | 1 | IA + navigation inside the Hub app shell | **Built.** Sidebar: *Dashboard card* (Card, Plugin library, Studio) + *Governance* (Activity, Connection). Recommendation: **standalone app wearing the Hub system** — the buyer is a bank, not a Mesh operator, and the sidebar should not expose Hub's platform routes. | | 2 | Rule builder | **Built.** Plain-language condition rows, no expression syntax. | | 2 | Slot model extended, drag-reorderable | **Built.** Ordered rules → matched plugin, required default pinned at the bottom. | | 2 | Preview-as-member | **Built.** Four personas, card face + Expanded View, bank's real theme. | | 2 | Publish: draft bar → diff → approval → schedule → verify → rollback | **Built.** | | 2 | Create via Studio (chat + canvas) | **Built** as a working sketch. | | 3 | Light **and** dark | **Built.** Explicit toggle in the sidebar footer. | | — | First-run Connect (guided sync, live verification) | **Partial.** Steps are described in the Connection view and the add-card dialog; not yet a first-run flow. | | — | Create via Upload | **Partial.** Described in the library; no upload flow. | | — | Scope-drift repair looping back into Connect | **Not built.** | | — | Standalone extended slot-model diagram | **Not built.** The rule list carries the mental model today; the concept/brief also want it as a diagram for the publish preview. | | — | Rollback of a *rule change* specifically | **Partial.** Rollback exists in Activity; the rule-set-restore path isn't distinguished in the UI. | Nothing above is a promise. It's the honest edge of the current mock. --- ## v3 — team feedback, 2026-08-31 (supersedes where it conflicts) The public narrative lives at `trabian.com/trabian-your-banno-team` ("Trabian is your Banno team"; the Plugin Router — one Banno registration, many contexts; "a plugin in motion — from Banno dashboard card to full experience"; runs on Mesh, SOC 2 Type II). These prototypes and that page must tell the same story. **1. The product is the orchestration, not the cards.** "One slot, a flow decides which plugin renders per user" is what we sell. Lead every surface with it. The v2 "ordered first-match rules" model is a special case of the flow model; the flow (one deterministic Temporal workflow per card, first matching condition wins, unconditional last branch) is now the canonical mental model. **2. Go past the card into the Expanded View.** Same plugin, and it is the surface Banno already provides for deeper interaction — if we own the card we own the full page. Mocks must be Garden-accurate: per jackhenry.dev (`architecture/userinterface`, `overview/configuration`) the card title, icon, and **primary action button sit outside the plugin iframe** as Banno-rendered chrome from static Banno People config. The orchestrator prototype annotates these seams on demand. **3. Write-back journeys are in scope — the strongest version isn't rotating ads, it's writing back.** Flagship demo: account maintenance. A card nudges "confirm your address" (snowbird persona: 12+ months stale, bounced email), the primary action opens a full journey in the Expanded View, and the change writes to the core through a governed Mesh op with a correlation ID and an audit entry. Why this one: banks ask to customize the Q2 address change constantly (validated recurring demand), it is cross-platform rather than Banno-only, and it reads as data hygiene / compliance instead of an ad server. This supersedes the blanket view-only stance for the *journey* plugin class (precedent: mesh-platform's `skip-a-payment` actional extension, 2026-08-25); campaigns and feature tiles remain render-only. The targeting vocabulary grows accordingly: contact-data hygiene signals (address staleness, bounced email) join account type and balance — still governed read ops, still no external data. **4. Demo multiple plugin types on demand.** The demo must switch between at least: a campaign, a feature tile, and a write-back journey — both through the flow (personas) and directly (bypassing the flow), card face and Expanded View. **The payoff demo:** complete the address journey as the snowbird persona and return to the dashboard — the flow re-evaluates, the maintenance branch no longer matches, and the *same slot* now renders the CD campaign. That loop is the product in one interaction. Built as `banno-plugin-orchestrator.html`. Known gap: flow edits apply instantly there; the governed publish path (draft → approval → rollback) still lives only in the card manager and needs to be unified in a later pass. --- ## v3.1 — research-driven demo lineup, 2026-08-31 `RESEARCH-extension-drivers.md` (cited, in this folder) grounds which plugins the demo carries. Rule: **one demo story per measured buyer pain, no duplicates, no invented placements.** | Demo asset | Buyer pain it maps to (evidence) | |---|---| | Confirm-address journey | Efficiency / call deflection + compliance (calls cost 10–20× digital; efficiency top-3 priority) | | Skip-a-payment journey | Loan-side fee income ($100K+/yr at Vibe CU, self-service, zero call-center touches) | | First 90 Days activation | CUs' #1 priority: younger members; matches the "sign-up detection" promise already on trabian.com | | Savings ladder (add → CD → match) | Deposits: banks' #1 priority (64%, JH Strategy Benchmark 2026) — one story, three branches | | SMB card (invoicing → cash-flow) | 75–80% of CEOs expanding SMB services; Autobooks proved SMB plugins deploy at Banno scale | | Savings Insights tile | The slot's evergreen default — insight the native dashboard doesn't show, not an ad | **Placement honesty (fixes a v3 defect):** plugins are dashboard cards, period. The invented `accounts.detail.header` and `transfers.landing.1` slots are gone; the business card is honest because External Application **user-type filtering** (Cash Management) is real. Three cards remain: two retail dashboard cards, one Banno Business card. **Cut:** the Recent Transactions tile (duplicated native Banno — the weakest answer to "why pay for this card?"). Bill Pay Autopay stays licensed-but-idle in inventory to show breadth. **Avoid entirely:** PFM/budgeting (10–15% member adoption plateau) and crypto (usage declined post-2022) — see research file. **Deliberately deferred:** a funnel-rescue card riding the 67% digital-application-abandonment stat — sharpest number in the research, but it requires demonstrable visibility into abandoned applications through Mesh before we can demo it honestly. Six canned personas now (four retail, two business) — extends the v2 "canned for v1" decision, same rationale.