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

Provider application

Provider-category application, review and approval experience.

Observed route/admin/applicationsFuture Spec 05 →
Current maturityNine category configurations exist; submitted Provider record journeys remain unverified
Evidence confidencePartially verified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

The Applications Builder exposes the nine canonical Provider Categories, but the live Providers directory has no approved Provider records and the current review does not include a submitted Provider application for each category. Configuration presence therefore does not prove website signup, category-tailored form rendering, review, qualification, approval or provisioning.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Provider Category selectionMust use one of the nine canonical Categories and drive form, workflow, Matching Profile and qualification requirements.Categories verified in builder; applicant flow unverified
Tailored application formShared identity fields plus category-specific capabilities, credentials, Service Areas, capacity and Matchmaking answers.Configured pattern; submitted rendering unverified
Pending accountApplicant can authenticate and see status, requests and submitted information without entering an active Provider Workspace.Required future behavior; not evidenced
Review recordUses the shared application profile with Category-specific workflow requirements and shared modules.Required architecture; no live category record reviewed
Qualification and provisioningApproval creates Category Qualification, Provider Entity, Workspace and owner invitation as distinct idempotent outcomes.Not verified end to end

User journeys

Current flows

01

Apply from the website

  1. Choose Provider Category
  2. Create or resolve identity
  3. Complete tailored form
  4. Upload evidence
  5. Review and submit immutable version
  6. Enter pending account
Observed result

Required journey; current website integration has not been verified in this pass.

02

Review and approve Provider

  1. Open category queue
  2. Complete configured workflow
  3. Validate credentials and Matchmaking data
  4. Record decision
  5. Create Category Qualification
  6. Provision Workspace and onboarding
Observed result

Builder configuration exists; submitted-record and provisioning behavior remain unverified.

State model

Current and expected states

Draft

Website/applicant draft persistence unverified.

Submitted

Category-aware record rendering unverified.

Information or credential required

Request-and-resubmit loop unverified.

Approved, qualification pending

Must remain distinct; no live example.

Workspace provisioning or onboarding

No live example.

Declined, withdrawn or expired

No live example.

Product rules

Non-negotiable boundaries

  • Provider Category is canonical and configured once across website, form, Pipeline, qualification, profile and Workspace.
  • Shared fields reuse the common schema; category fields extend rather than fork it.
  • A Provider may later hold multiple Category Qualifications without duplicate Entities or Workspaces.
  • Pending applicants cannot access active network or Project data.
  • Approval and provisioning are idempotent and preserve the submitted Application Version.
Dependencies
Design Registry website signupSupabase AuthApplications BuilderProvider Application PipelinesProvider Category registryCredentialsMatching ProfileProvider EntityWorkspace provisioningNotifications

Known current limitations · 4 mapped

What is missing, broken or unverified

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

Future alignment

Required evolution

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

Current baseline

Acceptance record

  • All nine Provider Categories are recognized as required application variants.
  • Builder configuration is not mistaken for a working submitted-record journey.
  • Pending, approved, qualified, provisioned and onboarded remain distinct states.
  • No Provider Category can launch without an end-to-end fixture and acceptance test.

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 →