Conduit512

Find what you need

Reference architecture / Not delivered agency work

Licensing review portal

Reference architecture for application intake, evidence review, payments, and renewals. Design targets, not delivered outcomes.

Illustrative scenario

An applicant replaces a missing document online while a reviewer sees what changed and what still needs attention.

This anonymized blueprint describes a reference architecture. It is not an award, customer case study, or delivered system. Targets below are design intentions, not measured results.

The work should not get stuck here.

  • Applications arrive through disconnected forms and inboxes.
  • Reviewers cannot easily track missing evidence or responsibility.
  • Policy changes require another development request.
  • Exports and ownership arrangements are unclear.

Start with the workflow. Build in increments.

  • Map the application journey and review decisions before selecting screens.
  • Design applicant and staff portals around document verification, review queues, and clear status updates.
  • Use hosted or tokenized payment gateways and model renewals as repeatable workflows.
  • Keep forms, notices, reference data, and translated content configurable.

A reference foundation.

Reference architecture

A configurable core, with clear boundaries

A configurable core, with clear boundariesPortal / PWA connects to Configurable workflows connects to Services & integration connects to Data / audit / export. These are proposed architecture patterns, not a deployed customer system.Portal / PWAConfigurable workflowsServices & integrationData / audit / export

Portal / PWA → Configurable workflows → Services & integration → Data / audit / export

Pattern illustration. Hosting, identity, storage, and control requirements are selected for each engagement.

Explore the configurable core

Controls to agree during design.

  • Design role-scoped review and document access.
  • Include upload scanning and an auditable decision history in the agreed architecture.
  • Define retention, export, payment, and identity requirements during discovery.
Review assurance status

Routine changes within your control.

Proposed configurable areas, subject to the agreed architecture, role model, and acceptance criteria.

Application fieldsReview statusesDocument requirementsNotice templatesRenewal rules

Plan the exit path from the start.

Offer source code, deployment artifacts, a data dictionary, runbooks, and a tested export as agreed transition deliverables.

See transition deliverables

Design targets.

Targets are proposed acceptance intentions, not delivered performance results.

  • Applicants can understand the next step without a phone call.
  • Routine form and notice changes do not need a code release.
  • The customer can verify an export before accepting the system.
Talk through your workflowMore reference patterns

Start a conversation

Let’s make the complex work better.

Tell us where the work gets stuck. We’ll start with the workflow, the people, and the constraints.

Talk through your workflow