Reverse spec drafted

Designer Studios directory

Network list and profile entry point for independent Designer Studios.

Observed route/admin/designer-networkFuture Spec 05 →

Current maturityFunctional Designer Studio network directory with legacy labels

Evidence confidenceVerified

Last reviewedAugust 4, 2026

Visual evidenceDeferred during UI updates

Current-state summary

The live Designer Studios directory contains two approved, active Studio Entities and correctly separates applications through a Pipeline link. It provides four network metrics, status and market filters, twenty sort choices, export, columns and detailed matching/capacity columns. The page eyebrow incorrectly says Provider directory, the route and profile back link use Designer Network, and seeded records remain tied to legacy brokerage-style Assignment language.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

Element	Current behavior	Verification
Header and search	Search studios, markets, specialties; heading Designer Studios; eyebrow incorrectly says Provider directory.	Verified live
Application handoff	Open applications pipeline links to the Designer Applications Pipeline.	Verified live
Metrics	Directory Studios 2, Active Studios 2, Onboarding 0 and Credential Actions 0.	Verified live
Filters	Network Status and market filters; only Toronto appears as a market option.	Verified live
Enterprise grid	Studio, ID, Primary Market, Network Status, Specialties, Project Types, Budget Bands, Capacity, Profile, Last Activity and Actions.	Verified live
Studio records	Atelier Maison DS-00001 and Studio North DS-00002 open dedicated profiles.	Verified live

User journeys

Current flows

Find a Designer Studio

Search or filter Studios
Review status, services, budget bands, capacity and Profile Completeness
Open the Designer Studio Profile

Review applicants

Select Open applications pipeline
Open Designer Applications
Review and approve through the governed workflow

State model

Current and expected states

Active

Both Studios are Active and available to Matchmaking policies.

Onboarding

Metric and filter exist; no row.

Paused, Suspended, Offboarding or Inactive

Filter options exist; no rows.

Credential action

Metric exists at zero.

Empty/error

Not observed.

Product rules

Non-negotiable boundaries

Designer Studio is a distinct Entity type from Provider.
Applications remain Pipeline Records; approved Studios appear only after provisioning.
Network Status, Profile Completeness, capacity and Matchmaking eligibility are separate facts.
Directory financial and contact fields obey permissions and export restrictions.
Display values use canonical capitalization and glossary terms.

Dependencies

Designer Studio EntityDesigner Application PipelineWorkspace provisioningMatching ProfileCredential serviceCapacityEnterprise data gridPermissions

Known current limitations · 6 mapped

What is missing, broken or unverified

Future Spec 05 owns closure →

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

Future alignment

Required evolution

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

Current baseline

Acceptance record

Both Studio rows and directory controls are documented.
Applications are not conflated with approved Studio Entities.
Observed terminology conflicts are in the glossary register.

Reverse-spec completeness

Documentation coverage

The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.

Purpose and user outcome

Documented

Roles and access

Documented

Routes and entry points

Documented

Page and component anatomy

Documented

Fields and displayed data

Documented

Primary actions

Documented

Forms and validation

Documented

States and transitions

Documented

Empty, loading and error states

Documented

Responsive behavior

Partial

Accessibility behavior

Partial

Activity and audit events

Partial

Data sources and persistence

Documented

Notifications and automation

Partial

Known defects and limitations

Documented

Reusable component dependencies

Documented

Future-spec conflicts

Partial

Visual and repository evidence

Deferred

Acceptance of current baseline

Documented