Responsible engagement

Status: product direction for planning and prototyping; not authorization to launch a promotion, recommendation engine, or unattended trading feature.

The unified thesis and Clubs and Harvest extension now accept reviewed social Bundle plans, opt-in financial publications and separately approved managed strategies. They narrowly supersede the former blanket copy-trading/public-sharing prohibition. Private defaults, informed financial consent and separation of engagement from authority remain mandatory.

Account terminology and authority follow the canonical account and mirror system. All engagement surfaces follow the end-user experience specification: infrastructure complexity stays behind progressive disclosure, while material financial and legal facts remain plain and visible.

1. Product decision

September 5, 2026 priority clarification: the primary customer takeaway is earning money and creating, holding and trading personal asset bundles in their own subaccounts. The earning and bundle specification controls that experience. Merchant discovery, shared trails and games support earning and acquisition. This document governs engagement conduct; the rewards and income architecture controls financial accounting.

Forage should gamify discovery, shared exploration, planned purchases, comprehension, consistency, and control. Merchant-funded value gives people a reason to try the product and share useful finds. Cosmetic collections and personal goals make progress enjoyable. Financial order submission, market volatility, portfolio returns, and time spent in the app never determine a promotional reward. Separately approved operator service compensation and contractual collateral reimbursements are not engagement rewards and follow the Clubs extension.

The finance-product examples in the supplied notes are useful as an idea bank, but their mechanics should not be copied literally. Forage combines the healthiest parts of four patterns:

• YNAB-style legible progress: translate a complex condition into an understandable, inspectable measure;
• Qapital-style authorship: let customers describe their own rules instead of receiving opaque recommendations;
• Fortune City-style visibility: make otherwise invisible account state spatial and memorable;
• Cleo-style personality: make explanations human without shame, pressure, or false certainty.

The intended emotional outcome is, “I found something useful, kept more of my money, and chose what to build with it.” Clear ownership, custody and authority support that experience.

2. Design doctrine

North-star rule

Celebrate useful discoveries, shared experiences and funded rewards. Keep investment choices calm and customer-directed.

Five product principles

1. Truth before delight. Provider, custody, rights, eligibility, fees, quote quality, market state, and data freshness remain literal and prominent.
2. Progress is inspectable. Every score is decomposable into source facts. No opaque financial-health score or AI-generated grade.
3. The customer chooses the authority. Self-directed policies remain customer-authored. Forage may translate, simulate, and explain a rule; it may not silently choose a security, increase a budget, or widen authority. A separately enrolled managed strategy allows a vetted operator to trade within the customer's signed instrument universe and limits, not through a social action or AI suggestion.
4. Progress can pause, but never punish. No broken streaks, lost levels, red shame screens, countdown pressure, or repeated volatility nudges.
5. Engagement cannot expand authority. An achievement, social action, AI suggestion, or promotional event can never grant wallet permissions or change an automation mandate.

3. Inspiration translated into Forage

4. The experience system

The nature vocabulary is a secondary brand layer. Primary navigation and all regulated facts stay literal.

4.1 Forage Compass — portfolio clarity

The Compass is not a performance score. It summarizes how complete and current the platform's understanding of the customer's account is.

Its components are displayed separately:

• Identity and eligibility: customer and provider-account checks are current;
• Custody coverage: each position maps to a known provider, wallet/subaccount, instrument, and network;
• Rights coverage: each instrument has a current Asset Passport and applicable disclosures;
• Reconciliation health: balances, orders, settlements, and corporate actions reconcile or show an explicit exception;
• Authority health: owners, delegates, mandates, budgets, expiries, and revocations are current and visible;
• Data freshness: market, provider, and chain data expose source and timestamp.

Each component is factual and actionable. A customer can open any incomplete segment to see the exact missing record or required action. Portfolio value, gains, trade count, and return never increase the Compass.

Recommended display:

• use a segmented compass or six-part ring rather than a 0–100 grade;
• label states current, attention, pending, and unavailable;
• never convert provider outages or pending settlements into customer “failure”;
• show “last verified” and the authoritative data source beside each segment.

4.2 Account Map — make the system visible

The Account Map defaults to a simple Portfolio → Accounts → Holdings view. A customer can expand Details to inspect the truthful technical topology:

Customer / organization
  -> AGW owner and recovery authority
      -> Portfolio (logical grouping; no assets or approvals)
          -> PROVIDER Canonical Account
              -> Dinari Account Instance -> approved tokenized-equity positions
          -> BASKET Canonical Account
              -> Robinhood Chain Account Instance -> direct constituent holdings
          -> STRATEGY Canonical Account
              -> chain-local Account Instance -> customer-authored mandate
          -> AGENT Canonical Account
              -> sandbox Account Instance -> bounded local delegate
          -> Account Mirror -> policy, budget, pause, and expiry; never assets

Technical edges are absent from the default view unless they require customer attention. In Details, ownership, provider binding, delegation, and mirror synchronization use distinct styles. Selecting an edge explains its authority, expiry, budget, and revocation path in plain language, with raw identifiers in Advanced. Pending, stale, restricted, and reconciled are states—not decorations.

This is the strongest adaptation of the “growing city” idea: the map becomes more complete as the customer links and verifies accounts, resolves exceptions, and adds intentional policies. It does not grow when the customer trades more frequently.

4.3 Rules Studio — customer-authored automation

Rules Studio turns a customer's stated intent into a deterministic policy draft. It is the product expression of the programmable-subaccount architecture.

Example drafts:

• “Propose a $50 purchase of my selected instrument every other Friday.”
• “Reinvest this instrument's dividend into the same instrument when the provider permits it.”
• “Pause this mandate if the executable price is more than 1% beyond the reference price.”
• “Notify me when cash exceeds my chosen buffer; do not move it.”
• “Expire this rule after six executions or $300, whichever happens first.”

The creation flow is always:

Plain-language intent
  -> structured policy draft
  -> exact simulation and edge cases
  -> provider/jurisdiction compatibility check
  -> customer confirmation
  -> mandate signature
  -> active, observable, revocable rule

Before activation, the customer sees instrument, provider account, destination subaccount, action, amount, cadence, lifetime cap, price/quote bound, permitted hours, start/end time, expiry, and every stop condition. The AI-generated translation is untrusted until validated by the policy service and confirmed by the customer.

MVP Rules Studio is explain and simulate only. Execution remains disabled until the provider, counsel, contract threat model, monitoring, and release gates approve the specific automation.

4.4 Forage Guide — conversational understanding

The Guide supports five visibly distinct modes:

1. Observe — summarize factual state and cite provider/chain timestamps.
2. Explain — translate terms, account topology, fees, rights, and risk.
3. Simulate — show hypothetical policy behavior without suggesting a security.
4. Propose — construct a customer-requested policy draft for review.
5. Execute — submit only an already signed, active mandate through the narrow Automation Gateway.

Every response separates:

• Fact: provider or onchain state with source and timestamp;
• Interpretation: a plainly labeled explanation;
• Customer choice: available self-directed actions;
• Authority: what the Guide can and cannot do in the current session.

Tone may be Straight, Friendly, or Dry. Humor belongs in low-stakes explanations and empty states. Losses, eligibility failures, security alerts, corporate actions, and execution failures always use calm, literal language.

4.5 Goals and consistency

Customers may define a goal, cadence, or review ritual. Progress measures adherence to the customer's chosen plan, not investment performance.

Use a Consistency Trail rather than a streak:

• it records completed reviews, reconciled periods, and followed or intentionally changed plans;
• skipped periods create a gap, not a reset or punishment;
• pausing, cancelling, or reducing a mandate is treated as a valid act of control;
• a change of plan records the reason and effective time without labeling it a failure.

4.6 Social layer — shared plans and Clubs

The financial-learning social lane uses shareable policy cards describing generic rule shapes, limits, stop conditions and learning notes. Importing one always creates an inactive draft that must be adapted and confirmed. Merchant discovery separately supports shared trails, private groups and passport collections under the growth specification; it is the first social acquisition experience.

The accepted extension adds versioned customer/creator Bundle plans with original artwork, disclosed holdings and a short thesis. Make it mine creates an inactive draft. Opt-in customer snapshots and reviewed operator performance records need dates, fees, risk context, actual-versus-modeled labels and privacy controls. Operator comparisons are factual due diligence, not gamified return leaderboards. Required operator history does not expose identifiable customer records.

Join community, Review a plan and Authorize managed trading are separate decisions. Only the last can establish discretionary authority after the operator, provider, legal and security gates pass. A new social post, follower count, badge, public return or Club role never installs or expands that authority. Managed trading terms, collateral and Harvest follow the Clubs extension; AI remains within the existing Guide boundary.

Later, Forage may offer opt-in, aggregated process benchmarks such as:

• percentage of comparable users who review active mandates monthly;
• common mandate-expiry ranges;
• percentage who revoke an unused delegate;
• typical time to resolve a reconciliation exception.

These process benchmarks require a minimum cohort threshold, jurisdiction/provider segmentation, suppression of small cells, no individual lookup, and privacy review. They must never rank return, trade frequency, account balance, or named holdings. Separately reviewed operator track records follow the financial-publication rules above. “People like you bought X” is prohibited.

4.7 Forage Lab — an actual game boundary

Financial simulation games belong in the separate play-money Lab. Merchant exploration, illustrated passports and private group trails use the growth specification and can coexist with fixed funded merchant rewards. Neither grants a live order button game mechanics or financial authority.

Forage Lab may use scenarios, basket building, research missions, visual progression, and cooperative challenges. It measures whether a user identified issuer rights, liquidity, concentration, authority, corporate-action, and execution risks. It does not rank returns or reward trading frequency.

Lab has no deposits, withdrawals, transferable items, redeemable points, yield, cash prizes, fee rebates, or wallet authority. Moving a Lab basket toward the live product exports only an inactive policy draft. Live re-runs current identity, jurisdiction, eligibility, disclosures, asset status, quotes, fees, and policy simulation before requesting a new signature.

A game skin over real securities does not create regulatory separation and may increase digital-engagement risk. The complete boundary and Robinhood Chain basket design are in the VIMEN and Robinhood basket evaluation.

5. Reward and protocol policy

Allowed non-monetary recognition

• setup milestones for completing identity, custody, recovery, or security checks;
• learning acknowledgements tied to an understood disclosure or successful simulation;
• safety milestones for reviewing mandates, revoking unused delegates, or testing recovery;
• visual completion of the Account Map;
• nontransferable, non-financial Field Notes or profile markers.

These records live offchain in a versioned engagement ledger. They are not NFTs, do not imply expertise, do not modify eligibility, and do not grant governance or financial rights.

Fixed merchant and sponsor value

Merchant discounts, commission-funded cashback and fixed prefunded sponsor benefits enter the first commercial pilot when the individual program permits Forage's methods. They require a defined liability ledger, budget cap, explicit funding source, fair expiration policy, tax/accounting treatment and offer terms. Available rewards require collected cash or a fully funded guarantee; merchant confirmation alone is insufficient. They remain separate from:

• regulated customer assets;
• provider wallets and programmable subaccounts;
• protocol revenue and Protocol Distribution Gateway accounting;
• performance, trade count, deposits, or turnover.

Any randomized promotion follows the separate Forage randomized-DCA evaluation. It is not part of the core engagement loop.

Income earned on customer holdings belongs to that customer under the product terms and does not fund general rewards. It accrues without check-ins, collectibles or referrals. A shared trail has no pooled savings balance. Referral benefits are fixed, limited and reserved from an approved merchant/sponsor acquisition budget; they do not depend on securities deposits or trades. Actual permitted merchant promotions can have disclosed end dates, but no personalized urgency or implied financial opportunity.

6. Explicitly prohibited mechanics

• confetti or celebration triggered by order submission, execution, leverage, or portfolio gains;
• gamified P&L, balance, return, or trade-frequency leaderboards;
• public-by-default or involuntary friend-visible transaction, position, wallet, or balance feeds;
• execution through social actions, silent copying or mandate enrollment, one-click unreviewed purchases, or “trending with people like you” prompts; separately approved managed strategies follow the Clubs extension;
• streak resets, expiring achievements, shame copy, repeated loss alerts, or punitive red states;
• scarcity timers, variable rewards, personalized odds, mystery assets, spins, packs, or pity counters;
• notification logic optimized for app opens, volatility checking, or incremental trade volume;
• achievements or points that change an account's permissions, provider status, pricing priority, or access to customer funds;
• AI-generated “buy,” “sell,” “hold,” portfolio-construction, or security-selection outputs in the self-directed launch product.

7. Technical architecture

7.1 Keep engagement outside the money path

The engagement service consumes read models and emits presentation state. It cannot sign, relay, settle, transfer, or mutate a mandate.

Provider + chain events
  -> reconciliation and domain event store
  -> engagement projector
  -> Compass / Map / Trail read models

Customer-authored rule
  -> policy compiler
  -> simulation
  -> explicit signature
  -> mandate registry
  -> Automation Gateway

Engagement event --------------------X----> money-moving authority

Suggested bounded modules:

• EngagementEvent: immutable offchain event with subject, definition version, source event, timestamp, and reversal state;
• MilestoneDefinition: versioned rule based only on eligible factual events;
• CompassSnapshot: decomposed status plus source timestamps; never the authoritative portfolio record;
• PolicyCard: non-executable, provider-neutral rule template;
• CommunityBenchmark: aggregated cohort result with privacy threshold and methodology;
• NotificationDecision: reason, source state, frequency cap, and suppression history;
• PromotionCampaign: separately permissioned campaign with reserved funding, explicit terms, immutable claims and a stop control; never funded from customer accounts.

No engagement state needs a smart contract in v1. Onchain attestations, badges, and transferable points add privacy, speculation, and permanence without helping the customer understand their portfolio.

7.2 Event requirements

Every engagement event must be:

• derived from a durable provider, chain, customer, or security event;
• idempotent and reversible when its source is corrected;
• versioned so a definition change does not rewrite history silently;
• excluded from financial ledgers and authorization decisions;
• explainable to the customer and support team;
• retained and deleted under the applicable privacy schedule.

8. Measurement and experimentation

Customer economics are a core outcome: report funded cash rewards, received income/dividends, private realized/unrealized investment results and net costs truthfully. The rules below do not suppress performance information or normal buy/sell/rebalance functions. They prevent reward mechanics from encouraging unnecessary turnover. Deposits, internal transfers and gross sale proceeds are not profit.

Healthy outcome metrics

• onboarding and recovery-setup completion;
• percentage of portfolio positions with current Asset Passports;
• reconciliation coverage and median exception-resolution time;
• percentage of mandates reviewed before renewal;
• unused delegates revoked and expired authority removed;
• successful simulation-to-confirmed-policy comprehension;
• reduced support incidents caused by misunderstood custody, settlement, or authority;
• notification usefulness and low opt-out/complaint rates.

Harm guardrails

• trades per active customer and short-interval order reversals;
• volatility-driven app opens and notification re-entry;
• turnover, loss-chasing proxies, and repeated budget increases;
• mandate expansions immediately after losses or scarcity messaging;
• complaint, confusion, accidental-order, and self-exclusion signals;
• performance disparities by experience level or potentially vulnerable cohort;
• increased execution without a corresponding increase in comprehension.

An experiment is stopped if it materially increases a harm guardrail, even when retention, app opens, or revenue improve. Product analytics must not define order count, turnover, time-on-screen, or notification opens as primary success metrics.

Experiment review packet

Every engagement experiment records:

1. the customer problem and expected healthy outcome;
2. the exact trigger, message, audience, and frequency cap;
3. excluded cohorts and sensitive states;
4. primary outcome and harm guardrails;
5. compliance and provider review requirements;
6. an owner, end date, rollback switch, and post-test decision.

9. Notification policy

Notifications are service communications first. Default candidates are settlement changes, corporate actions, expiring authority, reconciliation exceptions, provider outages, security events, and customer-requested factual alerts.

Behavioral notifications must be opt-in, frequency capped, quiet-hour aware, and suppressible. Market movement alone does not justify a push notification unless the customer created the exact factual alert. One warning is preferred to a cascade. Messages never use “last chance,” “everyone is buying,” “do not miss out,” or loss-shaming language.

10. Delivery sequence

The stages below are independent workstreams, not required sequential releases. The delivery roadmap controls sequencing; reviewed social plans and manual Harvest do not depend on broad automation.

Stage A — comprehension layer

• Compass component model and source provenance;
• Account Map read-only topology;
• Guide in Observe and Explain modes;
• security, custody, reconciliation, and disclosure milestones;
• engagement event ledger and harm-metric baseline.

Stage B — authorship layer

• Rules Studio drafts and deterministic simulations;
• non-executable policy cards;
• Consistency Trail without resets;
• Guide in Simulate and Propose modes;
• user research focused on comprehension, not delight scores alone.

Stage C — controlled automation

• provider- and counsel-approved mandate types only;
• explicit signatures, caps, expiry, revocation, monitoring, and incident controls;
• Guide Execute mode through the Automation Gateway;
• experiment kill switches and cohort limits.

Stage D — reviewed social discovery and financial publications

• opt-in aggregated benchmarks with minimum cohort thresholds;
• private shared goals for approved account relationships;
• versioned plans that import as inactive drafts and explicitly consented customer snapshots;
• reviewed operator track records with fees, risk, failures and methodology, separate from promotional rankings;
• no default-public financial graph or social action that grants execution authority.

Merchant pilot — runs alongside Stage A

• useful offer discovery and local trails with fixed, disclosed benefits;
• a separate funded liability/campaign ledger and a complete payout/reversal cycle;
• location-optional verification, cosmetics, private groups and useful share links;
• prefunded fixed referral rewards only after attribution and contribution are measured;
• optional income and reward-to-equity funding follow their own provider and funds-flow acceptance;
• randomized Forage Boost remains research, outside the delivery roadmap.

11. Launch acceptance criteria

Apply the following checks to the capabilities included in each controlled pilot. Compass, Guide, policy cards and financial automation each require their own evidence before being enabled; they are not prerequisites for a merchant-only discovery/rewards pilot. That first pilot must instead prove funded claims, payouts, reversals, cosmetic/financial separation, location alternatives and approved merchant methods.

For enabled features:

• Compass state can be reproduced from authoritative sources and every segment is inspectable;
• engagement events cannot reach signing, relaying, or mandate-mutation code paths;
• performance, order count, and turnover are absent from milestone definitions;
• all notifications have a reason, cap, suppression rule, and customer control;
• accessibility works without color, animation, or the nature metaphor;
• Guide outputs distinguish fact, interpretation, choice, and authority;
• policy cards import only as inactive drafts;
• analytics dashboards show harm guardrails beside retention metrics;
• provider, compliance, privacy, and support teams have approved customer-facing language.

12. Source and regulatory notes

• YNAB currently documents Age of Money as an average time between receiving and spending money and explicitly says there is no universal target. That is the right model for an inspectable metric, not a prescriptive grade: YNAB Age of Money.
• Stash's Stock-Back program shows how a fixed commercial reward can connect an everyday action with ownership, but it depends on a brokerage/banking/card relationship and should not be generalized into a Forage launch feature: Stash Stock-Back.
• The SEC's request for information on digital engagement practices demonstrates that behavioral prompts, game-like features, and optimization in investment applications receive specific regulatory attention: SEC release 2021-167.
• The SEC withdrew its proposed predictive-data-analytics conflicts rules in June 2025. The proposal is not a current final rule, but the withdrawal is not a safe harbor from existing securities, communications, conduct, or supervisory obligations: SEC withdrawal.
• FINRA continues to identify gamification as a monitored fintech area because games, streaks, points, badges, leaderboards, and notifications may influence investment selection and trading: FINRA FinTech.
• Customer communications remain subject to the applicable provider agreement and communications rules, including fair-and-balanced presentation requirements where FINRA Rule 2210 applies: FINRA Rule 2210.
• Dinari's U.S. model requires a unique wallet for each account, restricts U.S. tokens from transfers and DeFi, and requires approval for partner communications. Engagement mechanics cannot bypass those product constraints: Dinari U.S. integration requirements.

This specification is product and architecture guidance, not a legal conclusion. Promotions, recommendations, automated trading, and customer communications require jurisdiction-specific counsel and provider approval.