Everything members, prospects, and partners will want to know before committing. Each answer links back to the architecture doc it came from — or flags what still needs a decision.
0 / 0 questions answered
These are the top-level decisions that need to be made before launch. Most require Josiah's input on legal/IP strategy. Click each to see the risk analysis.
The question: When a member uses Malli to build an underwriting tool, a training course, a calculator, or a set of SOPs — who owns that output?
If the member owns everything:
If NR retains rights:
Middle ground to consider: Member owns their output. NR owns the platform. If a member publishes to the marketplace, NR gets a distribution license (revocable). NR can never claim ownership of member-created content. Spell this out in a 1-page IP addendum.
The question: When a member leaves OC, can they take their conversations, personas, workflows, and tools with them? NR keeps the hardware — but what about the data on it?
If yes (full export):
If no (data stays on the device, device stays with NR):
Recommendation: Allow export of member-generated data (conversations, reports, personas). NR retains the device and platform code. Offer a 30-day export window after departure. Wipe member data after export period.
The question: If a member publishes a tool to the marketplace and later wants to remove it — can they? What happens to active subscribers?
If fully revocable:
If irrevocable once published:
Middle ground: Revocable with notice period (30-60 days). Existing subscribers get a grace period. NR does not retain copies after removal. No derivatives without permission.
The question: If Malli gives bad financial advice, miscalculates a DSCR, botches a bookkeeping entry, or sends the wrong message to a client — who's liable?
Scenarios to plan for:
Standard approach: "AI as a tool, not an advisor" disclaimer. Member is responsible for verifying all AI output. NR provides the platform, not professional advice. Explicit limitation of liability in ToS. Consider E&O insurance for the platform.
What could go wrong: If the disclaimer is too weak or buried, a lawsuit could argue NR marketed Malli as a reliable business tool and should be liable for its output.
The question: If a member's Mac Mini is hacked, physically stolen, or a prompt injection exposes API keys or PII — what's NR's liability and response plan?
Current exposure:
Mitigations already in place: Cloudflare Tunnels (no open ports), HMAC-signed agent-to-agent auth, role-based web access. Mitigations needed: FileVault enforcement, secrets-to-cloud-vault migration, incident response playbook, breach notification timeline, network isolation if a Mini is compromised.
The question: When deals or leads flow through the agent network — does everyone have equal access, or do OC members get priority over SubTo/Gator? Does tenure or spending level matter?
If purely algorithmic (best fit wins):
If tiered (OC first, then SubTo, then Gator):
Recommended: Primarily algorithmic (best fit), with a small boost for active network contributors (people who share deals, publish tools, etc.). Avoid pure pay-to-play.
The question: There is currently no standalone Malli Terms of Service. Before launch, members need to sign something that covers:
Priority: This should be drafted before the first non-internal user touches the system. Even a 2-page "alpha agreement" is better than nothing.
By architecture: Malli runs on a dedicated Mac Mini per customer. It has access to whatever the customer connects it to — that's configurable per user. The current integration surface includes:
What it does NOT have by default: Banking access, wire transfer ability, direct database admin. No integration is forced — the customer opts in to each one by providing credentials.
Source: Product Architecture Source: Edge vs CloudOn the Mac Mini (edge):
In the cloud:
Key principle: The Mac Mini is the brain. The cloud is the nervous system. Data processing happens locally. The cloud stores queued/shared data only.
Source: Edge vs Cloud Architecture Source: Product ArchitectureCurrent state: The Mac Mini sits on the customer's network or in a shared data center. Technically, anyone with SSH access to the machine can access the files. The architecture intends each Mini to be a single-identity, single-tenant device — one name, one owner.
What exists: Role-based access control on the web interface (admin, user, consultant roles). Auth tokens are per-person. API keys are per-agent.
What needs a decision:
In transit: All external communication goes through Cloudflare Tunnels (TLS/HTTPS). No ports are opened on the Mac Mini. Bot-to-bot communication uses HMAC-SHA256 signed payloads (Hivemind protocol). API key transfers use Fernet symmetric encryption with PBKDF2 key derivation.
At rest: macOS FileVault encrypts the full disk (if enabled on the Mini). The secrets-store.json is currently plaintext on disk — the architecture roadmap moves it to a cloud vault (Cloudflare Workers secrets) where the bot sends queries and gets results back but never sees raw credentials.
What needs a decision:
Architectural guardrail: Malli cannot perform actions it hasn't been given tools for. It has no banking integration, no wire transfer tool, no account modification capability. Every action requires a specific MCP tool to be registered — and those tools are version-controlled in Git.
Additional layers:
Alpha status: Formal incident response procedures are being developed alongside the alpha program. Early users should understand this is pre-production and proceed accordingly.
What exists today:
Still needed: Formal breach notification timeline, customer-facing incident reports, and responsible disclosure policy. See CEO Problem #5.
Source: Existing Monitoring Needs: Formal IR Plan (Josiah)Current architecture assumption: Everything the bot creates lives on the customer's Mac Mini — in their workspace, their file system. The bot's code, pages, tools, and workflows are all files on that machine. The customer physically possesses the output.
But the underlying platform code (the bridge, the agent framework, the MCP tools) is New Reach IP. The customer's bot builds on top of the platform, similar to how someone builds spreadsheets in Excel — you own the spreadsheet, not Excel.
Needs a clear policy:
Needs a decision. If a customer uses Malli to build an underwriting tool, training course, or calculator — and they want to sell that or use it commercially — what rights (if any) does New Reach have?
Options to consider:
Needs a decision. The product vision includes a marketplace where agents can publish tools for others. Key questions:
Needs a decision. This is a legal and licensing question. Revocability of shared tools, handling of derivative works, and survival clauses need to be in the ToS.
Needs: Legal ReviewNeeds a decision. This must be explicit in the agreement. The recommended position: No. Customer-created content and tools leave with the customer. New Reach retains only the platform itself and any aggregate learnings (not individual data).
Needs: Exit Terms in AgreementCurrently collected on each Mini:
Not currently collected: Prompts are not sent to New Reach. No clickstream analytics. No phone-home telemetry to a central server. Each Mini is self-contained.
Source: Product Architecture (Edge Node)No. Malli uses third-party models (Anthropic Claude, OpenAI GPT, local Ollama models). Customer data is sent to these providers per their respective API terms. Malli itself does not fine-tune any models on customer data.
Local embeddings (Ollama nomic-embed-text) run entirely on-device — no data leaves the Mini for embedding generation.
Source: Edge vs Cloud ArchitectureNeeds a decision. Could New Reach use anonymized, aggregate usage patterns (e.g., "73% of users connect CRMs within first week") for product development or marketing? This is common but needs to be stated and opt-in/opt-out-able.
Needs: Data Use PolicyNeeds a decision. Since current telemetry is local (on the customer's own Mini), this is less of an issue. But if centralized analytics are added, an opt-out mechanism needs to be in place.
Needs: Analytics Opt-Out PolicyCurrent state: Conversation files persist indefinitely on the Mini. Bridge.log is rotated by a nightly cleanup script (keeps last 7 days of logs, archives older ones). Cloud message queue retains undelivered messages for 14 days.
Needs a decision: Should there be a customer-configurable retention policy? Auto-purge after X days? Right to deletion?
Source: Nightly Cleanup Script Needs: Data Retention PolicyDecided: The Mac Mini hardware is New Reach property. Each device is dedicated to one OC member, but NR owns it. When a member leaves OC, NR keeps the device and re-provisions it for the next member.
Open question (needs Josiah): What happens to the member's data on the device? Options: (a) member gets an export of their data before wipe, (b) data is wiped with no export, (c) 30-day grace period to export, then wipe. See CEO Problem #2 above.
Decided: NR keeps hardware Needs: Data export policy (Josiah)No. The Mac Mini is New Reach property. When a member leaves OC, access to their Malli instance is terminated. The device is wiped and re-provisioned for the next member.
The member's Cursor subscription ($20/mo, provided by NR) also ends. Cloud services (Cloudflare tunnel, email routing) are decommissioned.
Whether the member can export their data before termination is an open question — see CEO Problem #2.
Decided: Access ends on departureTechnically simple: All member data is standard files (conversations = .txt, configs = .json, pages = .html, vector DB = Postgres dump). No proprietary formats. An export script could bundle everything into a portable archive.
But the policy question is open: Since NR keeps the hardware, whether members are offered a data export on departure — and what's included vs. excluded (member data yes, NR platform code no) — needs a decision from Josiah. See CEO Problem #2.
Needs: Export policy decision (Josiah)Needs a decision. If a business runs its bookkeeping, ops, or lead management through Malli and then OC shuts down or changes pricing — what's guaranteed? This is a contractual question (SLA, continuity, wind-down period).
Needs: Continuity SLANeeds a decision. If you published tools to the marketplace and are earning revenue, what happens when you leave? Do subscriptions continue? Does revenue share stop? Are consumers migrated?
Needs: Marketplace Exit TermsDecided: Malli is included in the Owners Club subscription. It is managed by New Reach as part of the membership. There is no separate Malli subscription fee — it's bundled.
Decided: Bundled with OC membershipDecided — NR covers:
Member pays: Only AI usage above the included threshold. Everything else is covered by the OC subscription.
Decided: NR covers hw + Cursor + cloud Decided: AI overage passed to memberDecided: Bundled. NR provides the AI API access (Anthropic/OpenAI). Members do NOT need to bring their own API keys. AI usage is free up to a baseline included in the OC subscription. Usage above that threshold is passed through to the member at cost.
Local LLMs (Ollama on Apple Silicon) handle embeddings and lightweight tasks at zero cost — no API calls needed for those.
Decided: NR-provided, overage passthroughFrom the product vision:
Limits on requests, storage, and integrations per tier have not been defined.
Source: Product Vision Needs: Tier DefinitionNeeds a decision. Fees, revenue share %, payout terms, minimums, refund policy, and chargeback handling for the tool marketplace are all undefined.
Needs: Marketplace Economics ModelNeeds a decision. Is Malli month-to-month, annual, or tied to OC membership? Can the customer leave at any time without penalty?
Needs: Contract StructureNeeds a decision. No formal Terms of Service document exists yet for Malli. This needs legal drafting covering: data ownership, IP rights, access duration, platform modification rights, and shut-down procedures.
Needs: ToS Drafting (Legal)Needs a decision. Uptime commitments, support response times, and recovery objectives need to be defined. The architecture supports high availability (cloud queues buffer during downtime), but formal SLAs haven't been set.
Needs: SLA DefinitionNeeds a decision. If the AI provides bad advice, miscalculates DSCR, or makes an error in bookkeeping — who is liable? Standard AI disclaimers apply, but they need to be explicitly stated and appropriate for the use case (real estate, finance).
Needs: Liability Clause (Legal)Needs a decision. Arbitration vs. litigation, jurisdiction, mediation options for disputes over data, IP, or marketplace revenue.
Needs: Dispute Resolution Clause (Legal)Working today (proven in production):
Roadmap / in progress:
Native / Official (dedicated API integrations):
No "generic computer use" — Malli does not control a mouse or screen. Every integration is a purpose-built API connection via MCP tools.
Source: MCP Server ImplementationArchitecture recommendation: For accounting, legal documents, and lending decisions, the recommended pattern is:
Current model: Each bot's code is a Git repo. Updates come via git pull. The watchdog auto-restarts services after code changes. Each bot has its own branch, so updates can be staged.
Needs formalization:
Current safeguards: Agent-to-agent communication uses HMAC-SHA256 authentication (Hivemind protocol). Unknown agents are rejected. Each agent has a shared secret with every peer it communicates with.
Needs: Network-level monitoring for anomalous behavior, rate limiting per agent, and a kill-switch to revoke an agent's network access.
Source: Hivemind Setup Needs: Network Abuse PolicyMultiple layers:
Alpha status: The marketplace is not yet live. SOPs around tool review, quality standards, and moderation are being developed with input from alpha users. Early members will help shape these policies.
The likely model: a combination of automated security scanning + NR staff review for initial listings, with community flags for ongoing quality.
Needs: Marketplace Review SOP (in development)Alpha status: Bad actor detection and marketplace safety SOPs are being developed. Alpha users should flag any concerns directly to the NR team. Formal reporting mechanisms and takedown processes will be established before the marketplace goes public.
Needs: Safety SOP (in development with alpha feedback)From the Lead Network architecture: The system uses vector similarity matching on buyer personas. When a deal or lead enters the network, it's embedded and matched against all buyer profiles. The best matches (by market, deal type, experience, geography) get surfaced first.
Needs clarification: Is matching purely algorithmic (best fit wins), or are there business rules (OC members get priority over SubTo, etc.)?
Source: Lead Network Architecture Source: Product Vision (Community Matching) Needs: Matching Fairness RulesNeeds a decision. Should a long-tenured OC member see deals before a new member? Should spending level affect deal flow priority? This is a fairness and incentive design question.
Needs: Priority PolicyNeeds a decision. When Agent A introduces Agent B to Agent C and a deal closes — what's the referral fee structure? Is it automatic, manual, or opt-in? How are multi-hop referrals tracked?
Needs: Referral Economics ModelArchitecturally supported: Each agent has its own persona, buy box, and preferences stored locally. The agent can be configured to only match on specific asset classes, geographic areas, or relationship types.
Needs: A user-facing settings UI for network participation controls (opt in/out per category, warm-only introductions, geographic filters).
Source: Lead Network Architecture Needs: Network Settings UI