The Design Registry

Product Vision & Platform Strategy

Version: 3.0
Prepared: August 2026
Status: Product vision and platform source of truth
Business source: The Design Registry Business Plan 4.0
Planning horizon: 2026–2030
Confidentiality: Private and confidential

1. Executive Summary

The Design Registry is a Designer-first technology company, private professional network and local studio platform for independent interior design businesses.

The product exists to solve a structural problem: residential design Projects are coordinated across disconnected people, businesses and systems. Designers manage clients, specifications, budgets, Vendors, procurement, trades, warehouses, delivery teams, installers, approvals, invoices and follow-ups through spreadsheets, email, messaging applications, shared drives and several specialized tools. Each participant recreates information, maintains a separate version of the truth and repeatedly asks the Designer for status.

The Design Registry connects this fragmented ecosystem around one durable Project record.

Client or opportunity
        ↓
Designer intake and matchmaking
        ↓
Designer Studio and Project
        ├── Client experience
        ├── Seven-Phase Project plan
        ├── Tasks, calendar and communication
        ├── Spaces, plans and documents
        ├── Construction materials
        ├── Decorating and FF&E items
        ├── Budgets and approvals
        ├── Provider matchmaking
        ├── Offers and Proposals
        ├── Work Orders and Change Orders
        ├── Procurement and purchase tracking
        ├── Receiving and storage
        ├── Delivery and installation
        ├── Invoices and payments
        └── Complete operational history

The Project is the operational centre. Pipelines create and qualify the relationships that may become part of a Project. Entities represent the people and organizations participating in the network. Workspaces give Designers, Providers and internal Registry teams the tools needed to operate. The Project connects them without exposing information they do not need.

The company will provide valuable core software free to qualifying Designer Studios and participating Providers. Designers may bring their own leads, clients, Projects and Providers while retaining their brand and relationships. Providers receive category-specific portals with enough operational value to quote, schedule, deliver, invoice and run their own business inside the system. Clients receive an elegant, Designer-branded experience for decisions, approvals, payments and relevant progress.

The platform supports the Business Plan's commercial strategy without making monetization the centre of the user experience. The Registry may earn revenue from Registry-generated design opportunities, Provider marketplace activity, procurement and products, optional premium software, managed services and studio-location programs. Core product value must remain real even when a participant does not use a monetized service.

AI operates as an assistance and operating-leverage layer. It accelerates migration, extracts product and commercial data, summarizes Projects, suggests next actions, supports matchmaking and identifies exceptions. Human judgment remains mandatory for consequential communications, Provider approval, work awards, commercial commitments, payments, suspension and sensitive matching decisions.

The long-term product vision is:

Give independent Designers the operating leverage of a larger firm while preserving the creativity, independence, brand and client relationships that make their studios valuable.

2. Purpose of This Document

2.1 Product vision, not an implementation PRD

This document defines what The Design Registry is becoming, why the product exists, how the major product surfaces fit together and which principles must remain true as the platform evolves.

It is the source of truth for:

• Product purpose and positioning
• Participant value propositions
• Platform architecture at the conceptual level
• Core records and relationships
• Shared module strategy
• Designer, Client, Provider and Registry experiences
• The seven-Phase Project operating model
• Provider-specific product direction
• Commercial workflow direction
• Matchmaking and AI direction
• Integration and data principles
• Product sequencing and success measures

It does not replace detailed specifications for database schema, APIs, permissions, individual screens, acceptance criteria or implementation tasks. Those documents must remain consistent with this vision.

2.2 Relationship to the Business Plan

The Business Plan defines the company strategy. This Product Vision translates that strategy into product commitments.

2.3 Product decision test

Every material product decision should answer:

1. Does this help a Designer run a better business or deliver a better Project?
2. Does it reduce duplicated coordination across participants?
3. Does it strengthen the Project as the trusted record?
4. Does it create meaningful value for the participant expected to update the data?
5. Can it be built once and configured across the platform?
6. Does it preserve user control, brand trust and appropriate privacy?
7. Can the resulting behaviour be measured?

3. Product Vision

3.1 Vision statement

The Design Registry is the shared operating network for independent interior design: one elegant platform where Designers run their studios, clients experience their Projects and specialized Providers deliver the physical work.

3.2 Future-state experience

In the intended future state:

• A Designer can create a workspace, brand it and import an active Project from a spreadsheet in one guided session.
• The system converts rooms, categories, items, budgets, dates and Providers into structured records without erasing the Designer's original source.
• The Designer sees the Project through seven meaningful stages rather than a generic task board.
• The client sees decisions, approvals, payments and milestones through a calm branded portal.
• A Provider sees only the work assigned or offered to them, through tools tailored to their service category.
• A warehouse can receive an expected item, photograph its condition, record its storage location and notify the Designer without composing a separate email.
• A delivery team can work from an approved manifest, publish limited day-of status and capture proof of delivery.
• An installer can see room placement, readiness, dependencies and punch items.
• A Vendor can answer a quote request using the same product record that becomes the purchase and shipment record.
• Proposals become Work Orders, accepted changes become Change Orders and completed work becomes an Invoice without re-entering scope.
• Matchmaking recommends Designers or Providers using relevant, explainable information while humans retain selection authority.
• The Registry's internal team sees exceptions requiring judgment instead of manually reading every record.
• All parties can determine what happened, what changed, who approved it and what happens next.

3.3 Product promise by participant

Designer: Your studio stays at the centre. The Registry organizes the work around you.

Provider: Receive clearer opportunities, run category-specific work and get paid with less duplicated administration.

Client: Experience a beautifully coordinated Project led by your Designer.

Registry operator: Govern a trusted network through structured applications, explainable matching, auditable decisions and exception-based operations.

3.4 The strategic wedge

The product does not initially need to replace every system. The wedge is:

Import one active Project, organize the items and Providers around it, and make the next external handoff measurably easier.

The first session must create value. A user should not be required to migrate every client, customize every field or configure every automation before the platform becomes useful.

4. Product Outcomes

4.1 Designer outcomes

• Less time searching for information and chasing status
• Faster conversion from lead to organized Project
• Fewer specification, purchasing and coordination errors
• Better control of budgets and decisions
• Clearer delegation across teammates
• More polished client experience
• Easier access to qualified Providers
• Ability to grow without proportional administrative hiring
• Greater confidence that the complete Project history is preserved

4.2 Provider outcomes

• More complete and appropriate opportunities
• Faster Proposal creation
• Less repeated data entry
• Clearer scope, items, locations and schedules
• Better operational evidence
• Greater payment visibility
• Stronger working relationships with Designers
• A category-relevant CRM and invoicing system for Registry and independent work

4.3 Client outcomes

• Clear next steps
• Fewer lost decisions
• Easier approvals
• Understandable financial status
• Relevant progress without operational noise
• Higher confidence in the Designer's coordination
• A premium experience consistent with the Designer's brand

4.4 Registry outcomes

• Measurable Designer and Provider activation
• Reliable lead attribution
• Better network quality and local coverage
• Higher match acceptance
• More completed multi-party workflows
• Marketplace activity with auditable commercial records
• Lower manual coordination per active Project
• A repeatable market-launch operating model

5. Product Principles

5.1 Designers first

The Designer is the primary operating customer and visible leader of the client Project. The product must enhance rather than obscure that role.

5.2 Projects are the operational centre

Relationships may begin in Pipelines, but delivery happens through Projects. The Project connects participants, spaces, items, work, money, decisions and history.

5.3 Build once, reuse everywhere

Tasks, Notes, Files, Activity, Communication, Forms, Data Grids, Offers, Proposals, Work Orders, Invoices, Notifications and History are shared modules. They should be configured by record type, workspace type and access—not independently rebuilt for every portal.

5.4 One record, appropriate views

Participants may see different representations of the same Project record. Separate views must not become separate truths.

5.5 The updater receives value

If the platform expects a warehouse, delivery company or Vendor to maintain status, that action must help them operate. Data collection without participant value will fail.

5.6 Calm over clutter

The interface should reveal the next meaningful action and allow depth when needed. It should not present every module, metric and automation simultaneously.

5.7 Structured where consequences matter

Commercial scope, item status, approvals, payments and evidence require structured records. Flexible Notes and Files supplement those records; they do not replace them.

5.8 Configuration before duplication

Provider differences should be expressed through modules, templates, terminology, statuses, evidence recipes and dashboards. Separate applications should be a last resort.

5.9 Human authority supported by AI

AI can suggest, extract, summarize and monitor. People approve, award, commit, pay, communicate consequential decisions and govern access.

5.10 Trust is a product feature

Access boundaries, provenance, approval history, evidence and explainable recommendations are core product capabilities.

5.11 Data portability

Designers and Providers must be able to import and export their legitimate business data. Retention should come from value, not captivity.

5.12 Progressive adoption

The platform must support partial adoption. A studio can begin with one Project, one spreadsheet and one Provider and expand naturally.

6. Platform Ecosystem

6.1 Participant types

The platform serves:

• Registry administrators and market operators
• Designer Studios
• Designer teammates
• Clients and client collaborators
• Vendors and product suppliers
• Millwork and custom fabricators
• Contractors and specialty trades
• Photographers
• Measurement and drafting Providers
• Receiving, warehouse and storage Providers
• White-glove delivery Providers
• Installation Providers
• General Service Providers
• Studio-location participants and guests

6.2 Platform layers

Experience layer
  Admin | Designer | Client | Provider | Studio location

Shared application layer
  CRM | Pipelines | Projects | Items | Budgets | Matchmaking
  Tasks | Calendar | Files | Communication | Commercial records

Workflow layer
  Automations | Notifications | Required fields | State transitions
  Approvals | Access grants | Evidence recipes | Exception handling

Intelligence layer
  Extraction | Summaries | Recommendations | Matching | Monitoring

Integration layer
  Resend | Twilio | Google Calendar | Google Sheets
  Stripe | QuickBooks | Vendor APIs | Website plugin

Data and trust layer
  Supabase | Authentication | Storage | Realtime | Audit | Security

6.3 Shared network, private businesses

The Design Registry is not one communal workspace. Each business operates in its own workspace. Shared Projects create controlled collaboration across businesses. A Provider does not gain broad access to a Designer's CRM. A Client does not see internal Notes, Provider comparisons or margins. A Designer does not automatically see a Provider's unrelated work.

6.4 Local market dimension

Workspaces, Providers, applications, service areas, leads, matches and studio locations must support market context. Ottawa is the intended first operating market; Toronto is a later replication market. The data model should not hard-code one city or assume all Providers serve the same geography.

7. Core Concepts

7.1 Workspace

A Workspace is the operating environment for one organization or Registry team. It owns branding, users, business settings, CRM records, templates and operational data.

Workspace types include:

• Registry administration
• Designer Studio
• Vendor or product supplier
• Millwork or custom fabrication
• Contractor or trade
• Photography
• Measurement and drafting
• Receiving, warehouse and storage
• White-glove delivery
• Installation
• General service

Clients receive controlled portal access and may later receive a lightweight Client workspace model if their needs extend beyond one Project.

7.2 User

A User is an authenticated person. A User may belong to more than one Workspace and may participate in Projects through membership or a Project-scoped access grant.

7.3 Entity

An Entity is a durable person or organization record that may exist before it receives a login.

Examples:

• Designer Studio
• Provider business
• Client household
• Contact
• Vendor
• Property or Project site

Entities may be passive records or Workspace Entities. Approval can provision an Entity into a Workspace without creating a duplicate organization.

7.4 Pipeline

A Pipeline is a configurable lifecycle for qualifying, reviewing or progressing a class of records. Each major Entity type receives its own Pipeline where lifecycle management is meaningful.

Examples:

• Project Opportunities
• Designer Applications
• Client intake
• Provider applications by category
• Designer relationship Pipeline
• Provider relationship Pipeline
• Project lifecycle Pipeline

Pipeline stages have names, colours, order, required transition data and automation. Pipelines qualify and create durable records; they are not the Project execution interface.

7.5 Pipeline Record

A Pipeline Record is one instance moving through a Pipeline. It has a current stage, owner, fields, activity, Notes, Files, Tasks, Communication, history and configurable modules.

7.6 Project

A Project is the durable operational container for design and delivery. It owns or links:

• Client relationship
• Designer Studio
• Project site
• Spaces and rooms
• Seven-Phase plan
• Team and collaborators
• Providers and access grants
• Tasks and calendar
• Plans, Files and Notes
• Materials, products and items
• Budgets and approvals
• Offers, Proposals and Work Orders
• Procurement and shipments
• Receiving, storage, delivery and installation
• Invoices, payments and financial history
• Communication and complete Activity

7.7 Assignment and access grant

An Assignment represents responsibility for work. An access grant defines the authorized Project information available to a participant. Assignment and access are related but not identical.

7.8 Item

An Item is a structured Project object representing a construction material, finish, fixture, furniture product, accessory, artwork or other selected object.

7.9 Work package

A Work Package is a Project-scoped snapshot of the information sent to a Provider for pricing or execution. It preserves what the Provider was asked to quote.

7.10 Offer, Proposal and Work Order

• Offer: Invitation to review or quote a Work Package.
• Proposal: Provider or Designer commercial response.
• Work Order: Authorized instruction to perform accepted work.
• Change Order: Authorized modification to an existing Work Order.
• Invoice: Request for payment associated with accepted commercial work.

8. One Project, Multiple Views

8.1 Principle

The Project has one underlying identity and shared history. Each participant sees a view appropriate to their role, organization, assignment and Project access.

Project
├── Designer view: full operational control
├── Client view: decisions, milestones, approved financials and selected content
├── Provider view: assigned scope, authorized items, dates and evidence
├── Registry view: network, commercial and exception context
├── Warehouse view: expected inventory, receiving, condition and release
├── Delivery view: manifest, route, access, status and proof
└── Installer view: readiness, placement, dependencies and punch work

8.2 Shared Project identity

Every view must reference the same Project identifier. Provider Work Orders, Client approvals and Registry attribution cannot exist as unrelated copies that require manual reconciliation.

8.3 Visibility layers

Project information is classified conceptually as:

• Workspace-private
• Internal Project team
• Shared with selected external participant
• Client-visible
• Registry-governed
• Commercially sensitive
• Restricted residential/security information

The detailed permissions matrix belongs in a separate specification. This Product Vision establishes that visibility is explicit, scoped and auditable.

8.4 Project summary

Each participant receives a summary answering:

• What is this Project?
• What stage is it in?
• What needs my attention?
• What changed?
• What is blocked?
• What am I allowed to do?
• What happens next?

9. Identity, Workspaces and Membership

9.1 Authentication

The intended authentication experience supports email and password, Google authentication, password reset, secure sessions and invitation acceptance. Pending Provider accounts may authenticate while access remains limited until approval.

9.2 Workspace provisioning

Workspaces may be created through:

• Direct Designer signup
• Approved Designer application
• Approved Provider application
• Registry administrative creation
• Future invitation or migration program

Provisioning creates the Workspace, owner membership, default navigation, profile, dashboard, templates, Pipeline relationships, notifications and onboarding checklist appropriate to the Workspace type.

9.3 Workspace owner

The owner can manage the Workspace profile, branding, teammates, role labels, templates, integrations and business settings available to that Workspace type.

9.4 Teammates and roles

Workspace owners invite teammates and assign customizable role labels. Role labels are customer-defined organizational language. Detailed permissions are intentionally governed by a separate permissions specification and future capability model.

9.5 Personal profile

Each User controls personal details, image, contact preferences, notification preferences, calendar connections and security settings, subject to organization requirements.

9.6 Multiple memberships

A User may operate in more than one Workspace without creating multiple identities. The interface must make the active Workspace clear and prevent cross-workspace data leakage.

10. Shared Authenticated Experience

10.1 Application shell

All authenticated experiences share:

• Brand-aware Workspace selector
• Workspace-appropriate navigation
• Global search
• Notifications
• Messages and Communication
• Tasks and calendar
• User menu
• Help and support
• Responsive layout

Navigation differs by Workspace type and later permissions, but uses the same shell and design system.

10.2 Dashboard framework

Dashboards are composed from shared modules:

• Attention queue
• Active work
• Upcoming dates
• Offers and approvals
• Commercial status
• Exceptions
• Recent activity
• Performance summaries
• Quick actions

Each Workspace type receives a default dashboard configuration that emphasizes its real operating work.

10.3 Global search

Search should locate authorized Projects, Clients, Providers, items, Work Orders, Invoices, Files and communications. Results must respect current Workspace and Project access.

10.4 Notifications

Notifications are delivered to the correct Workspace and User context. A User with multiple memberships must understand which business and Project generated the event.

11. Designer Studio Operating System

11.1 Designer dashboard

The Designer dashboard prioritizes:

• Projects requiring attention
• Upcoming client decisions
• Tasks due and overdue
• Budget risks
• Items with purchasing or delivery exceptions
• New Provider Offers or Proposals
• Registry-generated opportunities
• Client messages
• Upcoming appointments
• Installation readiness
• Invoices and payment status

11.2 Designer CRM

The Designer CRM supports self-generated and Registry-generated relationships:

• Leads and Project Opportunities
• Clients and households
• Contacts
• Properties and Project sites
• Providers and Vendors
• Referral sources
• Communication history
• Tasks and appointments
• Proposals and commercial history

11.3 Studio profile

The Studio profile includes:

• Brand and identity
• Team
• Portfolio and representative work
• Credentials and insurance where relevant
• Services
• Styles and specialties
• Project and budget fit
• Service area
• Languages
• Capacity and availability
• Matchmaking profile
• Registry participation
• Performance and history

11.4 Project builder

Designers can create reusable Project templates defining stages, milestones, Tasks, dependencies, required Files, item categories, budget categories, automation and recommended Provider packages.

Templates are starting structures. A live Project can be adapted without silently changing the source template or unrelated Projects.

11.5 Studio independence

The Designer can run Projects and use CRM tools without accepting Registry leads or matched Providers. The product should introduce Registry services at relevant moments without degrading independent use.

12. Client Experience

12.1 Design objective

The Client portal is not a reduced admin screen. It is a curated, calm and premium Project experience led by the Designer.

12.2 Client dashboard

The dashboard emphasizes:

• Welcome and Project summary
• Current stage
• Next milestone
• Decisions requiring attention
• Upcoming appointments
• Approved selections
• Proposals, agreements and Change Orders
• Invoices and payments
• Selected progress updates
• Messages with the Designer
• Shared Files and deliverables

12.3 Client approvals

Approvals are explicit records with:

• Subject and context
• Options or decision requested
• Relevant amount or schedule impact
• Supporting images and Files
• Deadline
• Approver
• Decision
• Timestamp
• Comments
• Revision relationship

12.4 Client financial view

The Client sees only authorized financial information, presented in understandable categories:

• Approved Project or phase budget
• Approved Proposals
• Deposits
• Invoices
• Payments
• Approved changes
• Remaining commitments where appropriate

Internal markups, Provider comparisons, Registry fees and private margin data remain hidden unless disclosure is legally or contractually required.

12.5 Client communication

Communication may include in-app messaging, email and SMS depending on consent and workflow. The portal maintains the Designer's voice and selected brand treatment.

12.6 Client access lifecycle

Client access is invited, verified, Project-scoped and revocable. Completed Projects remain available according to retention and agreement rules without exposing newly private internal activity.

13. Provider Operating System

13.1 Product promise

Providers must receive enough value to operate in the system willingly. The portal cannot function only as a compliance surface for Designers or the Registry.

13.2 Shared Provider capabilities

Every Provider Workspace receives:

• Provider-specific dashboard
• Business profile and matchmaking information
• Team
• CRM contacts and opportunities
• Offers and request-for-Proposal inbox
• Proposal templates
• Work Orders
• Tasks and calendar
• Communication
• Files and evidence
• Invoices and payment visibility
• Notifications
• Reporting
• Project-scoped access
• Tools for independent, non-Registry business where appropriate

13.3 Offers

All Provider types receive Offers. An Offer allows the Provider to:

• Review permitted Project and scope information
• Accept the invitation to quote
• Decline with structured reason
• Request clarification
• Identify capacity or schedule constraints
• Convert the accepted invitation into a Proposal

13.4 Proposal to Work Order

The Proposal preserves the Provider's commercial response to a specific Work Package snapshot. Acceptance produces a Work Order. Changes after acceptance occur through revisions or Change Orders, not silent edits.

13.5 Provider CRM and invoicing

Providers can use the CRM, Proposal, Work Order and Invoice tools for their own business relationships. The Registry should not limit Provider value to work originating in the marketplace.

13.6 Provider profile

The profile includes common and category-specific fields:

• Legal and operating identity
• Brand
• Contacts and team
• Locations
• Service areas
• Categories and capabilities
• Capacity and availability
• Commercial preferences
• Insurance and credentials
• Portfolio and representative work
• Matchmaking information
• Operating readiness
• Performance history

14. Provider-Specific Portal Vision

14.1 Vendors and Product Suppliers

Primary modules: Product catalogue, pricing, variants, samples, quote requests, purchase orders, acknowledgements, availability, expected ship dates, backorders, returns and credits.

Dashboard: New quote requests, orders requiring acknowledgement, discontinued or delayed items, sample requests, upcoming shipments, returns and open Invoices.

Product vision: Product information should flow from approved Vendor sources into Project Items without repeated transcription. Vendor APIs may synchronize catalogue, trade pricing, availability and order status. Source and data freshness remain visible.

14.2 Millwork and Custom Fabrication

Primary modules: Scope packages, site measures, drawing sets, material approvals, revisions, deposits, fabrication milestones, delivery and deficiencies.

Dashboard: Offers awaiting response, measurements to schedule, drawings awaiting approval, deposits outstanding, active fabrication milestones and deficiencies.

Product vision: The approved drawing revision, materials, scope and payment condition must be clear before fabrication begins.

14.3 Contractors and Specialty Trades

Primary modules: Scope, locations, labour and materials, allowances, exclusions, schedule, prerequisites, daily updates, inspections, deficiencies and completion evidence.

Dashboard: Quote requests, work starting soon, blocked site conditions, outstanding changes, inspections and unpaid Invoices.

Product vision: Trades receive discrete, complete scopes and can document change before additional work proceeds.

14.4 Photography

Primary modules: Creative brief, property access, shot list, styling, schedule, rights, deliverables, selections and licensing.

Dashboard: New briefs, shoots awaiting confirmation, upcoming shoots, missing releases, deliverables due and selections awaiting completion.

Product vision: Creative intent and usage rights remain attached to the resulting assets.

14.5 Measurement and Drafting

Primary modules: Measurement scope, access, floor levels, output standard, site visit, source files, drawing revisions and approval.

Dashboard: Site visits to schedule, draft sets due, comments requiring revision and approved files awaiting delivery.

Product vision: Floor plans and measurement deliverables become authoritative Project references with a controlled revision history.

14.6 Receiving, Warehouse and Storage

Primary modules: Expected shipments, receiving appointments, item identification, package quantity, condition, photographs, storage locations, chain of custody, storage billing, release authorization and outbound manifests.

Dashboard: Arrivals expected today, unidentified packages, damaged items, items awaiting location, overdue releases, upcoming outbound loads and storage exceptions.

Product vision: A warehouse employee can receive an expected item quickly on a mobile device, document its condition and location and immediately create the right exception without writing a separate email.

14.7 White-Glove Delivery

Primary modules: Delivery requests, manifests, pickup, crew and vehicle, routes, access constraints, appointment windows, live day-of status, proof of delivery, damage and client sign-off.

Dashboard: Offers, jobs awaiting scheduling, tomorrow's routes, loads not ready, active deliveries, exceptions and proof awaiting completion.

Product vision: The Designer knows where the delivery is during the authorized service window without receiving constant calls or exposing continuous employee tracking.

14.8 Installation Services

Primary modules: Install plans, room placement, readiness, assembly, hardware, crew, checklists, deficiencies, punch work and sign-off.

Dashboard: Upcoming installations, readiness failures, items missing from manifest, active punch items and completion awaiting sign-off.

Product vision: Installation begins from a verified readiness state and ends with room-level completion evidence.

14.9 General Service Providers

General Service Providers receive a configurable portal assembled from shared modules. Administrators choose schedule, item, location, milestone, evidence, inspection, sign-off and Invoice requirements. Repeated categories should graduate into canonical Provider types.

15. Project Operating Model

15.1 The seven canonical stages

Every Project follows a recognizable operating process:

1. Concept
2. Design
3. Design Package
4. Construction Administration
5. Decorating
6. Procurement
7. Installation

These stages provide a shared mental model. They are not decorative tabs. Each stage organizes relevant milestones, Tasks, Files, approvals, Items, budgets, Provider work and exceptions.

15.2 Project Phase configuration

Project templates define the standard stages and their content. Administrators and authorized Workspace owners can configure stage names or optional sub-stages where appropriate while preserving the canonical model needed for cross-Project reporting.

15.3 Automatic stage progression

Projects may move automatically when objective completion conditions are satisfied. Examples:

• Concept completes after brief and scope approval.
• Design completes after required room concepts and decisions.
• Design Package completes after deliverables are issued and approved.
• Construction Administration completes after defined construction milestones and deficiencies.
• Procurement progresses when approved items have ordering status.
• Installation completes when required items and punch Tasks are resolved.

Automatic movement must be explainable, previewable and reversible by authorized users. The system must not hide incomplete work simply to advance a status.

15.4 Stage workspace

Each stage view includes:

• Purpose and completion definition
• Stage owner
• Milestones
• Tasks and dependencies
• Upcoming dates
• Required Files
• Relevant spaces
• Relevant Items and categories
• Budget status
• Provider packages
• Approvals
• Exceptions
• Activity

15.5 Concept

Concept establishes Project intent and feasibility.

Typical content:

• Client brief
• Goals and constraints
• Scope boundaries
• Project type
• Budget range
• Property information
• Site photographs
• Existing plans
• Style direction
• Inspiration
• Early services needed
• Preliminary schedule
• Decision-makers
• Concept approval

15.6 Design

Design develops the Project solution.

Typical content:

• Spaces and room requirements
• Plans and layouts
• Design concepts
• Material and product research
• Preliminary selections
• Client presentations
• Design decisions
• Budget iterations
• Consultation with Providers
• Revisions and approvals

15.7 Design Package

Design Package turns approved intent into coordinated information others can price, build or supply.

Typical content:

• Issued drawings
• Finish schedules
• Material schedules
• Product specifications
• Elevations and details
• Room packages
• Scope packages
• Revision history
• Approval state
• Issue date and recipients
• Required professional or permit information

15.8 Construction Administration

Construction Administration coordinates materials, site work, decisions, inspections and changes.

Typical content:

• Construction schedule
• Contractor and trade Work Orders
• Construction materials
• Submittals and samples
• Requests for information
• Site meeting Notes
• Site photographs
• Inspections
• Change Orders
• Deficiencies
• Allowances and budget changes
• Client-impacting decisions

15.9 Decorating

Decorating develops FF&E, styling and room-based shopping lists.

Typical content:

• Room concepts
• Furniture and lighting
• Rugs, art and accessories
• Window treatments
• Shopping lists
• Presentation packages
• Client selections
• Alternatives
• Budget categories
• Product-source links

15.10 Procurement

Procurement converts approved Items into purchases and tracks them through fulfilment.

Typical content:

• Quote requests
• Approved pricing
• Purchase Orders
• Vendor acknowledgements
• Deposits and balances
• Lead times
• Expected ship dates
• Shipment and tracking
• Backorders
• Returns and credits
• Receiving destination
• Warehouse status

15.11 Installation

Installation coordinates the final movement and placement of Items.

Typical content:

• Item readiness
• Storage release
• Delivery manifests
• Site readiness
• Room placement
• Crew and schedule
• Live delivery state
• Assembly
• Damage and deficiencies
• Punch list
• Client sign-off
• Completion photography

15.12 Parallel work

Phases provide primary organization but do not imply that all Projects are strictly sequential. Decorating may begin during construction. Long-lead Procurement may begin before the Design Package is completely issued. The system supports parallel Phase activity while maintaining one Primary Project Phase for communication and reporting.

16. Project Profile and Information Architecture

16.1 Project profile objective

The Project profile must feel beautiful, useful and complete. It is the place a Designer opens to understand the whole Project, not merely a form containing fields.

16.2 Header

The Project header includes:

• Project name
• Client
• Project site
• Current stage
• Priority and health
• Designer Studio
• Project owner
• Key dates
• Primary actions
• Project identifier
• Source and attribution where relevant

16.3 Overview

The Overview is configurable from shared cards:

• Project information
• Client contact
• Project snapshot
• Budget summary
• Stage progress
• Upcoming milestones
• Decisions required
• Provider assignments
• Item exceptions
• Vision and inspiration
• Recent Notes
• Activity timeline
• Next Tasks
• Recent Files

16.4 Spaces and rooms

Spaces provide a hierarchy for plans, requirements, Items, budgets, Tasks and installation placement.

Space records include:

• Name and type
• Floor or level
• Dimensions and area
• Plans and images
• Design brief
• Occupants and functional needs
• Materials and Items
• Budget
• Stage status
• Decisions and Notes

16.5 Floor plans

Projects store floor plans as versioned, authoritative Files linked to floors, spaces and issue status. Future visual pinning may connect a plan location to an Item, Task, deficiency, measurement or installation instruction.

16.6 Project vision and inspiration

The vision module supports narrative, inspiration images, reference links, AI-assisted writing and Designer-controlled client visibility. It remains reusable across opportunity and live Project experiences.

16.7 Project tabs

The full Project may include:

• Overview
• Process
• Spaces
• Items and Materials
• Budgets
• Calendar
• Tasks
• Providers
• Commercial
• Procurement
• Receiving and Storage
• Delivery and Installation
• Communication
• Notes
• Files
• Activity
• History

Tabs appear when relevant to Project type, stage, Workspace and access. The interface should not show empty modules merely because they exist.

17. Tasks, Milestones and Calendar

17.1 Shared Task model

Tasks are reusable across Pipelines, Entities, Projects, Work Orders and internal operations.

A Task includes:

• Title and description
• Type
• State
• Priority
• Owner
• Collaborators
• Due date and time
• Start date where needed
• Milestone relationship
• Dependency
• Record link
• Checklist
• Attachments
• Comments
• Completion evidence
• History

17.2 Task ownership

A Task has one accountable owner and may have collaborators. Cross-Workspace Tasks are created only when the receiving participant has appropriate Project access.

17.3 Milestones

Milestones represent meaningful Project outcomes rather than individual actions. They may contain Tasks, dependencies, required approvals, required Files and completion rules.

17.4 Calendar

The calendar combines:

• Project milestones
• Tasks with dates
• Meetings
• Site visits
• Client presentations
• Measurements
• Deliveries
• Installations
• Provider appointments
• Payment due dates

Views include personal, Workspace, Project and Provider-job calendars.

17.5 Google Calendar synchronization

Users choose which events synchronize. The Registry owns Project context and Google Calendar remains the user's external scheduling system. Changes must be reconciled safely without duplicate events.

17.6 Automated Task creation

Templates, Pipeline transitions, approvals, commercial records and exceptions may create Tasks. Automation identifies its source, owner and due-date logic.

18. Items, Materials and Specifications

18.1 Unified Item foundation

Construction materials and decorating Items share a common technical foundation while retaining different fields, categories, statuses and views.

18.2 Construction Items

Construction Items include:

• Flooring
• Tile and stone
• Plumbing fixtures
• Appliances
• Hardware
• Lighting
• Paint and wall finishes
• Millwork materials
• Doors and windows
• Specialty construction products

Construction-specific fields may include specification, installation location, coverage, quantity unit, installer, required date, submittal, sample, technical document, warranty and construction status.

18.3 Decorating and FF&E Items

Decorating Items include:

• Furniture
• Decorative lighting
• Rugs
• Window treatments
• Art
• Accessories
• Bedding and textiles
• Plants and styling objects

Decorating-specific fields may include Vendor, product URL, image, variant, finish, dimensions, quantity, room, client selection, trade price, client price, lead time and presentation status.

18.4 Common Item fields

• Project and space
• Category and subcategory
• Name and description
• Manufacturer and Vendor
• Product number or SKU
• Image and source URL
• Quantity and unit
• Cost, markup and selling price
• Tax, freight and installation assumptions
• Budget category
• Approval state
• Procurement state
• Expected and actual dates
• Condition
• Storage location
• Delivery and installation status
• Files and Notes
• History

18.5 Item status model

Status is multi-dimensional. One generic status cannot accurately represent approval, purchasing, logistics and condition.

The Item may have:

• Selection state
• Approval state
• Pricing state
• Procurement state
• Vendor order state
• Shipment state
• Receiving state
• Condition state
• Storage state
• Delivery state
• Installation state
• Financial state

The user interface presents a useful summary while preserving the underlying dimensions.

18.6 AI-assisted item creation

Designers can paste a product URL or upload a Proposal, quote, invoice, order acknowledgement or purchase order. AI proposes structured fields and cites the source. The user confirms commercial and specification data before it becomes approved.

18.7 Spreadsheet import

Spreadsheet import is a primary adoption path. The workflow supports:

1. Upload or connect a sheet.
2. Detect headers and data types.
3. Map columns to standard and custom fields.
4. Normalize categories and statuses.
5. Identify duplicates and incomplete rows.
6. Preview changes.
7. Import with source lineage.
8. Produce a reconciliation report.

18.8 Enterprise data grid

Item lists use the shared enterprise grid with:

• Search
• Sort
• Filter
• Group
• Saved views
• Column chooser
• Inline editing where safe
• Bulk update
• Selection actions
• Import and export
• Row detail
• Validation
• Role-aware field visibility
• Currency and date formatting
• Sticky identifiers
• Pagination or virtualization

19. Budgets and Financial Planning

19.1 Integrated budget philosophy

Budgets are not a separate spreadsheet beside the Items. Budget categories aggregate the Items and commercial commitments that create the budget.

19.2 Budget hierarchy

Project budget
├── Stage or phase
├── Space or room
├── Category
│   ├── Planned allowance
│   ├── Selected Items
│   ├── Approved commitments
│   ├── Invoiced amounts
│   └── Paid amounts
└── Contingency

19.3 Financial states

The system distinguishes:

• Planned
• Estimated
• Quoted
• Client-approved
• Committed
• Ordered
• Invoiced
• Paid
• Refunded or credited

19.4 Budget views

Users can view budget by:

• Project
• Stage
• Room
• Construction category
• Decorating category
• Provider
• Vendor
• Approval state
• Commitment state

19.5 Pricing and margin

Cost, markup, client price and Registry-related commercial amounts are separate fields with controlled visibility. Currency values use appropriate symbols, grouping separators and precision.

19.6 Budget changes

Approved changes update forecasts and commitments while preserving the prior approved baseline. The user can distinguish design evolution from commercial Change Orders.

19.7 Spreadsheet familiarity

The grid and import/export experience should feel familiar to Designers who trust spreadsheets while providing stronger structure, relationships and auditability.

20. Procurement and Product Operations

20.1 Procurement lifecycle

Proposed Item
  → selected
  → priced
  → client approved
  → ready to order
  → ordered
  → acknowledged
  → in production/backordered
  → shipped
  → received
  → stored/released
  → delivered
  → installed
  → complete or exception

20.2 Shopping lists

Designers build shopping lists by room, category, presentation, purchase phase or client decision. Lists include images, links, prices, alternatives, approval and budget impact.

20.3 Quote and purchasing records

The system distinguishes Vendor quote, Client Proposal, Purchase Order, Vendor acknowledgement, shipment, receipt, return and credit. Files may supplement but do not replace structured state.

20.4 Proper Goods Club and other Vendors

Proper Goods Club may participate as a Vendor and commerce integration, but the platform is Vendor-neutral. Designers can work with other furniture and material suppliers. Approved Vendor integrations bring products into the same Item and procurement model.

20.5 Purchase Order creation

Purchase Orders can be created from approved Items, grouped by Vendor and receiving destination. They preserve pricing, terms, quantities, source Items, Project and approvals.

20.6 Order changes

Quantity, variant, address or price changes after order require a documented revision and reconciliation with the Vendor acknowledgement.

20.7 Returns, credits and claims

Returns and damage claims connect the affected Item, evidence, responsible party, financial credit and replacement status.

21. Receiving, Storage, Delivery and Installation

21.1 Connected logistics chain

The platform treats physical custody as a connected chain rather than unrelated status notes.

Vendor shipment
  → carrier tracking
  → receiving appointment
  → warehouse receipt
  → condition evidence
  → storage location
  → release authorization
  → outbound manifest
  → delivery
  → room placement
  → installation
  → deficiency or completion

21.2 Expected inventory

The receiving Provider sees expected Items before they arrive, including identifiers, quantities, Vendor, Purchase Order, carrier, tracking and special handling.

21.3 Condition and damage

Condition is recorded at receiving, release, delivery and installation when appropriate. Evidence includes photographs, notes, packaging state, quantity and severity. Damage triggers notifications and a governed exception workflow.

21.4 Storage location

Locations may include facility, zone, aisle, rack, bay, shelf, pallet or other Provider-defined hierarchy. Location history supports chain of custody.

21.5 Release authorization

Items leave storage only through an authorized release linked to a manifest, destination and responsible delivery Provider.

21.6 Day-of delivery visibility

Designers receive scheduled, confirmed, en route, arrived, delayed, delivered and exception states. Live location is time-limited, consent-aware and visible only to authorized participants.

21.7 Installation readiness

Readiness considers:

• Required Items received and released
• Delivery scheduled
• Site access confirmed
• Construction complete where required
• Utilities or mounting conditions ready
• Labour and tools confirmed
• Drawings and placement instructions approved
• Client or Designer attendance requirements

21.8 Punch and deficiency

Incomplete placement, damage, missing hardware, adjustment or follow-up becomes a structured punch Item with owner, evidence, due date and resolution.

22. Commercial Workflow

22.1 Commercial chain

Project need
  → Work Package
  → Offer
  → Proposal
  → acceptance
  → Work Order
  → Change Order when needed
  → completion evidence
  → Invoice
  → payment
  → reconciliation

22.2 Work Package

The Designer selects authorized Project information, Items, spaces, Files, dates and requirements. The system validates completeness and creates a snapshot.

22.3 Offer

An Offer invites a selected Provider to review or quote. It tracks recipient, delivery, response, expiry, questions and outcome.

22.4 Proposal

Proposals support templates, branding, line Items, milestones, taxes, terms, exclusions, attachments, revision, acceptance and electronic evidence. Designer Proposals to clients and Provider Proposals to Designers share a core engine with different templates and context.

22.5 Acceptance

Acceptance records the exact version, authorized person, timestamp, terms and any required deposit. A Proposal is not accepted merely because a stage changed.

22.6 Work Order

The Work Order becomes the operational contract record for the assigned Provider. It contains accepted scope, Items, schedule, milestones, evidence recipe, financial terms, changes and completion.

22.7 Change Order

Changes include reason, original reference, scope difference, schedule impact, financial impact, attachments, approval and resulting Work Order state.

22.8 Invoice

Invoices may be created from deposits, milestones, approved changes or completion. They support taxes, payment instructions, Stripe where configured, manual payment recording and QuickBooks synchronization.

22.9 Global navigation

Designer and Provider Workspaces receive global tables for Proposals, Work Orders and Invoices. Provider users see only records belonging to their Workspace and assignments. Project views present the same records in context.

22.10 Auditability

Every commercial record has durable numbering, revision history, access history and linked Activity. Deletion is restricted; correction uses reversal, void, credit or superseding revision as appropriate.

23. Pipelines and Lifecycle Management

23.1 Pipeline Builder

Administrators configure:

• Pipeline name and record type
• Stages and colours
• Stage order
• Closed and terminal states
• Required fields for transition
• Transition permissions in the future permissions model
• Stage-level forms
• Automation
• Notifications
• Task templates
• Service levels
• Conversion outcomes

23.2 Transition validation

When a user moves a record, the system evaluates required data and explains what is missing. Users can open a transition form containing only the fields needed to proceed.

23.3 Automation

Pipeline automation supports:

• In-app message
• Email
• SMS
• Calling Task or calling workflow
• Task creation
• Owner assignment
• Notification
• Field update
• Record creation
• Workspace provisioning
• Project conversion
• Webhook or integration event

23.4 Entity Pipelines

Each approved Entity type may have its own ongoing relationship Pipeline after application approval. Application review and active relationship management are separate lifecycles.

23.5 Project Pipeline

Projects can appear in a portfolio Pipeline for reporting and automatic state progression, while detailed execution remains in the seven-Phase Project experience.

23.6 Client Pipeline

Client lifecycle may include inquiry, qualified, consultation, active Project, repeat opportunity and inactive. A Client can have multiple Projects without duplicating the Client Entity.

24. Applications, Approval and Provisioning

24.1 Website-integrated application

Designer and Provider applications begin from The Design Registry website. The form reflects the selected participant or Provider category and creates an authenticated pending account where appropriate.

24.2 Dynamic application forms

Administrators configure sections, fields, guidance, conditions, uploads, validation, matchmaking questions and consent. Common identity fields are reused; category-specific questions extend the form.

24.3 Provider categories

Canonical categories:

1. Vendors and Product Suppliers
2. Millwork and Custom Fabrication
3. Contractors and Specialty Trades
4. Photography
5. Measurement and Drafting
6. Receiving, Warehouse and Storage
7. White-Glove Delivery
8. Installation Services
9. General Service Providers

24.4 Application record experience

The first tab is the configurable application workflow. Shared tabs include Overview, Activity, Notes, Files, Tasks, Communication, Matchmaking, History and any category-relevant review modules.

24.5 Approval

Approval creates or activates the Provider Entity, profile, Workspace, owner membership, category navigation, default templates, notifications and onboarding checklist.

24.6 Pending access

A pending applicant can authenticate to complete the application, upload evidence and respond to requests but cannot access active marketplace work until approved.

24.7 Rejection and reapplication

Rejection reasons, communication, retention, appeal and future reapplication rules are recorded and governed.

25. Matchmaking

25.1 Strategic role

Matchmaking is a core network capability, not a decorative score. It helps clients find suitable Designers and Designers find suitable Providers.

25.2 Client-to-Designer factors

• Geography and service area
• Project type
• Budget
• Style
• Services required
• Timeline
• Language
• Property type
• Rooms
• Desired working relationship
• Capacity and availability
• Conflict or prior relationship
• Designer preferences
• Verified performance where appropriate

25.3 Project-to-Provider factors

• Provider category and qualification
• Service area
• Scope and capability
• Item or material characteristics
• Required dates
• Capacity
• Commercial compatibility
• Insurance or credential requirements
• Project-type experience
• Designer preference
• Prior working relationship
• Response and completion history

25.4 Match profiles

Client, Designer and Provider forms capture relevant structured matchmaking information. Questions are category-specific, configurable and reusable between website application, profile and opportunity workflows.

25.5 Human-governed selection

AI and rules create ranked recommendations with explanations, missing data and conflicts. Authorized people decide who receives an introduction or Offer.

25.6 No hidden paid placement

Providers cannot secretly purchase a better match ranking. Sponsored visibility, if ever introduced, is visibly separated and cannot override eligibility.

25.7 Feedback loop

Match outcomes update future recommendations through response, acceptance, scope fit, schedule performance, completion, exception and satisfaction signals. Feedback is contextual and reviewable.

26. Registry-Generated Leads

26.1 Product experience

Registry-generated leads enter through website, studio location, referral or campaign. Intake captures budget, location, scope, timing, style and service needs.

26.2 Qualification

Automated validation checks completeness, geography, budget, duplicates and obvious abuse. A Registry operator reviews the summarized lead before matchmaking.

26.3 Curated introduction

The client is not broadcast to a large directory. The Registry creates a governed shortlist and coordinates a curated introduction or consultation path.

26.4 Attribution

Source, qualification, selected Designer, agreement, fee obligation, collected amounts and attribution period remain linked to the resulting Client and Project.

26.5 Commercial assumption

The Business Plan's current assumption is a 20% Registry share of the collected design service fee on Registry-originated opportunities. This is a planning assumption requiring contractual, legal and market validation. It is not hard-coded as an irreversible product rule.

26.6 Designer control

Designers choose whether an opportunity is suitable. The product does not pressure a Designer to accept poor-fit work or penalize reasonable declines.

27. Shared Modules

27.1 Overview cards

Overview cards are configurable, shared presentations of structured records. Cards may be added, hidden or specialized by record type without copying the underlying feature.

27.2 Activity

Activity is an immutable or correction-governed timeline of meaningful events:

• Record changes
• Communications
• Tasks
• Notes
• Files
• Meetings
• Approvals
• Stage transitions
• Commercial events
• Integration events
• AI-assisted actions

27.3 Notes

Internal Notes retain author and timestamp. Editing preserves history. Deletion is restricted according to policy. Mentions and attachments use shared components.

27.4 Files

Files support upload, preview, metadata, source, version, categories, search, access, export and record links. Plans and commercial documents may receive specialized treatment while remaining in the shared File service.

27.5 Communication

Communication unifies relevant in-app, email, SMS and calling records around the participant and Project context. Private internal communication remains distinct from external threads.

27.6 History

History provides complete field and state changes with actor, time, prior value, new value and source.

27.7 Comments and mentions

Contextual comments may attach to an Item, File revision, approval, Proposal or Task. Mentions respect access; a mention cannot grant unauthorized visibility.

27.8 Export and reporting

Shared grids support export according to authorization and data classification. Exports are logged where the data is sensitive.

28. Forms and Data Quality

28.1 Shared form system

All forms use a shared field registry, validation system and design language. The application form, Project edit form, transition form and Provider profile may arrange fields differently but should not create inconsistent versions of the same concept.

28.2 Standard field types

• Short and long text
• Email
• Phone
• Address lookup
• Country, province/state and city
• Currency
• Number and percentage
• Date and date-time
• Time and timezone
• Single and multi-select
• Checkbox and yes/no
• User, Workspace and Entity reference
• Project, space, Item and Provider reference
• File and image upload
• URL
• Rich description
• Repeating group
• Calculated field
• Signature or acceptance

28.3 Standard interaction rules

• Dropdown options are alphabetically sorted unless meaningful sequence requires otherwise.
• Currency displays symbols, grouping separators and consistent precision.
• Percentages distinguish stored value and displayed percentage.
• Dates use the shared date picker and clear timezone behaviour.
• Phone and address fields normalize data while preserving human-readable display.
• Required fields show when and why they are required.
• Validation is specific and appears near the field.
• Forms preserve unsaved work where practical.

28.4 Field registry

Standard fields have durable identifiers, definitions, data type, validation, formatting and allowed use. Custom fields extend records without redefining standard concepts.

28.5 Conditional forms

Sections and fields can respond to category, answer, stage, Project type, country or Workspace type. Conditions must be understandable and testable in the builder.

28.6 Data completeness

Completeness is context-specific. Matchmaking, transition and operational-readiness modules calculate completion based on fields relevant to that action rather than one universal profile score.

28.7 Duplicate prevention

Creation and import detect possible duplicate contacts, Clients, Providers, products and Projects. Users can link, merge or intentionally create separate records with an explanation.

29. Automation and Notifications

29.1 Automation model

Automation is defined as trigger, conditions, actions, timing, audience, owner, retry and audit.

Triggers include:

• Record created or updated
• Pipeline stage entered or exited
• Field changed
• Required date approaching
• Approval completed or overdue
• Offer delivered or unanswered
• Proposal accepted
• Work Order milestone reached
• Item state changed
• Damage recorded
• Payment succeeded or failed
• Integration event received
• Scheduled time

29.2 Actions

• Create Task
• Assign owner
• Send in-app message
• Send email
• Send SMS
• Create calling Task
• Update field
• Move Pipeline stage
• Create record
• Generate document
• Request approval
• Notify Workspace or User
• Call integration or webhook
• Provision Workspace
• Escalate exception

29.3 Notification Builder

Every workflow event that may require a User or Workspace notification is registered as an editable template.

Templates include:

• Event and purpose
• Recipient logic
• Channel
• Subject and body
• Variables
• Conditions
• Timing and reminders
• Sender identity
• Workspace branding
• Fallback
• Preview and test
• Enabled state
• Version history

Examples:

• You received an Offer
• Provider requested clarification
• Proposal awaiting approval
• Work Order changed
• Item received damaged
• Delivery is en route
• Client decision overdue
• Invoice paid
• Application approved

29.4 Protected meaning

Administrators may customize wording, but critical operational events retain required meaning and variables. A template cannot remove legally or operationally necessary information.

29.5 User preferences

Users control optional channel and digest preferences. Critical security, payment and safety events follow mandatory delivery rules.

29.6 Automation safety

Automations show their source and latest execution. Consequential actions support preview, testing, rate limits, idempotency, failure handling and audit.

30. AI Product Vision

30.1 Role of AI

AI should make the product feel more prepared, not more complicated. It converts unstructured information into reviewed structure, brings relevant context forward and helps the network operate by exception.

30.2 AI for migration

• Detect spreadsheet structure
• Suggest column mappings
• Normalize categories
• Identify duplicates
• Extract Projects, Clients, Items and budgets
• Flag uncertain rows
• Produce reconciliation report

30.3 AI for Items and procurement

• Extract product data from URLs
• Parse Vendor quotes
• Parse Purchase Orders and acknowledgements
• Suggest categories and spaces
• Compare approved and acknowledged order details
• Identify missing pricing, lead time or variant
• Summarize delays and exceptions

30.4 AI for Designers

• Summarize Project state
• Draft follow-ups
• Suggest next actions
• Build first-pass Tasks from a template
• Prepare client presentation text
• Improve Project vision language
• Summarize meeting Notes
• Identify budget and schedule risk
• Find relevant prior decisions

30.5 AI for Providers

• Summarize Work Package
• Extract scope and milestones
• Draft Proposal structure
• Identify missing information
• Suggest route or schedule considerations
• Summarize outstanding evidence
• Prepare completion summary

30.6 AI for clients

• Guided intake
• Plain-language Project summaries
• Decision summaries
• Explanation of options using approved Project information
• Preparation for upcoming appointments

AI must not provide unreviewed professional, legal, safety or financial advice.

30.7 AI for Registry operations

• Application summaries
• Qualification support
• Match recommendations and explanations
• Capacity and coverage monitoring
• Lead routing support
• Exception detection
• Complaint and evidence summaries
• Transaction reconciliation assistance
• Market-health monitoring

30.8 AI operating manager

The AI operating manager creates an exception queue rather than autonomously running the company. It identifies:

• Leads outside service level
• Applications missing evidence
• Provider insurance nearing expiry
• Shortlists without suitable capacity
• Unopened Offers
• Overdue Proposals
• Late Work Order milestones
• Expected Items not received
• Damage without resolution
• Delivery scheduled without readiness
• Overdue Invoices
• Integration and notification failures

30.9 Provenance

Every extraction preserves source, timestamp, proposed value, confidence, correction and approved value. Users can determine whether data came from a person, import, integration, automation or AI.

30.10 Human authority

AI does not independently:

• Approve or reject an applicant
• Select a winning Provider
• Send a consequential client message
• Accept a Proposal
• Create a binding Work Order
• Approve a Change Order
• Move money
• Suspend an account
• Make an undisclosed ranking decision

30.11 Evaluation

Each AI feature defines accuracy, correction rate, cost, latency, privacy, escalation and rollback requirements before production release.

31. Integrations

31.1 Integration principle

The Registry is the operational source of truth for connected Project workflows while specialist systems remain authoritative for their domain. Integration ownership must be explicit.

31.2 Resend

Supports transactional email, delivery state, bounce handling and template execution. The Registry owns notification meaning and audit.

31.3 Twilio

Supports SMS and calling workflows. The Registry records consent, communication metadata and linked context.

31.4 Google Calendar

Supports event synchronization for appointments, site visits, deliveries and installations. The Registry owns Project context; users control connection and sync direction.

31.5 Google Sheets

Supports migration, controlled export, selected collaboration and reporting. Confirmed Registry records do not remain dependent on a live sheet unless an explicit synchronization workflow exists.

31.6 Stripe

Supports client payments, Provider payments and marketplace settlement where the approved funds-flow architecture permits. Payment execution is not confused with the Registry's commercial obligation record.

31.7 QuickBooks Online

Supports Customers, Vendors, Invoices, payments, taxes and account mapping. QuickBooks remains the accounting ledger; the Registry preserves the operational relationship between Project, Work Order and Invoice.

31.8 Vendor APIs

Approved Vendor APIs may provide product, pricing, availability, sample, order and shipment data. The system displays source and freshness and does not imply live availability when the source is stale.

31.9 Website plugin

Designers can embed a branded or white-label lead form on their own websites. It creates qualified opportunities in their Workspace and can capture information required for later matching or Project creation.

31.10 Failure design

Every integration exposes:

• Connection state
• Last successful sync
• Error and user impact
• Retry state
• Manual fallback
• Duplicate protection
• Audit event
• Credential revocation

32. Design System and Experience Standards

32.1 Brand character

The Design Registry is black and white, elegant, clean, simple and confident. Rounded corners, generous spacing, restrained typography and intentional hierarchy create a premium feeling without decorative excess.

32.2 Product character

The interface should feel:

• Calm
• Precise
• Editorial
• Trustworthy
• Modern
• Warm enough for client use
• Serious enough for commercial work
• Efficient enough for warehouse and field operations

32.3 Shared components

The design system includes standardized:

• Application shell
• Navigation
• Buttons and actions
• Tabs
• Cards
• Status pills
• Data grids
• Forms
• Dropdowns
• Address lookup
• Currency and number fields
• Date and time pickers
• Search
• Filters
• Empty states
• Modals and drawers
• File upload
• Activity timeline
• Notes composer
• Communication composer
• Approval panel
• Mobile operational controls

32.4 Responsive design

Designer and Registry administration may be desktop-dominant, but Provider operations and client approvals must work exceptionally well on mobile. Receiving, delivery, installation, photography and site workflows cannot be treated as shrunken desktop pages.

32.5 Accessibility

The product supports keyboard navigation, readable contrast, focus visibility, semantic structure, accessible labels, scalable text and meaningful alternatives for status conveyed by colour.

32.6 Empty states

Empty states explain the purpose, expected next action and whether the module is unavailable, optional or simply empty. They should not create false impressions that planned functionality already exists.

32.7 Error states

Errors identify what failed, whether data was saved, what the user can do and whether support or retry is required.

32.8 Progressive disclosure

Overview pages show the most important information. Advanced fields, history and configuration remain available without overwhelming ordinary work.

33. Branding and Workspace Personalization

33.1 Brand hierarchy

• Designer's client experience: Designer brand is primary; Registry identification is appropriate and discreet.
• Registry-generated opportunity: Registry context is visible.
• Provider portal: Provider brand is primary in its own Workspace; Project collaboration identifies the Designer and Registry context.
• Internal Registry experience: Registry brand is primary.

33.2 Workspace branding

Workspace owners configure:

• Business name
• Logo
• Brand image
• Approved colours within accessibility safeguards
• Client greeting
• Email sender presentation
• Proposal and Invoice templates
• Terms and service descriptions
• Communication templates
• Optional custom domain or subdomain in future premium packaging

33.3 Controlled customization

Personalization does not create a separate design system. Layout, behaviour, accessibility and core interaction remain consistent.

33.4 “Powered by” treatment

The product may support reduced Registry treatment for premium workspaces where commercially appropriate, but provenance, legal identity and payment disclosures cannot be removed.

34. Trust, Privacy and Access

34.1 Trust model

The platform holds residential addresses, floor plans, budgets, commercial pricing, schedules, access instructions, live delivery state, Files and communications. Trust must be designed at every layer.

34.2 Least privilege

Users see only the Workspaces, Projects, records and fields required for their authorized work.

34.3 Project-scoped external access

Providers receive access through specific Offers, Work Orders or Project grants. Access can be time-bound, scope-bound and revoked without deleting the commercial history.

34.4 Client visibility

Client-facing content is intentionally published or approved for visibility. Internal Notes, comparisons, margins, match discussions and operational commentary are private by default.

34.5 Residential security

Access instructions, alarm details, live location, family information and unredacted floor plans require enhanced controls, minimal retention and careful notification content.

34.6 Audit

Sensitive access, exports, commercial approvals, payment events and permission-relevant actions produce audit records.

34.7 Permissions boundary

Detailed roles, capabilities, field-level controls and administration belong in the separate Permissions specification. This vision requires the underlying product architecture to support them without hard-coded role assumptions.

34.8 Data portability and retention

Participants can export legitimate records subject to privacy, commercial and contractual boundaries. Retention, deletion, legal hold and completed-Project access are governed explicitly.

35. Data and Platform Architecture Direction

35.1 Production foundation

Supabase is the intended production foundation for PostgreSQL, authentication, storage and Realtime capabilities.

35.2 Multi-tenant model

Core requirements:

• Durable Workspace identity
• User membership across Workspaces
• Row-level security
• Project-scoped external access
• Entity deduplication
• Environment separation
• Audit history
• File access policies
• Backup and restore
• Event-driven automation

35.3 Canonical data model

The frontend shell does not define the production data model. Shared modules use durable record identities and relationship tables rather than page-specific local structures.

35.4 Event model

Meaningful domain events drive Activity, notifications, automation, integrations and AI monitoring.

Examples:

• ApplicationSubmitted
• ProviderApproved
• PipelineStageChanged
• ProjectCreated
• ClientApprovalRequested
• OfferSent
• ProposalAccepted
• WorkOrderIssued
• ItemOrdered
• ItemReceived
• DamageReported
• DeliveryEnRoute
• InvoicePaid

35.5 Files and documents

Files are stored once and linked to authorized records. Generated commercial documents preserve source data and version.

35.6 Search and reporting

Search and reporting operate against authorized normalized data. Operational reporting distinguishes event time, effective date, currency, timezone and market.

35.7 API direction

APIs support the same business concepts used by the application. External integration does not bypass validation, audit or access policies.

36. Current Product Foundation and Gap

36.1 Existing shell value

The current authenticated platform demonstrates important reusable patterns:

• Admin shell
• Overview
• Pipelines
• Project Opportunities
• Designer Applications
• Matchmaking
• Projects
• Designer Studio profiles
• Clients
• Assignments
• Tasks
• Notes
• Files
• Activity
• Communication concepts
• Settings
• Teammates and teams
• Project Builder
• Pipeline Builder
• Notifications

36.2 Existing design patterns

The Project Opportunity record establishes a reusable record experience with:

• Header and actions
• Overview cards
• Activity timeline
• Internal Notes
• Files grid
• Tasks grid and creation form
• Communication tab
• Matchmaking results
• Proposals and History concepts
• Edit forms
• Project vision and inspiration

These patterns should become shared components rather than remain tied to one lead type.

36.3 Current limitations

The current product should not be represented as production-complete. Known gaps include:

• Legacy Proper Gallery language and taxonomy
• Incomplete production backend migration
• Incomplete Project operations
• Provider applications and category Workspaces
• Provider operational portals
• Offers, Proposals, Work Orders and Invoices
• Payment architecture
• QuickBooks synchronization
• Receiving and storage operations
• Delivery tracking
• Installation workflows
• Website plugin
• Complete notification delivery
• Mature permissions
• Production-grade AI and monitoring

36.4 Reverse-PRD discipline

Existing screens should be documented through screenshots, behaviour, fields, states and shared-component identification before replacement. Visual reuse does not mean preserving accidental data structures.

37. Product Roadmap

37.1 Phase 0 — Rebrand and production foundation

• Replace Proper Gallery terminology
• Adopt canonical Provider categories
• Confirm Supabase architecture
• Stabilize authentication and Workspaces
• Establish shared field, event and notification registries
• Connect website signup and applications

Outcome: Correct identity and safe production foundation.

37.2 Phase 1 — Users, teams and Designer activation

• Teammates and membership
• Workspace and User profiles
• Designer dashboard
• Designer CRM
• Projects and templates
• Seven-Phase Project process
• Spreadsheet import
• Client portal foundation
• Tasks, Files, Notes, Calendar and Activity

Outcome: Designers manage real Projects repeatedly.

37.3 Phase 2 — Provider applications and provisioning

• Dynamic category applications
• Review Pipelines
• Approval and Workspace creation
• Provider profiles
• Category dashboards
• Matchmaking fields
• Provider CRM foundation

Outcome: Qualified Providers activate correct Workspaces.

37.4 Phase 3 — Offers and commercial records

• Work Packages
• Offers
• Proposal templates
• Acceptance
• Work Orders
• Change Orders
• Invoices
• Global and Project views

Outcome: Project need becomes authorized external work without re-entry.

37.5 Phase 4 — Items, budgets and procurement

• Construction and decorating Items
• Enterprise grid
• Spreadsheet import
• Integrated budget
• Shopping lists
• Product URL and document extraction
• Purchase Orders
• Vendor acknowledgements and status

Outcome: Designers can leave core Item and budget spreadsheets for active work.

37.6 Phase 5 — Provider operational depth

• Receiving and condition
• Warehouse locations
• Storage release
• Delivery manifests and day-of state
• Installation readiness and punch
• Millwork revisions
• Photography and drafting deliverables

Outcome: Providers maintain the trusted operational record.

37.7 Phase 6 — Payments and integrations

• Stripe
• QuickBooks
• Resend
• Twilio
• Google Calendar
• Google Sheets
• Vendor APIs
• Reconciliation and exception handling

Outcome: Commercial and communication workflows operate reliably across systems.

37.8 Phase 7 — Matchmaking, leads and local markets

• Client-to-Designer matching
• Project-to-Provider matching
• Website lead plugin
• Registry attribution
• Market dashboards
• Studio-location support
• Human governance

Outcome: The network generates and routes suitable work.

37.9 Phase 8 — Intelligence and scale

• AI extraction
• Exception monitoring
• Match explanations
• Advanced reporting
• Market launch playbook
• Premium capabilities
• Expanded integrations

Outcome: The company can operate additional markets without proportional administration.

38. Product Success Measures

38.1 North-star measure

Monthly Coordinated Project Value: Active Project value for which at least two participant types completed a meaningful platform workflow during the month.

The measure captures real multi-party work. It must be paired with contribution margin and quality.

38.2 Designer activation

• Time to first Project
• Time to first imported Item list
• Time to first client invitation
• Time to first Provider invitation
• Percentage activating in 7, 14 and 30 days
• Weekly active Designers by cohort
• Active Projects per Designer

38.3 Provider activation

• Application completion
• Time to decision
• Time from approval to profile readiness
• Time to first Offer response
• Time to first accepted Work Order
• Status updates completed without Registry chasing
• Provider reuse across Projects

38.4 Client experience

• Invitation acceptance
• Approval completion
• Decision response time
• Payment completion
• Message response
• Client satisfaction
• Missed or disputed decision rate

38.5 Project coordination

• Participant types per Project
• External workflows completed
• Overdue milestones
• Item status completeness
• Budget variance
• Damage and claim rate
• Delivery exception rate
• Installation punch closure

38.6 Commercial

• Offers sent and responded
• Proposal acceptance
• Work Order completion
• Invoice accuracy
• Payment time
• Marketplace leakage
• Revenue and contribution by stream

38.7 AI

• Extraction accuracy
• Correction rate
• Time saved
• Recommendation acceptance
• False exception rate
• Cost per assisted workflow
• Harmful-error incidents

39. Adoption and Change Strategy

39.1 Import before configuration

Onboarding begins with a real Project or spreadsheet, not a long settings exercise.

39.2 Concierge migration

The founding cohort receives guided import and normalization. The service reveals product requirements and produces templates.

39.3 Provider invitations

Designers can invite existing Providers. The invitation explains direct value to the Provider and allows a lightweight start before full profile completion where risk permits.

39.4 In-context education

Education appears where the action occurs through examples, templates, previews and checklists. A separate knowledge base supports deeper learning.

39.5 Progressive feature release

Users see mature modules relevant to their workflow. Planned placeholders are clearly labeled and do not undermine trust.

39.6 Feedback

Feedback is attached to participant, Workspace, Project Phase and workflow so the team can distinguish general requests from recurring operational friction.

40. Product Risks and Mitigations

40.1 Excessive scope

Risk: The platform attempts to replace every system before proving a core workflow.

Mitigation: Phase gates, shared modules, canonical Provider priorities and real-Project activation.

40.2 Portal adoption

Risk: Providers view the portal as extra administration.

Mitigation: Category-specific operational value, mobile workflows, CRM for independent work and reduced duplicate entry.

40.3 Designer trust

Risk: Designers fear loss of brand, client or Vendor relationships.

Mitigation: Designer-first brand hierarchy, data portability, optional marketplace and explicit access.

40.4 Spreadsheet resistance

Risk: Item and budget workflows feel slower than existing sheets.

Mitigation: Strong grid, import/export, inline editing, saved views and AI-assisted entry.

40.5 Data fragmentation inside the new platform

Risk: Separate portals create duplicate records.

Mitigation: One Project identity, shared modules, access grants and canonical events.

40.6 Commercial and payment complexity

Risk: Marketplace funds flow creates errors, cost or compliance exposure.

Mitigation: Separate obligation and execution records, staged Stripe adoption, bank/manual options and reconciliation.

40.7 Automation harm

Risk: Incorrect automation sends messages, changes status or creates commitments.

Mitigation: Preview, scope, human confirmation, idempotency, audit and rollback.

40.8 Privacy

Risk: Residential or commercial information reaches the wrong participant.

Mitigation: Least privilege, Project-scoped access, field classification, safe notifications and audit.

40.9 AI error

Risk: Extracted price, dimension or commercial data is incorrect.

Mitigation: Source grounding, confidence, review, approved values and quality evaluation.

40.10 Local network imbalance

Risk: Matchmaking recommends Providers without capacity or adequate local coverage.

Mitigation: Capacity, service area, market health and human governance.

41. Non-Goals

The initial product is not intended to be:

• An open public directory where payment buys ranking
• A replacement for professional legal, engineering or code advice
• A full accounting ledger replacing QuickBooks
• A general construction ERP for every contractor type
• A consumer social network
• A continuous employee-location tracking system
• An autonomous AI Project manager with authority to commit or pay
• A mandatory procurement channel
• A system that owns the Designer's self-generated clients
• A separate custom application for every Provider category
• A design tool replacing professional CAD, rendering or modelling software

42. Future Horizons

Potential future directions after core validation:

• Custom domains and advanced branding
• Multi-location and multi-entity Workspaces
• Vendor product network and live catalogues
• Sample library and studio inventory
• Mobile receiving, delivery and install applications
• Advanced floor-plan pinning
• Client home records spanning multiple Projects
• Designer benchmarking
• Provider capacity forecasting
• Warranty and post-install service
• Trade account and discount management
• Expanded payment and financing options
• Marketplace insurance or protection programs
• Cross-market Provider networks
• Educational and certification programs
• AI-assisted operational forecasting

Future features must strengthen the Designer-first operating network rather than distract from it.

43. Product Vision Milestones

The vision is becoming real when:

1. Designers import active Projects and return weekly.
2. Item and budget data is maintained in the platform instead of recreated beside it.
3. Clients complete decisions and payments through the branded portal.
4. Providers accept Offers and update operational work without repeated chasing.
5. Proposals, Work Orders, Invoices and payments reconcile correctly.
6. Receiving, storage, delivery and installation share one Item history.
7. Matchmaking produces suitable, accepted relationships with explanations.
8. Registry-generated leads convert with durable attribution and trust.
9. AI reduces time and exceptions without taking unauthorized action.
10. A second market can launch from the platform and operating playbook without rebuilding the product.

44. Final Product Position

The Design Registry should not be described as another project-management application, mood-board tool or lead directory.

It is:

• The operating system for the independent Designer's business
• The shared operational layer for the physical Project
• The client experience through which decisions remain clear
• The private network through which trusted Providers are discovered and engaged
• The category-specific operating system through which Providers quote and deliver work
• The commercial chain connecting scope, authorization, evidence, Invoice and payment
• The local market infrastructure that creates trusted density
• The AI-supported operating layer that helps small businesses behave like larger, well-resourced firms

The defining product idea is:

Existing tools help one Designer manage information. The Design Registry coordinates the independent people and businesses required to complete the Project.

Appendix A — Canonical Provider Categories

1. Vendors and Product Suppliers
2. Millwork and Custom Fabrication
3. Contractors and Specialty Trades
4. Photography
5. Measurement and Drafting
6. Receiving, Warehouse and Storage
7. White-Glove Delivery
8. Installation Services
9. General Service Providers

Appendix B — Seven Project Phases

1. Concept
2. Design
3. Design Package
4. Construction Administration
5. Decorating
6. Procurement
7. Installation

Appendix C — Shared Modules

• Overview cards
• Activity
• Notes
• Files
• Tasks
• Calendar
• Communication
• Forms
• Enterprise data grids
• History
• Offers
• Proposals
• Work Orders
• Change Orders
• Invoices
• Payments
• Notifications
• Automations
• Search
• Reporting

Appendix D — Intended Technology Direction

• Supabase: production database, authentication, storage and Realtime foundation
• Resend: transactional email
• Twilio: SMS and calling
• Google Calendar: schedule synchronization
• Google Sheets: migration, import/export and controlled collaboration
• Stripe: payments and marketplace settlement
• QuickBooks Online: accounting synchronization
• Approved Vendor APIs: product, price, availability and order status
• AI services: extraction, summarization, recommendations and exception monitoring with human governance

Appendix E — Product Documents Governed by This Vision

• Users, Teams and Workspace Memberships
• Authenticated Workspace Dashboard and Profiles
• Provider Applications, Approval and Provisioning
• Proposals, Work Orders and Invoicing
• Projects, Items, Budgets and Provider Operations
• Pipeline Engine and Entity Architecture
• Permissions and Access Control
• Notifications and Automation
• Matchmaking
• Integrations and Production Backend
• Design System Handoff