The Design Registry

Pipeline, Forms & Automation Builder

Document: 09 - Pipeline, Forms & Automation Builder
Version: 2.1
Date: August 2026
Status: Engineering source of truth
Primary systems: Pipeline Engine, Pipeline Builder, Dynamic Form Builder, Enterprise Data Grid, Pipeline Record Experience, Automations, Notifications, Applications, Entities, Clients, Projects and Workspace CRM
Production backend: Supabase Auth, Postgres, Row Level Security, Storage, Realtime, Cron/Queues and Edge Functions

1. Executive Summary

The Design Registry will provide one configurable Pipeline Engine that serves two different but compatible product promises.

First, every Designer Studio and Provider Workspace receives a useful general CRM. These businesses can create private pipelines for leads, referrals, sales, inquiries, quote requests, partnerships and other opportunities. A Workspace can define its own stages, colours, fields, forms, transition requirements, tasks, owners, service levels, views, automations and conversion outcomes without code.

Second, The Design Registry uses the same engine for governed network workflows: Designer and Provider applications, Project Opportunities, Client intake, entity relationships, matchmaking readiness and other Registry-controlled lifecycles. These pipelines remain configurable, but protected system states and outcomes preserve analytics, approval, security and provisioning integrity.

The Pipeline system does not replace Projects. Pipelines qualify opportunities and create durable Entities, Clients, commercial records or Projects. Projects remain the operational centre for Design, Construction Administration, Procurement, receiving, storage, delivery and Installation. A Project may appear in a portfolio Pipeline for reporting, but its position is projected automatically from the Project’s canonical seven-Phase workflow and operational facts.

This specification also makes the Dynamic Form Builder and Automation Engine shared platform services. The same standardized field components, validation rules, transition forms, event model, Notification Builder templates, audit history and execution controls are reused everywhere.

The durable product rule is:

Pipelines qualify and progress opportunities. Entities preserve relationships. Projects execute the work.

2. Product Decisions

2.1 Three pipeline classes

2.2 Opportunity records are separate from Entities

One Contact, Client or Provider may have several opportunities at the same time. Therefore, an Entity does not carry one universal sales stage. Each opportunity is its own Pipeline Record linked to one or more Entities.

Examples:

• One Client has a decorating inquiry and a later renovation inquiry in separate Pipeline Records.
• One Vendor has an onboarding lifecycle and several sales or sourcing opportunities.
• One referral partner is linked to opportunities across multiple Clients.
• A Provider application creates or qualifies a Provider Entity without becoming that Provider’s permanent commercial status.

Where ongoing relationship management is required, an Entity may have one designated primary relationship-lifecycle record for that relationship type. Opportunity records remain many-to-one.

2.3 General pipelines use supported record classes

Version one does not allow customers to create arbitrary database entity types. Workspace Owners choose from supported record classes and extend them with custom fields.

Initial record classes:

• General Lead / Opportunity
• Project Opportunity
• Client Intake
• Application
• Entity Relationship
• Project Portfolio Projection

General Lead / Opportunity is the default for Designer and Provider custom pipelines.

2.4 System meaning and customer language are separate

Customers may rename stages and choose colours. Governed workflows map display stages to stable system-state keys. Workspace CRM pipelines map stages to broad reporting categories such as Open, Won, Lost or Archived without imposing Registry application states.

2.5 Published definitions are immutable

Every production Pipeline, Form and Automation uses a published version. Changes create a Draft and require validation, impact review and publication. Historical records retain their original meaning.

2.6 Current-product correction contract

The live product review completed on August 4, 2026 is the implementation baseline for this specification. The existing experience is a partially connected workflow scaffold, not yet the complete Pipeline Builder described in this document. Engineering must correct the live inconsistencies before expanding the engine to more Pipeline classes.

The reverse-built feature profiles in the Current Product Library remain the evidence record for these findings. This future-state specification is authoritative for the correction, while the reverse specifications remain authoritative for what is currently observable.

2.6.1 Legacy-system removal rule

No new feature may depend on the old Lead model as a public product concept. For Project Opportunities:

• Visible record IDs use PO-* consistently.
• Product copy uses “Project Opportunity” or the configured Pipeline Record label, not “Lead,” unless a Workspace-owned General Lead Pipeline is actually being shown.
• New canonical routes use /pipeline-records/{id} or a Pipeline-class route rather than /leads/{id}.
• Existing /admin/leads/* URLs may remain temporarily as redirects that resolve the hidden legacy alias to the canonical record.
• Legacy stage enums are read only during migration and are not valid values for new mutations.
• Legacy Proper Gallery field labels, commission labels and source names are mapped to Design Registry terminology or explicitly retired.
• Analytics, exports, notifications, Activity and API responses expose the canonical identifier and label.
• Historical audit records may retain the original raw alias, but ordinary users do not see it.

3. Objectives and Success Measures

3.1 Objectives

The completed system must:

1. Give every Designer and Provider Workspace a flexible general lead CRM.
2. Reuse the same engine for all Registry applications and opportunity workflows.
3. Allow stages, colours, transitions and required information to be edited safely.
4. Support manual and automatic progression with clear explanations.
5. Provide standardized forms and custom fields without fragmenting the data model.
6. Support in-app, Resend email, Twilio SMS and calling-task automation.
7. Preserve one complete record experience across pipelines.
8. Convert qualified records without duplicating Entities or losing history.
9. Enforce customizable permissions and sensitive-field visibility from Spec 08.
10. Provide reliable analytics, versioning, retries, audit and migration.

3.2 Success measures

4. Non-Goals

• Replacing the seven-Phase Project operating system.
• Allowing arbitrary customer code inside conditions or automations.
• Allowing customers to create unrestricted database tables or system states.
• Building a full telephony platform in the first release.
• Sending unapproved consequential AI communications.
• Letting a stage change substitute for legal acceptance, payment, approval or a Work Order.
• Automatically migrating active records to a changed definition without review.
• Exposing Registry pipelines or records to a Workspace unless explicitly shared through a governed relationship.

5. Product Principles

5.1 Build once, configure everywhere

Pipeline stages, forms, grids, tasks, communication, activity, files, notes, history, automation and conversion are shared components. Record-class and audience configuration create specialization.

5.2 Useful before customized

Designer and Provider Workspaces receive starter pipelines and views. A new Workspace can capture a lead immediately and refine its process later.

5.3 Structure where consequences matter

Moving an opportunity between ordinary Open stages may be simple. Approval, provisioning, Project conversion, financial commitment, award and rejection require explicit governed outcomes.

5.4 Automation is visible and reversible where possible

Users can see why a task, message, assignment or stage change occurred. Reversible actions provide correction. Irreversible or consequential actions require safeguards.

5.5 One source of truth

The Pipeline Record holds opportunity workflow truth. Entity records hold relationship truth. Project operations hold execution truth. Automation may project information across them but cannot create competing status fields.

5.6 Calm configuration

The builder uses progressive disclosure, presets and validation. It does not present every advanced rule in one dense matrix.

6. Core Domain Model

6.1 Pipeline Definition

A stable identity for a Pipeline owned by the platform, Registry or one Workspace. It holds display identity, record class, ownership, lifecycle and current published version.

6.2 Pipeline Version

An immutable published configuration containing stages, transitions, field/form references, views, automations, outcomes and access defaults.

6.3 Pipeline Record

One instance progressing through a Pipeline. It contains:

• Pipeline and version
• Current display stage and reporting state
• Workspace ownership
• Owner, Team and collaborators
• Canonical and custom field values
• Linked Entities and source records
• Activities, Notes, Files, Tasks and Communication
• Transition history and validation results
• Automation executions
• Conversion outcomes and resulting record links

6.4 Stage

A named step within one Pipeline Version. It has an immutable internal key within the version, display name, colour token, order, reporting/system mapping, ownership rules, service-level target, visibility and entry/exit behavior.

6.5 Transition

A permitted movement from one stage to another. A transition is an explicit command, not a direct stage-field update.

6.6 Outcome

A governed business result such as Qualified, Won, Lost, Approved, Declined, Converted to Project, Provisioned or Merged Duplicate. Outcomes may create durable linked records through controlled side effects.

6.7 Form Definition and Version

A reusable composition of sections, fields, validation and conditional logic. Forms may be public, internal, transition-specific or record-editing experiences.

6.8 Automation Definition and Version

A trigger, condition set, timing rule and action sequence attached to a Pipeline, stage, transition, field or platform event.

7. Pipeline Ownership and Visibility

7.1 Ownership levels

7.2 Workspace privacy

A Workspace CRM Pipeline and its records are private to the owning Workspace. Registry-generated opportunity sharing creates an explicit relationship and access grant; it does not make the Workspace’s other CRM records visible to Registry staff or another Workspace.

7.3 Shared records

When a Registry Project Opportunity is offered to a Designer, the Registry record remains governed. Acceptance or conversion may create a linked Workspace opportunity and later Project. Each party sees its authorized view of linked data rather than receiving ownership of the same unrestricted row.

8. Starter Pipelines

8.1 Designer Studio starters

• General Leads
• New Client Inquiries
• Referral Opportunities
• Project Opportunities
• Consultation Follow-Up

Recommended General Leads stages:

New
  → Contact Attempted
  → Qualified
  → Consultation Scheduled
  → Proposal / Next Step
  → Won / Converted
  → Lost / Not a Fit

8.2 Provider starters

• General Leads
• Quote Requests
• Referral Opportunities
• Trade Account or Business Inquiries
• Own Sales Opportunities

Recommended Quote Requests stages:

New Request
  → Reviewing
  → Information Required
  → Estimating
  → Proposal Sent
  → Won
  → Lost / Declined

Provider-category starter variants may add appropriate fields and tasks, but do not create separate engines.

8.3 Registry starters

• Project Opportunities
• Designer Applications
• Provider Applications by category
• Client Intake
• Designer Relationship Lifecycle
• Provider Relationship Lifecycle

9. Settings Information Architecture

Settings
├── Project Builder
├── Pipeline Builder
│   ├── All Pipelines
│   ├── CRM Pipelines
│   ├── Applications
│   ├── Entity Lifecycles
│   ├── Project Projections
│   ├── Forms & Fields
│   ├── Automation Library
│   └── Execution & Audit
├── Notifications
└── Permissions

Applications is a focused filtered surface powered by the same Pipeline Builder. It is not a second configuration engine.

9.1 Pipeline directory

The directory uses the shared Enterprise Data Grid and includes:

• Pipeline name
• Record class
• Ownership and Workspace
• Draft/published status
• Current version
• Active record count
• Open, won/lost or governed-state summary
• Automations enabled
• Last published by/date
• Validation status
• Actions: open, duplicate, deactivate, archive and export configuration

Filters include class, owner, status, Workspace type, Provider category and presence of Draft changes.

9.2 Create Pipeline flow

1. Choose Blank or Starter Template.
2. Choose supported record class.
3. Enter name, description and short identifier.
4. Select primary audience and Workspace scope.
5. Choose a stage preset.
6. Create Draft.
7. Configure and preview.
8. Validate and publish.

Record class and ownership cannot change after first publication. Duplicate creates a new definition and identifiers.

10. Builder Architecture

10.1 Builder header

• Back to Pipelines
• Pipeline name and class
• Ownership badge
• Draft/published status and version
• Validation summary
• Preview record
• Test automation
• Compare changes
• Publish changes
• More actions

10.2 Builder sections

1. Overview
2. Stages & transitions
3. Fields & forms
4. Record layout
5. Views & grid
6. Tasks & service levels
7. Automations
8. Outcomes & conversion
9. Access
10. Analytics
11. Version history

Each section must have one of three honest states: available and enforced, disabled with a Coming soon label, or unavailable because the Pipeline class does not support it. Empty placeholder copy is not a release state.

The live section names map to the target architecture as follows:

10.3 Builder readiness and publication gate

The header readiness state is computed from validation; it is not manually editable. It must show blocking errors, warnings and informational recommendations separately.

Publication is blocked when any of the following is true:

• An active non-terminal stage has no valid outgoing transition or documented resolution path.
• A terminal stage is mapped to open.
• A transition references a retired field, form, task, approval, template or outcome.
• A required form or transition cannot be completed by any authorized audience.
• A communication action references an unpublished or unavailable Notification Builder template.
• An outcome lacks a valid, idempotent conversion or resolution mapping.
• Duplicate stage keys, field keys, IDs or invalid probabilities exist.
• The configured record form cannot render or validate server-side.
• Access configuration would expose a protected record or sensitive field outside its allowed scope.
• A version migration is required but has not been previewed and approved.

Warnings may include an optional SLA, task template or description being absent. A version with warnings may publish only when it has no blockers and the publisher acknowledges the warnings.

10.4 Autosave and collaboration

Draft edits autosave. Optimistic concurrency prevents silent overwrites. If two administrators edit the same section, the later save must reconcile against the current revision and show conflicting changes.

Published content is read-only.

11. Overview Configuration

Fields:

• Internal name
• Workspace-facing name
• Description
• Record class
• Pipeline code / ID prefix
• Ownership
• Workspace and market scope
• Default language and time zone
• Default currency, where financial values exist
• Default record owner rule
• Default Team
• Default SLA
• Active/inactive state
• Website/plugin entry point
• Record title and subtitle formula
• Duplicate-detection profile
• Retention/archive policy

Title formulas use approved tokens only. They cannot execute code.

12. Stage Builder

12.1 Stage fields

name
internal_key
description
display_order
colour_token
reporting_state_key
system_state_key, governed pipelines only
default_owner_rule
default_team_rule
sla_duration
entry_form_id
exit_form_id
visibility
is_closed
is_terminal
is_success

12.2 Colours

Administrators choose from an accessible approved palette or enter an allowed brand colour where contrast rules pass. Colour is always accompanied by a label. System error, risk and success tokens remain protected where semantic consistency matters.

12.3 Ordering and paths

Stages can be reordered visually without rewriting transition history. The builder supports linear and branched paths. Every active non-terminal stage must have at least one valid next step or a documented manual resolution path.

12.4 Reporting categories for Workspace CRM

Every custom CRM stage maps to one category:

open
won
lost
archived

This enables comparable reporting while preserving custom language.

Stage probability is configured independently from reporting category. It is stored as a decimal from 0 to 1, displayed as 0–100%, included in version comparison and used by weighted-value reporting. Terminal Won/Success stages default to 100%; Lost, Declined, Archived and cancelled terminal stages default to 0%. Governed Pipelines may protect these values.

12.5 Protected system states

Registry applications retain protected system mappings defined by Spec 05. Display stages may vary by Provider category, but approval, conditional approval, decline, withdrawal, duplicate/merge and provisioning prerequisites cannot be bypassed.

13. Transition Builder and Stage Gates

13.1 Transition fields

from_stage_id
to_stage_id
action_label
description
confirmation_message
condition_group
required_field_rules
required_document_rules
required_task_rules
required_review_rules
required_approval_policy
permission_capability
override_policy
automation_set_id

13.2 Requirements

A transition may require:

• Canonical or custom fields
• A field meeting a validation rule rather than merely being non-empty
• Documents by type and validity
• Tasks completed or approved
• Notes or reason
• Review checklist completion
• Approval from a role or named authority
• Date/time condition
• Active Entity relationship
• Duplicate review
• Matchmaking/readiness threshold
• A commercial record in the correct state

13.3 Transition experience

When a user selects a next step, the system evaluates requirements server-side. If information is missing, a focused transition panel shows:

• Required items grouped by section
• Completed requirements
• Missing or invalid values
• Fields the user can complete now
• Items requiring another person
• Request-information action
• Override action, only when permitted
• Resulting automations and visible consequences

13.4 Overrides

Overrides require a dedicated capability, a reason and audit. Governed outcomes may prohibit override entirely. An override does not manufacture missing legal acceptance, payment or approval evidence.

13.5 Concurrency

A transition command includes expected record version and stage. If another action has moved the record, the command fails safely and returns the current state for reconciliation.

14. Dynamic Field Library

14.1 Canonical fields

Canonical fields are shared across the platform and use stable keys. Examples:

• Person and business names
• Email and phone
• Address and Project site
• Lead source and campaign
• Owner, Team and collaborators
• Estimated value, currency and probability
• Desired start date and timeline
• Project type, service needs and budget range
• Related Client, Contact, Provider or Project
• Outcome and loss reason

Canonical fields cannot be duplicated under a different key merely to change the label. The customer can configure display labels while preserving semantics.

14.2 Custom field types

• Short text
• Long text
• Rich text, restricted formatting
• Email
• Phone
• Address lookup with normalized components
• URL
• Integer and decimal number
• Currency with minor-unit storage and currency code
• Percentage
• Date, time and date range
• Single select
• Multi-select
• Yes/no
• Checkbox group
• File/document upload
• Image gallery
• User, Team, Entity, Project and record reference
• Repeating group, within defined limits
• Signature/declaration acknowledgement for approved use cases

14.3 Standardization rules

• Dropdown options sort alphabetically unless meaningful order is configured.
• Options use stable IDs separate from labels.
• Address lookup supports manual correction and normalized city, region, postal/ZIP and country.
• Currency displays symbols and thousands separators.
• Numbers define precision, minimum, maximum and unit.
• Dates use the shared accessible picker and explicit time zone where relevant.
• Phone values are normalized while retaining safe display formatting.
• Empty, zero and not-applicable remain distinct.

14.4 Field lifecycle

After publication, a field key and type cannot be repurposed. Labels and help text may change through a new version. Removing a field retires it from new entry but preserves historical values. Option merging requires an explicit data migration.

14.5 Sensitive-field classification

Every field maps to a Spec 08 field group. Custom fields default to Workspace Internal until an authorized administrator selects a more appropriate classification. Fields containing contact, financial, banking, tax, verification or private matching information require compatible classifications and permissions.

15. Dynamic Form Builder

15.1 Form types

• Public lead capture
• Internal create/edit
• Stage entry
• Stage exit/transition
• Request information
• Application
• Internal review
• Verification
• Outcome/decision
• Conversion handoff

15.2 Builder capabilities

Administrators can:

• Add and order sections
• Add canonical and custom fields
• Set labels, help text and placeholders
• Configure layout width and grouping
• Set default values from approved sources
• Configure required and validation rules
• Configure applicant, external and internal visibility
• Add conditional show/hide, require and validation logic
• Preview desktop and mobile
• Test conditions using sample values
• Publish immutable versions

15.3 Conditional logic

Conditions use a guided rule builder:

IF all/any conditions are true
  field / context / stage / Workspace type / Provider category
  operator
  approved comparison value
THEN
  show / hide / require / make optional / validate / set allowed default

Arbitrary JavaScript, SQL and regular expressions from customers are prohibited. Complex validation may use platform-approved operators.

15.4 Public form behavior

• Responsive and accessible
• Workspace branding
• Spam and abuse protection
• Rate limiting
• Consent and privacy language
• Save and return when authentication is appropriate
• Clear error summary and inline errors
• Duplicate suggestions without exposing existing private records
• Source, campaign, referring URL and plugin attribution
• Submission confirmation and next-step expectation

15.5 Submission snapshots

Public applications and consequential forms create an immutable submission snapshot containing definition version, field/option IDs, displayed labels, normalized values, consent/declaration version and timestamp. Later corrections create amendments.

16. Record Layout Builder

The builder configures shared record-detail components rather than custom pages.

16.1 Header

• Record title and subtitle
• Stage chip and reporting state
• Record ID
• Owner/Team
• Source and created date
• Estimated value/probability where applicable
• Primary next step
• Governed outcome actions

16.2 Tabs

Available shared tabs:

• Workflow
• Overview
• Activity
• Notes
• Files
• Tasks
• Communication
• Matchmaking
• Proposals/Commercial
• History

Record class and permissions determine availability. Applications continue to place Workflow first. General CRM records may default to Overview first while maintaining a visible workflow rail/header.

16.3 Overview cards

Administrators assemble cards from field groups, completeness, next steps, related Entities, related opportunities, matching snapshot and conversion status. Audience visibility and field permissions apply server-side.

17. Enterprise Data Grid and Board Views

17.1 Shared capabilities

• Search
• Saved views
• Filters and filter groups
• Sort and multi-sort
• Column chooser and ordering
• Column pinning where useful
• Grouping
• Board/Kanban by stage
• List/grid view
• Bulk actions
• Export, permission controlled
• Row selection
• Pagination or virtualized loading
• View sharing inside Workspace

17.2 Default views

Every Pipeline includes:

• All active
• My records
• Team records
• New/unassigned
• Stale or SLA at risk
• Won/success
• Lost/declined
• Recently updated

Governed pipelines add workflow-specific queues.

17.3 Board movement

Dragging a card invokes the same transition command and validation as the record page. The card cannot directly update stage_id. If requirements are missing, the transition panel opens.

The table stage action, record header next-step action and board drag all call the same server-side transition evaluator. A record can never be movable from one surface and blocked from another because the interfaces use different stage lists or validation logic.

17.4 Bulk movement

Bulk transition evaluates every record independently, previews allowed/blocked records and requires confirmation. Consequential governed outcomes cannot be bulk-applied unless explicitly supported.

18. General Designer and Provider CRM

18.1 General Lead creation

Records may originate from:

• Manual creation
• Workspace website lead form/plugin
• CSV or spreadsheet import
• Google Sheets import
• Registry referral or shared opportunity
• Approved integration/webhook
• Duplicate/clone action
• Email or communication capture in a later release

18.2 Required core behavior

• Link or create Contact and organization
• Detect likely duplicates
• Capture source and attribution
• Assign owner and Team
• Add tasks, meetings, notes, files and communication
• Track value, probability and expected decision date
• Move through custom stages
• Convert without losing history
• Report by source, owner, stage, age, outcome and value

18.3 Provider-owned customers

Providers may use CRM and commercial tools for business originating outside the Registry. These records remain private to the Provider Workspace. A Provider can create Proposals, Work Orders and invoices for its own customers where supported, while Registry marketplace economics apply only to Registry-attributed relationships.

18.4 Website plugin

Each Workspace can publish an approved lead form using an embed or hosted link. The plugin carries Pipeline/Form version, Workspace, source and consent configuration. A Workspace cannot embed Registry-governed application forms unless granted the appropriate published entry point.

19. Registry-Governed Applications and Opportunities

19.1 Application reuse

Spec 05 remains authoritative for Provider application content, system states, verification, decisions and provisioning. This specification supplies the underlying generic engine.

19.2 Protected behavior

• System-state mappings
• Approval authority
• Provisioning prerequisites
• Duplicate/merge semantics
• Verification-sensitive fields
• Category qualification
• Match eligibility
• Applicant visibility boundaries

19.3 Project Opportunities

Registry-generated leads use a governed Project Opportunity Pipeline. Qualification captures budget, geography, scope, timing, style, services and consent before matchmaking. Source attribution, commercial obligation and resulting Project links are durable.

When a Designer accepts and converts an opportunity:

1. Resolve/create Client and Contact Entities.
2. Create or link Designer Workspace opportunity when useful.
3. Create Project from selected Project Template.
4. Carry approved fields, files, notes, tasks and communication links.
5. Preserve Registry source and commercial attribution.
6. Record conversion and resulting IDs.

20. Entity Relationship Lifecycles

Application approval and active relationship management are different lifecycles.

Examples:

• Provider: Onboarding → Active → Paused → Review Required → Suspended → Offboarded
• Designer: Onboarding → Active → Capacity Limited → Paused → Review Required → Offboarded
• Client: Prospective → Active → Past Client → Re-engagement

Each Entity relationship type may designate one primary lifecycle Pipeline Record. Opportunity pipelines do not overwrite it.

Lifecycle Stages may affect Matchmaking readiness through governed rules, but a Workspace-created sales Stage cannot suspend a Provider or alter platform qualification.

21. Project Portfolio Projection

21.1 Purpose

Projects may appear in a Pipeline-style portfolio board for summary reporting and attention. This is a projection, not a second Project workflow.

21.2 Automatic movement

Projection stages are derived from:

• Canonical Project phase
• Phase state
• Gate completion
• Project health
• Completion/cancellation
• Configured Project Template mappings

Manual drag is disabled by default. An authorized Project phase command changes Project truth; the projection then updates.

21.3 No duplicate automation

Project phase automations belong to Project Builder/Project events. The Project projection may subscribe for reporting or notification but must not independently recreate phase tasks or Provider Work Packages.

22. Task Templates and Service Levels

22.1 Stage task rules

Stages and transitions may create task templates with:

• Title and description
• Type and priority
• Owner/Team rule
• Collaborators
• Due date relative to entry, field date or SLA
• Dependencies
• Required completion state
• Visibility
• Escalation
• Automation source

22.2 Service levels

SLA clocks support:

• Time in stage
• Time to first contact
• Response due
• Review due
• Applicant action due
• Offer or proposal follow-up

Business calendars and time zones are explicit. Pausing requires configured reasons. SLA breach is an event, not a silent colour change.

23. Automation Engine

23.1 Model

Trigger
  → Conditions
    → Delay or schedule
      → One or more actions
        → Execution result, retry and audit

23.2 Triggers

• Record created, submitted, updated or archived
• Stage entered or exited
• Transition completed or overridden
• Outcome selected
• Field changed from/to a value
• Owner or Team changed
• Task created, completed or overdue
• Document uploaded or approved
• SLA warning or breach
• Date/time reached
• Form submitted or amendment received
• Approval requested/completed/declined
• Proposal sent/accepted/expired
• Payment or integration event received
• Project conversion/provisioning completed or failed

23.3 Conditions

Conditions may reference:

• Pipeline, class, stage and reporting/system state
• Canonical/custom fields
• Source and campaign
• Owner/Team
• Workspace type and Provider category
• Linked Entity and relationship status
• Task/document/approval state
• Date and duration
• Permission-safe Project summary
• Prior automation result

Conditions use approved operators and typed values. The builder detects unreachable rules, circular stage movement and obvious duplicate actions.

23.4 Actions

• Create or assign task
• Add collaborators
• Send in-app notification/message
• Send Resend email
• Send Twilio SMS
• Create calling task/workflow
• Create calendar event
• Update allowed field
• Move stage through a named transition
• Request information or approval
• Create related Pipeline Record
• Resolve/create Entity through governed conversion
• Create Project from template
• Generate approved document
• Start Workspace provisioning
• Call approved integration webhook
• Escalate exception

23.5 Delays and schedules

Actions may run immediately, after a duration, at a field-relative time or on a business schedule. Scheduled jobs store the intended local time, time zone and computed UTC execution time. Editing an automation version does not silently rewrite already scheduled executions unless an explicit migration is approved.

23.6 Safety

• Draft test mode with sample record
• Clear execution preview
• Idempotency key per event, automation version and action
• Maximum action and recursion limits
• Rate limits by Workspace/channel
• Retry policy with backoff
• Dead-letter/failed execution queue
• Manual retry with reason
• Cancellation for pending actions
• Consequential actions require human authority
• Complete execution trace

23.7 Human approval

AI-generated or materially consequential external communication, commercial commitment, Project creation, provisioning, approval, rejection and payment action require configured human authority. Automation may prepare the action and task without silently completing it.

24. Communication Automation

24.1 Ownership boundary

Pipeline Builder determines when, under what conditions and to whom a communication is requested. Notification Builder determines the approved template, channel content, variables, sender identity, branding, fallback and version.

24.2 In-app

In-app actions may create a notification, shared thread message or internal alert depending on audience and event registration. Internal notes are never sent as external messages.

24.3 Email through Resend

• Verified sender/domain rules
• Workspace branding where permitted
• Template version and variables
• Delivery, bounce, complaint and suppression events
• Thread/record correlation
• No sensitive data in subject lines

24.4 SMS through Twilio

• Explicit consent and channel eligibility
• E.164-normalized phone
• Quiet hours and jurisdiction-aware policy
• Required opt-out language where applicable
• Delivery/failure status
• Fallback or task on failure

24.5 Calling

Initial calling automation creates a call task with recipient, approved script/context, owner, due time and outcome capture. Future live calling may replace the action implementation while retaining the same event and activity model.

25. Outcomes and Conversion Engine

25.1 Workspace CRM outcomes

• Won
• Lost
• Not a Fit
• Duplicate/Merged
• Converted to Client
• Converted to Project
• Converted to Proposal
• Referred
• Archived

25.2 Conversion mapping

The builder maps source fields to target canonical fields and permits reviewed defaults. Custom fields without a target remain accessible on the source Pipeline Record and may be copied into a structured Project intake snapshot.

25.3 Duplicate resolution

Before Entity creation, the engine searches permitted records using normalized email, phone, business name, address and other approved identifiers. The user may link an existing Entity, merge under permission, create separate with reason or send to reconciliation.

25.4 Transactionality

A conversion command is idempotent. It either creates/links the complete required result and outcome history or records a recoverable failure. Retrying does not create a second Client, Project or Workspace.

25.5 History preservation

Conversion does not delete the source record. It closes it with outcome, target links, mapping summary, attribution and conversion timestamp. Notes, files, tasks and communications remain historically attributable and are linked/copied only according to visibility rules.

26. Versioning and Migration

26.1 Version rules

• Published versions are immutable.
• Draft changes do not affect active records.
• New records use the latest active published version.
• Historical display can reconstruct original stage, form and option labels.
• Retired versions remain available for audit.

26.2 Active record strategy

26.3 Migration plan

A migration defines:

• Source and target version
• Stage mapping
• Transition/history preservation
• Field/option mapping
• Automation and pending-job treatment
• Records excluded
• Validation preview
• Affected counts and blockers
• Rollback strategy where possible

Migration runs asynchronously in batches with progress, reconciliation report and audit.

26.4 Deleting stages

A stage used by any record or history cannot be physically deleted. It may be retired in a new version and mapped during migration.

27. Permissions and Sensitive Information

Spec 08 is authoritative. This specification adds capability definitions:

pipelines.view
pipelines.create
pipelines.edit_draft
pipelines.publish
pipelines.retire
pipelines.records.view
pipelines.records.create
pipelines.records.edit
pipelines.records.assign
pipelines.records.transition
pipelines.records.override_transition
pipelines.records.archive
pipelines.records.export
pipelines.forms.manage
pipelines.views.manage
pipelines.automations.view
pipelines.automations.manage
pipelines.automations.test
pipelines.automations.retry
pipelines.outcomes.execute
pipelines.migrations.manage

Record scopes include own, assigned, Team, Workspace, Market and governed relationship. Field-level permissions independently control contact and financial information.

Public forms accept data through narrow authenticated/signed entry points and never grant read access to Pipeline Records.

28. Analytics and Reporting

28.1 Standard metrics

• Records created
• Open records
• Stage distribution
• Stage entry and exit counts
• Conversion/win rate
• Loss reasons
• Time to first action
• Time in stage
• Cycle time
• SLA attainment
• Value and weighted value
• Source/campaign performance
• Owner/Team workload
• Automation success/failure
• Form completion and abandonment for permitted public forms

28.2 Version-aware reporting

Reports use stable stage/system/reporting keys and retain version context. Renaming a stage does not rewrite historical results. Cross-Pipeline reporting compares reporting categories, not customer display names.

28.3 Attribution

Registry-originated opportunities preserve source, campaign, market, selected Designer, agreement, fee obligation, attribution period, Client and resulting Project. Workspace-owned leads preserve the Workspace’s private source data.

28.4 Privacy

Analytics aggregate only authorized records and fields. A dashboard total must not reveal hidden records through counts or filters.

29. Import, Export and Integrations

29.1 Spreadsheet and Google Sheets import

The import flow supports:

1. Upload/select source.
2. Choose Pipeline and published version.
3. Detect headers and data types.
4. Map columns to canonical/custom fields.
5. Map stage and select option values.
6. Normalize dates, numbers, currency, phone and address values.
7. Detect duplicates and invalid rows.
8. Preview creates/updates/skips.
9. Import idempotently.
10. Produce reconciliation report.

Imports cannot bypass transition, field visibility or Workspace boundaries. An authorized import mode may create records directly in mapped stages while recording import provenance and validation exceptions.

29.2 Export

Export respects record scope, field visibility and selected columns. Sensitive exports create audit events. Hidden fields are omitted server-side.

29.3 Webhooks and integrations

Approved inbound integrations use signed requests, idempotency and a narrow mapping profile. Outbound webhooks are asynchronous, signed, retried and visible in execution history. Integration payloads are filtered through permissions and field classification.

30. AI Assistance

30.1 Builder assistance

AI may:

• Suggest starter stages from a plain-language process
• Recommend required fields and tasks
• Detect dead ends, duplicate stages and contradictory rules
• Draft form help text
• Explain an automation in plain language
• Generate test scenarios

Suggestions remain Draft until reviewed.

30.2 Record assistance

• Summarize activity and next steps
• Extract structured lead data from approved text/documents
• Suggest duplicate matches
• Suggest stage or task, with explanation
• Draft follow-up communication
• Identify stale records or missing qualification data

AI does not silently change governed stages, approve applications, reject people, provision Workspaces, create commitments or send consequential messages.

30.3 Access-aware context

AI receives only fields and records visible to the requesting user. Hidden data is omitted before model invocation. Prompt/model version, source, output, approval and final action are auditable for consequential workflows.

31. Notification Builder Events

Each event is registered with variable schema, recipients, allowed channels, protected meaning and default template.

pipeline.record_created
pipeline.record_assigned
pipeline.stage_changed
pipeline.transition_blocked
pipeline.transition_overridden
pipeline.sla_warning
pipeline.sla_breached
pipeline.information_requested
pipeline.information_received
pipeline.outcome_selected
pipeline.record_converted
pipeline.conversion_failed
pipeline.automation_failed
pipeline.automation_retry_required
pipeline.migration_started
pipeline.migration_completed
pipeline.migration_failed
pipeline.definition_published
pipeline.definition_retired

Workspace administrators may edit optional operational templates. Security, approval, provisioning, financial and legally necessary meaning remains protected.

32. Activity, History and Audit

32.1 Record Activity

Activity includes:

• Creation and source
• Stage changes and transition actor
• Field changes according to visibility
• Owner/Team changes
• Tasks, notes, files, meetings and communications
• Automation results
• Requests and approvals
• Outcome and conversion

32.2 Definition audit

• Draft created/edited
• Version validated/published/retired
• Stage, field, rule, form, view, automation and outcome differences
• Publisher and authentication context
• Migration decisions
• Failed publication validation

32.3 Automation trace

Every execution contains event ID, automation/version, evaluated conditions, action attempts, idempotency key, provider response IDs where appropriate, retry count, final state and correlation ID.

33. Data Model

33.1 Definition tables

pipeline_definitions
pipeline_versions
pipeline_stage_definitions
pipeline_transition_definitions
pipeline_transition_requirements
pipeline_outcome_definitions
pipeline_view_definitions
pipeline_metric_definitions

form_definitions
form_versions
form_sections
field_definitions
field_options
form_field_placements
form_conditional_rules

automation_definitions
automation_versions
automation_triggers
automation_condition_groups
automation_actions
automation_schedules

33.2 Runtime tables

pipeline_records
pipeline_record_entity_links
pipeline_record_values
pipeline_record_participants
pipeline_record_stage_history
pipeline_transition_attempts
pipeline_record_outcomes
pipeline_record_conversions
form_submissions
form_submission_values
form_submission_amendments
automation_events
automation_executions
automation_action_executions
scheduled_automation_jobs
automation_dead_letters
pipeline_migrations
pipeline_migration_items

33.3 Canonical versus custom values

Frequently queried canonical fields remain typed columns or normalized relations. Custom values use typed value storage keyed by stable field definition, with separate text, numeric, boolean, date/time, JSON and reference representations and constraints ensuring one compatible value type.

Consequential form submissions also store immutable display/normalized snapshots for historical reconstruction.

33.4 Constraints

• Every tenant row includes workspace_id or protected platform ownership.
• Every Pipeline Record references one Pipeline Version and one valid stage in that version.
• Stage changes occur only through transition commands.
• Published versions are immutable.
• Internal keys are unique within their version and never silently reused.
• Entity links identify relationship type and primary link.
• Conversions have unique idempotency keys.
• Scheduled jobs reference immutable automation versions.
• Audit and history cannot be deleted by Workspace users.

33.5 Indexes

Indexes cover:

• Workspace, Pipeline, current stage and archive state
• Workspace, owner/Team and updated date
• Pipeline Version and reporting/system state
• Stage age/SLA deadlines
• Entity links
• Typed custom values designated filterable/searchable
• Scheduled automation status and run time
• Execution event and idempotency key
• Conversion source and target IDs

Custom field indexing is opt-in through field configuration and bounded to prevent unmanageable index growth.

34. Supabase Architecture

34.1 Row Level Security

RLS is enabled on all exposed Pipeline, Form, Automation and runtime tables. Policies require an active Membership and matching Workspace or governed access relationship. Authentication alone is never sufficient authorization.

Public form submission uses a narrow server endpoint/Edge Function or carefully constrained insert path; it does not allow selecting Pipeline Records or definitions beyond the published public form contract.

34.2 Data API exposure

Table exposure is explicit. New tables are granted to Data API roles only when required, with RLS already enabled. Internal automation, audit and scheduling tables remain in non-exposed schemas or have access revoked from public client roles.

34.3 Transactional event outbox

Business mutations write their state change and a durable automation event/outbox record in one database transaction. External email, SMS, webhook and AI work occurs asynchronously after commit.

34.4 Workers and schedules

• Short-lived Edge Functions process integrations and communication.
• Durable queue jobs process automation executions and retries.
• Cron schedules due-time scans, SLA events and recovery checks.
• Long-running migrations run in bounded batches with checkpoints.
• Workers claim jobs safely so concurrent workers do not duplicate actions.

34.5 Realtime

Realtime updates board/grid counts and record activity for authorized subscribers. Payloads are minimal and field-permission safe. Clients refetch protected data through RLS after significant changes.

34.6 Storage

Files link to the Pipeline Record and visibility class. Upload, replacement and retrieval require correct Storage and metadata permissions. Signed URLs are short-lived and generated after record authorization.

34.7 Security functions

Prefer security-invoker functions. Any necessary security-definer helper lives in a non-exposed schema, validates the caller, fixes search path, receives minimum privileges and has execution revoked from PUBLIC before explicit grants.

35. API Design

35.1 Definitions

35.2 Records and transitions

35.3 Forms and automations

Mutation endpoints use idempotency keys, expected-version checks and audit correlation IDs.

36. User Stories

36.1 Designer Owner

• I can use a starter lead pipeline immediately.
• I can create a custom referral pipeline without contacting support.
• I can require budget, Project type and contact details before qualification.
• I can automate a follow-up task and branded email.
• I can convert a won opportunity into a Client and Project without re-entering information.

36.2 Provider Owner

• I can create a quote-request pipeline for business outside the Registry.
• I can assign Estimators and restrict financial/contact visibility.
• I can send follow-ups and create Proposals from qualified opportunities.
• My private CRM is not visible to competing Providers or Designers.

36.3 Workspace Member

• I see records assigned to me or my Team according to permissions.
• I understand what information is required before moving a stage.
• I can see which tasks and messages were created by automation.

36.4 Registry Administrator

• I can configure each Provider Application workflow with category-specific stages and forms.
• I can protect approval and provisioning states.
• I can compare versions and migrate only appropriate active records.
• I can monitor failed automations across authorized markets.

36.5 Client or applicant

• I receive a polished, accessible form with relevant questions only.
• I can save and return where enabled.
• I receive clear confirmation and information requests without seeing internal review details.

37. Acceptance Criteria

37.0 Existing-product correction release

• Project Opportunities has one canonical six-stage published version across create, edit, board, table, profile, filters, reporting and conversion.
• Legacy Lead stage values are mapped through an approved migration and no longer appear as active options.
• Record IDs, stage labels, stage age and timestamps reconcile across every surface.
• Project Opportunity screens, exports, notifications and APIs expose PO-*; LD-* exists only as a hidden migration alias and redirect lookup.
• New canonical record links no longer use /admin/leads/*; old links redirect safely without duplicating or changing the record.
• Converted to project and Closed are terminal and are not counted as open records.
• Every active non-terminal stage has at least one named next step or an explicitly configured resolution path.
• The builder cannot display “Ready to publish” while blocking validation exists.
• Record details, Views, Automations, Outcomes, Access and Version history are implemented or visibly disabled as Coming soon.
• Weighted-value probability is visible, configurable and versioned.
• The 43-field Project Opportunity form is generated from the published form/field definition rather than a separate legacy schema.
• Board, table and record profile invoke the same transition service and return the same requirement result.
• Visible action and overflow controls have working, permission-aware behavior.
• Operational and Settings directories explain Pipeline class and scope consistently.
• Legacy Proper Gallery, generic Lead and /leads naming plus (saved) option-label artifacts are removed from the active Project Opportunity experience.

37.1 General CRM

• Designer and Provider Owners can create and publish private General Lead pipelines.
• Starter pipelines are available during provisioning.
• A Workspace can create multiple pipelines for the same supported record class.
• One Entity can link to multiple opportunity records.
• General CRM stages map to Open, Won, Lost or Archived reporting categories.
• Records convert to Clients/Projects/commercial records idempotently with attribution preserved.

37.2 Builder

• Stages can be added, renamed, ordered and assigned accessible colours.
• Transitions define allowed paths and server-enforced requirements.
• Draft validation identifies dead ends, missing terminal paths, invalid fields, unsafe actions and unregistered notification templates.
• Published versions cannot be edited in place.
• Preview works for record, form, transition and automation experiences.

37.3 Forms

• Standard address, currency, number, date, phone and dropdown components are reused.
• Dropdown option IDs remain stable and alphabetical sorting is default where appropriate.
• Conditional rules execute consistently client- and server-side.
• Public submissions create immutable snapshots and do not expose private records.
• Custom fields have stable keys, types, classifications and retirement behavior.

37.4 Automation

• In-app, email and SMS actions reference Notification Builder templates.
• Calling automation creates a governed calling task/workflow.
• Every execution is versioned, idempotent and traceable.
• Retries do not duplicate successful actions.
• Failed executions appear in an authorized queue with safe retry/cancel actions.
• Cycle, recursion and rate limits prevent runaway automation.

37.5 Projects and governed workflows

• Project portfolio movement is derived from Project operational truth.
• Pipeline changes cannot accept Proposals, create payments or bypass Project gates.
• Application pipelines preserve Spec 05 fixed system states and provisioning rules.
• Registry and Workspace records maintain explicit ownership/access boundaries.

37.6 Permissions and security

• Pipeline capabilities integrate with Spec 08 Access Roles and record scopes.
• Contact and financial fields respect field-level visibility in grids, forms, exports, AI and APIs.
• RLS denies cross-Workspace access.
• Public forms are rate-limited and cannot read records.
• Sensitive exports, overrides, publication and migrations are audited.

38. Migration from Existing Pipeline Builder

38.1 Inventory

Before migration, inventory:

• Existing Project Opportunity Pipeline
• Designer Application Pipeline
• Current Pipeline Builder definitions and stages
• Stored records and stage values
• Forms and fields
• Tasks and automation placeholders
• Views and grid columns
• Entity/Project conversions
• Prototype/local-only data
• Legacy Lead stage enums and any records still using them
• Cross-surface Pipeline Record ID, stage and age mismatches
• Stage category, terminal flag and probability configuration
• Builder sections that are currently placeholders
• Existing Notification templates and any hard-coded communication copy

38.2 Mapping

• Existing Designer Applications become Registry-governed Application Pipeline Version 1.
• Existing Project Opportunities become Registry-governed Project Opportunity Pipeline Version 1.
• Existing display stages receive stable internal and system/reporting mappings.
• Existing fields map to canonical field definitions where possible.
• Unmapped values enter reconciliation rather than being discarded.
• Existing records receive version and stage-history seed events.
• The published Project Opportunities stage set becomes canonical; legacy form stages map through an explicit reconciliation table with exception handling.
• Converted to project maps to terminal success and Closed maps to the appropriate terminal outcome instead of open.
• Existing display IDs such as LD-* and PO-* are reconciled into one canonical visible PO-* identifier. LD-* survives only in a restricted alias table used for redirect resolution, import reconciliation and audit.
• Existing weighted values are recalculated only after stage probabilities are approved and the impact preview is accepted.

38.3 Correction sequence for the live builder

1. Freeze new legacy stage values and inventory affected records.
2. Establish the canonical published Project Opportunities Version 1 definition.
3. Add reporting category, terminal flags, probability and named transitions to all stages.
4. Reconcile IDs, stage values and timestamps with a dry-run report; create hidden alias mappings and canonical redirects for old LD-* links.
5. Connect create/edit forms to the published form definition.
6. Route board, table and record actions through the transition service.
7. Implement or honestly disable every builder section.
8. Validate conversion idempotency and terminal-state metrics.
9. Run shadow comparison for record queries and weighted metrics.
10. Publish the corrected version and retain aliases/history for audit.

38.4 General CRM rollout

New Designer and Provider Workspaces receive starter Pipeline clones. Existing Workspaces receive a preview and explicit activation so navigation and records are not unexpectedly changed.

38.5 Shadow execution

New transition and automation evaluation runs in shadow for existing governed workflows. Differences are logged and resolved before authoritative enforcement.

38.6 No silent expansion

Migration does not broaden access, send communications, move stages, create Projects or trigger provisioning. First publication/migration can suppress automations until a reviewed activation point.

39. Implementation Phases

Phase 1 — Shared definitions and runtime

• Pipeline, version, stage, transition and record schema
• Capability registry additions
• RLS and Workspace boundaries
• Transition command service
• Stage history and audit
• Existing pipeline inventory/mapping

Phase 2 — General CRM and grid

• Designer/Provider General Lead starters
• Pipeline directory
• Grid, saved views and board
• Record creation/detail
• Entity links and duplicate detection
• Basic reporting

Phase 3 — Builder and Dynamic Forms

• Draft/publish lifecycle
• Stage and transition builder
• Shared field library
• Form Builder and public form entry point
• Record layout/view builder
• Validation and previews

Phase 4 — Automations and communications

• Durable events/outbox
• Automation Builder and workers
• Tasks, assignment and stage actions
• Resend, Twilio and in-app integration
• Scheduled jobs, retries and failure queue
• Notification Builder registration

Phase 5 — Outcomes and conversions

• Client/Contact resolution
• Project conversion
• Proposal/commercial entry points
• Attribution and duplicate reconciliation
• Entity relationship lifecycles

Phase 6 — Governed applications

• Port Designer Applications
• Port Provider Application categories
• Protected states, reviews and provisioning
• Website signup/application continuity
• Matchmaking/readiness integration

Phase 7 — Project projection and advanced governance

• Project portfolio projection
• Version migration tooling
• Advanced analytics and SLA
• Access-aware AI assistance
• Load, security and failure testing

40. Testing Strategy

40.1 Definition tests

• Stage/path validation
• Terminal and reporting mappings
• Field key/type immutability
• Conditional form rules
• Transition requirements
• Outcome side-effect eligibility
• Automation cycle detection

40.2 Runtime tests

• Concurrent transition attempts
• Duplicate event delivery
• Retry after partial external failure
• Scheduled action cancellation
• Conversion retry/idempotency
• Record-version conflicts
• Migration interruption and resume

40.3 Security tests

• Cross-Workspace record enumeration
• Unauthorized definition access
• Public form read attempts
• Field-level contact/financial leaks through grid, export, Realtime and AI
• Service-role worker authorization
• Signed webhook replay
• File URL access after revocation

40.4 Scale tests

• Large Pipelines and stage boards
• Many custom fields and filters
• High-volume public submissions
• Automation bursts
• Scheduled SLA scans
• Bulk import and migration batches

40.5 Release gates

Every shipped Pipeline class requires passing positive/negative RLS tests, transition tests, version reconstruction, automation idempotency, notification-template validation, accessibility review and rendered/mobile UI review.

41. Definition of Done

This specification is complete when:

1. Designers and Providers can build private general lead pipelines.
2. Registry applications and Project Opportunities use the same engine with protected governance.
3. Stages, colours, paths, required fields, tasks, approvals and outcomes are configurable.
4. The Dynamic Form Builder standardizes every field and preserves immutable submissions.
5. The Enterprise Data Grid, board and record experience reuse shared modules.
6. In-app, Resend, Twilio and calling-task automations are configurable, safe and observable.
7. Notification Builder owns communication templates and Pipeline Builder owns workflow timing/conditions.
8. Opportunities convert to Entities, Clients, Projects and commercial records without duplicate creation or lost history.
9. Projects remain operational truth and portfolio pipelines update automatically.
10. Access is enforced through Spec 08 capabilities, record scopes, field visibility and Supabase RLS.
11. Published versions, migrations, executions and overrides are fully auditable.
12. Existing Designer Application and Project Opportunity records migrate without silent stage movement or automation.

The final platform position is simple:

Every Designer and Provider receives a flexible CRM. The Registry operates governed network workflows with the same engine. Projects take over when opportunity becomes delivery.

Live-product correction contract — August 4, 2026

The current Pipeline Builder is a partial implementation and must not be treated as complete until it supports the full governed lifecycle below:

• stable Pipeline and Stage identifiers independent of editable labels;
• Stage colours plus protected semantic/reporting mappings;
• required fields, documents, approvals, tasks and conditions for every transition;
• versioned record forms and shared standardized field controls;
• Domain Event automations for in-app, email, SMS and calling without embedding provider logic in the builder;
• recipient, consent, timing, retry, idempotency and failure behavior;
• outcomes and Entity-creation/provisioning mappings;
• draft validation, preview, test records, version comparison, publish, retirement and migration preview;
• governed Pipelines for Applications, Project Opportunities, Clients and Projects plus Workspace-created general Pipelines for Designers and Providers; and
• automatic Project Pipeline movement driven by canonical Project facts, with explainable manual exception handling.

Legacy Lead, LD-* and /admin/leads values are migration aliases only. New user-facing labels and identifiers must use Project Opportunity or Pipeline Record. Builder labels must never reintroduce the retired business model.

Shared-component correction contract

The Pipeline and Forms engine also owns the governance contracts consumed by the current shared components:

• Enterprise data grid: one permission-scoped query must power rows, metrics, filters, selection, bulk actions and exports. Add saved views, URL state, accessible keyboard behavior, server-side pagination and per-record bulk failure results.
• Dynamic forms: every field requires a stable key, type, version, validation, privacy classification, normalization and mapping contract. Labels and layout may change without changing stored meaning.
• Record tabs: use one module registry to decide which shared modules are available by record type, Workspace type, participant, permission and release state. Disabled modules must be labelled Coming soon or omitted.
• Status registry: Stage, State, Priority, Access and evidence values require stable semantic keys reused by builders, forms, pills, grids, filters, exports and reports. Colour is never the only signal.
• Dialogs: shared dialogs must enforce explicit Create/Edit/View/Confirm modes, loaded target identity, optimistic concurrency, focus management and unsaved-change protection.
• Accessibility: custom colours, grids, forms, dialogs and statuses must pass keyboard, screen-reader, focus, contrast, zoom and responsive tests before reuse is considered complete.

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

Current-product review gap closure register

Generated: August 4, 2026
Owning future specification: 09
Mapped current-product profiles: 7
Recorded review gaps: 44

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 — Pipeline directory

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

Review gaps

• Critical: New opportunity uses legacy stages that do not match the published workflow.
• The workflow directory and operational selector expose different notions of available Pipelines without explaining the scope difference.
• The first data request failed once before successful retry.
• Search, filtering and cross-Pipeline reporting are not visible on the directory surface.
• The selected Workspace and form fields still use legacy Proper Gallery naming.
• New opportunity submission, validation and duplicate detection were not tested.

Required future closure

• Support governed Registry Pipelines and Workspace-created general CRM Pipelines through one directory.
• Expose Pipeline type, owner, version and health consistently.
• Replace visible legacy Lead IDs, labels and routes with canonical Pipeline Record identity; keep LD aliases only for redirects and audit.
• Add resilient loading, filters and saved views without fragmenting the shared engine.
• Preserve historical records against the version under which they were created.

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 — Pipeline board and grid

Current-product profile: pipeline-board-and-grid
Observed route: /admin/pipelines
Evidence confidence: Verified

Review gaps

• Critical: board/table and record profile disagree on identifier, stage label and age for the same record.
• The builder classifies Converted and Closed as open, weakening terminal-state meaning.
• No stage movement control—drag, menu or keyboard—was observed.
• No general filtering or search exists in Table mode.
• Column preference persistence and export contents were not tested.
• Row selection exposes no verified bulk action.
• No large-volume pagination or virtualization behavior was tested.

Required future closure

• Use the shared enterprise grid for Table mode.
• Expose the canonical PO identifier consistently and remove LD identity from active views.
• Provide accessible stage changes independent of drag-and-drop.
• Show blocked-transition reasons before mutation.
• Support saved filters, ownership views and overdue/attention signals.
• Retain version-aware stage history when definitions change.

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 — Pipeline record profile

Current-product profile: pipeline-record-profile
Observed route: /admin/leads/:id
Evidence confidence: Verified

Review gaps

• Critical: profile and Pipeline directory disagree on the record ID, stage label and age.
• Record URLs do not encode the selected tab, so refresh and direct-link behavior are limited.
• Actions toggles active styling without a visible menu; overflow behavior is unverified.
• Convert to Project is always visible, while readiness and required-field feedback were not observed.
• The record still contains legacy Proper Gallery commission terminology.
• Permission-based tab and field redaction were not validated.
• Proposals and History have no module yet, although their disabled state is now accurate.

Required future closure

• Make the profile shell entity- and Pipeline-configurable.
• Use the canonical PO identifier and Pipeline Record route; retain old Lead URLs only as safe redirects.
• Give every enabled tab a routable deep link and correct empty/loading/error state.
• Replace legacy business terminology with Workspace-configured labels.
• Use one conversion framework for entity creation and Project creation outcomes.

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 — Record Overview

Current-product profile: record-overview
Observed route: /admin/leads/:id
Evidence confidence: Verified

Review gaps

• Zero Project Snapshot values do not distinguish unset from calculated zero.
• Legacy Proper Gallery commission language remains.
• Matching completeness counts presence, but quality/recency rules are not visible.
• No duplicate Client warning is shown on the summary.
• Field-level access variants were not verified.

Required future closure

• Drive overview cards from Pipeline/entity profile configuration.
• Distinguish missing, not applicable and calculated zero.
• Expose readiness blockers for matching and conversion.
• Reuse the same standardized summary modules for Admin, Designer, Provider and Client with permission-aware content.

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 — Pipeline record creation and editing

Current-product profile: pipeline-record-create-and-edit
Observed route: /admin/pipelines
Evidence confidence: Verified

Review gaps

• Critical: the form stage list conflicts with the published Pipeline.
• The title and submit action still say lead rather than Pipeline Record or opportunity.
• The 43 active fields appear CRM-configured rather than versioned in the current Pipeline Builder; Record details is still a placeholder.
• No Client duplicate detection or link-to-existing flow is visible.
• Saved labels such as Full-service (saved) and $250–300K (saved) leak configuration state into user-facing options.
• Proper Gallery commission language remains.
• Required validation, server errors, partial failure, retry and idempotency were not tested.
• Conditional fields, per-stage visibility and permission-based field redaction are not evidenced.

Required future closure

• Replace the legacy Lead modal with the shared Dynamic Form renderer bound to a Pipeline version.
• Separate record creation requirements from later transition requirements.
• Resolve or create durable Client entities without duplicate contacts.
• Support Admin, Designer and Provider general-lead Pipelines through the same form engine.
• Record field provenance, original source and AI/import confidence when fields are populated automatically.

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 — Pipeline transitions and Project conversion

Current-product profile: pipeline-transition-and-conversion
Observed route: /admin/leads/:id
Evidence confidence: Partially verified

Review gaps

• Critical: three active stages have no configured next step.
• Critical: every stage is categorized open, including Converted and Closed.
• No general stage-change control was found.
• Readiness requirements and blocking fields are not visible.
• Outcomes configuration is a placeholder despite the directory claiming a Project outcome.
• Conversion confirmation, duplicate prevention, rollback and partial-failure behavior were not tested.
• Profile and board stage labels already disagree, so a transition may update only one projection.
• Automations, access, version history and record-detail builder sections remain placeholders.

Required future closure

• Complete the versioned transition graph and terminal categories before enabling free stage movement.
• Define per-transition required fields, role/capability, confirmation, automation and notification rules.
• Make Ready to convert a calculated, explainable readiness state.
• Implement Project conversion as a governed outcome service reused by other entity-creating Pipelines.
• Expose transition history in Activity and immutable History with human-readable reasons.

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 — Pipeline Builder

Current-product profile: pipeline-builder
Observed route: /admin/settings/pipelines
Evidence confidence: Partially verified

Review gaps

• Missing builder depth is recorded in Spec 09.
• Legacy Lead language remains.
• Migration preview and rollback are not evidenced.

Required future closure

• Complete Spec 09 rather than layering one-off builders.
• Add Clients, Projects and general Workspace Pipelines.
• Add transition gates, automation testing, version comparison and migration preview.

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 -->