A working specification for the proof-of-concept build covering Practice Licence processing, member email triage, case management, and a cross-team Exemptions Discovery workstream.
Engagement. Forward-deployed temp Practice Licence Processor cover, May–August 2026, contracted between Jordan Copeland Ltd and the Institute of Certified Bookkeepers.
POC scope is what we will deliver and demonstrate inside the engagement window; the production-cover handover plan that follows the POC is in §7.
An “assistant” to reduce PLP cognitive load on three high-volume surfaces, with a fourth cross-team discovery workstream.
Around 150–200 applications per year. The new online application form replaces the email-attached-PDF intake; the assistant ingests applications, checks them against the acceptance rubric, and presents Sadia or Abigail with a green-light / needs-more-from-applicant / escalate suggestion plus a draft reply and a draft Sodalis comment.
High-volume member queries currently bouncing between Professional Standards and Member Services. The assistant categorises inbound, drafts a suggested response, and surfaces a check-this list. The PLP keeps decision authority on every outbound.
Around seven active complaint cases per year, currently in unstructured SharePoint folders with no progress tracking — ICB's highest-risk operational surface. Same build pattern as PL processing but with case-state and momentum tracking the PL flow does not need. Scope expansion: Late Registration Fee instalment payment-state is folded into this workstream — Sadia presently triggers each reminder manually; the assistant will surface payment-state per applicant and draft the outbound for human send.
A discovery-first workstream sitting with Anthony's team rather than the PLP function. Not a build commitment inside the POC window; structured listening, mapping the existing exemption pathways, and surfacing what an assistant for that team would look like.
Humans-in-loop on every outbound. No autonomous emails, no autonomous Sodalis writes. The assistant suggests; a human decides; the human sends.
Assistant outlives the engagement. The deliverable is an operational system that ICB owns at handover (Mon 17 Aug 26m), with a Jordan-side support retainer post-handover.
Engagement window: 18 May → Fri 14 Aug 26f. Within that, the POC reach is bounded as follows.
ICB is weighing a Microsoft-stack alternative built on Copilot Studio. The POC bet is that a bespoke fit for the PLP workflow — Outlook category as state, Sodalis as the system of record, the SOP's seven-stage flow built in — beats a generic enterprise comparator on accuracy, running cost, and adoption. The POC is the evidence base for that bet.
jordan.copeland@bookkeepers.org.uk (provisioned 22 May 26f). Membership of the shared professional.standards@ mailbox so the assistant reads the same inbox the PLPs see.A web-rendered dashboard the PLPs work from:
Design language. Starting from ICB's main-project editorial defaults (DM Serif Display + DM Sans + stone palette + terracotta accent — the typography of recent ICB-facing deliverables). A separate design consideration from the member-facing ICB brand.
professional.standards@bookkeepers.org.uk (shared inbox) — primary working surface.jordan.copeland@bookkeepers.org.uk (Jordan's seat) — read access used as the corpus collection mechanism during initial bootstrapping and as a redundancy path.The assistant writes suggested replies, suggested Sodalis comments, case-state updates, and unified-timeline entries into the dashboard. Tile colours reflect stage; the statistics panel reflects volume, time-in-stage, and payment-state for LRF instalment plans. Reasoning traces and confidence signals surface alongside each suggestion so the PLP can see why the assistant has proposed what it has.
Role permissions are secondary to that. The PLP role has full edit on suggested drafts plus click-to-complete and click-to-escalate; the Member Services role is read-only on case state.
The architecture supports Teams integration via the same Microsoft Graph layer that handles email. We are deliberately not turning it on at POC launch because the audit and escalation conversations that happen in Teams widen the data boundary substantially, and the PII redaction layer needs to demonstrate stability against the email + Sodalis surface before a second comms channel is layered in.
Expected trajectory. Once the assistant is stable on the launch surfaces (probably late July, into the retainer window), Teams integration becomes a small additive extension rather than a re-scoping.
Yoti is ICB's complete IDV solution for Practice Licence applications. No live verification call is required for a Practice Licence to be granted. Ami's position confirmed 26 May 2026.
| Strand | Performed by | Triggered for | Assistant role |
|---|---|---|---|
| Identity verification | Yoti | Every PL application — every BOOM | Read Yoti result from Sodalis note; surface state on dashboard tile. |
| Sanctions screening | Yoti | Every PL application — every BOOM | Read Yoti result; surface escalation if flagged. |
| Adverse-media screening | Yoti | Every PL application — every BOOM | Read Yoti result; surface escalation if flagged. |
| Companies House check | Assistant (via API) + PLP decision | Every PL application | Programmatic lookup of company status, officers, and recent filings via the Companies House Public API; surfaces anomalies (e.g. dissolved company, undisclosed directorships) for the PLP to review. |
| Google "already practising" check | Assistant (via search API) + PLP decision | Every PL application | Programmatic web search via the Brave Search API — agent constructs targeted queries (name + bookkeeping + locality), parses results, and surfaces evidence of existing practice activity for the PLP to review. |
| Right-to-Work check | ICB (PLP) | Conditional — only where the applicant does not automatically have UK right to work | Detect the conditional trigger from application data; surface RTW workflow; capture findings against the applicant record. |
The decision is always ICB-staff. Article 22 UK GDPR requires that no application decision is taken solely on the basis of an automated result, and ICB's published staff training reinforces this: "Yoti gives ICB a result. ICB makes the decision." The assistant suggests, captures, and surfaces; the PLP determines.
BOOM-level verification. Practice Licence applications can involve multiple Beneficial Owners, Officers, or Managers of Practice, and each must be verified separately. The assistant's application data model holds a list of BOOMs, each with their own IDV state across the strands above. Tiles, escalations, and progress indicators are BOOM-aware.
Yoti runs as an external system; the assistant has no direct Yoti API integration on the ICB side. Yoti returns a result to the ICB Yoti Portal, and the PLP records the outcome — Pass, Fail, or Refer (with escalation target) — via a structured dropdown on the assistant dashboard. The dashboard both captures the outcome for the assistant and produces the canonical note text the PLP pastes into Sodalis. This is the entire integration surface.
The £250-per-month Yoti API tier referenced on the 19 May team call is not required for this architecture and can be deferred indefinitely. If actual Yoti-trigger frequency in live cover later indicates the manual session-creation workflow is a meaningful operator burden, the tier becomes a discrete cost decision; until then, no commitment.
Where a screening result triggers AML concerns, ICB must not tip off the applicant under the Proceeds of Crime Act 2002. The assistant's draft-reply layer (Mission B) is configured to use neutral language for applicant-facing communications on Fail outcomes — for example: "We need to conduct some additional checks on your application." — and never to surface the underlying screening result to applicant-facing drafts. Internal escalation drafts to the Head of Professional Standards or the MLRO carry the underlying result.
The assistant holds the result strings, the determination, the determination date, and minimal exception notes — and nothing else from the IDV process. Identity document images, biometric templates, and facial images are not stored by ICB and are not visible to the assistant. ICB outcome records are retained for five years after the end of the business relationship per Regulation 40 of the Money Laundering Regulations 2017; the assistant's retention policy mirrors this.
Ami additionally indicated that new successful applicants could potentially be automatically scheduled for a more generally educational onboarding call covering Customer Due Diligence, AML Online, and the Written Practice Risk Assessment — the new-practice training that previously sat inside the now-retired video-call IDV format. This is a stretch goal, not a launch-window commitment. The assistant's role, if and when this lands, is to surface an auto-scheduling suggestion against successful PL-grant events for human send, consistent with the no-autonomous-outbound architecture in §6.
The six realistic failure modes the build is designed against, ranked by blast radius:
sendMail permission. Hard-coded out at the runtime layer, not policy-only.Sodalis operational facts the assistant accommodates: the duplicate-record bug when applicants navigate back-and-forth through the new online form (the read pipeline dedupes per applicant); the subcontractor-field corruption where Sadia's workaround is to add subcontractors under Staff with a description-prefix flag (the read pipeline infers subcontractor status from the prefix). These are Sodalis facts to read around, not bugs for the assistant to fix.
professional.standards@ — still pending).Drafted 26 May 2026. Prepared by Jordan Copeland for Ami Copeland, Agatha Guarnaccia, and Julius Tafura.