The Three-Tier Verification Pattern at Workflow Scale
The L1 Ch2 Cardinal Rule lesson installed the three-tier verification protocol for an individual artifact: source-system check, regulatory check, client-fit check. The L3 Ch1 L2 handoff diagram placed the verification checkpoint inside every workflow's structure. This lesson — the third and final L3 Ch1 setup lesson — does the operational engineering. It converts the verification protocol from a per-artifact reflex into a discrete, named, retained, sampled checkpoint specification embedded inside every multi-step workflow the practice runs, with FINRA Rule 4511 retention baked into the checkpoint chain so the supervisory architecture has something to actually supervise against and the 2026 SEC examiner has something to actually examine. Every L3 chapter-2-through-10 workflow consumes the checkpoint specification this lesson defines.
The Three Tiers Revisited at Workflow Scale
The L1 Ch2 framing of the three tiers — source-system, regulatory, client-fit — held the per-artifact discipline. The L3 step-up is that workflows produce hundreds of artifacts per quarter, and a verification reflex that depends on the senior advisor's personal vigilance every time scales linearly with advisor time, which defeats the productivity collapse AI is supposed to deliver. The L3 verification pattern decouples the verification discipline from the advisor's personal reflex and embeds it as a system property of every workflow.
Source-System Verification at Scale
Source-system verification asks whether the AI's number, fact, or extraction matches the canonical data source. At per-artifact scale (L1), this is "did the AI's quote of the Hendersons' AGI match the Holistiplan extraction?" At workflow scale (L3), this is a structured checkpoint with named source systems per data category. The Roth conversion workflow's source-system checkpoint specifies: AGI from Holistiplan-extracted 1040 (line 11), marginal tax projection from RightCapital plan (2026 plan year), aggregated pre-tax IRA basis summed across all traditional/SEP/SIMPLE IRA accounts at Schwab + Fidelity + Pershing + BNY Mellon + Edward Jones (the §408(d)(2) + §72(e)(8) Form 8606 aggregation), Social Security PIA from SSA portal extracts where available or RightCapital plan assumption otherwise, state tax rate from RightCapital configuration matched against client domicile in Wealthbox, IRMAA tier definition from current CMS publication. Each data element has a named source, a named extraction tool, an extraction timestamp, and a verifying-person signoff.
The discipline forces clarity. An AI-generated Roth conversion proposal that cites "client AGI ~$148K" without a source citation fails the source-system tier; the same proposal that cites "client AGI $148,237 from Holistiplan-extracted 2025 1040 Line 11, retrieved 2026-09-15" passes the tier. The Cardinal Rule reflex (L1 Ch2 L3) does not change; the workflow-scale specification makes the reflex auditable, retainable, and supervisable.
Regulatory Verification at Scale
Regulatory verification asks whether the rule cited in the AI's output is the correct rule, whether the action proposed is permissible under the named regime, and whether the disclosure language meets the standard. At per-artifact scale, this is "did the AI cite §408(d)(2) for the backdoor Roth pro-rata, not §408(d)(6)?" At workflow scale, this is a structured checkpoint with named regulatory regimes per workflow type. The Roth conversion workflow's regulatory checkpoint specifies: IRC §408(d)(2) read with §72(e)(8) for pro-rata aggregation reported on Form 8606 lines 6-15 (not §408(d)(6) which governs IRA transfers incident to divorce); the separate-conversion-clock five-year rule for each conversion year; the 2026 IRMAA thresholds with two-year lookback to 2024; the state-tax rules in client domicile; Reg BI §240.15l-1 four obligations (Disclosure / Care / Conflict / Compliance) with documented consideration of reasonably available alternatives (no conversion / partial / full bracket-fill / multi-year ladder); Marketing Rule 206(4)-1 if the client-facing memo will be repurposed for marketing; FINRA Rules 2210 (principal review of client-facing memo) and 3110 (supervisory review) and 4511 (retention); SEC Compliance Rule 206(4)-7 for the WSP documentation.
The discipline is explicit citation. The AI's output and the human's signoff narrative both name the correct statute, the correct subsection, the correct CFR citation, and the correct regulatory regime. The discipline catches the 2024-2026 known-failure-mode of plausible-sounding but wrong citations — the §408(d)(6) confusion (program-wide audit explicitly flagged this), the SECURE 2.0 RMD-age confusion (70.5 vs 72 vs 73 vs 75 step-up in 2033), the conflation of contribution five-year clock with conversion five-year clock, the misattribution of 10b5-1 plan timing rules under Rule 10b5-1(c).
Client-Fit Verification at Scale
Client-fit verification asks whether the recommendation fits this household given their IPS, their risk tolerance, their prior decisions, their life situation, and their current planning state. At per-artifact scale, this is "would I actually recommend this to the Hendersons given what I know about them?" At workflow scale, this is a structured checkpoint with named household-state inputs. The Roth conversion workflow's client-fit checkpoint specifies: current IPS edition (and its review date / staleness flag); IPS-stated tax-management posture; risk tolerance qualitative and quantitative; prior-meeting documented client preferences (Zocks/Jump transcript citations); current life-event triggers (retirement timing, FAFSA visibility for grandchildren, business-sale calendar, inheritance pending); open action items from prior reviews; coordination with other in-flight planning workflows (Social Security claiming, IRMAA management, estate-vehicle decisions, equity-comp exercise calendar); fee-impact on the client; advisor's professional judgment narrative.
The discipline forces explicit reconciliation. An AI-generated Roth conversion proposal that contradicts a prior-meeting client-stated preference ("we want to keep AGI low for the grandchild's FAFSA") fails the client-fit tier and must be either modified or sent back with the contradiction documented. The same proposal that explicitly references the prior preference and explains why the recommendation differs ("client's preference was FAFSA-driven; FAFSA window has now closed as oldest grandchild entered junior year; this conversion sits within the remaining grandchild's untouched window") passes the tier with documented judgment.
Checkpoints as Discrete Workflow Nodes — Not Reflexes
The L3 verification pattern's central engineering choice is to make checkpoints discrete workflow nodes rather than implicit advisor reflexes. The handoff diagram (L3 Ch1 L2) showed the verification checkpoint as a single node between AI output and signoff. The checkpoint specification explodes that single node into the three named tiers, each with its own discrete pass/fail outcome, each producing its own retained log entry, each potentially handled by a different role in the practice (paraplanner for source-system in extract-mode workflows; senior advisor for regulatory + client-fit in propose-mode; CCO for regulatory in client-facing draft-mode under principal review).
The discrete-node design allows checkpoints to be (a) timed individually for L4 Ch5 ROI tracking (source-system check averaged 90 seconds per Roth conversion artifact post-AI vs 8 minutes pre-AI), (b) sampled individually for L4 Ch3 supervisory review (CCO samples 20% of regulatory checkpoints and 5% of source-system checkpoints, weighted by judgment-bearing risk), (c) audited individually for SEC exam response (regulatory checkpoint logs surface the firm's regulatory-citation discipline; client-fit checkpoint logs surface the firm's documented application of judgment), (d) refined individually based on failure-pattern data (if source-system checks routinely flag aggregation errors, the L3 Ch1 L1 audit re-runs and the checkpoint specification gets updated).
Checkpoint Pass Criteria
Each tier has explicit pass criteria. Source-system tier passes when every data element in the AI's output has a named source, a named extraction tool, an extraction timestamp, and a field-by-field match to the canonical source. Regulatory tier passes when every cited statute / rule / regulation is named with section / subsection / CFR citation, the cited authority is the correct one (not a confused near-miss like §408(d)(6)/§408(d)(2)), and the proposed action is permissible under the named regime. Client-fit tier passes when the IPS / risk tolerance / prior preferences / life-event state / other-workflow coordination is explicitly reconciled in the signoff narrative and any apparent contradiction is addressed with documented judgment.
Checkpoint Failure Handling
Each tier has explicit failure handling. Source-system fail: re-run extraction, correct the data, re-verify. Regulatory fail: re-prompt AI with corrected regulatory framing, re-verify; if pattern persists, update the prompt-library system prompt (L2 Ch8 L1) and the few-shot exemplars to embed the correct citation upfront. Client-fit fail: modify the proposed recommendation to reconcile, or document the deviation rationale, or refer to the senior advisor's judgment with explicit narrative. Repeated failures of the same pattern trigger the L3 Ch1 L1 audit re-score and the AI Governance Committee (L4 Ch6 L1) review.
Rule 4511 Retention Baked Into the Checkpoint Chain
FINRA Rule 4511 retention (and the SEC Rule 204-2 parallel for advisers) obligates the firm to retain communications and records in a way that is accessible, tamper-evident, and date-stamped. The L3 verification chain produces the records that satisfy the obligation. Each checkpoint produces a discrete log entry: (a) the AI output that was verified, (b) the named tier (source-system / regulatory / client-fit), (c) the pass/fail outcome with specifics (which data elements were verified, which statutes were checked, which IPS / preference items were reconciled), (d) the verifying-person identity (CRD or registered representative number) and timestamp, (e) the artifact's signoff and downstream-routing confirmation.
The checkpoint logs route to the Smarsh / Global Relay archive with tagged-Markdown metadata per L2 Ch8 L2: document_type=verification_log_source_system or verification_log_regulatory or verification_log_client_fit, household_id, workflow_id, advisor IDs, retention_policy=rule_4511_5yr_practical, related_records (the AI artifact, the signoff, the downstream routing confirmations). The archive's tagged-metadata search lets the CCO surface during quarterly sampling (L4 Ch3 L2), lets the L4 Ch5 ROI dashboard compute checkpoint timing and exception rates, lets the M&A buyer's diligence team query the firm's verification discipline at scale (L4 Ch8), and lets the SEC examiner verify the firm's Compliance Rule 206(4)-7 documentation.
Prompts and Outputs as Records
L3 Ch10 L2 develops the prompt-retention discipline in detail. For the L3 Ch1 L3 verification chain, the operational point is that the system prompt version (L2 Ch8 L1), the user prompt, the AI output, the human edits, and the signoff are all part of the Rule 4511 record. The verification log adds the per-tier checkpoint outcomes and the signoff narrative. The complete retained package per workflow per artifact: trigger event log, inputs snapshot, system prompt version, user prompt, AI output (structured per L2 Ch8 L2 schema), source-system checkpoint log, regulatory checkpoint log, client-fit checkpoint log, signoff narrative with CRD and timestamp, downstream routing confirmations, supervisory review entry. The package is the practice's Reg BI defense file for the artifact.
Checkpoint Design By Workflow Type
Each L3 chapter-2-through-10 workflow type carries a checkpoint specification tailored to its data sources, regulatory regimes, and household-state inputs. The pattern is the same; the specifics vary.
Roth Conversion Workflow Checkpoints (L3 Ch2)
Source-system: Holistiplan AGI line item, RightCapital marginal tax projection, aggregated pre-tax IRA basis across all custodians (§408(d)(2) + §72(e)(8) Form 8606), Social Security PIA, IRMAA tier definition, state tax rate, Wealthbox household state. Regulatory: IRC §408(d)(2)+§72(e)(8) for pro-rata (not §408(d)(6) divorce), separate-conversion five-year clock per IRC §408A(d)(3), 2026 IRMAA thresholds with two-year lookback, Reg BI four obligations with four-alternatives documentation. Client-fit: current IPS edition + staleness flag, tax-management posture, prior-meeting client preferences, life-event triggers (retirement, FAFSA, business sale), coordination with Social Security and IRMAA workflows.
RMD Calendar Workflow Checkpoints (L3 Ch3)
Source-system: Schwab/Fidelity custodian RMD-tracker data, prior-year-end balance per IRA, Uniform Lifetime Table or Single Life Table factor per age, prior-year distribution amount, beneficiary classification for inherited IRAs (eligible-designated vs non-EDB under SECURE 2.0). Regulatory: IRC §401(a)(9) and SECURE 2.0 ages (73 / 75 in 2033), §408(d)(8) QCD authorization for 70.5+ household, 10-year-rule annual-RMD-during-window clarification, December 31 deadline (or April 1 first-RMD exception). Client-fit: charitable orientation (QCD candidacy), tax-bracket fit, destination preference (cash to checking / in-kind / QCD direction), coordination with Roth conversion and IRMAA workflows.
Estate Gap Workflow Checkpoints (L3 Ch5)
Source-system: FP Alpha / Wealth.com extracted will, trust, POA, healthcare directive provisions (agents, trustees, beneficiaries, distribution mechanics, GST-tax provisions); custodial account titles from custodian feeds; beneficiary forms across every account type. Regulatory: state probate rules in domicile, RUFADAA digital-asset provisions, federal estate-tax exclusion (2025/2026 sunset framing), GST-tax computation, 10-year inherited-IRA stretch impact of trust-as-beneficiary, IRC §663(b) 65-day trust election where relevant. Client-fit: family-structure changes (births, deaths, divorces, marriages), prior-attorney handoff state, IPS estate-planning section, charitable orientation, business-succession state, special-needs household status, prior trust-funding open items.
Equity-Comp Workflow Checkpoints (L3 Ch6)
Source-system: grant agreement extracts (ISO / NQSO / RSU / ESPP terms, vesting schedules), Form 4 insider filings for executive-status confirmation, cap-table data for QSBS issuance-date determination (legacy vs OBBBA July 2025 dual regime), current bid for AMT crossover calculation, prior-year AMT credit carryforward, 10b5-1 plan terms if applicable. Regulatory: AMT triggers under IRC §55-§59, QSBS §1202 per-tranche classification under legacy vs OBBBA regime, 83(b) election windows, 10b5-1 plan structuring under Rule 10b5-1(c), disqualifying-disposition trap for ESPP under §423, NUA election under §402(e)(4) for separating executives. Client-fit: career-stage and liquidity event proximity, IPS concentrated-position policy, charitable orientation (CRT/CLAT/DAF fit), tax-bracket fit, family-cash-flow needs, coordination with Roth conversion and IRMAA workflows.
Rollover Reg BI Workflow Checkpoints (L2 Ch7 L2 applied at L3 scale)
Source-system: plan-document fee schedules (current plan vs proposed IRA), current plan share-class data, proposed IRA share-class data, plan fund line-up vs IRA fund line-up, plan distribution forms vs custodian intake forms. Regulatory: Reg BI §240.15l-1 four obligations, DOL fiduciary framing where applicable, IRC §72(t) early-withdrawal penalty if client under 59.5, IRC §402(c)(4) direct-rollover mechanism, four-alternatives documented (leave in plan / roll to new employer plan / roll to IRA / take cash). Client-fit: client age and 59.5 threshold, plan-specific protections (creditor protection, loan provisions, NUA opportunity if appreciated employer stock), fee impact, fund quality comparison, prior client-stated preferences, IPS retirement-asset policy.
The Checkpoint Specification as Firmwide Asset
The checkpoint specifications above are not advisor-individual artifacts. They are firmwide WSP-embedded design specifications that every advisor running the workflow uses, every CCO supervises against, every Governance Committee reviews quarterly, and every M&A buyer's diligence team requests. The specifications version (regbi-conversion-checkpoint-spec v2.1, rmd-calendar-checkpoint-spec v1.5, estate-gap-checkpoint-spec v3.0, equity-comp-checkpoint-spec v1.2) with documented update rationale and effective dates. The system prompts (L2 Ch8 L1), the few-shot exemplars, the structured-output schemas (L2 Ch8 L2), and the checkpoint specifications are linked artifacts in the firm's operational asset library — a change to one requires coordinated change to the others.
The AI Governance Committee (L4 Ch6 L1) governs the checkpoint specifications' change-control process. The CCO supervises against the current effective specifications. The L4 Ch5 ROI dashboard reports per-specification checkpoint timing, exception rates, and remediation cycles. The L4 Ch8 M&A diligence pack includes the current effective specifications for each workflow type as the operational-maturity artifact set. The SEC examiner asking "how does your firm verify AI-generated recommendations?" gets shown the checkpoint specifications, the verification log archive, the supervisory sampling output, and the change-control history. That answer is the difference between an AI-touched practice and an AI-integrated practice with defensible discipline.
The L3 Ch1 Design Package Complete
Three lessons of L3 Ch1 have now produced the design package every L3 chapter-2-through-10 workflow consumes. L3 Ch1 L1 produced the workflow audit — the inventory of motions, the time-spent × AI-leverage scoring, the 90-day intervention list. L3 Ch1 L2 produced the human-AI handoff diagram — the four modes, the six elements, the signoff node as Reg BI documentation point. L3 Ch1 L3 (this lesson) produced the verification checkpoint specification — the three tiers as discrete workflow nodes, the pass/fail criteria, the failure handling, the Rule 4511 retention baked into the chain.
Together: every prioritized motion has a diagram, every diagram has a verification specification, every specification produces retained checkpoint logs, every log is queryable from the Smarsh archive, every queryable log feeds the CCO supervisory sampling, every supervisory output feeds the L4 Ch5 ROI dashboard, every dashboard delta feeds the L3 Ch1 L1 audit re-score, every audit update feeds the AI Governance Committee, every governance review feeds the WSP change-control process, every WSP update flows back into the prompt library and the few-shot exemplars and the structured-output schemas and the checkpoint specifications, closing the loop. The L3 Ch1 design package is the practice's operational integration architecture for AI.
Chapters 2 through 10 now build the specific workflows the design package supports. L3 Ch2 (next) takes the design package into Roth conversion season — the 50-household screen, the per-client sizing memo, the Reg BI-compliant recommendation memo with execution and archiving. Every step of every L3 Ch2 lesson assumes the L3 Ch1 design package is in place.
Key Takeaways
- The L3 verification pattern decouples the verification discipline from the senior advisor's personal reflex and embeds it as a system property of every workflow. Per-artifact vigilance scales linearly with advisor time and defeats the productivity collapse AI is supposed to deliver.
- Three tiers as discrete workflow nodes: source-system (does the AI's number/fact/extraction match the canonical source?), regulatory (is the cited rule the correct rule, is the action permissible under the named regime, does the disclosure meet the standard?), client-fit (does the recommendation fit this household given IPS, risk, prior preferences, life situation, and current planning state?). Each tier has pass/fail criteria, failure handling, and produces its own retained log.
- Source-system tier passes when every data element has a named source, a named extraction tool, an extraction timestamp, and a field-by-field match. The Holistiplan extraction citation discipline at scale.
- Regulatory tier passes when every cited statute / rule / regulation is named with section / subsection / CFR, the cited authority is correct (not §408(d)(6)/§408(d)(2) confusion), and the proposed action is permissible. The audit's program-wide §408(d)(6) fix was a regulatory-tier failure caught at the audit stage.
- Client-fit tier passes when IPS / risk tolerance / prior preferences / life-event state / other-workflow coordination is explicitly reconciled in the signoff narrative and any apparent contradiction is addressed with documented judgment.
- Rule 4511 retention bakes into the chain. Each checkpoint produces a discrete log entry (AI output verified, named tier, pass/fail with specifics, verifying-person CRD and timestamp, signoff and downstream routing confirmation) tagged in Smarsh with metadata for quarterly sampling, ROI dashboard, M&A diligence, and SEC exam response.
- Checkpoint design varies by workflow type — Roth conversion (Holistiplan AGI + §408(d)(2)+§72(e)(8) pro-rata + IPS-fit), RMD calendar (custodian RMD-tracker + §401(a)(9) SECURE 2.0 ages + charitable-orientation fit), estate gap (FP Alpha/Wealth.com extraction + state probate + family-structure changes), equity comp (grant agreements + QSBS dual-regime + IPS concentrated-position policy), rollover Reg BI (plan-document fees + §240.15l-1 four obligations + 59.5 threshold).
- The L3 Ch1 design package is complete. Audit (L1) + handoff diagram (L2) + verification specification (L3) — every L3 chapter-2-through-10 workflow consumes the design package. L3 Ch2 (next) takes the package into Roth conversion season.
Skill.re