The Design Registry

Provider Applications, Entity Pipelines, Approval & Workspace Provisioning

Document: 05 - Provider Applications, Approval & Workspace Provisioning
Version: 2.1
Prepared: August 2026
Status: Active implementation — almost complete
Primary principle: Every Provider Category has its own application pipeline; every approved application creates or qualifies one durable Provider Entity.

1. Executive Summary

This specification defines how Designers, Providers and future entity types apply to The Design Registry, how Registry administrators configure and review those applications, and how an approved application becomes a trusted entity, authenticated Workspace, matching profile and Project-ready operating account.

The platform must support a distinct application pipeline for every Provider category. A storage facility cannot be evaluated with the same questions, evidence, stages and verification work as a photographer, millworker or white-glove delivery company. At the same time, the product must not create nine separate application systems. All application pipelines use the existing shared Pipeline Engine, Dynamic Form Builder, record tabs, tasks, files, communications, activity, automations, outcomes, enterprise data grid and Notifications Builder.

The current Designer Applications builder establishes the interaction model that must be reused. Each Provider Application pipeline is configured in Settings through the same builder sections:

1. Overview
2. Stages & next steps
3. Forms
4. Record details
5. Views
6. Automations
7. Outcomes
8. Access
9. Version history

When a Provider application is opened, its first tab is Workflow. That tab is generated from the published application-pipeline version and shows the current stage, available next steps, required fields, review checklist, owners, blockers, service-level target and automation history. The other tabs reuse the existing application and Project Opportunity record framework.

Approval is not merely a pipeline status. Approval runs an idempotent provisioning process that resolves or creates the Provider entity, records the approved Provider category qualification, provisions the Workspace and owner membership, seeds the category-specific dashboard and profile, creates matchmaking and operational-readiness records, and registers every required notification and audit event.

Applications create or qualify entities. Entities receive Workspaces. Projects connect approved entities through Offers, Work Orders and controlled access.

2. Objectives and Non-Goals

2.1 Objectives

• Give every Provider category a purpose-built application and review workflow.
• Let Registry administrators edit stages, colours, transitions, forms, required fields, review criteria, automations, outcomes and provisioning without code.
• Preserve fixed system-state mappings for reporting, security and provisioning.
• Reuse the current Designer Application builder and record experience.
• Integrate public website signup, authentication, save-and-return and pending-account access.
• Prevent duplicate entities when a Provider applies twice or adds a category.
• Create a complete Provider Workspace only after the correct approval outcome.
• Capture category-specific matchmaking attributes during application.
• Keep application approval, verification, Workspace activation, match eligibility and operational readiness as separate states.
• Register all application events in the Notifications Builder.

2.2 Non-goals

• Final permissions-builder design
• Full Provider dashboard and category operations
• Complete Project matchmaking algorithm
• Offer, Proposal, Work Order and invoicing state machines
• Legal determination of qualification or insurance adequacy
• Automated approval solely by AI

3. Core Concepts

3.1 Application Pipeline Definition

A versioned configuration describing how one entity/application type moves from draft through review to a terminal outcome.

3.2 Application Record

One applicant’s submitted or in-progress instance of a published Application Pipeline version. It contains normalized answers, files, participants, workflow state, tasks, reviews, verification, communications, activity and outcome.

3.3 Provider Entity

The durable organization record representing a Provider business. The Provider entity survives application completion, Workspace changes, category additions and future re-verification.

3.4 Category Qualification

The Provider entity’s approval and verification state for one Provider category. A Provider may hold more than one category qualification without creating duplicate entities or Workspaces.

3.5 Workspace

The authenticated operating environment belonging to the approved entity. It contains users, teams, Workspace Profile, category dashboards, CRM, Projects/Jobs, Offers, commercial records and integrations.

3.6 System State and Display Stage

• System state is a fixed platform meaning used for analytics, security, automations and provisioning.
• Display stage is an administrator-configurable stage shown to users.

Multiple display stages may map to one system state. System-state identifiers cannot be renamed or deleted.

3.7 Pipeline Outcome

A terminal or branching result such as Approved, Conditionally Approved, Declined, Withdrawn, Duplicate/Merged or Referred to another category. An outcome can trigger provisioning or other controlled actions.

4. Canonical Entity and Provider Taxonomy

4.1 Initial application entities

The Application Builder supports:

• Designer Studio Applications
• Provider Applications by category
• Future Client/organization applications where required
• Future Registry partner or market-operator applications

Project Opportunities remain a pipeline record type but are not Provider applications.

4.2 Canonical Provider categories

Every category receives its own default application pipeline:

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

These replace legacy placeholders such as Proper Goods Club, Contracting, Storage and White-glove Delivery. Canonical category IDs remain stable even if display names change.

4.3 Required default pipelines

pipeline-designer-applications
pipeline-provider-vendor-applications
pipeline-provider-millwork-applications
pipeline-provider-trade-applications
pipeline-provider-photography-applications
pipeline-provider-measurement-drafting-applications
pipeline-provider-storage-applications
pipeline-provider-white-glove-applications
pipeline-provider-installation-applications
pipeline-provider-general-service-applications

Each has its own ID prefix, form versions, stages, review requirements, automations, outcomes and provisioning configuration.

4.4 Multi-category Providers

An existing Provider applying for a second category starts an Additional Category Application attached to the existing entity. Approval creates a new category qualification and category capabilities inside the existing Workspace. It must not create a duplicate Provider or owner account.

4.5 Provider directory and Category visibility

The approved Providers directory must expose the complete canonical Category registry even when no Provider has yet been provisioned. A Category selector containing only All is incomplete and must not ship.

The directory must show:

• all nine Provider Categories with active, pending-readiness and action-required counts;
• zero-count Categories as intentional empty states rather than hiding them;
• Provider Entity, Provider ID, qualified Categories, primary market, Service Areas, Network Status, capacity, readiness, credential actions, Teammates and last activity;
• filters for Category, market, Network Status, capacity, readiness and credential state;
• a clear distinction between an approved Provider Entity and an in-review Provider Application;
• links to the canonical Provider Profile and the relevant Category Qualification view.

Display labels may be customized, but the stable Category ID and canonical glossary term Provider Category must be preserved. Provider type is a legacy label and must not be introduced in new interfaces, APIs or analytics.

4.6 Shared Provider Profile and Category Qualifications

Every approved Provider has one shared Provider Profile, regardless of how many Categories it qualifies for. The Profile is the canonical Entity Profile and contains identity, contacts, locations, Service Areas, Workspace ownership, Teammates, Network Status, Relationship Owner, capacity, Profile Completeness, shared Matching Profile data, Credentials and operational records.

Each Category Qualification extends that shared Profile with category-specific capabilities, matching criteria, Credentials, readiness rules and operational modules. The Profile must visibly list every applicable Category and its status, readiness, verification evidence, expiry, capabilities and category-specific work. Adding a second Category extends the existing Entity and Workspace; it never creates a duplicate Provider.

Registry-only Notes, risk decisions, comparisons and internal scoring remain hidden from Provider Workspace users.

4.7 Administrative Access Sessions

The current shorthand action Log in to workspace must be implemented as Start Administrative Access Session. It is a protected support operation, not ordinary impersonation. The administrator selects a purpose, sees the target Workspace and scope, enters a time-limited session with a persistent banner, and generates immutable start/end audit events. Sensitive actions may require step-up authentication or remain unavailable. The system never exposes another user’s password, token or authentication factors.

5. Application Types

Application type selects the correct workflow variant, outcome and provisioning actions while reusing the category definition.

6. Settings Information Architecture

6.1 Recommended Settings navigation

Settings
├── Teammates
├── Teams
├── Role Labels
├── Project Builder
├── Pipeline Builder
│   ├── Project Opportunities
│   ├── Clients
│   └── Projects
├── Applications
│   ├── Application Pipelines
│   ├── Provider Categories
│   ├── Shared Field Library
│   ├── Review Standards
│   └── Provisioning Defaults
├── Notifications
└── Data Reconciliation

The Applications area is not a second workflow engine. It is a focused directory and configuration surface powered by the same Pipeline Builder components. This prevents the general Pipeline Builder directory from becoming unmanageable while keeping one technical architecture.

6.2 Application Pipelines directory

The directory groups pipelines by entity type and Provider category. Each card displays:

• Pipeline name and category
• Draft/published/archived status
• Published version
• Number of stages
• Form field count
• Configured next steps
• Successful outcome/entity created
• Last published date and author
• Active record count
• Review or configuration warnings

Actions:

• Open builder
• Create draft
• Duplicate as starting point
• Compare versions
• Archive when no active dependencies exist
• Preview applicant experience
• Preview reviewer Workflow tab

6.3 Pipeline creation

Administrators can create a Provider Application pipeline by:

1. Selecting a canonical Provider category.
2. Choosing the Registry default template or duplicating a compatible pipeline.
3. Confirming pipeline name, ID prefix and application type.
4. Configuring forms, stages, reviews, automations and outcome.
5. Running validation.
6. Publishing version 1.

A category may have multiple workflow variants, but one default public application pipeline per market/application type is active at a time.

7. Application Pipeline Builder

7.1 Builder header

The header matches the current Designer Applications builder:

• Back to Application Pipelines
• Publication status and version
• Pipeline name and description
• Create new draft
• Publish changes
• Validation summary
• Preview applicant
• Preview reviewer

Published versions are immutable. Changes happen in a draft cloned from the latest version.

7.2 Builder section: Overview

Fields:

• Workflow name
• Short ID prefix
• Workflow type, fixed after first publication
• Entity type
• Provider category
• Application type
• Description
• Default market scope
• Applicant-facing name and description
• Internal owner Team
• Default SLA
• Default language
• Active website entry point

Workflow type for applications is intake_and_qualification.

7.3 Builder section: Stages & next steps

Administrators can:

• Add, rename and reorder display stages
• Choose a stage colour from the approved semantic palette
• Map each display stage to a fixed system state
• Set stage description and applicant-facing label
• Set stage ownership and SLA
• Define allowed next steps
• Define required fields, documents, tasks, review checks and approvals for each transition
• Configure manual override capability and reason requirement
• Configure applicant visibility
• Configure stage-entry and stage-exit automations

Stage definition fields

name
internal_key
display_order
colour_token
system_state_key
description
applicant_label
applicant_description
visibility
default_owner_rule
sla_duration
is_terminal

Transition definition fields

from_stage_id
to_stage_id
action_label
confirmation_message
required_field_keys
required_document_types
required_task_states
required_review_checks
required_approval_rule
condition_expression
override_policy
automation_set_id

Transitions are validated and enforced server-side. Front-end hidden buttons are not enforcement.

7.4 Builder section: Forms

Forms are assembled from shared field components and category-specific sections. The builder supports:

• Applicant form
• Action Required/correction form
• Internal review form
• Verification form
• Interview/site-review form
• Conditional approval requirements
• Onboarding handoff form

Administrators can add sections, fields, help text, conditional logic, validation, required rules and applicant/internal visibility. Every form is versioned.

7.5 Builder section: Record details

Controls the application record’s Overview tab and summary header:

• Record title formula
• Subtitle and secondary identifiers
• Status chip
• Summary metadata
• Information cards and field groups
• Profile completeness card
• Review/verification snapshot
• Matching snapshot
• Provisioning status
• Quick actions

This is configuration over shared record-detail components.

7.6 Builder section: Views

Defines default and saved table views:

• All active
• Newly submitted
• My review queue
• Action required
• Verification
• Decision pending
• Approved awaiting provisioning
• Declined/withdrawn
• SLA at risk
• Duplicate review

View configuration includes filters, sort, columns, grouping, audience and default ownership.

7.7 Builder section: Automations

Automations use trigger → conditions → actions.

Triggers

• Application started
• Form section completed
• Application submitted
• Stage entered/exited
• Field or document changed
• Task completed/overdue
• Review check passed/failed
• SLA threshold reached
• Outcome selected
• Provisioning step completed/failed
• Credential approaching expiry

Actions

• Create/assign task
• Notify in-app
• Send email through Resend
• Send SMS through Twilio
• Create calendar event
• Update an allowed field
• Add review checklist
• Request applicant information
• Schedule escalation
• Run duplicate check
• Run readiness evaluation
• Start provisioning
• Call an approved integration webhook

Every communication action uses a registered Notification Builder event/template. Automations are versioned, idempotent and visible in application activity.

7.8 Builder section: Outcomes

Outcomes define terminal results and controlled side effects.

Default outcomes:

• Approved
• Conditionally Approved
• Declined
• Withdrawn
• Duplicate/Merged
• Referred to another Provider category
• Reapply later

The Approved outcome can configure:

• Entity type created or resolved
• Category qualification created
• Workspace template
• Default dashboard/navigation capability bundle
• Profile mapping
• Matching profile seed
• Onboarding template
• Owner membership/invitation
• Initial entity lifecycle state
• Notification set

7.9 Builder section: Access

Defines who may:

• View applications
• Edit answers after submission
• Move stages
• Override requirements
• Complete review checks
• Decide outcomes
• View sensitive verification data
• Retry provisioning
• Export records

This section consumes future permission capabilities. Initial releases may use protected system capabilities and Team-based defaults without exposing the full permissions builder.

7.10 Builder section: Version history

Shows:

• Version number
• Draft/published/retired status
• Author and timestamp
• Change summary
• Validation result
• Record count using each version
• Side-by-side comparison
• Roll-forward action

Publishing never mutates existing submitted records onto the new version automatically.

8. Fixed System States and Configurable Stages

8.1 Fixed application system states

draft
submitted
under_review
applicant_action_required
verification
decision_pending
conditionally_approved
approved
declined
withdrawn
merged_duplicate

8.2 Recommended default Provider workflow

Draft
  → Submitted
  → Completeness Review
  → Initial Fit Review
  → Applicant Action Required, when needed
  → Verification
  → Interview / Site Review, category dependent
  → Decision Pending
  → Conditionally Approved / Approved / Declined

8.3 Category variations

• Storage may require Facility Review and Capacity Validation.
• White-glove may require Fleet/Crew Review and Insurance Verification.
• Millwork may require Portfolio/Quality Review and Shop Capability Review.
• Trades may require Licence/Safety Review.
• Photography may require Portfolio and Usage-Rights Review.
• Vendors may require Product/Brand Fit and Fulfilment Review.

These are display stages mapped to the fixed states above.

8.4 State protections

• Draft and published stages must each map to one system state.
• A path to at least one terminal outcome is required.
• Approval cannot be reachable without a decision authorization rule.
• Provisioning cannot run from a non-approved system state.
• A stage in use cannot be deleted from a published version.
• Colours communicate meaning but never replace labels.

9. Dynamic Application Forms

9.1 Shared field library

Supported fields:

• Short and long text
• Rich text
• Email and phone
• Address lookup with normalized components
• Number, currency and percentage
• Date and date range
• Single select and multi-select
• Yes/no and checkbox groups
• File/document upload
• Portfolio/image gallery
• URL and social profile
• Repeating group
• Contact/person reference
• Entity reference
• Signature/declaration acknowledgement
• Category capability matrix
• Service-area builder
• Availability/capacity input

9.2 Standardization

• Dropdowns use shared option sets and are alphabetically sorted where order has no semantic meaning.
• Addresses use one normalized lookup/manual correction component.
• Currency shows symbols and thousands separators while storing minor units and currency code.
• Dates use one accessible date picker and explicit time zone where relevant.
• Phone numbers are normalized while preserving display format.
• Percentages have defined minimum, maximum and precision.
• File inputs declare allowed type, size, count and retention.

9.3 Conditional logic

Forms support show/hide, require, validate and repeat logic based on earlier answers. Logic is evaluated client-side for responsiveness and server-side for enforcement.

9.4 Save and return

• Every section autosaves.
• Applicants can resume on another device.
• Progress shows completed, incomplete and blocked sections.
• Submitted answers become an immutable snapshot for that version.
• Action Required creates a controlled amendment rather than silently rewriting the original submission.

9.5 Form versioning

Each application records:

• Form definition/version
• Exact field keys and option IDs
• Normalized answers
• Display snapshot
• Submission timestamp
• Applicant declaration version

Changing a label or option never changes the meaning of historical submissions.

10. Provider-Specific Application Requirements

10.1 Shared Provider sections

• Business identity and contacts
• Ownership/legal information where required
• Provider category and services
• Service areas
• Capacity and availability
• Typical Project and job size
• Experience and references
• Portfolio/evidence
• Insurance, licences and credentials
• Commercial and operational contacts
• Technology/integration readiness
• Matching profile questions
• Declarations and consent

10.2 Vendors and Product Suppliers

• Brands and product categories
• Trade program and Designer support
• Pricing/discount structure information
• Order minimums
• Samples and memo program
• Shipping regions and lead times
• Returns, claims and warranty process
• API/catalogue availability
• Inventory/fulfilment capabilities

10.3 Millwork and Custom Fabrication

• Fabrication categories and materials
• Shop location, equipment and capacity
• Drawings/engineering capability
• Finishing and sample process
• Site measurement and installation capability
• Lead times and project-size range
• Quality-control process
• Portfolio and references
• Insurance and safety documents

10.4 Contractors and Specialty Trades

• Trade specialties
• Licence numbers and jurisdictions
• Crew capacity and supervision
• Service area
• Project types and size
• Scheduling/lead time
• Safety and compliance documents
• Insurance
• Change-order and documentation process

10.5 Photography

• Photography specialties
• Portfolio
• Service area/travel
• Crew and equipment
• Shoot-day capacity
• Deliverables and turnaround
• Revision policy
• Usage rights/licensing
• Insurance

10.6 Measurement and Drafting

• Measurement services and methods
• Drawing/document types
• File formats and software
• Service area
• Site-visit capacity
• Turnaround and revision process
• Professional credentials
• Sample deliverables

10.7 Receiving, Warehouse and Storage

• Facility locations and service areas
• Receiving hours and appointment rules
• Storage capacity/types
• Climate control and security
• Dock/loading/handling capability
• Inspection and condition-photo process
• Inventory/location system
• Damage and claims process
• Insurance
• Delivery/pull-list capability
• Technology readiness for item-level receiving

10.8 White-Glove Delivery

• Fleet and vehicle types
• Crew size and training
• Service regions
• Cargo insurance
• Furniture handling/assembly capability
• Routing and tracking capability
• Proof-of-delivery process
• Damage/exception process
• Packaging removal
• Capacity and lead time

10.9 Installation Services

• Installation categories
• Crew skills and capacity
• Service regions
• Tools/equipment
• Site and safety credentials
• Item handling capability
• Deficiency/punch-list process
• Completion evidence
• Insurance

10.10 General Service Providers

Uses shared sections plus administrator-configured capabilities, evidence, service area, capacity and category-specific review criteria.

11. Public Website Signup and Application Experience

11.1 Entry points

The Design Registry website includes separate paths for:

• Designer Studios
• Providers
• Clients/future lead intake where applicable

Provider applicants first select the category that best describes their business. Help content explains categories without revealing internal scoring.

11.2 Applicant flow

Choose applicant type
→ Select Provider category
→ Create account or sign in
→ Verify email
→ Confirm business identity / duplicate check
→ Complete tailored application
→ Review and declaration
→ Submit
→ Pending Application Workspace
→ Requests, interview and decision
→ Approved Workspace onboarding

11.3 Authentication

Applicants may use Google authentication or email/password. Forgotten-password and email-verification flows use the shared Auth specification. Authentication creates a User, not an approved Provider.

11.4 Pending Application Workspace

Before approval, the applicant receives limited access to:

• Application progress/status
• Submitted answers
• Requests for information
• Interview/site-review schedule
• Messages with Registry reviewers
• Uploaded documents
• Decision and next steps
• Personal profile/security

They do not receive the full Provider portal, marketplace directory, Projects or Jobs.

11.5 Duplicate detection

Before creating a provisional entity, the system checks normalized business name, domain, address, registration identifiers and authorized email domain. Potential matches create a review case; they are not auto-merged solely by fuzzy similarity.

12. Application Record Experience

12.1 Record header

• Applicant/entity name
• Application ID and category
• Current stage and colour
• Submitted/updated date
• Owner/Team
• SLA status
• Primary actions/next steps
• Duplicate/verification/provisioning warnings

12.2 Tabs

1. Workflow
2. Overview
3. Activity
4. Notes
5. Files
6. Tasks
7. Communication
8. Verification
9. Matchmaking
10. History

The tabs reuse current shared modules used by Designer Applications and Project Opportunities.

12.3 Workflow tab

The first tab is generated from the pipeline version and includes:

• Stage progress map
• Current stage purpose
• Allowed next steps
• Required fields/documents/tasks/reviews
• Checklist with owner and status
• Blockers
• SLA and escalation
• Applicant-visible versus internal requirements
• Stage activity and automation results
• Transition confirmation and override reason where permitted

The Workflow tab is not manually designed per category; it renders pipeline configuration.

12.4 Overview tab

Shows configured applicant/business information cards, category answers, profile completeness, key contacts, service area, capacity and application summary.

12.5 Verification tab

Tracks each verification requirement independently:

• Type
• Submitted evidence
• Reviewer
• Status
• Effective/expiry dates
• Notes
• Reverification rule
• Applicant visibility

12.6 Matchmaking tab

Shows the future Network Profile seed, completeness, normalized attributes, internal exclusions and review status. It does not expose internal ranking weights or comparisons.

12.7 History

Immutable timeline of stage changes, answer amendments, reviews, outcome, provisioning, merges, overrides and versions.

13. Review, Verification and Decisioning

13.1 Review standards

Each category has a versioned review standard containing:

• Completeness checks
• Minimum qualification checks
• Required evidence
• Interview/site-review requirements
• Quality criteria
• Risk flags
• Decision authorization
• Renewal/expiry policy

13.2 Review checks

Review checks are structured records, not free-text notes. Each has outcome, reviewer, timestamp, evidence, comment and optional expiry.

13.3 AI assistance

AI may:

• Summarize an application
• Extract document fields for reviewer confirmation
• Identify missing or inconsistent answers
• Draft an information request
• Suggest relevant review checks

AI may not approve, decline, merge entities, verify credentials or create Workspace access without authorized human confirmation.

13.4 Conditional approval

Conditional approval records specific outstanding conditions, due dates, owner and restrictions. Provisioning may create a limited Workspace, but match eligibility remains false until configured conditions pass.

13.5 Decline and reapply

Decline reasons use an internal controlled taxonomy plus applicant-safe communication. Reapplication policy can specify waiting period, required changes and whether prior answers may be reused.

14. Approval and Provisioning

14.1 Approval transaction

Approved outcome confirmed
→ lock decision snapshot
→ resolve or create Provider entity
→ create approved category qualification
→ create or activate Workspace
→ activate/invite owner membership
→ seed Workspace and Network Profiles
→ seed category dashboard/navigation
→ seed matchmaking profile
→ create operational-readiness evaluation
→ create entity lifecycle record
→ create onboarding tasks
→ emit audit/activity events
→ send registered notifications

14.2 Idempotency

The provisioning job uses the approved application ID as an idempotency key. Retries must continue incomplete steps without duplicating entities, Workspaces, memberships, qualifications or notifications.

14.3 Provisioning states

• Not started
• Queued
• In progress
• Awaiting manual resolution
• Complete
• Failed/retryable
• Failed/permanent

Approval remains auditable if provisioning fails. The record displays the failed step and safe retry action.

14.4 Profile mapping

Application answers map to profile fields through versioned mapping rules. The applicant reviews imported profile information during onboarding. Source application values remain preserved.

14.5 Workspace template by category

Provisioning enables the correct dashboard and navigation modules:

• Common Offers, Jobs, Tasks, Calendar, Messages, Proposals, Work Orders, Invoices and Profile
• Vendor product/availability modules
• Millwork drawings/fabrication modules
• Trade site/RFI/deficiency modules
• Photography brief/asset modules
• Measurement/drafting deliverables
• Storage receiving/inventory modules
• White-glove dispatch/tracking modules
• Installation readiness/deficiency modules

15. Entity Lifecycle Pipelines

15.1 Separation from application pipeline

The Application Pipeline ends in an outcome. The resulting Provider entity then participates in a Provider lifecycle pipeline. These are related but separate records.

15.2 Provider entity lifecycle

Approved
→ Workspace Setup
→ Profile Incomplete
→ Verification Pending
→ Match Eligible
→ Active
→ Capacity Limited / Paused
→ Review Required
→ Suspended
→ Inactive

Every Provider entity receives one primary lifecycle pipeline. Category qualifications maintain their own state and can independently be active, expiring, restricted, suspended or inactive.

15.3 Designer and Client pipelines

• Designer Studio entities use the Designer lifecycle pipeline after Designer Application approval.
• Client entities use the Client relationship pipeline.
• Project entities use the Project process/pipeline with automated movement derived from Project work.

All reuse the Pipeline Engine but have distinct system-state taxonomies and builders.

16. Matchmaking and Operational Readiness

16.1 Matchmaking profile seed

Application answers seed category-relevant matching fields:

• Capabilities
• Service areas
• Job value range
• Project types
• Lead times
• Capacity and availability
• Specialties/materials/product categories
• Operational constraints
• Evidence/quality signals
• Languages and communication preferences

16.2 Readiness gates

Match eligibility may require:

• Approved application/category qualification
• Active Workspace
• Complete Network Profile
• Current insurance/licences/credentials
• Current capacity and availability
• Service-area coverage
• Required category workflow setup
• No suspension or blocking review
• Required payment/invoicing setup where applicable

16.3 Separation of states

The following are never treated as synonyms:

• Application approved
• Category qualified
• Workspace active
• Profile complete
• Match eligible
• Available for new work
• Active on a Project

16.4 Match-to-Project handoff

Project Work Package requirement
→ eligible Provider pool
→ category-specific match run
→ ranked, explainable results
→ authorized shortlist
→ Offer
→ Provider response
→ accepted commercial workflow
→ Provider Job and Project access

Providers do not see competitors, rankings, internal notes or marketplace economics.

17. Notifications and Automations

17.1 Required event keys

application.started
application.email_verified
application.section_completed
application.submitted
application.assigned
application.stage_changed
application.action_required
application.action_received
application.sla_at_risk
application.interview_scheduled
application.site_review_scheduled
application.verification_passed
application.verification_failed
application.conditionally_approved
application.approved
application.declined
application.withdrawn
application.duplicate_review_required
application.merged
provisioning.started
provisioning.step_failed
provisioning.completed
provider.category_qualified
provider.workspace_activated
provider.onboarding_required
provider.match_eligibility_changed
provider.credential_expiring

17.2 Notification Builder

Every event is registered with variable schema, allowed channels, protected variables, default template, recipient rules and delivery history. Registry administrators may edit approved wording, branding, channel enablement, reminders and escalation.

17.3 Recipient rules

• Applicant/Workspace Owner
• Application owner
• Reviewing Team
• Verification assignee
• Market operator
• Escalation recipient
• Provisioning support

Recipient resolution is performed at event time and logged.

18. Data Model

entity_types
provider_categories
provider_category_versions
application_types

application_pipeline_definitions
application_pipeline_versions
application_stage_definitions
application_transition_definitions
application_transition_requirements
application_outcome_definitions
application_automation_definitions
application_view_definitions

application_form_definitions
application_form_versions
application_form_sections
application_field_definitions
application_field_options
application_conditional_rules

application_records
application_answer_snapshots
application_answer_amendments
application_documents
application_participants
application_stage_history
application_reviews
application_review_checks
application_verifications
application_outcomes

provisional_entities
provider_entities
provider_category_qualifications
provider_entity_lifecycle_records
workspace_provisioning_jobs
workspace_provisioning_steps

matchmaking_profiles
matchmaking_profile_versions
operational_readiness_evaluations

18.1 Key constraints

• Pipeline version is immutable after publication.
• Application record retains pipeline and form version IDs.
• One approved category qualification exists per Provider entity/category/market scope unless explicitly versioned.
• Provisioning job is unique per approved application.
• Application stage must belong to the attached pipeline version.
• Terminal outcome is append-only; correction requires a governed superseding decision.

19. API Design

19.1 Public/applicant

GET   /v1/public/application-categories
POST  /v1/applications
GET   /v1/applications/:applicationId
PATCH /v1/applications/:applicationId/answers
POST  /v1/applications/:applicationId/files
POST  /v1/applications/:applicationId/submit
POST  /v1/applications/:applicationId/amendments

19.2 Administration

GET   /v1/admin/application-pipelines
POST  /v1/admin/application-pipelines
POST  /v1/admin/application-pipelines/:id/drafts
PATCH /v1/admin/application-pipeline-versions/:versionId
POST  /v1/admin/application-pipeline-versions/:versionId/validate
POST  /v1/admin/application-pipeline-versions/:versionId/publish

GET   /v1/admin/applications
GET   /v1/admin/applications/:id
POST  /v1/admin/applications/:id/transitions
POST  /v1/admin/applications/:id/review-checks
POST  /v1/admin/applications/:id/outcomes
POST  /v1/admin/applications/:id/provisioning/retry

19.3 Enforcement

The server validates pipeline version, current stage, allowed transition, requirements, authorization, duplicate/merge state and optimistic concurrency version before changing workflow.

20. Supabase Architecture and Security

20.1 Authentication and provisional access

Supabase Auth identifies the User. Pending applicants receive application-scoped access grants, not general Provider Workspace membership.

20.2 Row Level Security

• Applicants can access only applications where they are an authorized participant.
• Reviewers access applications through active Registry Workspace membership and market/category scope.
• Provider users cannot access another Provider’s application or qualification.
• Sensitive verification documents use narrower policies than general application files.
• Approved Provider Workspace access begins only after membership activation.

20.3 Trusted functions

Edge Functions or trusted server services handle:

• Submission finalization
• Transition validation
• Duplicate-resolution operations
• Approval/outcome recording
• Provisioning
• Resend/Twilio delivery
• Credential extraction/verification integrations
• Website webhook intake

Service-role credentials are never exposed to the browser.

20.4 Idempotency and events

Submission, transitions, notifications and provisioning use idempotency keys. Domain events are written durably and processed with retries. Duplicate delivery cannot create duplicate entities or messages.

21. Enterprise Data Grid and Reporting

The Applications table supports:

• Search
• Category and application-type filters
• Stage/system-state filters
• Market
• Owner/Team
• SLA status
• Verification status
• Match readiness
• Submission date
• Saved views
• Configurable columns
• Permitted export
• Bulk assignment and safe bulk task creation

Approval, decline, merge, stage overrides and provisioning retry are not general bulk actions.

Required reporting dimensions use system states and canonical Provider category IDs so custom stage labels do not fragment analytics.

22. Migration from Existing Pipelines

22.1 Preserve

• Existing Designer Applications pipeline and records
• Existing builder section architecture
• Shared record tabs
• Published version behaviour
• Project Opportunities, Client and Project pipelines
• Existing notes, tasks, files, communications, activity and history

22.2 Replace legacy placeholders

Replace:

• Proper Good Club
• Photography
• Contracting
• Millwork
• Storage
• White-glove Delivery

With the complete canonical Provider category directory and pipelines defined in this specification.

22.3 Backfill

• Assign stable entity and category IDs.
• Map existing Designer Application stages to fixed system states.
• Convert placeholder metadata into unpublished default Provider pipeline drafts.
• Preserve legacy IDs through alias/migration tables.
• Reconcile records before enabling public application routes.

22.4 Launch sequence

1. Introduce Applications Settings directory.
2. Move Designer Applications card into the grouped directory without breaking URLs.
3. Seed nine Provider pipeline drafts.
4. Configure category forms and review standards.
5. Publish one category at a time.
6. Enable matching/provisioning only after end-to-end testing.

23. Acceptance Criteria

23.1 Pipeline coverage

• Every canonical Provider category has a dedicated Application Pipeline.
• Designer, Client and Project pipelines remain supported by the shared engine.
• Each Provider pipeline has stable system-state mappings and editable display stages.
• Pipeline Builder validations prevent broken or unsafe publication.

23.2 Builder

• Administrators can configure Overview, Stages & next steps, Forms, Record details, Views, Automations, Outcomes, Access and Version history.
• Stage colours, order and labels are editable.
• Required fields, documents, tasks, reviews and approvals can gate transitions.
• In-app, Resend email and Twilio SMS automations use Notification Builder templates.
• Published versions are immutable and existing records retain their version.

23.3 Application record

• Workflow is the first tab and renders the active pipeline configuration.
• Other tabs reuse shared application/Project Opportunity modules.
• Applicant-visible and internal requirements remain separate.
• Every transition is enforced server-side and audited.

23.4 Website and pending account

• Website category selection opens the correct current form version.
• Applications autosave and can be resumed.
• Pending applicants can access only their Application Workspace.
• Approval state belongs to the application/entity relationship, not the global User.

23.5 Entity and provisioning

• Approved applications create or resolve exactly one Provider entity.
• Additional categories never create duplicate Provider entities or Workspaces.
• Provisioning safely resumes after failure.
• Correct category dashboards, profile fields and onboarding tasks are seeded.
• Approval alone does not imply match eligibility.

23.6 Security and notifications

• RLS tests prove applicant, Registry, Provider and market isolation.
• Sensitive verification files use restricted access.
• All material application and provisioning events exist in Notification Builder.
• Notification failure never rolls back a valid transition or approval.

24. Implementation Phases

Phase 1 — Shared pipeline foundation

• Entity/application pipeline type registry
• Fixed system states
• Version validation
• Transition requirements
• Existing Designer Pipeline migration

Phase 2 — Applications Settings and builder

• Application Pipelines directory
• Provider category registry
• Reused builder sections
• Workflow preview
• Version history/comparison

Phase 3 — Forms and website

• Shared field library
• Category forms
• Save-and-return
• Website signup/authentication
• Pending Application Workspace

Phase 4 — Review and decisioning

• Workflow-first application record
• Review standards/checks
• Verification
• SLA/escalation
• Outcomes

Phase 5 — Provisioning

• Entity resolution
• Category qualifications
• Workspace/membership provisioning
• Profile and dashboard seeding
• Onboarding

Phase 6 — Matchmaking readiness

• Category matching profiles
• Readiness rules
• Expiry/re-verification
• Match-to-Offer handoff

Phase 7 — Category rollout

• Vendors
• Millwork
• Trades
• Photography
• Measurement/drafting
• Storage
• White-glove
• Installation
• General Providers

Each phase ships with audit, RLS, Notification Builder events, migration/reconciliation and automated tests.

25. Definition of Done

This specification is complete when:

1. Every Provider Category has a distinct, editable application pipeline.
2. The pipelines are built with the same engine and interaction patterns as Designer Applications.
3. Settings provides a clear Applications Builder without duplicating the general Pipeline Builder architecture.
4. The Workflow tab is the first tab on every application and is generated from the published pipeline version.
5. Stages, colours, requirements, next steps, forms, views, automations and outcomes are configurable while system states remain protected.
6. Public website applications, pending accounts, review and requests form one continuous experience.
7. Approval creates or qualifies one durable entity and safely provisions the correct Workspace.
8. Multi-category Providers do not create duplicate entities.
9. Matching eligibility depends on category qualification and operational readiness, not approval alone.
10. Every material event is auditable and configurable through the Notifications Builder.
11. The Providers directory displays all nine canonical Categories, including zero-count empty states.
12. Every approved Provider opens one shared Provider Profile with independently governed Category Qualifications.
13. Administrative access uses a time-limited, purpose-bound and fully audited Administrative Access Session.

The application system should make every Provider feel individually understood while allowing The Design Registry to operate one scalable, governed platform.

Live-product correction contract — August 4, 2026

The live Applications Builder now exposes Designer Studio Applications plus all nine canonical Provider Categories and a six-part builder: Application form, Review checklist, Application details, Documents, Decision and Version history. The Storage Application draft contains 35 fields across 11 sections and identifies Workspace Profile and Matchmaking mappings.

The implementation cannot be accepted until the following findings are resolved:

1. Critical mapping defect: every locked item in the Storage Application details reviewer summary currently resolves to Damage documentation and claims process. Each summary item must resolve to its intended stable submitted-field key.
2. Publishing must run schema validation, duplicate-key detection, required-field validation, Workspace Profile mapping validation, Matchmaking mapping validation and reviewer-summary mapping tests.
3. Submitted Applications retain the exact published schema version used at submission; later builder edits must not reinterpret historical answers.
4. The website signup/application and authenticated continuation must use the same schema version and stable field keys.
5. The builder must preview both applicant and reviewer experiences before publish.
6. Published versions are immutable. Corrections create a new draft/version and an explicit migration plan for in-progress drafts.
7. Category-specific sections extend shared defaults; they do not fork separate application services.
8. Approval remains blocked until required checklist items, documents, applicant-facing message and reviewer notes satisfy the published Decision rules.
9. Approved field seeding into Workspace Profile and Matchmaking Profile records source Application, answer version, reviewer and timestamp.
10. Application and provisioning events remain registered in Notifications Builder, with delivery failures visible to authorized operators.

<!-- CURRENT-PRODUCT-GAP-COVERAGE:START -->

Current-product review gap closure register

Generated: August 4, 2026
Owning future specification: 05
Mapped current-product profiles: 17
Recorded review gaps: 69

This register is part of the release contract. It maps the current-product reverse review into required future behavior. A gap is not closed because a screen exists; closure requires the corrected canonical data, permissions, states, migration, audit and test evidence described below.

Register rules

1. Every profile in the Current Product Library must resolve to one owning future specification.
2. Current limitations are evidence, not optional ideas. If a limitation is intentionally retained, the specification must record the decision, risk, owner and review date.
3. Shared-component defects are corrected through Spec 16 and then consumed here; feature teams may not create local replacement controls.
4. Permission, contact, financial and visibility defects also require Spec 08 enforcement, even when the functional feature is owned by another specification.
5. Legacy Proper Gallery, Lead, Partner and implementation-facing labels are migration inputs only and must not return through new UI, APIs, exports or notifications.
6. Verification must use realistic fixtures for Admin, Designer, Provider and Client audiences where applicable.

G01 — Applications directory

Current-product profile: applications-directory
Observed route: /admin/applications
Evidence confidence: Partially verified

Review gaps

• Only the navigation entry is conclusively verified in this review.
• Complete Designer and all nine Provider Category queues are not evidenced.
• Bulk review, saved views, export, provisioning exceptions and category-aware empty states are unverified.
• The directory-to-record and approval-to-provisioning journeys are not yet proven end to end.

Required future closure

• Implement one permission-scoped directory for Designer and every Provider Category application.
• Expose independent review, Entity, Workspace, invitation and onboarding statuses.
• Add saved views, assignment, service-level indicators and provisioning exception recovery.
• Use the immutable submitted form and workflow versions defined in Spec 05.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G02 — Designer application

Current-product profile: designer-application
Observed route: /admin/designer-network
Evidence confidence: Partially verified

Review gaps

• The Designer application has not been freshly reviewed across every tab in this pass.
• Current Stages, required fields, decision actions and applicant-visible states are not reconfirmed.
• Duplicate prevention, idempotent approval and Workspace provisioning are not proven end to end.
• Submitted-version immutability and mapping into the Designer Profile are not verified.

Required future closure

• Reconcile the live Designer workflow to the published configuration in Spec 05.
• Implement immutable submission versions and explicit approved mappings into Entity and Matching Profile fields.
• Make approval and provisioning independent, observable and safely retryable.
• Reuse the shared application record and modules without preserving legacy Designer-only forks.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G03 — Provider application

Current-product profile: provider-application
Observed route: /admin/applications
Evidence confidence: Partially verified

Review gaps

• No submitted Provider application was reviewed for any canonical Category.
• Website signup, draft persistence, authentication continuation and pending-account behavior are unverified.
• Category-tailored fields, Matching questions and Credentials are not proven in applicant or reviewer views.
• Approval-to-qualification-to-Workspace provisioning is not proven end to end.

Required future closure

• Connect the public website to the canonical category configuration and immutable application service.
• Provide a high-quality pending account with status, requests, notifications and safe resubmission.
• Build all nine category workflows from shared primitives with explicit category qualification outputs.
• Add end-to-end tests from website submission through Entity, Workspace, owner invitation and onboarding.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G04 — Application workflow tab

Current-product profile: application-workflow
Observed route: /admin/applications/:id
Evidence confidence: Partially verified

Review gaps

• Runtime parity with the Applications Builder is not proven.
• Required fields, documents, Credentials, Tasks, decisions and transition blockers are not verified across categories.
• Waiting-on-applicant, override, rejection, withdrawal and provisioning-failure states are not fully evidenced.
• No end-to-end test proves that one published configuration produces the correct reviewer workflow.

Required future closure

• Render Workflow entirely from the attached immutable configuration version.
• Show structured requirements, blockers, owners, deadlines and completion evidence.
• Preview and audit decision side effects, overrides and provisioning exceptions.
• Create category fixtures and automated tests for every Stage and transition in Spec 05.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G05 — Designer Studios directory

Current-product profile: designer-studios-directory
Observed route: /admin/designer-network
Evidence confidence: Verified

Review gaps

• The eyebrow says Provider directory.
• Designer Studios, Designer Network and Studio terminology are inconsistent across links and routes.
• Capacity is a bare percentage plus availability label without freshness or source.
• Profile Completeness does not explain requirements.
• Export, columns and bulk selection outcomes were not exercised.
• Only Toronto and two seeded Studios are represented.

Required future closure

• Standardize on Designer Studios directory and Designer Studio Profile.
• Show capacity source, period and freshness.
• Explain Profile Completeness and Credential actions.
• Add saved views and filters for Service Areas, readiness, specialties, credentials and relationship owner.
• Remove remaining legacy brokerage and Lead links from related profile modules.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G06 — Providers directory

Current-product profile: providers-directory
Observed route: /admin/providers
Evidence confidence: Verified

Review gaps

• No Provider records exist.
• Only All appears in the category filter.
• The grid uses Provider Type rather than Provider Category.
• No Category counts, qualification states, recruitment actions or profile examples exist.
• Search, export and columns cannot be validated with data.

Required future closure

• Show all nine Category cards/filters and counts.
• Add Category Qualification and readiness summaries.
• Provide category-aware empty states and recruitment/application actions.
• Open one shared Provider Profile extended by Category modules.
• Connect availability and capacity to source-aware scheduling data.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G07 — Shared Provider Profile

Current-product profile: provider-profile
Observed route: /admin/providers/:id
Evidence confidence: Known limitation

Review gaps

• No live Provider Profile exists to verify.
• No Category-specific navigation, fields, dashboards or operational views can be inspected.
• The current directory cannot distinguish zero Providers from a failed load without deeper diagnostics.

Required future closure

• Implement shared Provider Profile shell.
• Add all nine category extensions below.
• Reuse Designer Studio shared modules where semantics match.
• Connect Provider Workspace profile editing, Category verification, Project Jobs and commercial operation.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G08 — Vendors & Product Suppliers

Current-product profile: provider-category-vendors-product-suppliers
Observed route: /admin/providers?category=vendors-product-suppliers
Evidence confidence: Known limitation

Review gaps

• No approved Provider Workspace exists in the live directory.
• The Category is not present in the filter.
• There is no sample profile, readiness model, credential summary, Matchmaking projection or Project operating view.
• Route behavior for the proposed category query is not implemented.

Required future closure

• Expose this Category in the Providers directory at zero and populated counts.
• Build its application and Category Qualification through Spec 05.
• Render shared identity plus the Category-specific profile contract above.
• Connect Matchmaking, Work Packages, commercial records and the relevant Project operating workflow.
• Add Category-specific dashboard and Provider Job projections without forking shared services.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G09 — Millwork & Custom Fabrication

Current-product profile: provider-category-millwork-custom-fabrication
Observed route: /admin/providers?category=millwork-custom-fabrication
Evidence confidence: Known limitation

Review gaps

• No approved Provider Workspace exists in the live directory.
• The Category is not present in the filter.
• There is no sample profile, readiness model, credential summary, Matchmaking projection or Project operating view.
• Route behavior for the proposed category query is not implemented.

Required future closure

• Expose this Category in the Providers directory at zero and populated counts.
• Build its application and Category Qualification through Spec 05.
• Render shared identity plus the Category-specific profile contract above.
• Connect Matchmaking, Work Packages, commercial records and the relevant Project operating workflow.
• Add Category-specific dashboard and Provider Job projections without forking shared services.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G10 — Contractors & Specialty Trades

Current-product profile: provider-category-contractors-specialty-trades
Observed route: /admin/providers?category=contractors-specialty-trades
Evidence confidence: Known limitation

Review gaps

• No approved Provider Workspace exists in the live directory.
• The Category is not present in the filter.
• There is no sample profile, readiness model, credential summary, Matchmaking projection or Project operating view.
• Route behavior for the proposed category query is not implemented.

Required future closure

• Expose this Category in the Providers directory at zero and populated counts.
• Build its application and Category Qualification through Spec 05.
• Render shared identity plus the Category-specific profile contract above.
• Connect Matchmaking, Work Packages, commercial records and the relevant Project operating workflow.
• Add Category-specific dashboard and Provider Job projections without forking shared services.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G11 — Photography

Current-product profile: provider-category-photography
Observed route: /admin/providers?category=photography
Evidence confidence: Known limitation

Review gaps

• No approved Provider Workspace exists in the live directory.
• The Category is not present in the filter.
• There is no sample profile, readiness model, credential summary, Matchmaking projection or Project operating view.
• Route behavior for the proposed category query is not implemented.

Required future closure

• Expose this Category in the Providers directory at zero and populated counts.
• Build its application and Category Qualification through Spec 05.
• Render shared identity plus the Category-specific profile contract above.
• Connect Matchmaking, Work Packages, commercial records and the relevant Project operating workflow.
• Add Category-specific dashboard and Provider Job projections without forking shared services.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G12 — Measurement & Drafting

Current-product profile: provider-category-measurement-drafting
Observed route: /admin/providers?category=measurement-drafting
Evidence confidence: Known limitation

Review gaps

• No approved Provider Workspace exists in the live directory.
• The Category is not present in the filter.
• There is no sample profile, readiness model, credential summary, Matchmaking projection or Project operating view.
• Route behavior for the proposed category query is not implemented.

Required future closure

• Expose this Category in the Providers directory at zero and populated counts.
• Build its application and Category Qualification through Spec 05.
• Render shared identity plus the Category-specific profile contract above.
• Connect Matchmaking, Work Packages, commercial records and the relevant Project operating workflow.
• Add Category-specific dashboard and Provider Job projections without forking shared services.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G13 — Receiving, Warehouse & Storage

Current-product profile: provider-category-receiving-warehouse-storage
Observed route: /admin/providers?category=receiving-warehouse-storage
Evidence confidence: Known limitation

Review gaps

• No approved Provider Workspace exists in the live directory.
• The Category is not present in the filter.
• There is no sample profile, readiness model, credential summary, Matchmaking projection or Project operating view.
• Route behavior for the proposed category query is not implemented.

Required future closure

• Expose this Category in the Providers directory at zero and populated counts.
• Build its application and Category Qualification through Spec 05.
• Render shared identity plus the Category-specific profile contract above.
• Connect Matchmaking, Work Packages, commercial records and the relevant Project operating workflow.
• Add Category-specific dashboard and Provider Job projections without forking shared services.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G14 — White-Glove Delivery

Current-product profile: provider-category-white-glove-delivery
Observed route: /admin/providers?category=white-glove-delivery
Evidence confidence: Known limitation

Review gaps

• No approved Provider Workspace exists in the live directory.
• The Category is not present in the filter.
• There is no sample profile, readiness model, credential summary, Matchmaking projection or Project operating view.
• Route behavior for the proposed category query is not implemented.

Required future closure

• Expose this Category in the Providers directory at zero and populated counts.
• Build its application and Category Qualification through Spec 05.
• Render shared identity plus the Category-specific profile contract above.
• Connect Matchmaking, Work Packages, commercial records and the relevant Project operating workflow.
• Add Category-specific dashboard and Provider Job projections without forking shared services.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G15 — Installation Services

Current-product profile: provider-category-installation-services
Observed route: /admin/providers?category=installation-services
Evidence confidence: Known limitation

Review gaps

• No approved Provider Workspace exists in the live directory.
• The Category is not present in the filter.
• There is no sample profile, readiness model, credential summary, Matchmaking projection or Project operating view.
• Route behavior for the proposed category query is not implemented.

Required future closure

• Expose this Category in the Providers directory at zero and populated counts.
• Build its application and Category Qualification through Spec 05.
• Render shared identity plus the Category-specific profile contract above.
• Connect Matchmaking, Work Packages, commercial records and the relevant Project operating workflow.
• Add Category-specific dashboard and Provider Job projections without forking shared services.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G16 — General Service Providers

Current-product profile: provider-category-general-service-providers
Observed route: /admin/providers?category=general-service-providers
Evidence confidence: Known limitation

Review gaps

• No approved Provider Workspace exists in the live directory.
• The Category is not present in the filter.
• There is no sample profile, readiness model, credential summary, Matchmaking projection or Project operating view.
• Route behavior for the proposed category query is not implemented.

Required future closure

• Expose this Category in the Providers directory at zero and populated counts.
• Build its application and Category Qualification through Spec 05.
• Render shared identity plus the Category-specific profile contract above.
• Connect Matchmaking, Work Packages, commercial records and the relevant Project operating workflow.
• Add Category-specific dashboard and Provider Job projections without forking shared services.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G17 — Applications Builder

Current-product profile: applications-builder
Observed route: /admin/settings/applications
Evidence confidence: Verified

Review gaps

• Critical review-summary field mapping defect.
• Several default controls appear disabled as intended but mapping presentation is confusing.
• Publish, applicant preview and version retention were not mutated or tested.

Required future closure

• Block publish when a summary item resolves to the wrong field.
• Add schema diff, migration preview and automated mapping tests.
• Use the same website signup schema and authenticated continuation.
• Register complete Application notifications and provisioning handoff.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

<!-- CURRENT-PRODUCT-GAP-COVERAGE:END -->