Plant Roster Templates

Status: Intake Product: Platform — Plant Catalog Administration Created: 2026-03-25

---

Problem

Landscape professionals working across multiple clients and properties repeatedly select the same sets of plants. There is no way to pre-curate a plant palette and carry it forward into designs. Every new project starts from the full 2,500+ plant catalog, which slows down workflow and introduces inconsistency.

Concept

Introduce Plant Rosters — curated, reusable lists of plants that can be created, templated, and applied at the business, client, or property level.

Core Mechanics

1. Templates: Businesses maintain a library of roster templates (e.g., "Desert Southwest," "Coastal Mediterranean," "Low-Water Native"). A template is a pre-built plant list that can be applied to any client or property as a starting point.

2. Client / Property Rosters: When a template is applied to a client or property, it becomes that entity's active plant roster. The roster can then be modified freely — plants added, removed, or swapped — without affecting the source template.

3. Design Integration: The active roster for a given client/property pre-populates the plant selection in both the Visual Designer and the Site Planner, giving quick access to the curated palette instead of browsing the full catalog.

4. AI Context: The active roster feeds into the AI Platform as context for that client/property. When a professional chats with AI about a property, the AI knows which plants are in play and can make recommendations within (or adjacent to) the roster.

5. AI-Assisted Roster Creation: Rosters can be assembled through AI conversation — describe the client's preferences, share a photo of an existing landscape, discuss climate and soil conditions, and the AI proposes a plant list. The professional reviews and commits it as a roster.

Key Principles

• Templates are the starting point, not a constraint. Any roster derived from a template is fully editable.
• Multiple templates per business. A company can maintain as many templates as they want for different styles, regions, or use cases.
• Roster flows downstream. Once set, the roster influences plant selection UI and AI context automatically — no extra configuration.
• AI is one of many creation paths. Rosters can be built manually, from templates, from AI conversation, from photo analysis, or any combination.

Cross-Product Touchpoints

| Product | Integration | |---------|-------------| | Visual Designer | Pre-populate plant picker with roster plants | | Site Planner | Pre-populate plant list for material takeoffs | | AI Platform | Roster as conversation context; AI-assisted roster building | | Platform (Plant Catalog) | Template CRUD; roster assignment to clients/properties | | CRM | Client/property association for rosters |

Open Questions

• Should rosters version over time (snapshot per project), or is the current state always the active one?
• How do rosters interact with the existing plant "collections" and "recommendations" in the catalog?
• What is the minimum template structure — just a list of plant IDs, or does it include quantities, notes, or groupings?
• Should templates be shareable across businesses (marketplace potential)?

Reconciliation Note: Overlapping Plant-List Systems (2026-07-09)

Dated note — 2026-07-09 (Dan). This intake-stage concept now overlaps two newer plant-list mechanisms and needs a placement ruling before it advances.

Since this brief was written (2026-03-25), the platform has grown two other ways to represent a curated plant list:

1. AI Template plant palettes (ai_template_plant) — every AI Design Template carries a curated plant palette, live on Hasura dev with 20 templates seeded 2026-06-15. See the AI Design Templates data model (spec §5) and its brief. These are admin-curated generation inputs, not user working palettes — but they are, structurally, another plant-list system.
2. Partner / instance plant-list scoping (candidate, 2026-07-09) — the new scoping direction attaches plant lists to whitelabel instances (shipped instance_plant_collection precedent) and to partners (builder/HOA sponsored pre-approved plant lists), scoped by geography/HOA. See Template & Plant-List Scoping in the AI Design Templates brief and spec §14.

Together with the pre-existing plant_collection system (already raised in Open Questions above), that is three or four coexisting plant-list shapes if this idea proceeds as drafted.

Recommendation: decide deliberately between —

• (a) A single plant-list system — one canonical plant-list entity that template palettes, business/client/property rosters, and partner/instance scoped lists all reference (one list model, many attachment points); or
• (b) An explicit split — with documented boundaries: rosters = workspace-owned working palettes (this idea); template palettes = admin-curated generation inputs (ai_template_plant); partner / instance lists = scoped compliance palettes.

Flagged for CEO placement ruling: should this idea stay a standalone Platform / Plant Catalog concept, merge into the AI Design Templates scoping work, or become the unifying plant-list system both consume? Do not advance this brief past intake until ruled.

Version History

| Date & Time (MT) | Author | Summary | |-------------------------|--------|---------| | 2026-03-25 (intake) | Intake | Initial intake concept (predates the Version History convention; time not recorded). | | 2026-07-09 06:30 PM MT | Dan | Added the dated reconciliation note: overlap with ai_template_plant template palettes and the new (2026-07-09, candidate) partner/instance plant-list scoping; recommended a single plant-list system or an explicit split; flagged for CEO placement ruling. Cross-linked the AI Design Templates brief + spec §14 (bidirectional). |