BC
Brad CodyAdministrator
Current product→Applications and network approval
Reverse spec drafted

Designer application

Designer-specific application record, workflow, information and approval process.

Observed route/admin/designer-networkFuture Spec 05 →
Current maturityExisting Designer pattern; current end-to-end behavior requires renewed verification
Evidence confidencePartially verified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

The Designer Application is the reference pattern for application records and historically includes an editable workflow plus shared record tabs. The current product inventory can rely on that pattern for architecture, but it must not assume that every field, Stage, action, permission or approval side effect remains correct without a fresh live review.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Workflow tabExpected first tab with Stage-aware review guidance, requirements and actions.Known prior pattern; current state requires verification
Application informationDesigner identity, Studio details, portfolio, services, experience, markets, capacity and Matching Profile answers.Required contract; current field inventory requires verification
Shared record modulesActivity, Notes, Files, Tasks, Communication, Proposals and History should reuse shared modules according to availability.Architecture requirement; current tab behavior requires verification
Decision controlsApprove, request information, decline and withdraw require reasons, authority and Activity.Required by Spec 05; current controls unverified
Provisioning resultApproval must create or link one Designer Entity, one Designer Workspace and the intended owner User/Membership.End-to-end side effect unverified

User journeys

Current flows

01

Review Designer application

  1. Open submitted application
  2. Complete workflow requirements
  3. Review portfolio, credentials and Matching Profile
  4. Request missing information when needed
  5. Record a decision
Observed result

Reference journey is known; the current live implementation requires renewed verification.

02

Approve and provision

  1. Approve with authority
  2. Resolve duplicate Entity/User candidates
  3. Create or link Designer Entity
  4. Provision Workspace
  5. Invite owner
  6. Start onboarding
Observed result

Required idempotent future journey; not proven end to end.

State model

Current and expected states

Draft

Applicant-owned pre-submission state requires verification.

Submitted and under review

Expected core review states; exact live Stages require verification.

More information required

Applicant response and resubmission behavior unverified.

Approved and provisioning

Must be separate states; current behavior unverified.

Declined or withdrawn

Reason, retention and reapplication behavior unverified.

Product rules

Non-negotiable boundaries

  • A submitted Application Version is immutable; applicant corrections create a successor version.
  • Designer application approval never creates duplicate Entities, Users or Workspaces.
  • Review requirements resolve from the active published Designer Application configuration.
  • Internal review content is never exposed to the applicant.
  • Matching answers become governed Entity data only through an explicit approved mapping.
Dependencies
Applications BuilderDesigner Application PipelineDesigner EntityWorkspace provisioningMatching ProfileCredentialsFilesNotificationsPermissions

Known current limitations · 4 mapped

What is missing, broken or unverified

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

Future alignment

Required evolution

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

Current baseline

Acceptance record

  • Designer Application remains the reference pattern, not proof that Provider variants are complete.
  • Current unverified behavior is labeled accurately.
  • Approval, Entity creation, Workspace provisioning and onboarding are modeled separately.
  • A fresh live verification pass is required before release acceptance.

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
← Feature inventoryOpen Future Spec 05 →