The Design Registry

Matchmaking, Offers & Network Assignment Engine

Version: 1.1
Prepared: August 2026
Status: Engineering and product source of truth

1. Executive Summary

The Matchmaking, Offers and Network Assignment Engine is the network intelligence layer of The Design Registry. It connects qualified Clients with suitable Designer Studios and connects Projects with qualified Providers while protecting privacy, commercial confidentiality and human decision authority.

Matchmaking is not a public directory, a decorative percentage or an automated award mechanism. It is a governed decision-support system that:

• confirms who is eligible before anyone is ranked;
• evaluates structured compatibility using published, versioned criteria;
• identifies missing, stale or conflicting information;
• produces explainable ranked recommendations;
• lets authorized people build a controlled shortlist;
• coordinates introductions, availability requests and Offers through existing platform records;
• converts a selected relationship into explicit Project access and operational work; and
• learns from reviewable outcomes without silently penalizing participants.

The system supports two primary journeys:

1. Client-to-Designer Matchmaking — a Registry-generated Project Opportunity is matched to qualified Designer Studios. The Registry curates an introduction; the Designer may accept or decline the opportunity; the Client and authorized Registry users receive an intentionally limited experience.
2. Project-to-Provider Matchmaking — a Designer or Registry user matches a Project Provider Requirement or Work Package to qualified Providers. Selected candidates may receive an availability request or an Offer. An accepted and awarded commercial record can become a Provider Job and Project assignment.

The architecture follows the platform rule build once, reuse everywhere. One matching engine, criteria framework, service-area model, capacity model, shortlist experience and audit system are reused across Designer and Provider matching. Category-specific questions, eligibility policies, weights, views and outreach actions are configuration, not separate applications.

This specification does not redefine Provider applications, Project Opportunities, Offers, Proposals, Work Orders, Projects or Permissions. Specifications 05 through 09 remain authoritative for those records. This document defines how the platform determines suitable candidates and safely advances a recommendation into those existing workflows.

1.1 Current-product correction contract

The August 4, 2026 live-product review is the implementation baseline. The current interface contains useful Designer-matching, shortlist, offer-preparation and relationship-grid components, but it does not yet expose a safe, reproducible Match Run lifecycle.

The Current Product Library profiles remain authoritative evidence of observable behavior. This specification is authoritative for corrections and future-state implementation.

2. Product Outcomes

2.1 Client outcomes

• Receive a curated introduction to a Designer suited to the Project rather than an overwhelming directory.
• Avoid repeating information already provided during intake.
• Understand why a recommended Designer may be a strong fit without seeing confidential ranking data.
• Retain agency to accept an introduction, request another option or stop the process.
• Have personal information shared only when required and authorized.

2.2 Designer outcomes

• Receive opportunities that fit service area, budget, Project type, style, timing and capacity.
• See enough information to make an informed interest decision without unnecessary Client exposure.
• Decline unsuitable opportunities with structured, non-punitive reasons.
• Find qualified Providers from the Project context without manually rebuilding scope.
• Compare Providers using relevant evidence, capability, timing and experience.
• Use Designer-selected Providers outside the Registry when desired.

2.3 Provider outcomes

• Receive relevant, well-scoped opportunities instead of low-quality broadcasts.
• Control service area, category capabilities, lead time, capacity and commercial preferences.
• Understand the requested service and response deadline.
• Decline for a legitimate reason without hidden ranking punishment.
• Avoid disclosing private capacity, pricing or business information to competitors.
• Convert accepted opportunities into the same Proposals, Work Orders, Jobs, schedules and invoices used to operate the business.

2.4 Registry outcomes

• Maintain a high-quality, trusted and locally useful network.
• Make explainable and auditable recommendations.
• Measure local supply, demand, acceptance, responsiveness and completion quality.
• Avoid overusing a small number of Providers when other qualified candidates are suitable.
• Preserve source attribution and commercial obligations for Registry-originated opportunities.
• Operate matchmaking efficiently with exception-first review and AI assistance.

3. Goals and Success Measures

3.1 Goals

1. Create one configurable matching framework for Clients, Designers and every Provider category.
2. Separate eligibility, compatibility, ranking, human selection and commercial award.
3. Make every recommendation explainable from versioned inputs and rules.
4. Integrate matching directly into Project Opportunities, Projects and Work Packages.
5. Protect Client, Designer, Provider and Registry-confidential information.
6. Support local markets without hard-coding Ottawa, Toronto or a single geography model.
7. Let human operators override recommendations with reason and audit history.
8. Improve network decisions using governed outcome signals.

3.2 Success measures

• Percentage of eligible match runs producing at least three viable candidates.
• Median time from match-ready opportunity to approved shortlist.
• Designer opportunity interest/acceptance rate.
• Provider availability and Offer response rate.
• Shortlist-to-selection and Offer-to-award conversion.
• Percentage of matches with complete explanations and no unresolved hard conflict.
• Reassignment rate after selection.
• On-time response, completion and exception rates by relationship/category.
• Participant satisfaction after introduction or completed work.
• Distribution of opportunities among qualified participants, reviewed in context.
• Number of manual hours per completed match.

Targets are configured by market and category after baseline data exists. The product must not manufacture a single universal “good match” threshold without evidence.

3.3 Non-goals

• A consumer marketplace that exposes every Designer or Provider.
• Automatic awarding of work without authorized human action.
• Pay-to-win organic ranking.
• A black-box AI score used as the sole selection reason.
• Replacement of Provider approval, verification or qualification.
• Guaranteed availability, price or performance.
• A public review site.
• Independent duplicate Offer, Proposal or Work Order systems.
• Autonomous contract formation.

4. Product Principles

4.1 Eligibility before ranking

The engine first determines whether a candidate is permitted and able to be considered. A high style score cannot overcome an expired required credential, wrong Provider category, prohibited service area or suspended relationship.

4.2 Explain every recommendation

Authorized users can see the criteria version, input sources, eligibility result, category scores, missing data, freshness and any adjustment. Participants receive audience-safe explanations, not confidential internal scoring.

4.3 Human authority

Rules and AI organize evidence. Authorized people approve shortlists, initiate outreach, select participants and award work. Automation may only proceed within an explicitly configured, auditable policy.

4.4 Project context is canonical

Provider matching starts from structured Project scope, dates, items, categories, location and Work Package data. Matching does not create a competing copy of Project truth.

4.5 Privacy increases progressively

Candidates receive the minimum information needed at each step. Personal contact details, full address, internal budget, competing candidates and commercial margin remain protected unless a later relationship requires them.

4.6 A decline is data, not automatic punishment

Declines improve fit and capacity understanding. Legitimate reasons such as timing, geography or scope do not silently reduce a Provider or Designer’s standing. Repeated misrepresentation or unexplained non-response may trigger human review under a published policy.

4.7 Configuration, not category forks

The engine is shared. Provider-specific factors and questionnaires extend a common schema. The White-Glove workflow does not become a separate matching product from Storage or Photography.

4.8 Network quality over maximum broadcasting

The system should produce the smallest useful shortlist and limit unnecessary outreach. More recipients do not necessarily mean a better marketplace.

4.9 No hidden paid placement

Payment cannot secretly improve organic suitability ranking. Any future sponsored placement is visibly separate, cannot bypass eligibility and is never presented as an organic recommendation.

5. Scope and Specification Ownership

5.1 In scope

• Match Profiles and configurable matching questions
• Criteria Sets and versioning
• Eligibility policies and disqualifiers
• Service-area compatibility
• Availability and capacity signals
• Compatibility scoring and explanations
• Match Runs and candidate results
• Shortlist building and comparison
• Client-to-Designer introduction workflow
• Project-to-Provider discovery and outreach handoff
• Network assignments and access-grant handoff
• Feedback, quality signals and marketplace health
• Notifications, permissions, audit, APIs and data model

5.2 Authoritative ownership map

5.3 Conflict rule

The originating record remains canonical. A Match Run stores a versioned snapshot and source references for reproducibility, but never becomes the editable source of Project scope, application status, credentials, capacity commitments or commercial terms.

6. Core Concepts

6.1 Match Subject

The demand being matched. Initial subject types are:

• Registry Project Opportunity seeking a Designer Studio;
• Project Provider Requirement seeking a Provider;
• Work Package seeking one or more Provider responses; and
• controlled rematch of an existing assignment.

6.2 Candidate

A Designer Studio or Provider Entity that may be evaluated for a Match Subject. Users are not candidates independently of their Workspace or Entity.

6.3 Match Profile

Structured matching data for a Client/Project demand, Designer Studio or Provider Entity. A profile combines canonical fields, questionnaire answers, derived signals and freshness metadata.

6.4 Criterion

A stable, typed comparison rule such as service-area coverage, minimum budget, style alignment, required vehicle type or installation capability.

6.5 Criteria Set

A versioned collection of eligibility rules, scoring rules, weights, explanation templates and policy limits for one match type, market and optional category.

6.6 Eligibility Result

The deterministic result of mandatory gates: eligible, conditionally eligible, ineligible or insufficient data.

6.7 Match Run

An immutable evaluation event against a frozen subject snapshot, candidate cohort, Criteria Set version and data timestamp.

6.8 Match Result

One candidate’s eligibility, component scores, total normalized score, reasons, missing data, conflicts, freshness and review state within a Match Run.

6.9 Shortlist

A governed collection of candidates selected for review, introduction or outreach. A shortlist is not an assignment or award.

6.10 Outreach

The controlled action that asks a shortlisted participant to express interest, confirm availability or respond commercially. Provider commercial outreach creates or references an Offer under Spec 06.

6.11 Selection

An authorized decision identifying a preferred candidate for the next relationship step. Selection records rationale and source Match Result; it does not silently create a contract.

6.12 Network Assignment

The explicit Project relationship and scoped access created after the governing acceptance/award rule is satisfied. Assignment uses Spec 08 access recipes and Spec 07 Project/Provider Job records.

7. Match Types

7.1 Client-to-Designer

Subject: Registry Project Opportunity with Client and Project requirements.
Candidate: approved, active Designer Studio.
Result: curated Designer shortlist and introduction workflow.
Conversion: Designer interest plus Registry/Client decision may create the Project and Designer assignment while preserving attribution.

7.2 Project-to-Provider

Subject: Provider Requirement or Work Package linked to a Project.
Candidate: approved Provider qualified for the required category.
Result: shortlist for availability request, fixed Offer or RFP.
Conversion: award/acceptance creates the Provider Job, Work Order or other configured operational relationship.

7.3 Replacement match

A replacement Match Run references the prior assignment and a structured reason, such as capacity failure, declined Work Order, suspension, schedule conflict or scope change. The prior relationship is preserved; access is adjusted explicitly rather than overwritten.

7.4 Multi-provider requirement

A subject may need multiple Providers of the same or different categories. Required slots are explicit. Each slot has its own selection and assignment status so one award cannot accidentally satisfy all requirements.

8. Match Readiness

8.1 Readiness states

not_ready
→ needs_information
→ ready_for_match
→ matching
→ shortlist_review
→ outreach_active
→ selected / no_match / cancelled

Readiness is a projection of the subject and does not replace its Pipeline stage.

8.2 Client-to-Designer minimum readiness

• Client consent and valid contact channel
• Market/location or approved remote-service rule
• Project type and service need
• Budget band and minimum qualification
• Desired timeline
• Sufficient scope summary
• Required matchmaking questions for the active Criteria Set
• No unresolved duplicate or abuse flag

8.3 Project-to-Provider minimum readiness

• Active Project and Provider Requirement
• Required Provider category
• Permission-safe scope summary
• Service location or delivery geography
• Required date/date range or timing flexibility
• Relevant items, quantities, rooms or files when applicable
• Required credentials/capabilities
• Response mode and deadline
• Authorized owner

8.4 Readiness panel

The record shows completed, missing, stale and conflicting inputs. Each blocker links to the canonical field or task. Authorized users may save a Match Run draft, but publication/outreach is blocked when mandatory readiness is not met.

9. Match Profile Architecture

9.1 Profile layers

1. Canonical identity — Entity, Workspace, category, market and approval state.
2. Declared preferences — questionnaire answers, services, budget, style and working preferences.
3. Operational availability — capacity windows, lead time, active commitments and blackout periods.
4. Verified evidence — credentials, insurance, portfolio, references and qualification.
5. Derived signals — response history, completed work, exceptions and satisfaction where permitted.
6. Private Registry data — internal review and network risk signals.

9.2 Field provenance

Every input stores source record, field key, value type, captured/verified time, author/system, visibility classification and freshness rule. An explanation cannot claim a criterion was satisfied without identifying the data used.

9.3 Profile completeness

Completeness is evaluated against the active match type/category, not as a universal vanity percentage. Missing optional style answers should not make a Storage Provider appear operationally incomplete.

9.4 Freshness

Criteria define freshness windows. Examples:

• insurance: based on actual expiry date;
• capacity: configurable, such as confirmation within 30 days;
• service area: reconfirmed after profile changes or annually;
• portfolio: no strict operational expiry unless policy requires;
• availability response: valid only for the subject/date window stated.

Stale data produces a warning, conditional eligibility or hard block according to policy.

10. Matching Question Builder

10.1 Settings location

Settings
└── Matchmaking
    ├── Match Types
    ├── Questions & Profiles
    ├── Criteria Sets
    ├── Service Areas
    ├── Capacity Rules
    ├── Shortlist Policies
    ├── Outcome Reasons
    ├── Feedback & Quality
    ├── Test Lab
    └── Version History

10.2 Question definition

Questions reuse Spec 09’s Dynamic Field Library and include:

• stable key and label;
• audience and match type;
• answer source and form placements;
• Provider category/Project type applicability;
• required/optional status;
• field type and option set;
• Client-safe and candidate-safe help text;
• sensitivity classification;
• visibility after introduction/assignment;
• freshness and reconfirmation policy;
• criteria that consume the answer; and
• published version.

10.3 Reuse rules

The same stable question may appear in website intake, application, profile editing, Project Opportunity, Project Builder or Provider Requirement forms. Forms control placement; the Match Profile controls meaning. Historical answers retain their exact question/version snapshot.

10.4 Conditional questions

Examples:

• show high-rise access questions when property type is condominium;
• show vehicle/fleet capability for White-Glove Delivery;
• show usage-rights questions for Photography;
• show material/fabrication questions for Millwork;
• show dock, climate and oversized-item questions for Storage;
• show licensing jurisdiction for regulated trades.

Conditions are enforced client-side and server-side through Spec 09.

11. Criteria Set Builder

11.1 Criteria Set identity

Each Criteria Set declares:

• match type;
• applicable market(s);
• Provider category or Designer Project type, optional;
• currency/geography context;
• effective date;
• owner and approver;
• lifecycle state; and
• version lineage.

11.2 Lifecycle

draft → testing → approved → published → superseded → retired

Published versions are immutable. Editing creates a new Draft. Existing Match Runs retain the version used.

11.3 Criterion types

• Boolean requirement
• Set intersection/containment
• Numeric minimum/maximum/range
• Currency range compatibility
• Geographic containment/distance/travel rule
• Date-window overlap
• Capacity threshold
• Ordinal preference
• Weighted similarity
• Verified evidence requirement
• Historical signal band
• Human-review-only flag

11.4 Criterion configuration

Each criterion includes:

• stable key and name;
• purpose and rationale;
• subject and candidate inputs;
• eligibility or scoring classification;
• comparison operator;
• weight and maximum contribution;
• missing-data behavior;
• stale-data behavior;
• conflict severity;
• explanation templates by audience;
• sensitivity and display rules;
• test cases; and
• enabled state.

11.5 Weight rules

Weights apply only after eligibility. Scores are normalized to a configured scale, typically 0–100, but UI language should emphasize fit dimensions and evidence rather than false precision. Weight totals are validated, category overrides are explicit and one criterion cannot be counted twice through aliases.

11.6 Publication validation

Block publication when:

• a required field/option/category reference is missing;
• no eligible path can exist for the test cohort;
• an eligibility rule depends on an AI-only judgment;
• weights are invalid or create unbounded contribution;
• an explanation leaks restricted data;
• a freshness rule has no timestamp source;
• a criterion cannot be reproduced from stored inputs;
• test cases fail; or
• the permission/audience model is undefined.

12. Eligibility Engine

12.1 Eligibility order

1. Candidate relationship is active and permitted.
2. Candidate holds the required type/category qualification.
3. Market and service-area rules permit the work.
4. Required credentials are valid for the date/jurisdiction.
5. Candidate’s declared restrictions do not conflict with the subject.
6. Required capabilities and scope are supported.
7. Minimum/maximum commercial or Project thresholds are compatible.
8. Required date/capacity data is sufficient.
9. Conflict, suspension, duplicate or policy blocks are evaluated.

12.2 Results

• Eligible — all mandatory rules satisfied.
• Conditionally eligible — permitted only after named confirmation or evidence.
• Ineligible — one or more non-overridable rules failed.
• Insufficient data — required evaluation input is missing or stale.

12.3 Override policy

Criteria may be non-overridable, Registry-overridable or subject-owner-overridable. An override requires the capability defined in Spec 08, a reason and optional evidence. It changes the candidate’s review state for that Match Run; it does not rewrite the underlying credential or profile.

12.4 Candidate exclusions

Exclusions may be explicit and time-bound:

• do not match this Client and Designer;
• do not use this Provider for this Project/category;
• prior conflict or legal restriction;
• participant-requested exclusion;
• temporary market/category pause.

Sensitive reasons are masked outside authorized Registry views.

13. Service-Area Engine

13.1 Supported models

• Named markets
• Country/province/state/municipality/postal regions
• Radius from one or more operating locations
• Custom polygon
• Travel corridor or route-based region where supported
• Remote/virtual service
• Delivery-only region
• Category-specific service area

13.2 Candidate service-area profile

A Designer or Provider may define multiple service areas with category, distance/region, travel fee indicator, minimum job size, lead time, date range and approval status. Private operational notes are separate from public profile text.

13.3 Subject geography

The engine uses the minimum precise geography needed for evaluation. Pre-introduction matching may use market/postal area or approximate coordinates. Exact residential addresses remain protected until operational access is justified.

13.4 Result explanation

Examples:

• “Within primary service area.”
• “Outside primary area; candidate accepts travel for this Project size.”
• “Conditional: delivery postal code requires confirmation.”
• “Ineligible: category is not served in this jurisdiction.”

Distance alone never implies availability or price.

14. Availability and Capacity

14.1 Capacity sources

• Participant-declared capacity windows
• Category-specific lead time
• Workspace calendar and blackout periods
• Accepted Work Orders/Provider Jobs
• Active Projects and phase load
• Manual holds
• Availability-request responses
• Registry restrictions

14.2 Capacity units

Capacity may be represented by:

• new Projects per month/quarter;
• crew-days or appointment slots;
• square footage, pallet/bin volume or oversized capacity;
• delivery vehicles/crews;
• fabrication hours or production windows;
• shoot days;
• item/receiving volume; or
• simple available/limited/unavailable status for early implementation.

14.3 Confidence

Availability displays confidence based on source and recency: confirmed for this request, recently declared, inferred from commitments or unknown. Inference cannot be presented as a promise.

14.4 Reservation

Shortlisting does not reserve capacity. A configurable soft hold may be created only after the participant confirms availability. Award/Work Order acceptance converts the hold into a commitment; expiry releases it.

15. Compatibility Scoring

15.1 Scoring sequence

Eligible candidate cohort
→ Evaluate category dimensions
→ Normalize dimension scores
→ Apply published weights
→ Apply bounded policy adjustments
→ Calculate score and confidence
→ Generate explanations

15.2 Client-to-Designer dimensions

• Geography/service area
• Project type and service model
• Budget fit and minimum engagement
• Style/aesthetic alignment
• Rooms/property type
• Timeline and capacity
• Language/communication needs
• Desired working relationship
• Designer specialities
• Prior relationship or Client preference
• Verified experience and completion history, where appropriate

15.3 Project-to-Provider dimensions

• Category qualification
• Scope/capability fit
• Service area
• Required dates and capacity
• Item/material/handling characteristics
• Project type and scale experience
• Required insurance, licence or evidence
• Commercial compatibility
• Designer preference/prior relationship
• Response and completion history
• Exception/quality history in comparable work

15.4 Missing data

Missing data cannot silently become a zero or perfect score. Each criterion defines: exclude from denominator, neutral value, conditional eligibility, confirmation task or block. Result confidence decreases when important inputs are unavailable.

15.5 Bounded adjustments

Policy may apply transparent, bounded adjustments for objectives such as avoiding repeated over-concentration or prioritizing a confirmed response. Adjustments cannot overcome eligibility and must appear in authorized explanations. Commercial payment is never an organic adjustment.

15.6 Score display

Registry users may see total and component scores. Designers see useful fit evidence and warnings for Provider matching. Clients and candidates receive plain-language compatibility information, not internal ranking mechanics or competitor scores.

16. AI Assistance

16.1 Permitted uses

• Summarize Project and candidate fit from structured evidence.
• Extract candidate capabilities from approved application evidence for human confirmation.
• Suggest potential missing questions or criteria.
• Classify free-text decline/feedback into configured reasons with review.
• Detect contradictory profile answers.
• Generate comparison narratives using permission-safe inputs.
• Identify unusual outliers or possible duplicate Profiles.

16.2 Prohibited authority

AI may not:

• approve an application or credential;
• silently change a Criteria Set;
• create an undisclosed eligibility rule;
• award a Project or Work Package;
• infer protected personal attributes;
• use private data outside its permitted purpose;
• invent availability, price or experience; or
• produce the sole reason for an adverse marketplace decision.

16.3 AI evidence contract

Every AI-generated statement stores model/service identifier, prompt policy version, source references, timestamp, output and human review state where material. AI prose never replaces the deterministic criterion result.

17. Match Run Lifecycle

17.1 Creation

A user opens Matchmaking from a Project Opportunity, Project Provider Requirement or Work Package. The system validates readiness, selects the Criteria Set, resolves the initial candidate cohort and shows expected exclusions before running.

17.2 Execution states

draft → queued → running → completed
                    ↘ partially_completed / failed
completed → superseded

17.3 Immutable snapshot

A completed Match Run stores:

• subject type/ID and snapshot hash;
• Criteria Set/version;
• subject input snapshot;
• candidate cohort definition;
• candidate input snapshots/hashes;
• evaluation time;
• results, explanations and confidence;
• engine version;
• initiating user/system; and
• warnings/errors.

17.4 Refresh and rerun

When canonical information changes, the UI marks the run stale and explains why. Refresh creates a new Match Run linked to the prior one. It does not mutate prior rankings or remove decisions already made.

Subject selection is part of this integrity boundary. A completed run is rendered only when its subject_type, subject_id and snapshot hash match the active subject. Switching subjects never carries forward scores, shortlist membership or outreach actions. If a historical run is intentionally opened, the interface labels it historical/stale and prevents new outreach until refreshed.

17.5 Partial failure

One candidate evaluation failure does not invalidate all results. Failed candidates show an error state and retry path. A shortlist cannot be finalized if required cohort/evaluation integrity rules are not met.

18. Matchmaking Workspace and UI

18.1 Record header

• Subject name and type
• Project/Opportunity context
• Match type/category
• Readiness and freshness
• Market
• Run version/time
• Owner
• Actions: Edit requirements, Run/Refresh, Save shortlist, Start outreach

18.2 Tabs

1. Recommendations — ranked eligible/conditional candidates.
2. Compare — selected candidates across relevant dimensions.
3. Shortlist — governed candidates and next actions.
4. Outreach — introductions, availability requests and linked Offers.
5. Assignments — selected/awarded relationships and access.
6. History — runs, changes, overrides and decisions.

18.3 Candidate card

• Workspace name, category and approved profile identity
• Overall fit band/score where permitted
• Top matching reasons
• Warnings, missing data and conditional requirements
• Service-area result
• Availability confidence
• Relevant specialities/evidence
• Prior working relationship, if visible
• Profile link
• Add/remove shortlist action

18.4 Filters

• Eligible/conditional/insufficient/ineligible
• Market/service area
• Availability window
• Category/capability
• Budget/job-size fit
• Qualification/evidence
• Prior relationship
• Profile completeness/freshness

Filters refine review; they do not silently rewrite the Criteria Set or saved Match Run.

18.5 Empty/no-match state

The system distinguishes:

• no approved candidates in cohort;
• candidates exist but failed eligibility;
• insufficient subject information;
• candidate data is stale;
• required timing/capacity unavailable; and
• technical failure.

Suggested actions may include adjust flexible criteria, request updated availability, invite a new Provider to apply, use an external Provider or escalate to Registry operations.

19. Comparison Experience

19.1 Comparison rules

Users select up to a configured number of candidates. Rows are driven by the active Criteria Set and category. Internal comparison data is never shared with candidates.

19.2 Comparison groups

• Eligibility and qualifications
• Service area and location
• Scope/capabilities
• Timing and capacity
• Commercial compatibility
• Relevant experience/evidence
• Prior relationship/performance
• Risks, missing data and conditions

19.3 Evidence links

Each material value links to its permitted source: Profile field, approved application evidence, credential, response, Project history or calculated result. Stale/declared/verified distinctions are visible.

19.4 Decision note

An authorized user may record structured rationale and private notes. The decision note can reference criteria and exceptions but is not exposed to losing candidates unless converted into an approved audience-safe message.

20. Shortlist Governance

20.1 States

draft → internal_review → approved → outreach_active
→ selected / exhausted / cancelled

20.2 Shortlist policy

Policies may define:

• minimum/maximum candidate count;
• required approval by match type/value/risk;
• whether conditional candidates are allowed;
• whether selection may occur without outreach;
• candidate-contact limits;
• outreach sequencing; and
• expiry/review date.

Before any outreach action, the server verifies that the Shortlist belongs to the active completed Match Run, every selected candidate belongs to that Run, the Run is not stale or superseded, eligibility has not been invalidated and the disclosure snapshot matches the active subject. Client-side button state is not sufficient protection.

20.3 Add outside recommendation

An authorized user may add an eligible candidate not recommended in the top results or a Designer-selected external Provider. The system records source and rationale. External Providers may use a lightweight contact path until application/onboarding is required; their external status is prominent.

20.4 Remove from shortlist

Removal requires a configured reason, such as poor scope fit, Client request, conflict, timing or duplicate. Removal does not change the underlying Entity or future eligibility unless an authorized separate action does so.

21. Client-to-Designer Workflow

21.1 End-to-end flow

Registry Project Opportunity becomes match-ready
→ Run Client-to-Designer criteria
→ Registry reviews recommendations
→ Approve curated shortlist
→ Send interest request to one or more Designer Studios
→ Designer accepts interest / declines / requests clarification
→ Coordinate Client-safe introduction
→ Client/Registry selects path
→ Convert opportunity and assign Designer
→ Preserve source, agreement and fee attribution

21.2 Designer interest request

This is an Opportunity Invitation linked to the Project Opportunity, not a Provider commercial Offer. It includes permission-safe Project summary, approximate location, budget band, service type, desired timing, fit reasons, response deadline and permitted clarification channel.

21.3 Designer responses

• Interested
• Interested with conditions
• Request clarification
• Decline with reason
• Request deadline extension where permitted

Interest is not acceptance of a Client contract. It advances the Registry workflow.

21.4 Client presentation

The Client may see one recommended Designer or a small curated group depending on policy. Presentation includes approved public profile, relevant portfolio, fit narrative and next step. Internal scores, private availability, other candidates and commercial arrangements remain hidden.

21.5 Conversion

Conversion uses Spec 09 and Spec 07 to resolve/create Client Entities, create the Project from a template, link the Designer Workspace and preserve the Project Opportunity, Match Run, selection and Registry attribution. It is idempotent.

22. Project-to-Provider Workflow

22.1 Entry points

• Project Overview Provider requirement
• Phase workflow
• Work Package Builder
• Item/category grid
• Project Calendar need
• Provider assignments tab
• Project Template automation creating a draft requirement

22.2 Outreach modes

1. Availability request — confirm interest, timing, area and capacity before detailed commercial scope.
2. Fixed Offer — request acceptance of defined terms under Spec 06.
3. Request for Proposal — invite one or more independent Provider responses under Spec 06.
4. Direct assignment — authorized selection of a known Provider when no competitive outreach is required, followed by the required Work Order/commercial process.

22.3 Information release

Before outreach, a Provider sees only public/approved profile context. Outreach may expose the Work Package snapshot, approximate or operational location, required dates, item manifest and approved files according to Spec 08. Full Project access is not created merely by shortlisting.

22.4 Confidential sourcing

Each Provider’s outreach is independent. Providers cannot see the recipient count, competitor identity, competing response, ranking, internal comparison, Designer margin or award rationale.

22.5 Handoff to Spec 06

Starting fixed Offer or RFP creates the canonical Offer record and captures Match Run, Result, Shortlist and subject references. Offer lifecycle, Provider response, Proposal, award, Work Order and invoice behavior remain governed by Spec 06.

23. Selection, Award and Network Assignment

23.1 Selection states

proposed → approval_required / approved → selected
→ converted / withdrawn / superseded

23.2 Selection record

• Match Subject and slot
• Candidate Entity/Workspace
• Match Run/Result
• Shortlist
• Decision maker and authority
• Rationale and exceptions
• Conditions/expiry
• Client involvement where relevant
• Linked Opportunity Invitation or Offer
• Conversion/assignment IDs

23.3 Assignment prerequisites

Examples by configuration:

• Designer expressed interest;
• Client/Registry selection complete;
• Provider accepted Offer or was awarded Proposal;
• required agreement/Work Order exists;
• required credential remains valid;
• Project is active;
• access recipe resolves successfully.

23.4 Atomic assignment

Assignment creates or updates the Project participant/Provider Job, applies the correct access recipe, links commercial records, creates required tasks/calendar events and emits notifications in one idempotent command/outbox transaction. Failure cannot leave broad access without the relationship record.

23.5 Reassignment

Reassignment records reason, protects history, revokes or narrows prior access, handles open commercial records explicitly and starts a linked replacement match when needed. It never deletes prior evidence or authorship.

24. Category-Specific Provider Criteria

24.1 Vendors and Product Suppliers

• Product category/brand coverage
• Trade program and order minimums
• Shipping region
• Lead time/availability confidence
• Sample/memo capabilities
• Return/warranty support
• API/catalogue readiness
• Project item compatibility

24.2 Millwork and Custom Fabrication

• Fabrication category/material
• Project scale and complexity
• Shop/service area
• measurement/drawing/engineering capability
• finishing/sample process
• production window and installation capability
• credentials/insurance
• comparable portfolio

24.3 Contractors and Specialty Trades

• Trade and jurisdictional licence
• crew/supervision capacity
• Project type/scale
• service area
• schedule and sequencing
• safety/compliance evidence
• documentation/change-order process

24.4 Photography

• Interior/architecture/editorial speciality
• portfolio/style fit
• geography/travel
• crew/equipment
• desired shoot date
• deliverables/turnaround
• usage rights
• budget compatibility

24.5 Measurement and Drafting

• service/drawing type
• location/site access
• method and file format
• software compatibility
• turnaround/revision needs
• professional credentials
• sample deliverables

24.6 Receiving, Warehouse and Storage

• facility/service location
• receiving hours/appointment rules
• item count, volume, weight and oversized handling
• climate/security requirements
• dock/equipment
• expected receipt dates and duration
• condition-photo/inventory process
• delivery/pull capability
• insurance and available capacity

24.7 White-Glove Delivery

• pickup/delivery geography
• required date/window
• fleet/vehicle and crew
• item count, size, weight and handling
• assembly/stairs/elevator/site constraints
• route/tracking capability
• packaging removal
• proof-of-delivery and insurance

24.8 Installation Services

• installation category
• location/date window
• crew skill/capacity
• item/room readiness
• tools/equipment
• dependency and site constraints
• evidence/punch-list capability
• insurance/safety requirements

24.9 General Service Providers

Uses shared eligibility, service area, capacity, experience and commercial criteria plus administrator-configured category criteria.

25. Provider and Designer Control

25.1 Profile controls

Workspace Owners and authorized Members may update match-facing services, categories, service areas, minimum engagement, lead times, availability, capacity, preferences and temporary pauses. Protected qualifications require Registry approval.

25.2 Opportunity preferences

Participants may indicate preferred Project types, scope, geography, budget/job size, cadence and communication channel. Preferences influence suitable matching but cannot alter protected qualification.

25.3 Pause and blackout

A participant can pause new opportunities globally or by category/market until a date, while continuing active work. The system records pause reason privately and excludes or conditionally evaluates according to policy.

25.4 Data correction

Participants can report inaccurate information and see the source of editable Profile values. Disputed derived/private quality signals follow a Registry review workflow rather than direct editing.

26. Declines, Non-Response and Expiry

26.1 Structured reason library

• Outside service area
• Timing/capacity
• Scope/capability mismatch
• Budget/job size
• Conflict/prior relationship
• Insufficient information
• Commercial terms
• Client/Project preference
• Temporary pause
• Other with explanation

Reason libraries are configurable by match/outreach type and may map to suggested Profile updates.

26.2 Non-response

Reminder and expiry rules come from Spec 09 automation and Notification Builder templates. Non-response is recorded objectively. Repeated patterns may create a review flag, but do not autonomously suspend or permanently demote a participant.

26.3 Fairness safeguard

A decline aligned with current Profile constraints should improve future filtering. A decline contradicting Profile data prompts reconfirmation. Operators can distinguish inaccurate Profile data from participant reliability.

27. Feedback and Quality Signals

27.1 Feedback moments

• After Designer introduction
• After Provider outreach response
• After award/assignment
• At milestone or Work Order completion
• After Project phase/completion
• After reassignment or serious exception

27.2 Signal classes

• Match relevance
• Scope accuracy
• Schedule/capacity accuracy
• Communication/response
• Quality/evidence completion
• Commercial/process reliability
• Client/Designer/Provider satisfaction
• Exception and resolution

27.3 Signal governance

Signals store source, context, comparable category, sample size, recency and visibility. One disputed outcome does not become an unexplained universal score. Registry users can review and correct classification while preserving audit.

27.4 Model improvement

Outcome analysis may recommend Criteria Set changes. Changes enter Draft/testing and require approval. Historical results are never retroactively rewritten to pretend a new model made an old decision.

28. Marketplace Fairness and Network Health

28.1 Concentration monitoring

Analytics show opportunity distribution, shortlist frequency, response, awards and completion by category/market, adjusted for eligibility and availability. Concentration is a review signal, not proof of unfairness.

28.2 Cold-start participants

New approved participants should not be permanently disadvantaged for lacking platform history. Criteria Sets distinguish verified application evidence from platform history and cap historical-signal weight. Operators can include qualified new entrants with explicit rationale.

28.3 Small cohorts

The UI suppresses misleading benchmarks and sensitive aggregation when cohorts are too small. Marketplace health may show “insufficient data” rather than revealing participant performance.

28.4 Quality intervention

Serious or repeated concerns create a separate relationship review under Spec 05/entity lifecycle. Matchmaking cannot silently suspend qualification through scoring alone.

29. Permissions and Visibility

Spec 08 is authoritative. Representative capabilities include:

matchmaking.view
matchmaking.run
matchmaking.compare
matchmaking.shortlist_manage
matchmaking.override_eligibility
matchmaking.approve_shortlist
matchmaking.start_outreach
matchmaking.select
matchmaking.assign
matchmaking.criteria_view
matchmaking.criteria_manage
matchmaking.criteria_publish
matchmaking.analytics_view

29.1 Audience boundaries

Registry: permitted network-wide results, private signals and policy controls.
Designer: its Project subjects, Provider recommendations and permitted evidence.
Provider: its own Profile, outreach and audience-safe reasons; never competitor data.
Client: approved Designer presentation and actions; never internal rankings.

29.2 Sensitive fields

• Exact residential address is hidden until operational need.
• Client direct contact is released only through approved introduction/assignment.
• Provider private capacity and commercial preferences are restricted.
• Internal cost, margin, referral economics and negotiated Registry terms are never exposed through explanations.
• Competitor identity, rank and response are confidential.

29.3 Exports and AI

Exports and AI context are filtered through effective field permissions. A user who cannot view a field cannot obtain it through comparison export, explanation generation or AI summary.

30. Notifications and Automation

30.1 Notification Builder ownership

All participant-facing messages use editable templates from the Notification Builder in Spec 03. Matchmaking owns events and payload contracts, not message copy.

30.2 Required events

• match.subject_ready
• match.information_required
• match.run_completed
• match.run_failed
• match.shortlist_review_requested
• match.shortlist_approved
• designer.opportunity_invitation_received
• designer.opportunity_response_due
• designer.opportunity_accepted_interest
• designer.opportunity_declined
• provider.availability_request_received
• provider.availability_response_due
• match.clarification_requested
• match.candidate_selected
• match.no_suitable_candidate
• match.assignment_created
• match.assignment_failed
• match.profile_reconfirmation_required

Offer/Proposal/Work Order events remain owned by Spec 06.

30.3 Automation examples

• Create review task when a match-ready opportunity has no eligible candidate.
• Remind a Designer 24 hours before an interest-request deadline.
• Ask a Provider to reconfirm stale capacity before shortlist approval.
• Start an RFP only after shortlist approval and required Work Package fields.
• Notify the Project owner when a selected Provider’s credential expires before service date.
• Start a replacement Match Run after an authorized assignment failure event.

Every automation is idempotent, audited and permission-checked at execution time.

31. Search, Directory and Global Views

31.1 Registry Matchmaking queue

Global table columns include subject, type/category, market, readiness, owner, best eligible count, shortlist state, outreach state, SLA, freshness and next action.

31.2 Designer Provider discovery

Designers may browse approved Provider profiles within permitted marketplace rules, but Project-aware matchmaking is the preferred workflow. Browsing does not expose private capacity, ranking or Client-confidential data.

31.3 Provider opportunities

Provider navigation includes Opportunities/Offers scoped to its Workspace. It does not include a reverse directory of Clients or Projects.

31.4 Saved views

Users can save filters such as “Ottawa Storage requirements with no shortlist,” “Designer opportunities awaiting response” or “Selected Provider credentials expiring before service.” Saved views do not alter match policy.

32. Analytics and Reporting

32.1 Funnel

Match-ready subjects
→ eligible cohort
→ completed runs
→ shortlists
→ outreach
→ positive responses
→ selections
→ assignments/awards
→ completed work

32.2 Operational metrics

• Time in readiness/review/outreach
• Eligible candidates per subject
• No-match reasons
• Stale/missing Profile causes
• Response times and expiries
• Reassignment and cancellation
• Automation failures

32.3 Quality metrics

• Fit/relevance feedback
• Schedule/capacity accuracy
• Completion and exception outcomes
• Satisfaction
• Criteria prediction versus actual outcome

32.4 Network health

• Approved/active/available supply by market/category
• Demand by type/date/value band
• Coverage gaps
• Opportunity concentration
• New-participant exposure
• Capacity pressure

32.5 Attribution

Registry-originated Project Opportunities preserve source, campaign, studio location/referral, Match Run, selected Designer, resulting Project, agreement, fee obligation and collected amounts. Attribution is not inferred from the latest Pipeline stage.

33. Audit and Explainability

33.1 Audit events

• Criteria Set draft/test/publish/retire
• Match Profile material change
• Match Run start/complete/fail
• Eligibility override
• Candidate shortlist add/remove
• Shortlist approval
• Outreach start/withdraw/expiry
• Selection and rationale
• Assignment/reassignment
• Feedback correction
• Sensitive result access/export

33.2 Explanation object

Each result stores machine-readable explanation components:

• criterion key/version;
• outcome and contribution;
• subject/candidate source references;
• data freshness/confidence;
• audience classification;
• human-readable template version; and
• override/adjustment metadata.

33.3 Reproducibility

Given the stored snapshots, Criteria Set version and engine version, the system can reproduce the evaluation result. If a code defect prevents exact reproduction, the discrepancy becomes an incident and historical evidence remains intact.

34. Data Model

34.1 Configuration

match_types

• id, key, name
• subject_type, candidate_entity_type
• market_scope
• status

match_questions

• id, stable_key, field_definition_id
• audience, match_type_id, category_id
• sensitivity, freshness_policy
• status, current_version_id

criteria_sets

• id, match_type_id, market_id, category_id
• name, status, current_version_id
• owner_workspace_id, created_by

criteria_set_versions

• id, criteria_set_id, version_number
• definition_json, definition_hash
• engine_compatibility_version
• published_at, published_by

match_criteria

• id, criteria_set_version_id, stable_key
• criterion_type, eligibility_class
• subject_input_key, candidate_input_key
• operator, weight, max_contribution
• missing_policy, stale_policy, override_policy
• explanation_template_keys

34.2 Profiles and availability

match_profiles

• id, profile_type, entity_id, workspace_id
• market_id, category_id
• status, completeness, updated_at

match_profile_values

• id, match_profile_id, stable_key
• typed value columns/JSON
• source_type, source_id, source_version
• visibility_class, captured_at, verified_at
• fresh_until

service_areas

• id, entity_id, category_id, market_id
• area_type, normalized geometry/region reference
• travel_policy, minimum_job_minor, currency
• effective_from, effective_to, status

capacity_windows

• id, workspace_id, category_id
• start_at, end_at, capacity_type
• declared_capacity, committed_capacity, held_capacity
• confidence_source, confirmed_at, status

34.3 Execution

match_subjects

• id, match_type_id, subject_type, subject_id
• project_id, market_id, category_id
• readiness_state, owner_membership_id
• active_match_run_id

match_runs

• id, match_subject_id, criteria_set_version_id
• engine_version, status
• subject_snapshot_json, subject_snapshot_hash
• cohort_definition_json, candidate_count
• started_at, completed_at, initiated_by
• supersedes_match_run_id, error_summary

match_results

• id, match_run_id, candidate_entity_id, candidate_workspace_id
• eligibility_status, total_score, confidence
• dimension_scores_json, explanation_json
• missing_data_json, conflicts_json, adjustments_json
• candidate_snapshot_hash, review_state

eligibility_overrides

• id, match_result_id, criterion_key
• decision, reason, evidence_file_id
• created_by, created_at, expires_at

34.4 Shortlist and decisions

match_shortlists

• id, match_subject_id, match_run_id
• status, policy_version, owner_membership_id
• approved_by, approved_at, expires_at

match_shortlist_entries

• id, shortlist_id, match_result_id, candidate_entity_id
• position, state, source, rationale
• added_by, removed_by, removed_reason

match_selections

• id, match_subject_id, shortlist_entry_id
• slot_key, state, rationale
• selected_by, selected_at, expires_at
• outreach_type, outreach_record_id
• assignment_type, assignment_id

opportunity_invitations

• id, project_opportunity_id, designer_workspace_id
• match_selection_id, snapshot_json
• state, sent_at, viewed_at, response_due_at
• response, response_reason, responded_at

34.5 Feedback

match_feedback

• id, match_subject_id, match_result_id, assignment_id
• feedback_type, context_category
• rating/value, reason_code, comment
• visibility_class, submitted_by, submitted_at
• review_state, dispute_state

match_quality_signals

• id, candidate_entity_id, category_id, market_id
• signal_type, source_type, source_id
• value, confidence, occurred_at
• status, reviewed_by

34.6 Integrity rules

• Every completed Match Run references one published Criteria Set version.
• One Match Result exists per candidate per Match Run.
• A Shortlist Entry references the exact Match Result reviewed.
• Selection cannot reference an ineligible Result without a valid permitted override.
• Assignment cannot be created twice for the same selection/idempotency key.
• Commercial outreach references canonical Spec 06 records.
• Historical snapshots and explanations are immutable.
• Protected Profile data cannot be copied into lower-visibility explanation fields.

35. Supabase and Backend Architecture

35.1 Database and Row-Level Security

Matchmaking tables use workspace, Registry, Project and relationship context enforced with Row-Level Security. RLS is defense in depth; service methods still verify current capabilities and record state before commands.

Provider users can access only their own Match Profile, invitation/Offer and audience-safe response information. They cannot query other candidates or Shortlists. Client users cannot query internal Results. Designer users can access Provider recommendations only for Projects within their effective scope.

35.2 Match execution worker

Match Runs execute asynchronously through a controlled worker/Edge Function pattern:

1. Command validates readiness, access and published Criteria Set.
2. Transaction creates queued Match Run and immutable subject snapshot.
3. Outbox/queue schedules cohort resolution and evaluation.
4. Worker evaluates candidates in bounded batches.
5. Results are written idempotently.
6. Completion transaction sets summary/state and emits events.

The browser never receives service-role credentials or the unrestricted candidate cohort.

35.3 Geographic evaluation

Normalized geography and indexed geospatial data support service-area evaluation. Exact residential coordinates are stored and accessed according to sensitive-address policy; match snapshots may use reduced precision where sufficient.

35.4 Realtime

Realtime may update Run progress, shortlist collaboration and outreach status. Realtime payloads are permission-safe and non-authoritative; commands and reads re-evaluate current authorization.

35.5 Storage

Credential evidence, portfolios and Work Package files remain in their canonical secured Storage locations. Match Results reference approved files rather than duplicating binaries.

35.6 Idempotency and concurrency

• Match Run creation uses an idempotency key.
• A subject may have one active Run unless an authorized parallel scenario is explicit.
• Shortlist edits use optimistic concurrency/version numbers.
• Selection/assignment commands lock the relevant subject slot.
• Offer/Invitation creation prevents duplicate recipient outreach for the same campaign/version.

35.7 Observability

Record run duration, cohort size, exclusion counts, criterion errors, retry counts, stale-data frequency, worker version and assignment conversion failures. Sensitive values are excluded from general logs.

36. API Design

36.1 Commands

POST   /v1/match-subjects/:id/validate-readiness
POST   /v1/match-subjects/:id/runs
POST   /v1/match-runs/:id/retry
POST   /v1/match-results/:id/override
POST   /v1/match-subjects/:id/shortlists
POST   /v1/match-shortlists/:id/entries
DELETE /v1/match-shortlists/:id/entries/:entryId
POST   /v1/match-shortlists/:id/request-approval
POST   /v1/match-shortlists/:id/approve
POST   /v1/match-shortlists/:id/start-outreach
POST   /v1/opportunity-invitations/:id/respond
POST   /v1/match-subjects/:id/select
POST   /v1/match-selections/:id/convert-assignment
POST   /v1/match-assignments/:id/start-replacement
POST   /v1/match-feedback

36.2 Queries

GET /v1/match-subjects/:id
GET /v1/match-subjects/:id/readiness
GET /v1/match-runs/:id
GET /v1/match-runs/:id/results
GET /v1/match-results/:id/explanation
GET /v1/match-shortlists/:id
GET /v1/match-subjects/:id/outreach
GET /v1/match-subjects/:id/assignments
GET /v1/match-profiles/:entityId
GET /v1/matchmaking/queue
GET /v1/matchmaking/analytics

36.3 Administration

POST /v1/matchmaking/criteria-sets
POST /v1/matchmaking/criteria-sets/:id/versions
POST /v1/matchmaking/criteria-versions/:id/test
POST /v1/matchmaking/criteria-versions/:id/publish
POST /v1/matchmaking/criteria-versions/:id/retire
POST /v1/matchmaking/questions
POST /v1/matchmaking/test-lab/scenarios

36.4 Error contract

Errors use stable codes such as:

• MATCH_SUBJECT_NOT_READY
• CRITERIA_VERSION_NOT_PUBLISHED
• NO_ELIGIBLE_CANDIDATE
• MATCH_RUN_ALREADY_ACTIVE
• RESULT_STALE
• ELIGIBILITY_OVERRIDE_NOT_ALLOWED
• SHORTLIST_APPROVAL_REQUIRED
• OUTREACH_ALREADY_EXISTS
• SELECTION_CONFLICT
• ASSIGNMENT_PREREQUISITE_FAILED

Responses include audience-safe remediation and correlation ID without leaking other candidates.

37. User Stories

37.1 Registry operator

• As a Registry operator, I can see why a Designer is eligible and recommended for a Project Opportunity.
• I can build a curated shortlist without exposing Designers to one another.
• I can request missing information and rerun matching without losing the original result.
• I can override a permitted conditional rule with reason and evidence.
• I can see network coverage gaps by market and category.

37.2 Designer

• As a Designer, I receive opportunities that fit my declared business and capacity.
• I can decline an opportunity with a reason and update my Profile.
• From a Project, I can find Providers qualified for the actual Work Package.
• I can compare permitted evidence, availability and relevant experience.
• I can use my own Provider without losing Project operations.

37.3 Provider

• As a Provider, I control category, service area, minimum job size and availability.
• I receive a scoped request with enough information to decide whether to engage.
• I cannot see competitors, and they cannot see me.
• My accepted opportunity becomes operational work inside my Workspace.
• I can dispute incorrect Profile or quality information.

37.4 Client

• As a Client, I receive a calm curated Designer introduction.
• I do not need to understand an internal score.
• My personal address and contact information are not broadly broadcast.
• I can request another option or decline an introduction.

37.5 Workspace owner

• As a Workspace Owner, I can assign who may run matches, approve Shortlists or see sensitive fit information.
• I can review my Workspace’s opportunity outcomes and update matching preferences.

38. Acceptance Criteria

38.0 Existing-product correction release

• The no-subject state contains no seeded results, Shortlist or Offer action.
• Switching Project Opportunities cannot retain another subject’s criteria, scores, Shortlist or Offer preparation.
• Inline Compatible Designers or Compatible Providers and full Matchmaking identify and project the same completed Match Run.
• Every displayed score includes Criteria Set version, evaluated time and freshness/confidence context appropriate to the audience.
• Stale, superseded, partial or failed Runs cannot create Offers.
• Send-time validation rejects subject, snapshot, Run, Shortlist, candidate, eligibility or disclosure mismatches.
• Complete criteria opens the canonical opportunity fields and returns to the same Matchmaking context.
• Temporary criteria provide Apply, Reset and permission-controlled Save to Project Opportunity actions.
• Proper Gallery policy naming, legacy Lead language and /admin/leads links are removed from active Matchmaking.
• Disabled Provider categories are labeled Coming soon until functional.
• Offers and Assignments have dedicated canonical profiles; source Opportunity/Project links are secondary context.
• The Assignments directory separates type and status filters and supports lifecycle-appropriate actions.

38.1 Engine

• Eligibility is evaluated before scoring.
• Every completed Result references a published Criteria Set version and immutable snapshots.
• Missing/stale data follows configured policy and appears in explanations.
• The same inputs/version reproduce the same deterministic result.
• AI text cannot alter eligibility or numeric contribution.

38.2 Client-to-Designer

• Only approved active Designer Studios enter the cohort.
• Registry users can approve a curated Shortlist.
• Opportunity Invitations expose only permitted Project data.
• Designer responses preserve structured reasons and deadlines.
• Conversion preserves Match Run, selection, Project Opportunity and source attribution.

38.3 Project-to-Provider

• Matching starts from a Project Provider Requirement or Work Package.
• Category qualification, service area and required credentials are enforced.
• Shortlisting does not create Project access.
• Starting commercial outreach creates/references Spec 06 Offer records.
• Assignment occurs only after configured acceptance/award prerequisites.
• Provider access is scoped through Spec 08 recipes.

38.4 Privacy

• Providers cannot query candidates, rankings, recipient counts or competing responses.
• Clients cannot view internal scores or Registry notes.
• Exact addresses/contact details follow progressive disclosure.
• Exports, notifications and AI summaries respect field visibility.
• Sensitive access and exports are audited.

38.5 Builder

• Criteria Sets are versioned and published versions immutable.
• Publication validates references, tests, weights, explanations and permissions.
• Test Lab can run synthetic and historical shadow scenarios without sending outreach.
• Impact comparison shows cohort/result changes before publication.

38.6 Reliability

• Run, outreach and assignment commands are idempotent.
• Partial candidate failures are visible and retryable.
• Concurrent shortlist/selection edits cannot silently overwrite one another.
• Worker failures emit operational events without exposing sensitive data.

39. Migration from Existing Matchmaking

39.1 Inventory

Identify existing Project Opportunity matchmaking fields, Designer Profile answers, Provider application questions, scores, shortlist data, manual notes and assignment links. Classify each as canonical field, Profile value, historical Result, unsupported legacy value or data-quality issue.

The inventory must also include seeded or static candidate results, subject/result mismatches, divergent inline/full-workspace scores, Proper Gallery Criteria labels, legacy leadId links, Offer/Assignment rows without dedicated records and disabled Provider-category controls.

39.2 Stable field mapping

Map current Client/Project questions and Designer/Provider answers to stable keys in Spec 09. Normalize option IDs, currencies, addresses, categories and service areas without rewriting the original submission snapshot.

39.3 Baseline Criteria Sets

Create version 1 Client-to-Designer and Provider-category Criteria Sets that reproduce intended existing logic where valid. Document known deviations. Do not copy opaque legacy percentages without definable criteria.

39.4 Shadow evaluation

Run the new engine against existing eligible records without changing recommendations or outreach. Compare cohort, exclusions, ranking and explanations. Resolve material differences before activation.

39.5 Historical preservation

Legacy scores may be stored as historical artifacts labeled with source and non-reproducible status. Active shortlists are linked or recreated through a reviewed migration. Existing Offers, Proposals, assignments and Projects remain canonical.

39.6 Cutover

1. Freeze legacy matching configuration.
2. Complete profile mapping and readiness audits.
3. Publish baseline Criteria Sets.
4. Enable new Match Runs for internal Registry users.
5. Validate outreach handoff.
6. Enable Designer Project-to-Provider matching by category.
7. Retire legacy score writes after reconciliation.

Before cutover, remove every seeded Result from production paths. Reconcile visible Offers and Assignments into canonical records with stable IDs, source links and history. Legacy Matchmaking links may redirect to the canonical Pipeline Record, but new links and notifications must use the canonical route.

Rollback disables new Run initiation while preserving completed records; it never deletes decisions or assignments.

40. Implementation Phases

Phase 1 — Foundation

• Match types, Profiles and stable questions
• Criteria Set/version schema
• Service-area normalization
• Match Subject/readiness
• Basic deterministic eligibility/scoring
• Audit and capabilities

Phase 2 — Client-to-Designer MVP

• Project Opportunity integration
• Baseline criteria and explanations
• Registry recommendations, comparison and Shortlist
• Designer Opportunity Invitation/response
• Selection and Project conversion attribution

Phase 3 — Project-to-Provider MVP

• Provider Requirement/Work Package integration
• Initial Provider categories
• Availability requests
• Shortlist-to-Offer/RFP handoff
• Provider Job/assignment conversion

Phase 4 — Builder and Governance

• Full Criteria Set Builder
• Question/profile placement management
• Test Lab and impact comparison
• Publication approval/versioning
• Shortlist policy configuration

Phase 5 — Capacity, Feedback and Network Intelligence

• Category-specific capacity models
• Soft holds and commitment signals
• Feedback/dispute workflow
• Marketplace health and coverage analytics
• Fairness/concentration review

Phase 6 — AI Assistance

• Evidence-grounded summaries
• Contradiction/missing-data detection
• Feedback classification
• Criteria-change recommendations with human approval

41. Testing Strategy

41.1 Unit tests

• Every criterion operator and missing/stale policy
• Score normalization and weight validation
• Service-area boundary cases
• Date/capacity overlap
• Eligibility override rules
• Explanation audience filtering
• Idempotency keys and hashes

41.2 Integration tests

• Project Opportunity to Designer assignment
• Provider Requirement to Offer/Work Order/Provider Job
• Permission changes during Run/outreach
• Credential expiry between shortlist and award
• Project scope change and stale Run
• Notification event payloads
• Worker retry and partial failure

41.3 Security tests

• Cross-Workspace and cross-Project reads
• Provider competitor enumeration
• Client access to internal scores
• Export/AI sensitive-field bypass
• Exact-address disclosure
• Service-role/worker authorization
• Malicious criteria/explanation configuration

41.4 Scenario library

Synthetic scenarios include:

• no eligible candidate;
• one conditionally eligible candidate;
• dense urban service-area boundary;
• remote Project with travel exception;
• expired credential;
• stale capacity;
• equal scores with different confidence;
• new Provider with no platform history;
• previously preferred Provider unavailable;
• multiple Provider slots;
• replacement after award;
• external Designer-selected Provider.

41.5 User acceptance

Registry operators validate explanations and governance. Designers validate Project-context usefulness. Providers validate opportunity quality and confidentiality. Clients validate clarity and discretion. Testing includes desktop and mobile operational surfaces.

42. Definition of Done

The Matchmaking, Offers and Network Assignment Engine is complete for its approved release scope when:

• Client-to-Designer and enabled Project-to-Provider match types use versioned Criteria Sets;
• eligibility, scoring, explanations, Shortlists and selections are auditable;
• existing Project, Provider, commercial and permission records remain canonical;
• participant privacy and competitor confidentiality are enforced server-side;
• Shortlists advance through authorized outreach rather than hidden automation;
• accepted/awarded selections create scoped assignments idempotently;
• every participant-facing event is available in the Notification Builder;
• stale/missing data and no-match outcomes have actionable workflows;
• migration and shadow evaluation pass agreed reconciliation thresholds;
• security, reliability and user-acceptance tests pass; and
• operational dashboards expose failures, coverage gaps and marketplace health.

The finished product should feel curated to the Client, useful to the Designer, commercially relevant to the Provider and fully explainable to The Design Registry.

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

Current-product review gap closure register

Generated: August 4, 2026
Owning future specification: 10
Mapped current-product profiles: 4
Recorded review gaps: 24

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 — Matchmaking workspace

Current-product profile: matchmaking-workspace
Observed route: /admin/matchmaking
Evidence confidence: Verified

Review gaps

• Critical: active subject and visible result snapshot can disagree.
• The empty-selection state still shows seeded candidates and shortlist.
• Complete criteria produced no visible action during review.
• Temporary adjustments mention saving to the opportunity but expose no clear save action.
• Proper Gallery policy branding and legacy /admin/leads links remain.
• Loading, run failure, no-match, partial evaluation and stale-data states are not represented.
• Provider matching is not available on this workspace.

Required future closure

• Bind every result and shortlist to an immutable subject/run identity from Spec 10.
• Replace legacy Lead links and Proper Gallery policy language.
• Implement readiness, stale-run, running, failure, no-match and superseded states.
• Add governed Provider matching from Project Requirements and Work Packages.
• Prevent offer creation whenever subject, run, shortlist or disclosure snapshot is inconsistent.

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 — Compatible partners (current label)

Current-product profile: compatible-partners
Observed route: /admin/leads/:id?tab=matchmaking
Evidence confidence: Verified

Review gaps

• The generic Compatible partners label conflicts with the governed Designer/Provider vocabulary.
• Scores conflict with the full workspace for the same visible subject and Match Candidates.
• No Match Run ID, Criteria Set version, timestamp or freshness is shown.
• Provider Categories are unexplained disabled controls.
• Service-area exceptions are less detailed than earlier evidence.
• Empty, error, stale and insufficient-data states were not observed.

Required future closure

• Replace Compatible partners with category-specific Match Candidate labels.
• Render a compact projection of the latest valid Match Run.
• Show score confidence, run freshness and top reasons consistently.
• Mark unavailable Provider Categories Coming soon until Project-based Matchmaking exists.
• Use canonical Pipeline Record links instead of leadId routes.

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 — Full matching run

Current-product profile: full-matching-run
Observed route: /admin/matchmaking
Evidence confidence: Verified

Review gaps

• No immutable run identity or lifecycle is visible.
• No compare, run history, override, exclusion or candidate-error experience exists.
• Seeded results can outlive their subject selection.
• Offer creation is reachable from inconsistent state.
• Actual execution and send were not tested.

Required future closure

• Implement the Match Run lifecycle and workspace tabs from Spec 10.
• Add comparison, history, freshness, failure and partial-result handling.
• Require send-time subject/run/shortlist integrity validation.
• Preserve outreach and assignment linkage back to the source run.

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

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

Review gaps

• No dedicated Offer or Assignment profile is available from the grid.
• The filter mixes record type and status in one control.
• No response, accept, decline, withdraw, expire, cancel, reassign or close actions are exposed.
• No Provider-category relationships are present.
• Bulk-selection outcome and export contents were not tested.
• Legacy Lead routes remain.

Required future closure

• Add dedicated Offer and Assignment profiles with their own histories and actions.
• Separate record-type, status, category, Project, owner and date filters.
• Link accepted Offers to Proposal/Work Order and atomic Project assignment creation.
• Support Designer and all Provider-category participation from one grid.
• Remove legacy Lead links in favor of canonical source and relationship routes.

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