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

Application workflow tab

Stage-aware review work, next actions and approval progression.

Observed route/admin/applications/:idFuture Spec 05 →
Current maturityConfigurable concept with incomplete runtime verification
Evidence confidencePartially verified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

The application Workflow tab is intended to translate the published Application Builder configuration into reviewer work: current Stage, requirements, blockers, next actions and decisions. The first-tab pattern is established by the earlier Designer Application experience, but runtime parity with every configured Designer and Provider workflow is not yet verified.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Current StageMust resolve from the immutable Pipeline/Application configuration version attached to the application.Required contract; runtime parity unverified
Stage requirementsRequired fields, documents, credentials, Tasks, checks and decisions are shown with completion evidence.Builder capability partially reviewed; runtime unverified
Next actionsReviewer actions include assign, request information, validate, advance, return, approve, decline and withdraw according to configuration and authority.Complete action set unverified
Blockers and exceptionsMissing or failed requirements prevent transition and identify remediation without hidden rules.Required future behavior
Decision effectsApproval previews Entity, qualification, Workspace, invitation, notification and onboarding side effects before confirmation.Required future behavior

User journeys

Current flows

01

Advance a review

  1. Open Workflow
  2. Review Stage requirements
  3. Resolve or assign blockers
  4. Complete required evidence
  5. Advance with reason
  6. Write Activity
Observed result

Expected pattern; complete live behavior not verified.

02

Approve safely

  1. Validate decision authority
  2. Preview provisioning effects
  3. Resolve duplicates
  4. Confirm approval
  5. Run idempotent provisioning
  6. Monitor completion or exception
Observed result

Required future journey; current behavior unverified.

State model

Current and expected states

Ready

All requirements met; exact live presentation unverified.

Blocked

Structured blocker state is required; current presentation unverified.

Waiting on applicant

Response deadline, reminder and resubmission state unverified.

Decision required

Authority and reason controls unverified.

Provisioning in progress or failed

Must be observable after approval; current handling unverified.

Product rules

Non-negotiable boundaries

  • Runtime Workflow is generated from the exact published configuration version attached to the application.
  • Transitions validate server-side requirements and never trust the visible checklist alone.
  • Every manual override requires authority, reason and Activity.
  • Decision and provisioning side effects are idempotent and independently retryable.
  • Workflow content respects applicant/internal visibility boundaries.
Dependencies
Application Pipeline runtimeApplications Builder versionsTask engineCredential checksFilesDecision serviceWorkspace provisioningNotifications BuilderAudit History

Known current limitations · 4 mapped

What is missing, broken or unverified

Future Spec 05 owns closure →
  1. Runtime parity with the Applications Builder is not proven.
  2. Required fields, documents, Credentials, Tasks, decisions and transition blockers are not verified across categories.
  3. Waiting-on-applicant, override, rejection, withdrawal and provisioning-failure states are not fully evidenced.
  4. No end-to-end test proves that one published configuration produces the correct reviewer workflow.

Future alignment

Required evolution

  • 01Render Workflow entirely from the attached immutable configuration version.
  • 02Show structured requirements, blockers, owners, deadlines and completion evidence.
  • 03Preview and audit decision side effects, overrides and provisioning exceptions.
  • 04Create category fixtures and automated tests for every Stage and transition in Spec 05.

Current baseline

Acceptance record

  • The Workflow tab is defined as configuration-driven.
  • Unverified runtime behavior is not claimed as complete.
  • Server transition validation is required independently of visible controls.
  • Every canonical applicant type and Provider Category needs a tested workflow fixture.

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 →