> For the complete documentation index, see [llms.txt](https://wiki.fridays.bot/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.fridays.bot/documentation/white-paper/14.-roadmap.md). # 14. Roadmap Roadmap items are ordered by a single rule consistent with the rest of this paper: **each addition must reuse the existing invariants (single gateway, approval model, audit chain) rather than create exceptions to them.** A feature that would require a side channel around the gateway (§2.1) or an approval bypass (§6.5) is rejected regardless of demand. #### 14.1 Category expansion sequencing The sequence is demand-weighted but gated by the transport decision rule (§3.2) and partner-program lead times (§3.7), which is why order is *payments → e-commerce/POS → payroll → social* rather than alphabetical or purely by request volume: 1. **Payments (next).** Closes the invoice-to-paid loop — the single highest-value gap, because the wedge playbook (`invoice_followup`, §5.1) currently ends at "reminder sent" when the tenant's actual goal is "invoice paid." Integrating a payments provider (Stripe-class) lets the playbook attach a pay link and *observe settlement*, converting a communication playbook into an outcome playbook. Risk-class note: payment-link issuance is `money_movement` (§6.1) — always approval-gated — so the feature lands inside the existing control, not around it. Payments vendors also have mature webhooks (§3.4), so settlement events are event-driven, not polled. 2. **E-commerce / POS.** Adds a selling channel (Shopify/Square-class), extending the ledger view to revenue as it happens. Primarily read-heavy (order/settlement awareness feeding cash-flow playbooks); write actions (refunds) are `money_movement`-gated. 3. **Payroll — via aggregator (§3.2.3).** Finch/Merge, not direct ADP/Rippling — the transport rule already decided this. Read-heavy (headcount, pay-date awareness for cash-flow forecasting); the highest-liability PII (§9.1 C5) is deliberately confined to one aggregator sub-processor. 4. **Social publishing — via aggregator (§3.2.3).** Ayrshare-class over one adversarial-review pipeline instead of four direct builds (Meta/LinkedIn/TikTok/X). Low risk class (posting), so it lands late — value-to-cost ratio, not capability, sets the order. Each new category is a set of connectors (§3.2) + playbooks (§5.1) + golden datasets (§11.1) + Appendix-A entries; the sandbox matrix (§3.6) and eval harness gate every one. No category ships without its evals — the §11 discipline is a release gate, not a nicety. #### 14.2 Accountant / bookkeeper collaboration surface The GTM channel (accountants touch 50–500 SMBs each) implies a product surface, not just a referral link: a **multi-tenant view for the professional** who manages many client books. Technical requirements, each mapping to existing architecture: * **Cross-tenant access with hard isolation.** The accountant sees N tenants, but tenant isolation (§8.3) must hold — access is per-tenant grants the *tenant* extends to the professional, recorded as configuration events (§7.1), not a superuser role. The professional is modeled as a delegate (§6.3) across multiple tenants, with per-tenant, per-class approval grants — reusing the delegation machinery, not inventing an admin tier. * **Aggregated audit view.** The professional needs cross-client oversight (which clients have overdue approvals, failing connectors); this is a query over per-tenant audit chains (§7.1) scoped to their granted tenants — the open-source verifier (§7.3) lets them validate integrity independently, which is itself a trust selling point to a professional staking their license on the books. * **No new trust boundary.** The accountant surface is delegation + scoped audit read, both already specified — deliberately so, because a bespoke "accountant admin" role would be a new privilege class to secure and a new isolation-failure surface. #### 14.3 Public API and third-party playbooks The tension: §5.1 forbids tenant-authored playbooks because golden-set correctness guarantees (§11.1) are only tractable over a closed, first-party task set — yet an ecosystem is a growth vector. Resolution path, staged so the §11 discipline is never abandoned: * **Read/observe API first.** Expose tenant-scoped, audited read access (business state, action history) so third parties build *reporting and analytics* on Fridays data without gaining action capability. Zero new action-safety surface; strictly additive. * **Curated playbook marketplace, not arbitrary code.** If third-party playbooks arrive, they enter as *reviewed, first-party-quality artifacts* subject to the same golden-dataset requirement (§11.1) and gateway allow-listing (§3.3) — a submission is a playbook spec that must pass the eval harness before any tenant can activate it, not free-form logic. This preserves the §5.1 closed-task-set property while widening the catalog: the set stays closed and evaluated, it just admits vetted external contributions. * **Action API — gated on the approval model generalizing.** Any programmatic action capability exposed externally routes through the same gateway, risk classification, and approval interception (§6) as internal actions — an external caller cannot obtain an un-approved, un-audited action path, because none exists (§2.1). This is the hard constraint that determines whether an action API ships at all: if it cannot be built without a gateway bypass, it is not built. The ordering principle restated: **the ecosystem expands the catalog and the read surface freely, and the *****action***** surface only through the existing approval-and-audit spine.** Growth that would require dismantling the §6/§7 controls is out of scope by the same logic that governs §1.3's non-goals. *** *No references — this section projects the architecture defined in §§2–13 forward; all mechanisms cited (gateway §2.1, transport rule §3.2, delegation §6.3, evals §11.1, isolation §8.3) are specified in their home sections.* *** *Next: Section 15 (Related Work).* *** ### As-Built Reconciliation — V1 *Legend/sources as in §1's addendum.* **Ordering principle ("reuse invariants, no gateway bypass") is sound but predicated on the single gateway existing — which is ASPIRATIONAL (§3.3).** Reconcile against backend's **actual** phased roadmap (MR §3): | Phase (MR §3) | Content | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Phase 0 — complete** | Marketing site + `backend` v0.3.1 (heartbeats, budgets, approvals, isolation, plugins, adapters). | | **Phase 1 — MVP** | **Gmail + QuickBooks** connectors, end-to-end approval loop with literal-action prompts, real backend behind fridays.bot, pre-revenue security hardening. | | **Phase 2 — completeness** | All four connector families, billing, mobile + multi-channel approvals, self-serve. | | **Phase 3 — scale/compliance** | SOC 2, managed Postgres/scale, GDPR program. | | § | Status | As-built (source) | | --------------------------------------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 14.1 Category sequencing (payments → e-comm → payroll → social) | **reconcile** | Paper says "payments next"; MR sequences **Gmail + QuickBooks first**, *then* four families, with Stripe/Shopify as **beta after** the four families stabilize. Align the two orderings. | | 14.2 Accountant / bookkeeper surface | **PLANNED** | Delegation + grant machinery EXISTS (SC §4, AO §7) — the surface reuses it. | | 14.3 Public API / third-party playbooks | **PARTIAL** | Backend is **already open-source (MIT)** with **plugin SDK 1.0.0** + adapter npm packages — a third-party **extension** surface EXISTS at the platform layer (MR §1.5). The **action API gated on the approval model generalizing** depends on the gateway (aspirational). | **Flag:** the roadmap is coherent, but its gating invariant (single gateway, "no un-approved action path exists") is aspirational — the honest version is *"…will exist once write paths are consolidated behind audited plugin tools."* Reconcile the paper's category order with MR's connector-first sequence. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://wiki.fridays.bot/documentation/white-paper/14.-roadmap.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.