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

Applications directory

Central entry point for Designer and Provider application records.

Observed route/admin/applicationsFuture Spec 05 →
Current maturityVisible directory entry; complete records and category coverage require verification
Evidence confidencePartially verified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

Applications is present in the authenticated navigation and is intended to be the shared administrative directory for Designer and Provider applications. The current review confirms the entry point and the separate Applications Builder, but it does not yet prove a complete permission-scoped directory, all Provider Category queues, saved views, bulk review actions or application-to-Workspace provisioning from this surface.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Navigation entryApplications is visible in the Admin navigation.Verified live
Directory datasetExpected to combine Designer and all nine Provider Category applications from one canonical application service.Requires live record verification
Filters and viewsRequired filters include applicant type, Provider Category, Pipeline Stage, review owner, readiness, submitted date and exception state.Future contract; not fully verified
Record entryEach row must open the shared application record while preserving its category-specific form and workflow version.Known architecture; route coverage requires verification
Provisioning statusApproval, Entity creation, Workspace provisioning, invitation and onboarding readiness must be separately visible.Required by Spec 05; current directory behavior unverified

User journeys

Current flows

01

Triage incoming applications

  1. Open Applications
  2. Choose applicant type or Provider Category
  3. Filter by Stage and owner
  4. Open an application
  5. Complete the next review action
Observed result

Navigation is verified; complete queue behavior remains unverified.

02

Monitor approved provisioning

  1. Filter approved applications
  2. Review Entity and Workspace creation state
  3. Resolve failed provisioning
  4. Confirm invitation and onboarding
Observed result

Required future operational journey; not evidenced in the current directory.

State model

Current and expected states

Loading

Not reviewed.

No applications

Category-aware empty guidance is not verified.

Needs review

Expected core queue state; current presentation unverified.

Approved, provisioning

Must remain distinct from active Workspace status; current presentation unverified.

Provisioning failed

Retry and exception ownership are not verified.

Product rules

Non-negotiable boundaries

  • Designer and Provider applications use one application service and shared directory primitives.
  • Provider Category is mandatory for Provider applications and never inferred from a display label.
  • Application Stage, review decision, Entity status, Workspace status and onboarding state remain distinct.
  • Directory rows and exports obey contact, credential and financial permissions.
  • Every approval and provisioning action is idempotent and auditable.
Dependencies
Application serviceApplication PipelinesApplications BuilderProvider Category registryEntity serviceWorkspace provisioningTeammates and invitationsNotifications BuilderPermissions

Known current limitations · 4 mapped

What is missing, broken or unverified

Future Spec 05 owns closure →
  1. Only the navigation entry is conclusively verified in this review.
  2. Complete Designer and all nine Provider Category queues are not evidenced.
  3. Bulk review, saved views, export, provisioning exceptions and category-aware empty states are unverified.
  4. The directory-to-record and approval-to-provisioning journeys are not yet proven end to end.

Future alignment

Required evolution

  • 01Implement one permission-scoped directory for Designer and every Provider Category application.
  • 02Expose independent review, Entity, Workspace, invitation and onboarding statuses.
  • 03Add saved views, assignment, service-level indicators and provisioning exception recovery.
  • 04Use the immutable submitted form and workflow versions defined in Spec 05.

Current baseline

Acceptance record

  • Applications is present as a navigation destination.
  • Unverified directory behavior is not presented as complete.
  • Designer and Provider applications are represented as variants of one canonical service.
  • Provisioning state is not collapsed into the approval decision.

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 →