PCProvider ComplianceClient brief
Evidence-backed client specification · 31 August 2026

What Harrison actually needs us to build.

Replace fragmented Claude projects and manual hand-offs with one persistent application workspace, without erasing the consultant judgement and client confirmation that make each regulated application accurate.

Read the product decisionSee the video workflowSee the build stack

The client

Provider Compliance is an Australian consultant-led firm serving aged-care, NDIS, ISO and provider-growth clients. Its public offer spans registration support, policies and procedures, governance, audit readiness, management systems and operating-model advice.

Immediate focusThe evidence supplied for this project is centred on aged-care provider registration: organisation design, business and financial plans, category-specific policy packs, application forms, gap analysis and submission readiness.

The current system works through Harrison’s judgement.

Each case has a different entity history, people, service categories, geography, funding model, evidence position and regulatory backstory. Harrison currently moves approved outputs between separate AI projects, reconciles contradictions manually, distinguishes fixable defects from client blockers and asks for approval before major transitions.

Fragmentation

Context is copied between chats.

Downstream projects can silently receive stale or incomplete context.

Authority

Facts and examples are mixed.

Prior applications are useful fixtures, never facts for the current applicant.

Documents

Master packs are versioned products.

Category editions, replacements and output receipts need deterministic control.

Waiting

Client pauses are normal workflow.

The case must resume from durable state rather than restart in a new conversation.

Product decision

Build one consultant-led, evidence-backed application workspace.One conversational front door sits over governed lanes for intake, organisation design, source-document construction, master-pack generation, application assembly, gap routing, review, finalisation and post-submission lifecycle.

The system of record is typed case state, not an AI conversation. Every material claim links to current applicant evidence and an applicable regulatory requirement. Unknown material facts remain gaps. Approved artifacts are immutable revisions.

  1. 1
    One persistent case

    Facts, backstory, people, categories, decisions, artifacts and history survive every pause.

  2. 2
    One evidence graph

    Application answer → applicant evidence → regulatory requirement → reviewer status.

  3. 3
    One gap queue

    Every missing fact, document, contradiction or defect has a named owner and next action.

  4. 4
    One approval history

    Consultant, client and authorised declaration gates are explicit case events.

Who uses it and what they need

ActorPrimary jobMust never happen
ConsultantAssemble, question, reconcile, draft, validate and prepare the case.AI inference silently becomes an approved fact.
ClientProvide facts/documents, review proposals and confirm material decisions.Unclear tasks or approval of content they cannot understand.
Authorised declarantOwn the final representations and approve submission-ready output.Submission or declaration performed autonomously.
Research/operations agentMonitor public authority, extract sources and run bounded document jobs.External research enters the private case authority without review.

Automation boundary

proposeextractcomparedraftvalidateroute gapsprepare review set
Human-only gatesConfirm material facts, approve organisation structure, accept financial assumptions, approve client-facing artifacts, authorise declarations and operate the external submission step unless an official integration is later authorised.

Phase 0 acceptance gate

The architecture is not proven by a polished demo. It passes when one de-identified successful case and one incomplete case can be represented end-to-end with exact source/form versions, structured backstory, claim-level provenance, correct gap ownership, approvals, deterministic document receipts, final review sets, submission/outcome history, tenant-leakage tests and a deletion/restore exercise.

What is still required from Harrison

  • One structurally complete successful case from intake through outcome.
  • One incomplete case with the exact blocker and expected next action.
  • The exact current Commission form packs used in practice.
  • The authoritative instruction/prompt registry and supersession history.
  • Pricing, delivery capacity, team roles and credential confirmation.
  • Hosting region, identity, subprocessors, retention, deletion and incident decisions.