Sesame Bankhall Group
×
Confidential · Access Required

SBG × JammJar Evaluation

This evaluation package contains confidential commercial, technical, and strategic material. Enter the access code to continue.

Confidential material — do not share the link or access code without explicit authorisation from JammJar.
Evaluation Deliverables
PMS · 10-day structured review
JammJar
SBG × JammJar · Evaluation Deliverables Last updated 17 April 2026

A structured evaluation of JammJar for SBG's PMS and OneView strategy.

SBG is evaluating how to modernise its PMS offering to directly-authorised firms and how to deepen the OneView oversight data that underpins its network. This evaluation tests JammJar across four workstreams — capability parity with Acre, OneView integration design, commercial models, and the engagement model best suited to SBG's strategic objectives — so that SBG leadership can decide, with evidence, whether and how JammJar fits.

Engagement 10-day structured evaluation
Scope Fixed scope · 10 working days
SBG sponsor Shane Wright (CTO)
JammJar lead Chris Underhill (CTO)
Headline numbers at a glance
Capability score
+9.6pts
JammJar leads Acre · 83.3 vs 73.7
Explore the 128-feature matrix →
OneView data surface
7entities
Full schema mapping · 33 MCP tools · OAuth 2.0 + PKCE
See integration design →
5-year DA SaaS opportunity
£4.18M
Base-case gross ARR · £1.13M minimum fee floor underneath
View commercial models →
Engagement routes
3options
Partnership · Minority invest · Acquisition
Compare engagement models →
Executive Summary

Headline findings for the SBG Executive team

A board-ready synthesis of all four deliverables — what SBG is buying, what the numbers say, the open questions, and our recommendation on engagement model.

Read summary
01
PMS / DA Platform Review

Capability matrix, gap analysis & roadmap

Interactive 128-feature comparison of JammJar vs Acre CRM, weightable by persona. Paired with a roadmap-impact view showing exactly what JammJar would build to reach full capability parity and the dev-day effort to deliver it.

Key findings
JammJar leads by 9.6 points on capability-weighted scoring against Acre — ahead on 8 of 13 categories (plus 1 tie), including the entire AI & Automation surface.
43 JJ wins 31 Acre wins 54 parity Parity build ~200–335 dev-days
What SBG receives
Scored capability matrix against PMS / DA checklists
Gap analysis with effort estimates
Roadmap impact — post-build JammJar score & dev-day range
Open interactive capability explorer
02
OneView Integration

Integration architecture & data flow

Three integration options (levels of depth, not sequential phases) for JammJar ↔ OneView, plus the source-of-truth data map grounded in the real JammJar production schema.

What Shane sees
Three integration depths — event-driven push, bidirectional REST, and MCP service layer. OAuth 2.0 + PKCE wired throughout (Shane's requirement).
7 entities mapped 33 MCP tools catalogued 3 integration depths
What SBG receives
Integration architecture across three depth options (event-driven, REST, MCP)
Source-of-truth data map across 7 entities with PII class and per-option availability flagged
View integration design
03
Commercial Models

DA SaaS & OneView commercial framing

Pricing, packaging, and go-to-market plan for the DA market opportunity, plus the commercial structure for OneView integration — meaningful software-subscription revenue for SBG, with a minimum fee floor underneath as the engagement guarantee.

Headline numbers
DA SaaS Base-case 5-year opportunity: £4.18M gross ARR from software subscriptions (Y5 £1.66M). OneView integration: £600k platform commitment over 3 years plus build and usage fees. £1.13M 5-year fee floor sits underneath as the contractual minimum. No revenue share.
Y1 Base £248k Y5 Base £1.66M 3 GTM routes
What SBG receives
DA SaaS proposition (pricing, packaging, go-to-market outline)
OneView integration commercial framing
View commercial models
04
Engagement Model

Service provision & partnership framework

How JammJar would deliver core CRM services to the PMS side of the business, and three engagement models for how SBG and JammJar could work together — commercial partnership, minority investment, or acquisition.

The three options
Commercial partnership (slowest, no capital), minority investment (early position, option to buy), or acquisition (turnkey route — product plus team).
Investment £750k–£2.5M Acquisition £12–£20M Integration depth inverse to commitment
What SBG receives
Service provision and partnership model review
Analysis of JammJar delivering core CRM to PMS
Three engagement models with risk, speed, and control comparison
View engagement options
Annexes Supporting evidence that sits alongside the four core deliverables — external proof and the full risk register.
A
Annex · Network proof point

Cornerstone Finance · 5-hour meeting, 20 April 2026

A 300-adviser, 114-firm AR network currently on Acre. Karl and Chris walked them through JammJar end-to-end. Captured in full fidelity: what they asked, what they reacted to, and why they closed the session with "I have quite a few concerns about staying with Acre".

Why this matters
A customer already important to SBG, on Acre for years, did their own deep technical due diligence on JammJar — and ratified every capability claim in this proposal.
300 advisers 114 firms 5hr technical DD
What SBG gets from this
How a live network responds to JammJar on first serious exposure
Network-admin layer requirements validated in real time
Commercial channel structure already discussed and received positively
Read the meeting record
B
Annex · Risks & mitigations

Risks & mitigations

Risks framed around the decision SBG is being asked to make. The register starts with what it costs not to act — then lays out the risks of the proposal itself and the mitigations that sit against them.

What's in the register
Four risks of not acting — competitor-owned Acre penetration in the PMS member base, no internal engineering mirroring capability, no flagship CRM partner for the OneView integration, no AI-automation partner. Three risks of this proposal — the change programme required for member adoption, SBG-side engineering capacity gating integration depth, and JammJar's pre-profit P&L profile. Each with a named mitigation.
4 risks of not acting 3 risks of proposal 100% mitigated
What SBG gets from this
Decision-framed view — the risks of inaction are the ones that dominate
Every proposal-risk paired with a named, actionable mitigation
Honest treatment of P&L exposure across the three engagement models
Open the risk register
Four deliverables · two annexes · evidence-based · confidential to SBG Executive
Deliverables › Executive Summary
Executive Summary

Executive Summary

A train-readable synthesis of the four deliverables. An overall verdict up front, then a half-page on each workstream. Deeper evidence sits behind every link.

00

Overall verdict

JammJar delivers everything SBG needs from a PMS CRM and OneView integration partner — and, objectively scored, does so better than the incumbent alternative.

Across 128 features measured head-to-head, JammJar scores 83.3 against Acre's 73.7 today, and reaches 97.4 after the Acre-parity roadmap. The OneView integration has three viable depths, each grounded in the real JammJar production schema and ready to build. The DA market commercial opportunity is real (£4.18M five-year gross ARR in the Base case from software subscriptions) and a £1.13M five-year fee floor sits underneath as the contractual guarantee. Cornerstone Finance — an experienced 300-adviser Acre user inside the SBG ecosystem — ratified every capability claim independently. Three engagement models are offered; minority investment preserves optionality at £750k–£2.5M.

Balanced today
+9.6pts
JJ 83.3 vs Acre 73.7
Post-roadmap
+23.7pts
JJ 97.4 vs Acre 73.7
Parity effort
~200–335*
dev-days, indicative
Build items
21
covering 31 Acre-win features

JammJar leads Acre today by 9.6 points under balanced weighting across 128 features — decisively in AI & Automation (where Acre has no comparable answer) and comfortably in client records, document handling and case management. Acre's genuine advantages are addressable: RMAR regulatory reporting (P0 for DA firms), a dedicated compliance view, payments-settled pipeline tracking, and a pre-built report library. The roadmap impact view consolidates every Acre-wins feature into 21 JammJar builds, with an indicative effort range; after that work JammJar scores 97.4 and the lead widens to 23.7 points. The capability matrix is reviewer-weightable — balanced is the lead figure; DA-firm, AI-first and network weightings shift the balance but the direction of travel does not.

Option 1 · Event-driven push + SSO
Lowest SBG-side lift. OAuth 2.0 with OneView as IdP (Shane Wright-confirmed). Deliverable by JammJar alone against today's schema.
Option 2 · Bidirectional REST
Adds pull + drill-down on top of Option 1. Requires SBG-side REST endpoints for firms, advisers, policies, commissions.
Option 3 · Full MCP service layer
Agent-consumable tool surface across JammJar. Requires SBG-side MCP clients to consume the tool catalogue.

All three options are grounded in real JammJar production schema (MariaDB 10.11, per-client database isolation) with dual IDs (bigint + UUID) throughout. The data mapping covers 424 fields across seven entities — Customer, Case, Application, Fact-find, Documents, Audits & Checks, Activity & Telephony — every field tagged with PII class, per-option availability, and Now-vs-Proposed status. Proposed items flag where new rollup tables, cross-tenant aggregation, or OneView-side data layers are required (firm_id and network_id are OneView-side joins, annotated inline). Options are depth choices, not sequential phases — SBG starts at the depth that matches engineering capacity today and moves deeper at the pace engineering permits.

Y5 DA SaaS ARR · Base
£1.66M
40% penetration · 240 firms · 600 seats
5-year gross · Base
£4.18M
from software subscriptions
Contractual floor
£1.13M
5-year minimum commitment
OneView platform fee
£600k
3-year minimum (£200k/yr)

The commercial model has two parts. Part 1 — DA SaaS: Base case projects £248k → £1.66M ARR from software subscriptions over Year 1–5 (£4.18M gross over five years), built on 600 addressable firms × 2.5 advisers × cumulative 6%–40% penetration × £200/seat/month × 15% SBG markup × 0% churn. Conservative is Base minus 20% on penetration plus 10% churn; Growth is Base plus 20% on penetration at £220. Three GTM routes — Pure referral, Joint go-to-market, SBG acquires JammJar. Part 2 — OneView integration: SBG is the customer, paying JammJar to deliver — £200k/year platform fee (3-year minimum = £600k floor), £1,000/developer/day build cost phased through Option 1/2/3, a per-adviser monthly usage fee (£5–£15). No revenue share anywhere. Underneath DA SaaS sits a £1.13M five-year fee floor that functions as the contractual minimum whether the penetration curve hits Base or not.

Commercial partnership
Contract only
Slowest rollout · shallowest integration
Minority investment
£750k – £2.5M
Info rights + board observer · medium influence
Acquisition
£12M – £20M
Full ownership · full influence · team implant

The engagement model is deliberately structured so that integration depth is inverse to commitment. A Commercial Partnership is the slowest route and leaves OneView integration depth gated on SBG-side engineering capacity without any shared ownership. A Minority Investment (indicative £750k–£2.5M, fast to close, info rights plus board observer without a seat, medium influence on the roadmap) preserves optionality — SBG takes a position early with the ability to buy more in future. An Acquisition (indicative £12–20M, full ownership, full roadmap influence) is framed as a turnkey move: the deal delivers the AI-native engineering team as well as the product. Delivery profile is the same across all three: 6–8 weeks to delivery, 8–12 weeks pilot, go-to-market Q3, scale into Year 2+.

Cornerstone Finance — a 300-adviser, 114-firm mortgage network, currently an Acre customer and an important customer to SBG — committed a five-hour technical due diligence session with JammJar on 20 April 2026. They entered as experienced Acre users actively seeking an alternative; they closed the session with the words “I have quite a few concerns about staying with Acre” and an October 2026 go-live target under board review. Across the case types that reflect day-to-day PMS-club activity, Cornerstone confirmed JammJar works today for regulated mortgage (standard purchase, remortgage, complex), works perfectly for buy-to-let including limited-company BTL, and is materially better than Acre on protection & GI. They flagged two where development is required before first-class coverage: equity release (handled today as referral) and commercial mortgage (not covered end-to-end). The verdict matters because it came from experienced Acre practitioners, not from JammJar — and it corroborates every capability claim in Deliverable 01.

The risk register is reframed around the decision SBG is being asked to make. Four risks of not acting sit up front and dominate: (1) a growing proportion of SBG's PMS members are on Acre — now owned by a future competitor; (2) SBG does not have internal engineering mirroring capability to deliver the OneView solution at the depth described; (3) no flagship CRM partner is currently available to hold the other end of OneView integration at meaningful depth (Acre is owned by a competitor, Smartr365 has no API); (4) no AI-automation partner for the capabilities this proposal describes — they are not a feature set, they are a full AI engineering programme. Three risks of the proposal itself sit behind: change programme required to land adoption; SBG-side engineering capacity gates deeper OneView integration options; JammJar is not yet profitable, which is a P&L consideration under Minority Investment and Acquisition routes. Each is mitigated by named actions in the relevant deliverable.

Deliverables › OneView Integration
Deliverable 02

OneView Integration Design

How JammJar connects to OneView to enable a centralised single customer view across SBG — current-state architecture, target-state design, and a phased path to production.

▶
Launch simulation Interactive · 3 scenes

Executive summary

OneView is SBG's single source of truth for activity across its PMS and Network businesses. JammJar's role is to feed OneView with adviser-level activity — and, depending on how deep SBG wants the integration to run, to become the intelligence layer OneView can interrogate directly.

We see three options for SBG, spanning light-touch to full interoperability. These are not sequential phases — they are levels of integration SBG can choose between based on appetite, commercial structure, and where JammJar sits in the long-term architecture.

01 · Light-touch
Event-driven push & SSO
02 · Interoperable
Bidirectional API
03 · Strategic
Full MCP service layer

The global picture: OneView as the group oversight hub

OneView sits above SBG's PMS and Network businesses as the single source of truth for adviser activity, compliance outcomes, and commercial pipeline. What reaches OneView depends entirely on what each firm's underlying CRM exposes.

Today the PMS club runs predominantly on two CRMs: Acre and Smartr365. Both are structural systems — they record cases, track statuses, hold client records. OneView's oversight of PMS firms is therefore capped at the depth those two platforms can offer. Rich, AI-native capability — file audit, fact-find extraction, continuous compliance scoring — is outside both of their feature sets.

JammJar enters the PMS stack as a third option — not a replacement. Firms that choose JammJar get an AI-native CRM that accelerates their own day-to-day work; OneView gets a vastly richer oversight surface for those firms; and SBG's internal compliance and network teams get a toolkit they can reach into from OneView itself. The offering to PMS club members expands, and the quality of group oversight lifts in step.

SBG EXEC · GROUP OVERSIGHT ONEVIEW SBG's single source of truth · PMS + Network activity compliance oversight · pipeline visibility · group reporting ONEVIEW DATA STORE single source of truth · PMS · Network PMS CRM LAYER ACRE CRM REST API · integrable structural data only NO AI SERVICES Firms on Acre — day-to-day case work SMARTR365 no API surface manual / batched only NO AI SERVICES Firms on Smartr365 — oversight blind-spot today JAMMJAR AI-native · fully integrable structural + rich services 8+ AI SERVICES · LIVE file audit suitability call review thin feed minimal / intermittent LIVE · service-rich THE CHOICE-DRIVEN POSITIONING The PMS club is a choice-driven market. JammJar sits alongside Acre and Smartr365 as the AI-native option — and for every firm that adopts it, OneView's oversight depth lifts dramatically. thin structural feed minimal / intermittent live service-rich feed
Acre and Smartr365 stay. Firms that have built their operations on either one aren't being moved. The question isn't "which CRM wins" — it's "what do we offer firms who want more?"
JammJar is the upgrade path. For firms looking to write more business with less operational drag, JammJar is the differentiated offering on the club menu. AI-native throughout, built for the FCA's Consumer Duty era.
OneView's oversight scales with adoption. Every firm that joins JammJar gives OneView a service-rich feed instead of a structural one. Group oversight capability grows firm-by-firm, without any change to how Acre or Smartr firms operate.

The JammJar service layer: three audiences, one engine

JammJar's AI-native capabilities aren't just a benefit for adopting advisers. They're a shared service layer that three different audiences inside and around SBG can consume — each for a different purpose, each getting compounding value from the others' use.

JAMMJAR SERVICE ENGINE 🔍 File audit ✅ Compliance scoring 📋 Fact-find extraction 📄 Suitability drafting 📞 Call QA & review 🛡️ Consumer Duty evidence + FULL AUDIT TRAILS ON EVERY ACTION ONEVIEW · GROUP OVERSIGHT invokes JammJar services for network-wide reporting, risk surfacing, and on-demand audits across firms FIRM ADVISERS · DAY-TO-DAY • calls auto-transcribed & indexed • fact-finds extracted automatically • suitability reports drafted in seconds • affordability from raw bank statements • lender matches kept fresh continuously SBG INTERNAL TEAMS • compliance officers run on-demand audits • network supervisors pull evidence packs • file-audit team works at 10× throughput • telephony QA covered across all firms • regulator responses drafted from source data oversight & reporting day-to-day workflows audit · supervision · evidence One engine · three audiences · compounding value Every adviser interaction creates data that OneView can oversee and SBG teams can act on. Every SBG audit refines the signal that feeds back to advisers. Every OneView report is evidenced by source material. The more the engine is used, the more useful it becomes to all three.
For advisers
Faster work, more business written

AI takes on the work advisers can't scale: transcribing calls, extracting fact-finds, drafting suitability reports, running affordability from raw statements, keeping lender matches live. Advisers spend their day on client conversations — not admin.

Outcome More cases per adviser per month. Lower drop-off rate. Better advice quality. More business placed.
For OneView
Oversight with real teeth

Beyond "what cases are in flight", OneView can now see every Consumer Duty signal, every compliance score, every call-level QA flag — and invoke services on demand to go deeper. Reports stop describing activity and start evidencing it.

Outcome FCA-ready evidence on demand. Risk surfaced before it becomes incident. Group oversight that actually oversees.
For SBG internal teams
A force multiplier for compliance & supervision

File-audit teams, network supervisors, and compliance officers reach into JammJar services through OneView. On-demand audits, automatic evidence packs, full telephony review coverage — work that used to take weeks happens in minutes.

Outcome The same team covers more firms, more deeply, with better evidence trails. Regulator responses drafted from source data.
Capability uplift · exposed through OneView

Ten live services that land inside SBG's oversight stack

Every service below is already in production at JammJar today. None are on Acre or Smartr365's roadmaps. Each is exposed to adviser workflows in the CRM, to OneView's oversight surfaces through the integration, and to SBG's internal audit and compliance teams through the staff tooling.

01
Automated compliance engine
Continuous file-level oversight, delivered by AI rather than sampling.
File audit

Run a full compliance file review on any case in the book. Evidence pack lands in OneView with every finding tagged and justified.

Compliance scoring

Every case scored on completeness, risk, and Consumer Duty adherence as it progresses. OneView sees the score; SBG sees the trend.

Bank-statement audit

Automated affordability analysis from raw bank statements. Summary, red flags, and the full working — all retained in the audit trail.

Consumer Duty evidence

Every client outcome instrumented against the four Consumer Duty outcomes. OneView pulls firm-level or network-level evidence on demand.

02
Case & conversation intelligence
Structured data created from the work advisers do, rather than bolted on after.
Fact-find extraction

Adviser calls converted into structured fact-find data automatically. No re-keying. No gaps. Evidence of client understanding built into the record.

Suitability generation

Regulator-ready suitability reports drafted from case data. OneView can request a draft, a final, or an evidence-bundle — on demand.

Telephony review & QA

Every adviser call captured, transcribed, indexed, and scored for compliance. SBG's QA team can query an entire network's conversations in seconds.

Lender criteria match

Continuous check against live lender criteria. When terms move, affected cases surface in OneView automatically — proactive oversight, not retrospective.

03
Oversight & evidence surfaces
Defensible records and query access, landed into SBG's compliance workflow.
Full audit trails

Every action, every AI output, every service call recorded. Defensible evidence by default — the regulator's first question already has an answer.

SBG staff AI tooling

The same engine available to compliance officers, supervisors, and audit teams. Natural-language queries across any firm's activity, with evidence attached.

12/13 AI features won
JammJar's capability lead across AI-driven operations is 12 of 13 AI features won in the balanced-weighting analysis. See Deliverable 01 for the full capability matrix.
Option 1 · Light-touch

Event-driven information push & SSO

JammJar pushes state changes into OneView as they happen, and OneView's CTO requirement for single sign-on is included in the same bundle — advisers log into OneView, click a button, and land authenticated inside JammJar. The lowest-coupling option on the stack.

JAMMJAR State change case · check · suitability Event emitter Laravel observer WEBHOOK DISPATCHER HMAC · retry · idempotent ONEVIEW Ingestion endpoint receives · acks · maps Single source of truth PMS + Network activity GROUP OVERSIGHT compliance · pipeline · audit application.status_changed check.completed · suitability.signed One-way flow · fire-and-forget · full audit trail on both sides
How it works
  • JammJar fires events on state changes: application.status_changed, check.completed, suitability.signed
  • Payloads signed with HMAC, versioned schema, idempotency key per event, retry with exponential backoff
  • OneView receives, acknowledges, and maps events onto its single-source-of-truth record
  • SSO via OAuth 2.0 — OneView is the identity provider; advisers authenticate there and JammJar accepts the token
  • One-click traversal from inside OneView into the relevant JammJar record, already signed in
What SBG gets
  • Near-real-time visibility of JammJar activity inside OneView
  • Compliance outcomes and submission progress surface group-wide without manual reporting
  • Clean FCA audit trail — every event logged both sides
  • Seamless login experience for advisers — no second set of credentials to manage
  • OneView remains the identity and oversight authority; JammJar is the activity source
SBG stands up
Webhook receiver, payload contract, OAuth identity provider config
JammJar stands up
Event schema, OAuth consumer, session exchange flow
Character
Low coupling · high value · proven pattern on both sides
Events JammJar emits & the SSO handshake

Outbound events carry state changes from JammJar into OneView. Each has a signed, versioned payload; each expects an acknowledgement. Every card below cites the source tables in the current production schema. Events tagged Now can be emitted against today's schema; those tagged Proposed require new tables or aggregation jobs. firm_id and network_id are OneView-side joins, not JammJar columns — annotated inline where they appear.

EVENT application.status_changed Now

Fires whenever case__application.stage transitions — DIP, submitted, under review, offer issued, completed, declined. Emitted via Laravel observer on the application model.

Payload sent 
{
  "event": "application.status_changed",
  "event_id": "evt_9f3a...",
  "ts": "2026-04-21T10:14:02Z",
  "firm_id": "frm_8421",          // OneView-side join
  "network_id": "net_sesame",     // OneView-side join
  "case": {
    "id": 4471,
    "uuid": "9f3ab2c1-4b18-..."
  },
  "application": {
    "id": 5523,
    "uuid": "2c11d7e3-a0f2-..."
  },
  "user_id": 193,                 // JJ adviser (user.id)
  "from_stage": 3,                // case__application.stage enum
  "to_stage": 5,
  "lender_id": 42,
  "mortgage_amount": 275000,
  "product_code": "HFX-5Y-85LTV"
}
Acknowledgement expected 
HTTP 202 Accepted
{
  "received": true,
  "event_id": "evt_9f3a..."
}
SCHEMAcase__application · audits · audit_log
stage enum is tinyint — from_stage/to_stage are raw values from the same column. OneView resolves to human-readable labels.
EVENT check.completed Now

Fires when an AI file-audit workflow finishes. Maps to case__application_check_workflow — carries the summary, compliance_rating, and items_for_attention straight from the row.

Payload sent 
{
  "event": "check.completed",
  "event_id": "evt_7b12...",
  "ts": "2026-04-21T11:02:41Z",
  "firm_id": "frm_8421",          // OneView-side join
  "case": {
    "id": 4471,
    "uuid": "9f3ab2c1-4b18-..."
  },
  "application_check_id": 881,
  "check_workflow_id": 12,        // template used
  "summary": "Income evidence present…",
  "compliance_rating": 78,
  "items_for_attention": 2,
  "status": 3                      // workflow status enum
}
Acknowledgement expected 
HTTP 202 Accepted
{ "received": true }
SCHEMAcase__application_check · case__application_check_workflow · case__application_check_question
EVENT suitability.signed Now

Fires when a suitability report is marked complete and sent. Today: an entry in suitability_report with non-null edited_by / edited_at. Document reference is the signed PDF in document.

Payload sent 
{
  "event": "suitability.signed",
  "event_id": "evt_c442...",
  "ts": "2026-04-21T14:08:00Z",
  "firm_id": "frm_8421",          // OneView-side join
  "case": {
    "id": 4471,
    "uuid": "9f3ab2c1-4b18-..."
  },
  "suitability_report_id": 231,
  "application_id": 5523,
  "document": {
    "id": 3329,
    "uuid": "7b44aa18-9e03-...",
    "signed_url": "https://...sig=...",
    "signed_url_expires_at": "2026-04-21T14:18Z"
  },
  "signed_by_user_id": 193,
  "template_id": 7,
  "template_version_id": 22
}
Acknowledgement expected 
HTTP 202 Accepted
{ "received": true }
SCHEMAsuitability_report · suitability_report_template_version · document
EVENT customer.upserted Now

Fires on material changes to a customer row or related preference tables. Minimal PII — IDs and a change summary only; full detail is fetched on demand via Option 2 REST.

Payload sent 
{
  "event": "customer.upserted",
  "event_id": "evt_ff12...",
  "ts": "2026-04-21T09:31:15Z",
  "firm_id": "frm_8421",          // OneView-side join
  "customer": {
    "id": 2210,
    "uuid": "c8a1f704-22e5-..."
  },
  "change": "marketing_preferences_updated",
  "summary": {
    "has_email": true,
    "has_phone": true,
    "marketing_opt_out": false,
    "stage": 4                    // customer.stage enum
  }
}
Acknowledgement expected 
HTTP 202 Accepted
{ "received": true }
SCHEMAcustomer · customer__marketing_preferences · audits
EVENT case.created Now

Fires on new case creation. Simple lightweight event that OneView can use to keep its case directory aligned.

Payload sent 
{
  "event": "case.created",
  "event_id": "evt_case_...",
  "ts": "2026-04-21T08:14:00Z",
  "firm_id": "frm_8421",          // OneView-side join
  "case": {
    "id": 4471,
    "uuid": "9f3ab2c1-4b18-..."
  },
  "status": 1,                    // case.status enum
  "referrer_name": "Acme Estate Agents",
  "lead_source_id": 3,
  "created_by_user_id": 193
}
Acknowledgement expected 
HTTP 202 Accepted
{ "received": true }
SCHEMAcase · lead_sources
EVENT document.uploaded Now

Fires when a document lands — uploaded by adviser, by client via portal, or produced by the AI (call recording, IDV output). For bank statements, extracted metadata is carried on the event.

Payload sent 
{
  "event": "document.uploaded",
  "event_id": "evt_doc_...",
  "ts": "2026-04-21T09:47:00Z",
  "firm_id": "frm_8421",          // OneView-side join
  "case": {
    "id": 4471,
    "uuid": "9f3ab2c1-4b18-..."
  },
  "document": {
    "id": 3329,
    "uuid": "7b44aa18-9e03-...",
    "name": "payslip_2026-03.pdf",
    "mime": "application/pdf",
    "size": 218174,
    "category_id": 2,
    "state": 3                    // document.state enum
  },
  "uploaded_by_user_id": 193,
  "bank_statement_metadata": null  // populated for bank statements
}
Acknowledgement expected 
HTTP 202 Accepted
{ "received": true }
SCHEMAdocument · document__metadata · document__customer
EVENT call.completed Now

Fires when an AI-telephony call ends and transcription/summarisation completes. Full transcript stays in JammJar (PII); the event carries IDs, duration, and the adviser-visible summary.

Payload sent 
{
  "event": "call.completed",
  "event_id": "evt_call_...",
  "ts": "2026-04-21T10:36:00Z",
  "firm_id": "frm_8421",          // OneView-side join
  "call": {
    "id": 9921,
    "started_at": "2026-04-21T10:22:00Z",
    "ended_at": "2026-04-21T10:35:47Z",
    "direction": "outbound",
    "state": 2                    // call.state enum
  },
  "case": {
    "id": 4471,
    "uuid": "9f3ab2c1-4b18-..."
  },
  "user_id": 193,                 // advising user
  "customer_id": 2210,
  "summary": "Discussed affordability, confirmed deposit source…",
  "document_id": 3411             // recording file ref
}
Acknowledgement expected 
HTTP 202 Accepted
{ "received": true }
SCHEMAcall · call_history · call_states · document
EVENT commission.recorded Now

Fires when a commission entry is recorded, updated, or paid. Keeps OneView aligned with the procuration / advice-fee figures JammJar tracks per application.

Payload sent 
{
  "event": "commission.recorded",
  "event_id": "evt_comm_...",
  "ts": "2026-04-21T12:01:22Z",
  "firm_id": "frm_8421",          // OneView-side join
  "case_commission_id": 552,
  "commissionable_type": "case__application",
  "commissionable_id": 5523,
  "commission_type_id": 2,
  "amount": 137500,               // pence
  "due_date": "2026-05-14",
  "payment_received": 0,
  "advisor_id": 193
}
Acknowledgement expected 
HTTP 202 Accepted
{ "received": true }
SCHEMAcase__commission · commission_types
amounts held in pence at DB level; consumer display formats to £
EVENT adviser.activity_day Proposed · requires build

Daily rollup of adviser activity — calls made, fact-finds progressed, suitability reports sent. Useful for OneView dashboards without pulling granular events. Requires a build: nightly aggregation job against activity_log.

Payload sent 
{
  "event": "adviser.activity_day",
  "event_id": "evt_day_...",
  "ts": "2026-04-22T00:05:00Z",
  "firm_id": "frm_8421",          // OneView-side join
  "user_id": 193,
  "date": "2026-04-21",
  "metrics": {
    "calls_logged": 14,
    "fact_finds_updated": 3,
    "cases_progressed": 6,
    "documents_uploaded": 11,
    "suitability_signed": 2
  }
}
Acknowledgement expected 
HTTP 202 Accepted
{ "received": true }
NEW TABLESadviser_activity_day
Proposed table — nightly rollup derived from activity_log, call, case__application, document, suitability_report
EVENT firm.compliance_snapshot Proposed · requires build

Periodic firm-level compliance health snapshot — aggregate check workflow outcomes, open items_for_attention, trend. Fired on schedule and on threshold breach. Requires a build: firm-level aggregation is OneView-side (firm boundary is not in JJ schema).

Payload sent 
{
  "event": "firm.compliance_snapshot",
  "event_id": "evt_snap_...",
  "ts": "2026-04-21T03:00:00Z",
  "firm_id": "frm_8421",          // OneView-side entity
  "period": "2026-W16",
  "source_metrics": {
    "avg_compliance_rating": 81.4,
    "open_items_for_attention": 27,
    "workflows_run": 142,
    "trend": "improving"
  }
}
Acknowledgement expected 
HTTP 202 Accepted
{ "received": true }
NEW TABLESfirm_compliance_snapshot
Proposed table — firm boundary requires OneView→JJ firm mapping. Underlying metrics already available from case__application_check_workflow.
SSO FLOW OAuth 2.0 Authorization Code + PKCE Required

Per Shane Wright's requirement: OneView is the identity provider. An adviser signed into OneView clicks "Open in JammJar"; JammJar redirects to OneView's authorization endpoint; the token is exchanged server-to-server and the adviser lands inside JammJar authenticated in the correct tenant context.

What OneView sends 
// Step 1 — user click in OneView
GET https://app.jammjar.com/sso/start
  ?return_to=/cases/9f3ab2c1-4b18-...
  &firm_hint=frm_8421

// Step 3 — token exchange (server-to-server)
POST https://oneview.sbg/oauth/token
{
  "grant_type": "authorization_code",
  "code": "ac_...",
  "code_verifier": "dBjft…",      // PKCE
  "client_id": "jammjar",
  "redirect_uri":
    "https://app.jammjar.com/sso/cb"
}
What JammJar receives & does 
// Token response from OneView
{
  "access_token": "ey...",
  "id_token": "ey...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "openid profile jammjar:firm"
}

// JammJar verifies signature, resolves
// id_token → user.id, mints a session,
// redirects to /cases/<uuid>
REQUIRES BUILD OAuth consumer + id_token → user.id mapping table. Tenant-context resolution (firm_hint → which DB) sits alongside JammJar's existing per-client isolation.
Option 2 · Interoperable

Bidirectional API

JammJar and OneView both expose APIs to each other. Events continue as before; now either side can ask the other for deeper data on demand.

JAMMJAR REST API · exposes /cases · /advisers · /activity API consumer pulls firm & adviser directory Event emitter Option 1 stream · retained OAuth 2.0 · service-level auth ONEVIEW API consumer drills into case depth REST API · exposes /firms · /advisers · /policy Event ingestion single source of truth PMS + Network activity GET /cases · /advisers/{id}/activity GET /firms · /advisers · /policy events (Option 1, retained) Request/response in both directions · events continue to flow underneath
How it works
  • JammJar exposes tenant-scoped REST endpoints; OneView holds a service-level credential
  • OneView exposes firm, adviser, policy, and directory endpoints for JammJar to consume
  • Typical JammJar-side calls: GET /api/v1/cases?updated_since=…, GET /api/v1/advisers/{id}/activity
  • Both sides: pagination, filtering, field-selection, rate limiting
  • Option 1 event stream continues operating — Option 2 adds pull, it doesn't replace push
What SBG gets
  • On-demand depth — OneView can drill from a summary card into full case history
  • JammJar picks up firm / adviser / policy changes from OneView without manual sync
  • Foundation for embedded widgets (a JammJar case panel inside a OneView screen)
  • Supports reconciliation flows where both sides need to cross-check a record
SBG stands up
OneView REST surface, API consumer in OneView, token-based auth for service-to-service
JammJar stands up
Tenant-scoped REST API, OneView directory consumer, widget-ready endpoints
Character
Reciprocal · both systems become more valuable when used together
Bidirectional REST endpoints

Option 2 opens both systems to each other through versioned, tenant-scoped REST. Events from Option 1 continue flowing. Endpoints tagged Now are deliverable against today's schema; Proposed means new tables or aggregation jobs are required. OneView-side endpoints are annotated OneView-side — JammJar consumes them.

Endpoints JammJar exposes — OneView calls these
GET /api/v1/cases Now

List cases with pagination, filtering, field selection. Used by OneView to hydrate its case list when an oversight user drills into a firm.

Request 
GET /api/v1/cases
  ?firm_id=frm_8421            // OV-side filter
  &status=2                       // case.status enum
  &updated_since=2026-04-14T00:00:00Z
  &fields=id,uuid,status,title,user_id,
          lender_id,mortgage_amount
  &page=1&per_page=50
Authorization: Bearer <service token>
Response 
200 OK
{
  "data": [
    {
      "id": 4471,
      "uuid": "9f3ab2c1-4b18-...",
      "title": "Smith - Residential purchase",
      "status": 2,
      "user_id": 193,
      "lender_id": 42,
      "mortgage_amount": 275000,
      "created_at": "2026-04-01T09:00:00Z",
      "updated_at": "2026-04-20T14:22:00Z"
    }
  ],
  "meta": { "page": 1, "total": 86 }
}
SCHEMAcase · case__mortgage · case__application
firm_id is an OneView-side filter applied via tenant mapping; not a JammJar column.
GET /api/v1/cases/{uuid} Now

Full case detail with selectable facets. Drives "drill into case" from OneView. Facets map 1:1 to schema sub-tables.

Request 
GET /api/v1/cases/9f3ab2c1-4b18-...
  ?include=customer,mortgage,property,
          application,checks,documents,
          factfind,timeline
Authorization: Bearer <service token>
Response 
200 OK
{
  "id": 4471,
  "uuid": "9f3ab2c1-4b18-...",
  "status": 2,
  "user_id": 193,
  "customer": { "id": 2210, "uuid": "...", ... },
  "mortgage": { ...case__mortgage... },
  "property": { ...case__property... },
  "application": { ...case__application... },
  "checks": [
    { "workflow_id": 12,
      "compliance_rating": 78,
      "items_for_attention": 2,
      "status": 3 }
  ],
  "documents": [ {"id": 3329, "uuid": "...",
                  "category_id": 2, "state": 3} ],
  "factfind": { "completeness": 0.92 },
  "timeline": [ ...audit_log entries... ]
}
SCHEMAcase · customer · case__mortgage · case__property · case__application · case__application_check_workflow · document · fact__find · audit_log
GET /api/v1/applications/{uuid} Now

Full application record — lender, product, all rate steps, complete ERC ladder, fees, recommendation rationale. Supports OneView drilling into a specific product submission.

Request 
GET /api/v1/applications/2c11d7e3-a0f2-...
Authorization: Bearer <service token>
Response 
200 OK
{
  "id": 5523,
  "uuid": "2c11d7e3-a0f2-...",
  "case_id": 4471,
  "lender_id": 42,
  "product_code": "HFX-5Y-85LTV",
  "stage": 5,
  "mortgage_amount": 275000,
  "term_years": 25,
  "rate_initial": 4.34,
  "rate_initial_term": 60,
  "rate_initial_type": 1,
  "rate_year_2": 7.99,
  "rate_year_3": 7.99,
  "standard_variable_rate": 8.49,
  "erc": true,
  "erc_year_1": 13750,
  "erc_year_2": 11000,
  "erc_year_3": 8250,
  "erc_year_4": 5500,
  "erc_year_5": 2750,
  "procuration_fee": 137500,      // pence
  "advice_fee_amount": 50000,
  "application_date": "2026-04-10",
  "offer_date": null
}
SCHEMAcase__application · lender · product_type · product_status
Full 10-year ERC ladder is a real schema feature — columns erc_year_1…erc_year_10.
GET /api/v1/documents/{uuid} Now

Document metadata plus a short-lived signed URL for the file content. Bank statement metadata (account, date, closing balance) is included when available.

Request 
GET /api/v1/documents/7b44aa18-9e03-...
Authorization: Bearer <service token>
Response 
200 OK
{
  "id": 3329,
  "uuid": "7b44aa18-9e03-...",
  "name": "bank_stmt_2026-03.pdf",
  "mime": "application/pdf",
  "size": 218174,
  "category_id": 1,
  "state": 3,
  "case_id": 4471,
  "application_id": 5523,
  "uploaded_at": "2026-04-15T10:22Z",
  "signed_url": "https://storage...?sig=...",
  "signed_url_expires_at": "2026-04-21T14:18Z",
  "metadata": {
    "account_number": "****1234",
    "date": "2026-03-31",
    "closing_balance": 8142.55
  }
}
SCHEMAdocument · document__metadata · document__customer
Raw file bytes never exposed directly — always via signed URL. contents_extract (binary) stays inside JJ.
GET /api/v1/checks/workflows Now

List AI file-audit workflow runs with their compliance rating, items for attention and status. Supports OneView dashboards tracking outstanding items across a firm.

Request 
GET /api/v1/checks/workflows
  ?firm_id=frm_8421
  &status=3                        // in-progress / complete enum
  &min_items_for_attention=1
Authorization: Bearer <service token>
Response 
200 OK
{
  "data": [
    {
      "id": 881,
      "application_check_id": 55,
      "check_workflow_id": 12,
      "case_id": 4471,
      "compliance_rating": 78,
      "items_for_attention": 2,
      "status": 3,
      "summary": "Income evidence present but…",
      "created_at": "2026-04-21T10:50Z"
    }
  ],
  "meta": { "total": 27 }
}
SCHEMAcase__application_check_workflow · case__application_check · check__workflow
POST /api/v1/cases/search Now

Compound-filter case search — status, application stage, amount range, lender, has-open-workflow-items, dates. Returns matching case summaries.

Request 
POST /api/v1/cases/search
{
  "filters": {
    "status_in": [2, 3],
    "application_stage_in": [4, 5],
    "mortgage_amount_gte": 200000,
    "lender_id_in": [42, 57],
    "has_open_check_items": true,
    "updated_since": "2026-04-01T00:00:00Z"
  },
  "sort": [{ "updated_at": "desc" }],
  "page": 1, "per_page": 50
}
Authorization: Bearer <service token>
Response 
200 OK
{
  "data": [
    {
      "id": 4471,
      "uuid": "9f3ab2c1-4b18-...",
      "status": 2,
      "user_id": 193,
      "lender_id": 42,
      "mortgage_amount": 275000,
      "open_items_for_attention": 2
    }
  ],
  "meta": { "matched": 14 }
}
SCHEMAcase · case__application · case__application_check_workflow · lender
GET /api/v1/firms/{firm_id}/compliance Proposed · requires build

Firm-level compliance aggregate — average workflow rating, total items for attention, by adviser. Requires build: firm boundary sits in OneView, aggregation job needed against case__application_check_workflow.

Request 
GET /api/v1/firms/frm_8421/compliance
  ?window=30d
Authorization: Bearer <service token>
Response 
200 OK
{
  "firm_id": "frm_8421",            // OV-side
  "window_days": 30,
  "workflows_run": 142,
  "avg_compliance_rating": 81.4,
  "total_items_for_attention": 27,
  "by_user": [
    {
      "user_id": 193,
      "workflows_run": 42,
      "avg_rating": 83.2,
      "items_for_attention": 7
    }
  ]
}
NEW TABLE / AGGREGATIONfirm_compliance_rollup
Proposed — requires OneView→JJ firm tenant mapping and scheduled rollup query. Underlying data exists in case__application_check_workflow + user.
Endpoints OneView exposes — JammJar calls these
GET /oneview/v1/firms OneView-side

Firm directory with FCA references, network membership, DA / AR status. JammJar syncs nightly for tenant-structure alignment. Firm is a OneView-side entity; JammJar stores the mapping in a lookup table.

Request 
GET /oneview/v1/firms
  ?updated_since=2026-04-20T00:00:00Z
Authorization: Bearer <JJ service token>
Response 
200 OK
{
  "data": [
    {
      "id": "frm_8421",
      "name": "Acme Mortgages Ltd",
      "fca_ref": "123456",
      "network_id": "net_sesame",
      "status": "active",
      "da_or_ar": "AR"
    }
  ]
}
NEW TABLE (JJ SIDE)firm_tenant_map
JJ-side: a firm_tenant_map lookup — (firm_id, tenant_db_name, fca_ref). Built during onboarding, refreshed from this endpoint.
GET /oneview/v1/advisers OneView-side

Adviser directory — who works at which firm, competency permissions, SPS status, CPD currency. Authoritative for FCA-side adviser attributes. JammJar joins to user.user_id to enrich adviser records.

Request 
GET /oneview/v1/advisers
  ?firm_id=frm_8421
Authorization: Bearer <JJ service token>
Response 
200 OK
{
  "data": [
    {
      "id": "adv_0193",
      "jj_user_id": 193,               // JJ-side mapping
      "firm_id": "frm_8421",
      "full_name": "Sarah Patel",
      "sps_valid_until": "2026-09-30",
      "permissions": ["residential","buy_to_let"],
      "cpd_status": "current"
    }
  ]
}
SCHEMAuser · team · team__assignment
JJ side: user.user_id (not PK) is used as the external identifier for OneView cross-reference.
GET /oneview/v1/policies/{firm_id} OneView-side

Network-specific compliance policy — questions, thresholds, rule overlays to apply to cases in that firm's tenant. Pulled by JammJar and hydrated into the check__workflow template layer.

Request 
GET /oneview/v1/policies/frm_8421
Authorization: Bearer <JJ service token>
Response 
200 OK
{
  "firm_id": "frm_8421",
  "policy_version": "2026.3",
  "required_questions": [
    { "slug": "aml_source_of_deposit",
      "criteria": "Evidence required if deposit > £10k" }
  ],
  "thresholds": {
    "min_compliance_rating": 70,
    "vulnerable_customer_review": "mandatory"
  }
}
SCHEMAcheck__workflow · check__workflow_category · check__workflow_question
JJ side: incoming policy questions populate check__workflow_question rows against the appropriate workflow template.
GET /oneview/v1/commissions/{firm_id} OneView-side

Commission statements — received-from-lender and payable-to-adviser breakdown by case. JammJar consumes read-only; source of truth for commission sits with SBG.

Request 
GET /oneview/v1/commissions/frm_8421
  ?period=2026-04
Authorization: Bearer <JJ service token>
Response 
200 OK
{
  "firm_id": "frm_8421",
  "period": "2026-04",
  "statements": [
    {
      "jj_case_uuid": "9f3ab2c1-4b18-...",
      "jj_application_uuid": "2c11d7e3-...",
      "lender": "Halifax",
      "gross_amount": 137500,        // pence
      "net_to_firm": 96250,
      "received_on": "2026-04-18"
    }
  ]
}
SCHEMAcase__commission
JJ side: incoming statements reconcile against existing case__commission rows by (commissionable_type, commissionable_id).
POST /oneview/v1/events/ack OneView-side

Acknowledgement endpoint for the event stream from Option 1 — reused here. Included for completeness of the bidirectional surface.

Request 
POST /oneview/v1/events/ack
{
  "event_id": "evt_9f3a...",
  "received_at": "2026-04-21T10:14:03Z"
}
Response 
202 Accepted
{ "ok": true }
SCHEMAaudit_log
JJ-side ack receipts recorded in audit_log as outbound_event_acknowledged.
Option 3 · Strategic

Full MCP service layer

JammJar exposes its full capability set as a Model Context Protocol server. OneView — and whatever AI layer sits on top of it — can discover and invoke JammJar tools dynamically. This is where JammJar stops being a separate system and becomes part of SBG's AI-native infrastructure.

JAMMJAR MCP SERVER typed tools · streaming natural-language ready Case & compliance engine REST API Option 2 · retained Event emitter Option 1 · retained capabilities exposed as tools MCP PROTOCOL discover · negotiate invoke · stream ONEVIEW MCP CLIENT AI-layer driven intent → tool call AI layer / assistant Group oversight surfaces PMS & Network workflows discovers & invokes tools REST (Option 2) — dashed: still flowing events (Option 1) — dashed: still flowing OneView's AI discovers & invokes JammJar tools dynamically · zero-UI integration
How it works
  • JammJar runs an MCP server exposing its full capability set as typed tools
  • OneView's AI layer connects as an MCP client, discovers tools, negotiates schemas
  • Natural-language intents from adviser or oversight users map to JammJar tool calls
  • Option 1 events and Option 2 REST continue to operate underneath — MCP sits on top
What SBG gets
  • JammJar capability is accessible from any AI tool SBG chooses to run — not tied to a specific vendor
  • "Run a full audit on this firm's last quarter" → executes as a JammJar tool call
  • Zero UI to maintain — capability appears wherever the AI layer surfaces it
  • JammJar is positioned as infrastructure underneath SBG's AI strategy, not displaced by it
SBG stands up
AI layer (orchestrator / assistant) capable of consuming MCP tools
JammJar stands up
MCP server exposing typed tools, schemas, streaming responses
Character
AI-native · zero-UI · JammJar becomes infrastructure beneath OneView
MCP tools JammJar exposes

Each tool is a typed function an AI layer can discover, validate against schema, and invoke. Inputs are JSON objects; outputs are structured results with citations and provenance. Every call is recorded in the audit trail. Tools tagged Now can be exposed against today's schema (20 tools); Proposed means new tables, cross-tenant aggregation, or OneView-side data layers are required (13 tools).

✓ Compliance & oversight Run audits, score cases, surface risks and generate evidence packs on demand. 8 tools · 2 now · 6 proposed
MCP TOOL jammjar.file_audit.run Now

Run the AI file-audit workflow against an application. Returns the workflow summary, compliance rating, and per-question outcomes.

Input 
{
  "case_uuid": "9f3ab2c1-4b18-...",
  "application_uuid": "2c11d7e3-a0f2-...",
  "workflow_id": 12              // check__workflow.id
}
Output 
{
  "workflow_run_id": 881,        // case__application_check_workflow.id
  "compliance_rating": 78,
  "items_for_attention": 2,
  "status": 3,
  "summary": "Income evidence present…",
  "questions": [
    {
      "question_id": 47,
      "answer": "Self-employed 2y",
      "passed": true,
      "confidence": 92,
      "confidence_reason": "SA302 x2 attached",
      "reason": "Match on 3-year rule"
    }
  ]
}
SCHEMAcase__application_check_workflow · case__application_check_question · check__workflow · check__workflow_question
MCP TOOL jammjar.case.score Proposed · requires build

Score a single case across multiple dimensions — completeness, compliance, risk. Completeness comes from fact-find coverage today; compliance wraps workflow rating. Multi-dimensional scoring model requires build.

Input 
{
  "case_uuid": "9f3ab2c1-4b18-...",
  "dimensions": ["completeness",
                 "compliance",
                 "risk"]
}
Output 
{
  "scores": {
    "completeness": 92,
    "compliance": 78,
    "risk": 64
  },
  "evidence": {
    "completeness":
      "118/128 fact-find fields populated",
    "compliance":
      "workflow_run 881: rating 78"
  }
}
REQUIRES BUILD / AGGREGATIONcase_scoring_model
Requires a scoring service. Today's schema can feed completeness (fact__*) and compliance (case__application_check_workflow); risk model is new.
MCP TOOL jammjar.firm.audit_sweep Proposed · requires build

Run a compliance sweep across an entire firm's recent case book. Firm boundary is OneView-side, so this requires tenant mapping + batched workflow runs.

Input 
{
  "firm_id": "frm_8421",        // OV-side
  "window_days": 90,
  "sample": "all" | "risk_weighted"
}
Output 
{
  "cases_reviewed": 142,
  "workflows_run": 142,
  "breaches": 3,
  "amber_flags": 18,
  "top_themes": ["income_evidence"],
  "report_url": "https://..."
}
REQUIRES BUILD / AGGREGATIONcase__application_check_workflow · firm_tenant_map
Requires firm→tenant mapping + batched orchestration. Underlying workflow engine exists today.
MCP TOOL jammjar.consumer_duty.evidence Proposed · requires build

Generate a Consumer Duty evidence pack — outcome-by-outcome with citations. No Consumer Duty tracking exists in the schema today; requires new outcome tagging against advice/recommendations.

Input 
{
  "subject_type": "firm" | "user",
  "subject_id": "frm_8421",     // OV-side for firm
  "period": "2026-Q1",
  "outcomes": ["price_value",
               "products_services",
               "understanding",
               "support"]
}
Output 
{
  "evidence_pack_url": "https://...",
  "outcome_scores": { ... },
  "gaps": [ "No vulnerable-customer MI" ],
  "provenance": [
    "case:9f3ab2c1-...",
    "call:551"
  ]
}
REQUIRES BUILD / AGGREGATIONconsumer_duty_outcome · consumer_duty_mapping
Requires new tagging layer over case__application, suitability_report, and call. No equivalent columns today.
MCP TOOL jammjar.vulnerability.detect Proposed · requires build

Scan recent calls and notes for signals of customer vulnerability. Today the schema only stores a single fact__detail.is_vulnerable boolean + free-text details — signal-type detection, confidence and unhandled-flagging require build.

Input 
{
  "scope": "user" | "case",
  "id": "9f3ab2c1-4b18-...",
  "window_days": 30,
  "signal_types": ["health",
                   "bereavement",
                   "financial_difficulty",
                   "capability"]
}
Output 
{
  "flagged": [
    {
      "case_uuid": "9f3ab2c1-4b18-...",
      "customer_id": 2210,
      "signal": "bereavement",
      "confidence": 0.87,
      "unhandled": true,
      "source": "call:9921 @ 14:22"
    }
  ]
}
REQUIRES BUILD / AGGREGATIONvulnerability_signal · vulnerability_detection_run
Today: fact__detail.is_vulnerable (bool) + vulnerable_details (text). Structured signal layer, confidence scoring and "unhandled" tracking are new.
MCP TOOL jammjar.rmar.generate Proposed · requires build

Auto-generate RMAR-ready MI from underlying case data. No RMAR mapping exists in the schema today. Requires build: field-level mapping from JJ columns to RMAR-G/K/A line items.

Input 
{
  "firm_id": "frm_8421",        // OV-side
  "period": "2026-Q1",
  "return_type": "RMAR-G"
                 | "RMAR-K" | "RMAR-A"
}
Output 
{
  "rows": [
    { "field": "G.1", "value": 142 }
  ],
  "provenance": [
    "case_query:…",
    "commission_source:…"
  ],
  "sign_off_required_by": "2026-04-30"
}
REQUIRES BUILD / AGGREGATIONrmar_field_mapping · rmar_return
Requires RMAR field mapping against case, case__application, case__commission. No mapping exists today.
MCP TOOL jammjar.tc.observation_sample Proposed · requires build

Pull a T&C sample of calls / fact-finds / submissions weighted by risk. No T&C sampling framework exists in the schema today — requires observation scheme definition tables.

Input 
{
  "scheme": "monthly_tc",
  "user_id": 193,
  "sample_size": 5,
  "weighting": "risk" | "random"
}
Output 
{
  "items": [
    {
      "type": "call",
      "ref_id": 9921,
      "case_uuid": "9f3ab2c1-...",
      "risk_score": 72,
      "themes": ["income_evidence"]
    }
  ],
  "rationale": "2 of 5 were risk-weighted…"
}
REQUIRES BUILD / AGGREGATIONtc_scheme · tc_observation_sample
Today's schema has no T&C sampling artefacts. Sample source data exists in call, fact__find, case__application.
MCP TOOL jammjar.audit_trail.fetch Now

Complete time-ordered audit trail for a case, customer, or user — every edit, every AI action, every change. Reads from two immutable streams + the change reconciliation layer.

Input 
{
  "subject_type": "case" | "customer"
                  | "application",
  "subject_uuid": "9f3ab2c1-4b18-...",
  "from": "2026-01-01",
  "to":   "2026-04-15"
}
Output 
{
  "events": [
    {
      "ts": "2026-03-18T09:12:00Z",
      "actor_user_id": 193,
      "source": "audits",
      "event": "updated",
      "auditable_type": "fact__detail",
      "auditable_id": 5510,
      "diff": { ... }
    }
  ],
  "sources_used": ["audits","audit_log","change"]
}
SCHEMAaudits · audit_log · activity_log · change · change__item
◈ Cases & applications Read, update, drive and close cases across the full advice lifecycle. 6 tools · 5 now · 1 proposed
MCP TOOL jammjar.case.get Now

Retrieve the complete state of a case — customer, fact-find, mortgage, property, application, documents, workflow checks, timeline — as one structured object.

Input 
{
  "case_uuid": "9f3ab2c1-4b18-...",
  "include": ["customer", "factfind",
              "mortgage", "property",
              "application", "documents",
              "checks", "timeline"]
}
Output 
{
  "case": { "id": 4471, "uuid": "...",
            "status": 2, ... },
  "customer": { "id": 2210, ... },
  "factfind": { ...fact__*... },
  "mortgage": { ...case__mortgage... },
  "property": { ...case__property... },
  "application": { ...case__application... },
  "documents": [ { "id": 3329, ... } ],
  "checks": [ { "workflow_run_id": 881,
                "compliance_rating": 78 } ],
  "timeline": [ ... ]
}
SCHEMAcase · customer · fact__find · case__mortgage · case__property · case__application · document · case__application_check_workflow · audit_log
MCP TOOL jammjar.case.search Now

Filter the case book by any combination of status, application stage, amount, lender, user, flags and dates. Returns matching case summaries.

Input 
{
  "filters": {
    "status_in": [2, 3],
    "application_stage_in": [4, 5],
    "mortgage_amount_gte": 200000,
    "lender_id_in": [42, 57],
    "has_open_check_items": true,
    "updated_since": "2026-02-01"
  },
  "limit": 50
}
Output 
{
  "total": 34,
  "results": [
    {
      "case_id": 4471,
      "case_uuid": "9f3ab2c1-4b18-...",
      "status": 2,
      "user_id": 193,
      "lender_id": 42,
      "mortgage_amount": 275000,
      "open_items_for_attention": 2
    }
  ]
}
SCHEMAcase · case__application · case__application_check_workflow · lender
MCP TOOL jammjar.case.timeline Now

Time-ordered narrative of everything that happened on a case — calls, document events, audits, status transitions, AI actions. Merges three activity streams.

Input 
{
  "case_uuid": "9f3ab2c1-4b18-...",
  "types": ["call", "document",
            "audit", "status_change",
            "ai_action"]
}
Output 
{
  "events": [
    {
      "ts": "2026-04-21T10:22:00Z",
      "type": "call",
      "ref_id": 9921,
      "summary": "Affordability discussion",
      "ai_generated": true
    }
  ]
}
SCHEMAcall · document · audits · audit_log · activity_log
MCP TOOL jammjar.application.status Now

Current stage and key milestone dates for any application — offer date, offer expiry, exchange, completion. Reads directly from case__application.

Input 
{
  "application_uuid": "2c11d7e3-a0f2-..."
}
Output 
{
  "application_id": 5523,
  "stage": 5,                   // case__application.stage
  "lender_id": 42,
  "application_date": "2026-04-10",
  "offer_date": null,
  "offer_expiry_date": null,
  "exchange_date": null,
  "completion_date": null,
  "open_workflow_items": 2
}
SCHEMAcase__application · case__application_check_workflow · lender
MCP TOOL jammjar.case.flag Proposed · requires build

Raise, clear or escalate an oversight flag on a case with typed reason + audit. Today flags are indirect — implicit in items_for_attention on workflow runs. A dedicated flag table with typed reasons is proposed.

Input 
{
  "case_uuid": "9f3ab2c1-4b18-...",
  "action": "raise" | "clear" | "escalate",
  "reason_code": "income_evidence_gap",
  "note": "Payslip missing page 2"
}
Output 
{
  "flag_id": 118,
  "state": "open",
  "audit_log_id": 9912
}
REQUIRES BUILD / AGGREGATIONcase_flag · case_flag_type
Today the workflow engine tracks items_for_attention but there's no free-standing typed-reason flag table. Audit already goes to audit_log.
MCP TOOL jammjar.lender_criteria.match Now

Match a case's fact-find against live lender criteria and return a ranked panel. Today runs through Twenty7tec via mortgage_sourcing__requests; the tool wraps that and structures the response.

Input 
{
  "case_uuid": "9f3ab2c1-4b18-...",
  "product_type": "residential_purchase",
  "packager_code": "twenty7tec"
}
Output 
{
  "sourcing_request_id": 771,
  "matches": [
    {
      "lender_id": 42,
      "lender_name": "Nationwide",
      "product": "5y fix @ 4.34",
      "ltv_max": 85,
      "max_loan": 310000,
      "why": "Self-employed 2y OK"
    }
  ]
}
SCHEMAmortgage_sourcing__requests · mortgage_sourcing__packagers · lender
Today: sourcing requests stored in mortgage_sourcing__requests.response (JSON). This tool provides a structured view over that.
⇄ Data extraction & enrichment Turn calls, documents and bank statements into structured, verified data. 5 tools · 5 now · 0 proposed
MCP TOOL jammjar.factfind.extract Now

Extract a structured fact-find from calls, documents, and existing records. Writes the result into the fact__* tables with source attribution per field.

Input 
{
  "case_uuid": "9f3ab2c1-4b18-...",
  "sources": ["calls", "documents"],
  "scope": "standard_mortgage_ff"
}
Output 
{
  "factfind_id": 441,           // fact__find.id
  "fields_populated": 118,
  "fields_total": 128,
  "confidence": {
    "fact__income.basic_income": 0.98
  },
  "gaps": [
    "fact__employment.status (partner)"
  ],
  "sources": {
    "fact__income.basic_income": "call:9921 @ 08:14"
  }
}
SCHEMAfact__find · fact · fact__detail · fact__income · fact__employment · fact__address · fact__commitment · fact__credit · fact__savings · fact__dependant
fact__find.request/response already stores raw extraction payloads; this tool produces the structured normalised writes into fact__*.
MCP TOOL jammjar.bank_statement.audit Now

Structured read of a bank statement — income verified, recurring spend classified, affordability risks flagged. Bank statement extraction is already a live JJ capability.

Input 
{
  "document_uuid": "7b44aa18-9e03-...",
  "months_required": 3,
  "use_for": "affordability"
}
Output 
{
  "document_id": 3329,
  "extract": {
    "account_number": "****1234",
    "closing_balance": 8142.55,
    "date": "2026-03-31"
  },
  "verified_income": 4250,
  "net_spend": 3170,
  "disposable": 1080,
  "recurring_commitments": [ ... ],
  "risk_flags": [ "gambling_tx" ]
}
SCHEMAdocument · document__metadata
document__metadata already captures account_number, date, closing_balance. Verification/classification output becomes supplementary extract JSON.
MCP TOOL jammjar.call.transcribe_and_review Now

Ingest a call recording, transcribe with speaker labels, extract advice steps, disclosures, risks and agreed actions. Already live via Deepgram — this tool exposes it via MCP.

Input 
{
  "call_source_url": "https://...",
  "case_uuid": "9f3ab2c1-4b18-...",
  "extract": ["transcript",
              "disclosures",
              "actions",
              "risk_flags"]
}
Output 
{
  "call_id": 9921,              // call.id
  "transcript": "…",            // call.transcript
  "summary": "…",               // call.summary
  "disclosures_covered":
    [ "fees", "data_use" ],
  "actions": [
    { "who": "adviser",
      "action": "send ILP pack" }
  ],
  "risk_flags": []
}
SCHEMAcall · call_history · call_states
call.transcript and call.summary are real columns populated on completion. Disclosures / actions / risk extraction is the model layer on top.
MCP TOOL jammjar.document.classify_and_extract Now

Classify any uploaded document (payslip, P60, SA302, ID, proof of deposit) and extract structured fields with confidence.

Input 
{
  "document_uuid": "7b44aa18-9e03-...",
  "expected_types": ["payslip",
                     "p60",
                     "bank_statement"]
}
Output 
{
  "document_id": 3329,
  "type": "payslip",
  "confidence": 0.97,
  "fields": {
    "gross_ytd": 41200,
    "employer": "Acme Ltd",
    "tax_code": "1257L"
  },
  "category_id": 4,             // assigned back to document
  "issues": []
}
SCHEMAdocument · document__metadata
document.contents + document.contents_extract already store extracted content; document.category_id holds classification.
MCP TOOL jammjar.factfind.reconcile Now

Reconcile captured fact-find against what documents and calls actually say. Surfaces discrepancies before they become check findings. Uses the existing change reconciliation layer.

Input 
{
  "case_uuid": "9f3ab2c1-4b18-...",
  "strictness": "standard" | "high"
}
Output 
{
  "reconciliation_run_id": 552,
  "discrepancies": [
    {
      "change_id": 881,
      "field": "fact__income.basic_income",
      "stated": 52000,
      "evidenced": 48500,
      "source": "document:3329 (payslip)"
    }
  ],
  "reconciled_count": 118
}
SCHEMAchange · change__item · fact__income · document
change + change__item already handle portal write reconciliation with conflict flags. This tool extends the same mechanism to document evidence.
◉ Firms, advisers & staff Supervisory visibility over firms, advisers, permissions and T&C status — across the network. 6 tools · 0 now · 6 proposed
MCP TOOL jammjar.firm.snapshot Proposed · requires build

Compliance, risk, activity snapshot for a firm. The one call an oversight team needs before a visit. Firm boundary is OneView-side, aggregation required.

Input 
{
  "firm_id": "frm_8421",        // OV-side
  "as_of": "2026-04-15"
}
Output 
{
  "firm_id": "frm_8421",
  "advisers": 14,               // from user/team mapping
  "active_cases": 287,
  "open_items_for_attention": 27,
  "rmar_due": "2026-04-30",
  "last_visit": "2025-11-08"
}
REQUIRES BUILD / AGGREGATIONfirm_compliance_rollup
Requires firm tenant mapping + rollup. Underlying data in case, case__application_check_workflow, user.
MCP TOOL jammjar.adviser.profile Proposed · requires build

Adviser profile — cases, outcomes, trend. Activity metrics come from real schema today; T&C status, permissions, SPS, breach rate live in OneView (fetched via Option 2 reverse endpoints).

Input 
{
  "user_id": 193,
  "period": "L90D"
}
Output 
{
  "user_id": 193,
  "full_name": "Sarah Patel",    // from user
  "cases_l90": 42,
  "completions_l90": 31,
  "avg_ttc_days": 37,
  "workflow_items_outstanding": 8,
  // from OneView (Option 2 join):
  "permissions": ["residential",
                  "buy_to_let"],
  "tc_status": "competent",
  "sps_valid_until": "2026-09-30"
}
REQUIRES BUILD / AGGREGATIONadviser_profile_rollup
JJ side: activity metrics from case, case__application, case__application_check_workflow. OV side: permissions / SPS / T&C. Combined in a rollup view.
MCP TOOL jammjar.network.query Proposed · requires build

Natural-language query across any firm or adviser's JammJar data, returning structured results with provenance. Requires NL query layer + network-level aggregation.

Input 
{
  "q": "which firms have 3+ open workflow
        items this quarter?",
  "scope": "network",
  "network_id": "net_sesame"    // OV-side
}
Output 
{
  "answer_summary": "4 firms currently…",
  "rows": [
    {
      "firm_id": "frm_8421",
      "open_items": 27,
      "trend": "stable"
    }
  ],
  "citations": [
    "case:9f3ab2c1-...",
    "case:8c11aa40-..."
  ]
}
REQUIRES BUILD / AGGREGATIONnl_query_layer
NL→SQL service + network-level aggregation required. Underlying data exists but network boundary is OV-side.
MCP TOOL jammjar.adviser.rank Proposed · requires build

Rank advisers across the network on any dimension — case quality, conversion, outcomes, breach rate. Ranking requires consistent metrics across firms.

Input 
{
  "dimension": "avg_compliance_rating",
  "scope": "firm" | "network",
  "id": "net_sesame",
  "min_cases": 20,
  "limit": 50
}
Output 
{
  "rows": [
    {
      "rank": 1,
      "user_id": 193,
      "score": 94,
      "cases_scored": 38
    }
  ]
}
REQUIRES BUILD / AGGREGATIONadviser_ranking_rollup
Requires cross-tenant aggregation. Underlying scoring comes from case__application_check_workflow.compliance_rating.
MCP TOOL jammjar.permissions.check Proposed · requires build

Verify whether a user or firm has the permissions required to advise on a product. Permissions live in OneView — this tool proxies a OneView call and caches locally.

Input 
{
  "subject_type": "user" | "firm",
  "subject_id": 193,
  "product_type": "equity_release"
}
Output 
{
  "authorised": true,
  "restrictions": [],
  "cpd_currency": "valid_to 2026-12-31",
  "source": "oneview_policy_cache",
  "checked_at": "2026-04-21T09:00Z"
}
REQUIRES BUILD / AGGREGATIONpermissions_cache
Proposed: local cache of OneView permissions calls (GET /oneview/v1/advisers). No permissions model in JJ today.
MCP TOOL jammjar.firm.compare Proposed · requires build

Compare any firm against network peers on any MI dimension. For 1:1 firm reviews and early-warning analytics. Requires cross-tenant rollup.

Input 
{
  "firm_id": "frm_8421",
  "peers": "size_band" | "network",
  "dimensions": ["avg_compliance_rating",
                 "items_per_case",
                 "conversion"]
}
Output 
{
  "firm": { "avg_compliance_rating": 84 },
  "peer_median":
    { "avg_compliance_rating": 79 },
  "percentile": 68,
  "outliers": []
}
REQUIRES BUILD / AGGREGATIONfirm_benchmark_rollup
▲ Performance & productivity Pipeline, throughput, time-in-stage and conversion metrics for users and firms. 4 tools · 4 now · 0 proposed
MCP TOOL jammjar.pipeline.snapshot Now

Live pipeline snapshot by stage, value, expected-close. Today: aggregates case.status and case__application.stage enums with sum of mortgage_amount.

Input 
{
  "scope": "user" | "team" | "firm",
  "id": 193,
  "stages": [1, 2, 3, 4, 5]
}
Output 
{
  "stages": {
    "2": { "count": 42, "sum_amount": 11550000 },
    "4": { "count": 18, "sum_amount":  4950000 },
    "5": { "count": 11, "sum_amount":  3025000 }
  },
  "expected_completions_30d": 9
}
SCHEMAcase · case__application · case__mortgage
Stage aggregation is real schema data. Firm scope requires OneView tenant mapping; user/team scope works today.
MCP TOOL jammjar.productivity.report Now

Per-user productivity — cases started, closed, time-in-stage, documents uploaded, calls logged. Derived from audit_log stage transitions + call + document.

Input 
{
  "scope": "user" | "team",
  "id": 193,
  "period": "2026-Q1"
}
Output 
{
  "users": [
    {
      "user_id": 193,
      "cases_started": 42,
      "cases_completed": 31,
      "avg_ttc_days": 37,
      "calls_logged": 124,
      "documents_uploaded": 487
    }
  ]
}
SCHEMAcase · case__application · audit_log · call · document
MCP TOOL jammjar.conversion.funnel Now

Conversion funnel — lead → appointment → fact-find → application submitted → offer → completion. Reads lead_statuses, case.status and case__application.stage enums.

Input 
{
  "scope": "user" | "team",
  "id": 193,
  "period": "2026-Q1",
  "lead_source_id": null
}
Output 
{
  "steps": [
    { "from": "fact_find",
      "to": "application_submitted",
      "rate": 0.84,
      "top_drop_reason": "income_gap" }
  ],
  "overall_conversion": 0.48
}
SCHEMAleads · lead_statuses · lead_sources · case · case__application
MCP TOOL jammjar.time_in_stage.hotspots Now

Where cases are stuck, for how long, why. Derived from audit_log entries of stage transitions combined with current stage dwell-time.

Input 
{
  "scope": "user" | "team",
  "id": 193,
  "threshold_days": 14
}
Output 
{
  "hotspots": [
    {
      "stage": 5,               // case__application.stage
      "cases": 34,
      "median_days": 22,
      "top_cause": "awaiting_valuation"
    }
  ]
}
SCHEMAcase__application · audit_log · audits
✦ AI-assisted workflows Generate, summarise, rewrite and orchestrate — directly from OneView or the SBG-staff assistant. 4 tools · 4 now · 0 proposed
MCP TOOL jammjar.suitability.draft Now

Draft a suitability report in the firm's template, grounded in the case evidence. Editable, audited, requires sign-off. Already live — this exposes it via MCP.

Input 
{
  "case_uuid": "9f3ab2c1-4b18-...",
  "application_uuid": "2c11d7e3-...",
  "template_id": 7,
  "template_version_id": 22,
  "tone": "plain_english"
}
Output 
{
  "suitability_report_id": 231,
  "content_url": "https://...",
  "citations": [
    { "text": "Net disposable £1,080",
      "source": "document:3329 p2" }
  ],
  "unverified_claims": []
}
SCHEMAsuitability_report · suitability_report_template · suitability_report_template_version
MCP TOOL jammjar.case.summarise Now

One-paragraph, one-page or board-pack summary of a case or application, grounded with citations.

Input 
{
  "subject_type": "case"
                  | "application"
                  | "customer",
  "subject_uuid": "9f3ab2c1-4b18-...",
  "length": "paragraph"
            | "one_pager"
            | "board_pack"
}
Output 
{
  "summary": "Mr & Mrs Patel, FTB £285k…",
  "sections": [ ... ],
  "citations": [
    "case:9f3ab2c1-...",
    "fact__income:441",
    "document:3329"
  ]
}
SCHEMAcase · customer · fact__find · case__application · document
MCP TOOL jammjar.letter.generate Now

Generate any standard client-facing letter (IDD / recommendation / offer / disengagement) in the firm's house style. Writes to document with appropriate category.

Input 
{
  "case_uuid": "9f3ab2c1-4b18-...",
  "letter_type": "IDD"
                 | "recommendation"
                 | "offer"
                 | "disengagement",
  "delivery": "email" | "portal" | "print"
}
Output 
{
  "document_id": 3412,
  "document_uuid": "8a21de33-...",
  "signed_url": "https://...",
  "suggested_send_to": "primary_email",
  "requires_sign_off": true
}
SCHEMAdocument · initial_disclosure_document · suitability_report_template · terms
IDD uses dedicated initial_disclosure_document table; other letter types write to document.
MCP TOOL jammjar.briefing.morning Now

Morning briefing for a user — cases needing attention, calls booked, items raised overnight. Aggregates task, notifications, case__application_check_workflow, and the adviser's scratchpad.

Input 
{
  "user_id": 193,
  "include": ["priority_cases",
              "open_items_for_attention",
              "bookings",
              "overnight_notifications"]
}
Output 
{
  "briefing_text": "3 cases need action…",
  "priorities": [
    { "case_uuid": "9f3ab2c1-4b18-...",
      "why": "offer expires tomorrow" }
  ],
  "open_workflow_items": 2,
  "tasks_due_today": 4
}
SCHEMAtask · notifications · case__application · case__application_check_workflow · scratchpad

Data mapping — JammJar schema available to OneView

This is JammJar's full data surface as it relates to adviser activity: the core entities (Customer, Case, Application, Fact-find) plus the operational layers that support them (Documents, Audits & checks, Activity & telephony). Every field OneView can ingest is listed below with type, description, PII class, and which integration option(s) surface the field.

Fact-find alone is backed by ~35 fact_* sub-tables spanning identity, employment, income (basic/variable/SE/rental/pension/investment/benefits), outgoings, credit commitments, assets, liabilities, credit events, property, deposit sources, health declarations, vulnerability, preferences, objectives, life events, and existing arrangements. All of it is reachable via Option 2 REST and Option 3 MCP; Option 1 events carry the minimum-necessary subset.

CORE ENTITIES & OPERATIONAL LAYERS ONEVIEW CAN INGEST CUSTOMER the client identity · contact · vulnerability CASE advice instance compliance · lifecycle · evidence APPLICATION product submission lender · decisions · offer · fees FACT-FIND ~35 fact_* sub-tables income · health · ATR · history DOCUMENTS evidence layer files · versions · signatures AUDITS & CHECKS AI assessment runs findings · scores · model lineage ACTIVITY & TELEPHONY calls · transcripts · notes · timeline events customer touchpoints · engagement 1:n 1:n 1:1 Solid arrows: primary relationships · Dashed: cross-entity references via FK
Availability per option 01 Event push 02 API 03 MCP not surfaced
PII classification PIIpersonal data SENSspecial-category or sensitive —non-sensitive

The client record and everything attached directly to them — names, contact, marketing preferences, ID verification (Onfido workflow state), customer-portal progress, T&Cs and IDD acceptance. One customer can have many cases.

Identifiers & ownership customer
FieldTypeDescriptionPIIOptions
idbigintJammJar canonical customer ID (auto-increment)—
uuiduuidStable external identifier — preferred reference in integrations—
entrust_applicant_idvarchar(255)Entrust (KYC provider) applicant reference where captured—
user_idbigintFK → user. Owning adviser—
lead_idbigintFK → leads. Originating lead, where applicable—
lead_source_idbigintFK → lead_sources. Where the customer came from—
stagetinyintCustomer lifecycle stage (enum)—
created_attimestampFirst captured—
updated_attimestampLast modified—
deleted_attimestampSoft-delete timestamp (nullable)—
Identity & names customer
FieldTypeDescriptionPIIOptions
titletinyintTitle enum (Mr / Mrs / Ms / Miss / Mx / Dr …)PII
firstnamevarchar(50)Given namePII
middlenamesvarchar(100)All middle namesPII
surnamevarchar(50)Family namePII
namevarchar(255)Generated: firstname + " " + surname (stored column)PII
known_asvarchar(100)Preferred first name used in correspondencePII
known_as_namevarchar(255)Generated: known_as + " " + surname (stored column)PII
maiden_namevarchar(50)Birth name if differentPII
marital_statustinyintMarital status enumPII
dobdateDate of birthPII
agebigintAge (stored — derived from dob)PII
gendertinyintGender enumPII
nationalitytinyintNationality enumPII
ni_numbervarchar(100)National Insurance number where capturedSENS
Contact customer
FieldTypeDescriptionPIIOptions
emailvarchar(100)Primary email addressPII
phonevarchar(20)Primary phone numberPII
preferred_contact_timetinyintPreferred contact window enum—
notestextFree-text customer notes (adviser-entered)PII
Marketing preferences customer__marketing_preferences
FieldTypeDescriptionPIIOptions
marketing_emailtinyint(1)Opted in to email marketing—
marketing_smstinyint(1)Opted in to SMS marketing—
marketing_telephonetinyint(1)Opted in to telephone marketing—
marketing_posttinyint(1)Opted in to postal marketing—
marketing_opt_outtinyint(1)Master opt-out flag—
ID verification (Onfido workflow) customer_id_verification
FieldTypeDescriptionPIIOptions
idbigintIDV record ID—
workflow_run_idvarchar(100)Onfido workflow run ID—
workflow_statusvarchar(50)Workflow status (in_progress / complete / error / expired …)—
workflow_outputtextOnfido workflow output (structured JSON)SENS
manual_decision_task_idvarchar(255)Manual review task ID (if reviewer intervention needed)—
manual_decision_bybigintFK → user. Reviewer who made manual decision—
manual_decision_resultvarchar(255)Manual decision (approved / rejected / further_evidence …)—
manual_decision_attimestampWhen manual decision was recorded—
applicant_idvarchar(100)Onfido applicant reference—
link_urltextClient-facing IDV link URL (short-lived)SENS
link_expires_attimestampWhen the IDV link expires—
started_attimestampWhen IDV was kicked off—
completed_attimestampWhen IDV completed—
has_documenttinyint(1)IDV captured a document—
has_face_capture_motiontinyint(1)IDV captured a biometric liveness check—
has_watchlisttinyint(1)Watchlist screening returned a resultSENS
documents_fetchedtinyint(1)Onfido documents pulled into the case—
Customer portal — section data & progress customer_portal_data · customer_portal_progress
FieldTypeDescriptionPIIOptions
sectionvarchar(255)Portal section identifier (fact-find segment / documents / T&Cs …)—
keyvarchar(255)Data point key within the section—
valuelongtextData point value submitted by the clientPII
completedtinyint(1)Client has completed this portal section—
T&Cs and IDD acceptance customer_terms_acceptance · initial_disclosure_document__customer
FieldTypeDescriptionPIIOptions
terms_idbigintFK → terms. Which terms version was accepted—
accepted_attimestampWhen the client accepted—
ip_addressvarchar(45)IP address at acceptance (audit evidence)PII
user_agenttextUser agent at acceptance—
initial_disclosure_document_idbigintFK → initial_disclosure_document—
accepted_attimestampWhen the client agreed to the IDD (if separate tracking)—

An instance of regulated advice given to a customer. The operational heart of JammJar — case header, mortgage details, property, products, protection and GI policies, commission, affordability budget, objectives and case-level notes.

Case header case
FieldTypeDescriptionPIIOptions
idbigintCanonical case ID—
uuiduuidStable external identifier—
titlevarchar(255)Human-readable case title—
statustinyintCase status enum—
status_npwtinyintNon-proceeding-with status (reason enum)—
referrer_idvarchar(255)External referrer reference—
referrer_namevarchar(255)Referrer namePII
referrer_emailvarchar(255)Referrer emailPII
lead_source_idbigintFK → lead_sources—
ai_processing_started_attimestampWhen AI processing began on this case—
ai_processing_completed_attimestampWhen AI processing finished—
created_attimestampCase created—
updated_attimestampLast modified—
deleted_attimestampSoft-delete timestamp—
Mortgage details case__mortgage
FieldTypeDescriptionPIIOptions
type_of_mortgagetinyintMortgage type enum (residential / BTL / bridging …)—
type_of_advancetinyintPurchase / remortgage / further advance / product transfer …—
loan_purposetinyintPrimary loan purpose enum—
mortgage_amountintMortgage amount (£)PII
deposit_amountintDeposit amount (£)PII
source_of_depositlongtextSource of deposit (free text / enum list)PII
source_of_deposit_notestextDeposit-source supplementary notesPII
net_equityintNet equity held in existing property (£)PII
term_requiredintDesired mortgage term (months)—
direct_debit_preference_datetinyintPreferred DD date—
monthly_rental_incomeintMonthly rental income (BTL cases, £)PII
vendor_builder_incentivestinyint(1)Incentives on this purchase—
incentives_detailslongtextIncentive details (free text)—
reason_for_debt_consolidationlongtextIf debt consolidation — reason (free text)PII
property_idbigintFK → case__property—
Property being transacted case__property
FieldTypeDescriptionPIIOptions
street_address1varchar(100)Property line 1PII
street_address2varchar(100)Property line 2PII
cityvarchar(100)CityPII
postcodevarchar(50)PostcodePII
purposetinyintProperty purpose enum—
tenuretinyintFreehold / leasehold / share of freehold enum—
typetinyintProperty type enum—
styletinyintProperty style enum (detached / semi / terraced / flat …)—
wallstinyintWall construction enum—
rooftinyintRoof construction enum—
year_builtsmallintYear built—
bedroomstinyintNumber of bedrooms—
receptionstinyintReception rooms—
bathroomstinyintBathrooms—
kitchenstinyintKitchens—
has_garagetinyint(1)Garage present—
is_new_buildtinyint(1)New-build flag—
is_commercialtinyint(1)Commercial property flag—
is_hmotinyint(1)HMO flag—
is_ex_counciltinyint(1)Ex-council flag—
is_current_propertytinyint(1)Is this the applicant’s current home—
is_being_soldtinyint(1)Existing property being sold—
valueintProperty value (£)PII
agreed_sale_priceintAgreed sale price where applicable (£)PII
original_purchase_priceintOriginal purchase price (£)PII
schemestinyintSchemes enum (shared ownership / help to buy / right to buy …)—
ownership_percentageintShared ownership percentage held (%)—
epctinyintEPC rating enum—
outbuildingstinyint(1)Outbuildings present—
has_other_adults_in_propertytinyint(1)Other adults residing (dependants / lodgers)PII
proposed_ownersvarchar(200)Proposed owners of the transacted propertyPII
Products attached to case case__products
FieldTypeDescriptionPIIOptions
titlevarchar(255)Product title—
referencevarchar(255)Product reference (internal)—
product_type_idbigintFK → product_type—
product_status_idbigintFK → product_status—
providervarchar(255)Provider name—
date_of_enquirydateEnquiry date—
date_writtendateDate of business—
premiumintPremium (£)PII
sum_assuredintSum assured (£)PII
sum_assured2intSecondary sum assured (£)PII
Protection policies on case case__protection
FieldTypeDescriptionPIIOptions
referencevarchar(255)Policy reference—
applicantsvarchar(255)Applicants coveredPII
sum_assuredintSum assured (£)PII
protection_typetinyintProtection type enum (life / CIC / IP …)—
protection_product_typetinyintProduct structure enum (level / decreasing / FIB …)—
protection_provider_idbigintFK → protection_providers—
protection_provider_othervarchar(255)Non-listed provider (free text)—
protection_stage_idbigintFK → protection_stages—
premiumintPremium (£)PII
premium_typetinyintPremium type enum (monthly / annual / single)—
protection_term_yearstinyintTerm (years)—
policy_datedatePolicy start date—
expiry_datedatePolicy expiry date—
policy_numbervarchar(255)Policy number (provider-issued)PII
commissionintCommission (£)—
commission_typetinyintCommission type enum—
advisor_idbigintFK → user. Advising user—
child_cover_optionvarchar(255)Child cover option on this policy—
tpd_includedtinyint(1)Total & Permanent Disability rider present—
trust_discussion_summarytextAdviser note on trust discussion—
inheritance_tax_advicetextAdviser note on IHT considerations—
provider_reasontextReason for provider selection—
provider_featurestextKey provider features—
General Insurance policies on case case__insurance
FieldTypeDescriptionPIIOptions
referencevarchar(255)Policy reference—
applicantsvarchar(255)Applicants coveredPII
property_addressvarchar(255)Property address coveredPII
sum_insuredintSum insured (£)PII
insurance_typetinyintGI type enum—
insurance_provider_idbigintFK → insurance_providers—
insurance_provider_othervarchar(255)Non-listed provider (free text)—
insurance_stage_idbigintFK → insurance_stages—
premiumintPremium (£)PII
premium_typetinyintPremium type enum—
accidental_includedtinyint(1)Accidental damage included—
no_claims_yearstinyintYears of no-claims—
policy_datedatePolicy start date—
expiry_datedatePolicy expiry date—
policy_numbervarchar(255)Policy number (provider-issued)PII
Case commission entries case__commission
FieldTypeDescriptionPIIOptions
commissionable_typevarchar(255)Polymorphic type (application / protection / insurance)—
commissionable_idbigintPolymorphic ID of the earning product—
commission_type_idbigintFK → commission_types—
amountintExpected amount (£)—
due_datedateDue date—
payment_receivedintAmount received (£)—
payment_datedateDate received—
advisor_idbigintFK → user—
Affordability budget case__budget
FieldTypeDescriptionPIIOptions
household_mortgage_rentintHousehold mortgage / rent (£/mo)PII
household_utilitiesintUtilities (£/mo)PII
household_council_taxintCouncil tax (£/mo)PII
household_phone_televisionintPhone / TV / broadband (£/mo)PII
household_insuranceintHousehold insurance (£/mo)PII
household_otherintOther household costs (£/mo)PII
living_groceriesintGroceries (£/mo)PII
living_clothingintClothing (£/mo)PII
living_mobileintMobile (£/mo)PII
living_homehelpintHome help (£/mo)PII
living_laundryintLaundry (£/mo)PII
lifestyle_sportsintSports / gym (£/mo)PII
lifestyle_holidaysintHolidays (£/mo)PII
lifestyle_cigarettes_alcoholintCigarettes / alcohol (£/mo)PII
lifestyle_entertainmentintEntertainment (£/mo)PII
lifestyle_pensionintPension contributions (£/mo)PII
transport_petrolintPetrol (£/mo)PII
transport_commutingintCommuting (£/mo)PII
transport_carintCar costs (£/mo)PII
transport_insuranceintTransport insurance (£/mo)PII
transport_otherintOther transport (£/mo)PII
children_clothersintChildren's clothing (£/mo)PII
children_maintenanceintChild maintenance (£/mo)PII
children_nursery_or_school_feesdecimal(10,2)Nursery / school fees (£/mo)PII
affordability_total_net_incomeintComputed total net incomePII
affordability_total_outgoingsintComputed total outgoingsPII
affordability_disposable_incomeintComputed disposable incomePII
affordability_mortgage_and_insurance_monthly_budgetintMonthly budget for mortgage+insurancePII
Mortgage objectives & preferences case__objective
FieldTypeDescriptionPIIOptions
mortgage_typetinyintDesired mortgage type—
mortgage_type_reasontextReason for mortgage type choice—
repayment_typetinyintDesired repayment type—
repayment_type_reasontextReason for repayment type—
repayment_vehicle_typetinyintRepayment vehicle (if interest-only)—
mortgage_term_yearstinyintDesired term (years)—
mortgage_term_monthstinyintDesired term (months component)—
mortgage_term_reasontextReason for term choice—
mortgage_budgetintMortgage monthly budget (£)PII
mortgage_fix_requirementtinyint(1)Fixed rate wanted—
mortgage_fix_yearsintPreferred fixed rate period (years)—
mortgage_fix_reasontextReason for fixed-rate period—
mortgage_initial_product_periodlongtextInitial product period preference—
mortgage_initial_product_period_reasonlongtextReason for initial product period—
income_changetinyint(1)Expected income changePII
income_change_detailstextDetails of expected income changePII
expenditure_changetinyint(1)Expected expenditure changePII
expenditure_change_detailstextDetails of expected expenditure changePII
loan_repaymenttinyint(1)Planned loan repaymentPII
loan_repayment_detailstextDetails of planned loan repaymentPII
concerned_about_interest_ratestinyint(1)Client concerned about rate rises—
concerned_about_interest_rates_detailstextRate concern detail—
needs_repayment_guaranteetinyint(1)Needs repayment guarantee feature—
pre_retirement_termtinyint(1)Term to end before retirement—
no_repayment_chargetinyint(1)Wants no early repayment charge—
max_repayment_chargetinyint(1)Maximum acceptable ERC—
move_propertytinyint(1)May move property—
cash_or_deposit_accounts_on_handtinyint(1)Liquid funds availablePII
add_fees_to_loantinyint(1)Adding fees to loan—
speed_of_completiontinyint(1)Speed of completion priority—
vary_repaymentstinyint(1)Wants variable repayments—
over_paymentstinyint(1)Wants overpayment capability—
under_payment_or_holidaytinyint(1)Wants underpayment / holiday capability—
link_to_savings_or_currenttinyint(1)Wants link to savings / current account—
no_booking_feetinyint(1)No booking fee wanted—
portabilitytinyint(1)Portability wanted—
payment_variabilitytinyint(1)Payment variability wanted—
offset_mortgagetinyint(1)Offset mortgage wanted—
features_reasontextExplanation of feature choices—
free_valuationtinyint(1)Free valuation priority—
free_legalstinyint(1)Free legals priority—
Case notes & portal options case__note · case__portal_options · case__required_document · case__assignment
FieldTypeDescriptionPIIOptions
contenttextNote bodyPII
titlelongtextNote title—
typetinyintNote type enum (general / meeting / call / message …)—
portal_excluded_sectionslongtextSections hidden from client portal on this case—
category_idbigintRequired document category ID—
category_sub_idbigintRequired document sub-category ID—
countbigintHow many of this category required—
assignable_typevarchar(255)Polymorphic type on case assignment (user / team)—
assignable_idbigintPolymorphic ID of assignee—

A product submission to a specific lender. A case can have multiple applications — DIPs to multiple lenders, subsequent full applications, re-submissions. Holds rate detail, full ERC ladder, fees, reason-for-recommendation, plus the AI file-audit check workflow that runs over supporting documents.

Application record case__application
FieldTypeDescriptionPIIOptions
idbigintApplication ID—
uuiduuidStable external identifier—
case_idbigintFK → case—
user_idbigintFK → user. Owning user—
advisor_idbigintFK → user. Advising user—
lender_idbigintFK → lender—
property_idbigintFK → case__property—
type_of_mortgagetinyintMortgage type enum—
type_of_advancetinyintType of advance enum—
repayment_typetinyintRepayment / interest-only enum—
repayment_vehicle_typetinyintRepayment vehicle enum (interest-only cases)—
mortgage_purposetinyintMortgage purpose enum—
stagetinyintApplication stage enum (DIP / submitted / offer / completed …)—
product_codevarchar(150)Lender product code—
application_reference_numbervarchar(100)Lender-issued application referencePII
account_numbervarchar(100)Lender-issued account numberPII
lender_referencevarchar(100)Adviser-side reference—
application_datedateApplication submission date—
start_datedatePolicy / product start date—
offer_datedateOffer issued date—
offer_expiry_datedateOffer expiry date—
exchange_datedateExchange date—
completion_datedateCompletion date—
Financials case__application
FieldTypeDescriptionPIIOptions
mortgage_amountintMortgage amount (£)PII
deposit_amountintDeposit amount (£)PII
source_of_depositvarchar(150)Source of depositPII
income_amountintDeclared income (£)PII
total_debts_amountintTotal existing debts (£)PII
monthly_repayment_amountintMonthly repayment (£)PII
net_equityintNet equity in existing property (£)PII
term_requiredintTerm requested (months)—
term_yearsintTerm (years)—
debt_consolidationtinyint(1)Debt consolidation flag—
mortgaged_property_addresstextAddress of the mortgaged propertyPII
mortgaged_property_valueintMortgaged property value (£)PII
mortgaged_property_valuation_datedateValuation date—
applicantsvarchar(200)Applicants named on the applicationPII
vendor_builder_incentivestinyint(1)Incentives present—
incentivestinyintIncentive type enum—
incentives_detailslongtextIncentive details—
Rate & fees case__application
FieldTypeDescriptionPIIOptions
rate_initialdecimal(10,2)Initial rate (%)—
rate_initial_typetinyintInitial rate type enum (fixed / tracker …)—
rate_initial_termintInitial rate term (months)—
rate_initial_end_datedateInitial rate end date—
rate_steppedtinyint(1)Stepped rate flag—
rate_year_2decimal(10,2)Year 2 rate (%)—
rate_year_3decimal(10,2)Year 3 rate (%)—
rate_year_4decimal(10,2)Year 4 rate (%)—
rate_year_5decimal(10,2)Year 5 rate (%)—
standard_variable_ratedecimal(10,2)Reverting SVR (%)—
mortgage_feeintMortgage product fee (£)—
mortgage_fee_typetinyintMortgage fee type enum—
advice_feetinyint(1)Advice fee chargeable—
advice_fee_amountintAdvice fee (£)—
advice_fee_payabletinyintWhen advice fee is payable (enum)—
procuration_feeintProcuration fee (£)—
valuation_feeintValuation fee (£)—
add_fees_to_loantinyint(1)Fees added to loan—
Early Repayment Charges ladder case__application
FieldTypeDescriptionPIIOptions
erctinyint(1)ERC applies—
erc_detailslongtextERC terms (free text)—
erc_max_costintMaximum ERC cost (£)—
erc_year_1intYear 1 ERC (£)—
erc_year_2intYear 2 ERC (£)—
erc_year_3intYear 3 ERC (£)—
erc_year_4intYear 4 ERC (£)—
erc_year_5intYear 5 ERC (£)—
erc_year_6intYear 6 ERC (£)—
erc_year_7intYear 7 ERC (£)—
erc_year_8intYear 8 ERC (£)—
erc_year_9intYear 9 ERC (£)—
erc_year_10intYear 10 ERC (£)—
is_previous_erctinyint(1)Applicant currently inside an ERC period—
is_previous_erc_detailstextDetails of existing ERC—
Reason for recommendation & BTL case__application
FieldTypeDescriptionPIIOptions
reason_recommendationtinyintRecommendation rationale enum—
reason_othertextFree-text recommendation rationale—
lender_reasontextReason for lender selection—
comparative_illustration_providedtinyint(1)Comparative KFI/ESIS provided—
btl_company_nametextBuy-to-let company name (limited-company BTL)PII
btl_company_infotextCompany structure / shareholding detailPII
notestextAdviser notes on the applicationPII
solicitor_notestextSolicitor notesPII
estate_agent_notestextEstate agent notesPII
AI file-audit — check workflow header case__application_check · case__application_check_workflow
FieldTypeDescriptionPIIOptions
typesmallintCheck type enum (document type being audited)—
summarylongtextAI-generated summary of workflow outcome—
compliance_ratingintNumeric compliance rating produced by workflow—
items_for_attentionintCount of items flagged for human review—
statusintWorkflow status enum—
status_reasontextReason for current status—
check_workflow_idbigintFK → check__workflow—
AI file-audit — per-question results case__application_check_question
FieldTypeDescriptionPIIOptions
answertextAI answer to the check question—
reasontextAI reasoning / evidence basis—
errortextError if check failed to run cleanly—
confidenceintConfidence score (0–100)—
confidence_reasontextWhy the model gave this confidence—
completedtinyint(1)Check completed—
passedtinyint(1)Check passed—
check_workflow_question_idbigintFK → check__workflow_question—
AI file-audit — evidence links & notes case__application_check_customer · case__application_check_document · case__application_check_note
FieldTypeDescriptionPIIOptions
customer_idbigintFK → customer. Customer the check relates to—
document_idbigintFK → document. Source document for this check—
notetextReviewer note on a question or workflow—
user_idbigintFK → user. Note author—
Suitability report (mortgage) suitability_report
FieldTypeDescriptionPIIOptions
contentlongtextAI-generated suitability report bodyPII
edited_contentlongtextAdviser-edited versionPII
template_idbigintFK → suitability_report_template—
template_version_idbigintFK → suitability_report_template_version—
generated_bybigintFK → user. User who triggered generation—
edited_bybigintFK → user. User who last edited—
edited_attimestampLast edit timestamp—
Mortgage sourcing & packaging mortgage_sourcing__requests · package · package__requirement · mortgage_sourcing__packagers
FieldTypeDescriptionPIIOptions
typevarchar(255)Sourcing request type—
paramslongtextSourcing request parameters (JSON)PII
requestlongtextFull sourcing request bodyPII
responselongtextSourcing response payloadPII
package.application_idbigintFK → case__application. Package for application—
package__requirement.category_idbigintRequired-document category for packaging—
package__requirement.countbigintCount of documents required—
mortgage_sourcing__packagers.codevarchar(255)Packager code—
mortgage_sourcing__packagers.enabledtinyint(1)Packager enabled—

The full discovery record. Every fact* table combined — applicant detail, address history, employment, income (including self-employed three-year data), commitments, credit, savings, dependants, existing mortgages, protection priorities and existing cover, and a ~100-point medical questionnaire with GP/lifestyle/conditions/family-history sub-sections.

Fact-find container fact__find · fact
FieldTypeDescriptionPIIOptions
fact__find.idbigintFact-find record ID—
fact__find.paramslongtextFact-find source parameters (e.g. call extraction payload)PII
fact__find.requestlongtextFull extraction requestPII
fact__find.responselongtextFull extraction responsePII
fact.is_primarytinyint(1)Primary applicant on the case—
fact.customer_idbigintFK → customer—
fact.case_idbigintFK → case—
Applicant detail fact__detail
FieldTypeDescriptionPIIOptions
has_previous_nametinyint(1)Applicant has had a previous namePII
previous_namevarchar(255)Previous namePII
name_changed_ontimestampWhen the name changedPII
retirement_ageintPlanned retirement agePII
passport_typetinyintPassport / ID type enumPII
has_lived_in_uk_since_birthtinyint(1)Lived in UK since birthPII
how_long_lived_in_uk_yearsintYears lived in UKPII
visa_typevarchar(255)Visa type where applicableSENS
is_politically_exposedtinyint(1)PEP flagSENS
is_smokertinyint(1)Smoker (headline flag)SENS
is_vulnerabletinyint(1)Vulnerability flag capturedSENS
vulnerable_detailstextVulnerability detail (free text)SENS
is_first_time_buyertinyint(1)First-time buyer—
has_willtinyint(1)Has a will in place—
has_expected_income_changetinyint(1)Expects income to changePII
has_expected_expenditure_changetinyint(1)Expects expenditure to changePII
bank_namevarchar(255)Bank namePII
bank_sort_codevarchar(255)Sort codeSENS
bank_account_numbervarchar(255)Account numberSENS
Address history fact__address
FieldTypeDescriptionPIIOptions
street_address1varchar(100)Line 1PII
street_address2varchar(100)Line 2PII
cityvarchar(100)CityPII
postcodevarchar(50)PostcodePII
residential_statustinyintOwner / tenant / living-with-parents enum—
is_on_electoral_roletinyint(1)Electoral roll registered at address—
moved_in_atdateMove-in datePII
Employment & benefits fact__employment
FieldTypeDescriptionPIIOptions
job_titlevarchar(100)Job titlePII
statustinyintEmployment status enum—
start_datedateRole start datePII
years_in_roletinyintYears in role—
employer_namevarchar(100)Employer namePII
employer_addressvarchar(255)Employer addressPII
related_employertinyint(1)Employer connected to applicant (family-run / own company)PII
distinyint(1)Death-in-service benefit presentPII
dis_detailstextDIS detailPII
other_benefitstinyint(1)Other employer benefits—
other_benefits_detailstextOther benefits detail—
Income fact__income
FieldTypeDescriptionPIIOptions
income_typetinyintIncome type enum (employed / self-employed / director …)—
basic_incomeintBasic income amountPII
basic_income_typebigintBasic income frequency FK—
net_monthly_pay_amountintNet monthly pay (£)PII
bonusintBonus amountPII
bonus_frequencybigintBonus frequency FK—
commissionintCommission amountPII
commission_frequencybigintCommission frequency FK—
overtimeintOvertime amountPII
overtime_frequencybigintOvertime frequency FK—
allowancetinyint(1)Allowances present—
allowance_amountintAllowance amountPII
allowance_detailslongtextAllowance detailsPII
pension_deductionintPension deduction at sourcePII
pension_companytinyint(1)Company pension scheme—
matching_contributionstinyint(1)Employer matching contributions—
matching_contributions_detailslongtextMatching contribution details—
other_deductionstinyint(1)Other deductions—
other_deductions_amountintOther deductions amountPII
other_deductions_detailslongtextOther deductions detailPII
investment_annualintInvestment income (annual £)PII
pension_annualintPension income (annual £)PII
maintenance_annualintMaintenance income (annual £)PII
uc_annualintUniversal Credit (annual £)PII
child_benefittinyint(1)Claims child benefit—
child_benefit_annualintChild benefit (annual £)PII
child_benefit_children_countintChildren covered by child benefitPII
other_income_child_tax_credit_annualintChild tax credit (annual £)PII
other_income_rental_annualintRental income (annual £)PII
other_income_rental_mortgage_payment_ratiolongtextRental-to-mortgage payment ratio—
second_job_annualintSecond job income (annual £)PII
other_income_notestextOther income notesPII
salary_year1intSelf-employed: salary year 1 (£)PII
dividends_year1intSelf-employed: dividends year 1 (£)PII
company_net_profits_year1intSelf-employed: company net profits year 1 (£)PII
salary_year2intSelf-employed: salary year 2 (£)PII
dividends_year2intSelf-employed: dividends year 2 (£)PII
company_net_profits_year2intSelf-employed: company net profits year 2 (£)PII
salary_year3intSelf-employed: salary year 3 (£)PII
dividends_year3intSelf-employed: dividends year 3 (£)PII
company_net_profits_year3intSelf-employed: company net profits year 3 (£)PII
accountant_detailstextAccountant contact detailsPII
Commitments & credit fact__commitment · fact__credit
FieldTypeDescriptionPIIOptions
commitment.typetinyintCommitment type enum—
commitment.providervarchar(200)Lender / providerPII
commitment.beneficiarieslongtextBeneficiaries of the commitmentPII
commitment.original_amountintOriginal amount (£)PII
commitment.current_balanceintCurrent balance (£)PII
commitment.current_balance_datedateBalance-as-at date—
commitment.regular_monthly_payment_amountintRegular monthly payment (£)PII
commitment.minimum_monthly_payment_amountintMinimum monthly payment (£)PII
commitment.term_remaining_monthsintTerm remaining (months)—
commitment.credit_limitintCredit limit (£)PII
commitment.will_be_redeemedtinyint(1)Will be redeemed at completion—
credit.is_bankrupttinyint(1)BankruptSENS
credit.has_arrearstinyint(1)Has arrearsSENS
credit.has_defaultstinyint(1)Has defaultsSENS
credit.has_ccjtinyint(1)Has CCJSENS
credit.has_debt_managementtinyint(1)Debt management planSENS
credit.has_ivatinyint(1)IVASENS
credit.has_recent_payday_loantinyint(1)Recent payday loanSENS
credit.has_missed_paymentstinyint(1)Missed paymentsSENS
credit.has_repossessedtinyint(1)Prior repossessionSENS
credit.has_mortgage_declinedtinyint(1)Mortgage previously declinedSENS
credit.detailstextAdverse credit detailSENS
Savings & dependants fact__savings · fact__dependant
FieldTypeDescriptionPIIOptions
savings.emergency_fundtinyint(1)Emergency fund held—
savings.emergency_fund_amountintEmergency fund amount (£)PII
savings.emergency_fund_detailstextEmergency fund detailPII
savings.savingstinyint(1)Has savings—
savings.savings_detailstextSavings detailPII
dependant.namevarchar(150)Dependant namePII
dependant.relationshipvarchar(100)RelationshipPII
dependant.dobdateDate of birthPII
dependant.agebigintAgePII
dependant.dependant_ofvarchar(50)Which applicant the dependant belongs toPII
Existing mortgages on other properties fact__mortgage
FieldTypeDescriptionPIIOptions
mortgage_property_addressvarchar(150)Property addressPII
mortgage_lendervarchar(150)Existing lenderPII
mortgage_account_numbervarchar(150)Existing account numberSENS
mortgage_start_datedateStart datePII
mortgage_end_datedateEnd datePII
mortgage_type_of_mortgagetinyintMortgage type enum—
mortgage_type_of_advancetinyintAdvance type enum—
mortgage_repayment_typetinyintRepayment type enum—
mortgage_property_valuevarchar(150)Property value (£)PII
mortgage_remaining_balanceintRemaining balance (£)PII
mortgage_net_equityintNet equity (£)PII
mortgage_balance_datedateBalance-as-at date—
mortgage_term_remaining_yearsvarchar(150)Term remaining (years)—
mortgage_current_interest_ratevarchar(150)Current interest rate (%)—
Protection priorities & existing cover fact__protection
FieldTypeDescriptionPIIOptions
priority_pay_billstinyint(1)Priority: pay bills if out of work—
priority_unable_to_worktinyint(1)Priority: unable to work—
priority_critical_illnesstinyint(1)Priority: critical illness—
priority_deathtinyint(1)Priority: death—
priority_building_contentstinyint(1)Priority: buildings/contents—
life_covertinyint(1)Has life cover—
life_cover_providervarchar(150)Existing life cover providerPII
life_cover_amountintExisting life cover amount (£)PII
life_cover_premiumintExisting life cover premium (£)PII
life_cover_end_datedateExisting life cover end datePII
life_cover_under_insured_amountintUnder-insurance gap (£)PII
citinyint(1)Has CI cover—
ci_providervarchar(150)CI providerPII
ci_amountintCI amount (£)PII
ci_premiumintCI premium (£)PII
ci_end_datedateCI end datePII
ci_under_insured_amountintCI under-insurance gap (£)PII
incometinyint(1)Has income protection—
income_providervarchar(150)IP providerPII
income_amountintIP benefit (£)PII
income_premiumintIP premium (£)PII
income_end_datedateIP end datePII
income_under_insured_amountintIP under-insurance gap (£)PII
medical_covertinyint(1)Has PMI—
medical_cover_providervarchar(150)PMI providerPII
medical_cover_amountintPMI amount (£)PII
medical_cover_premiumintPMI premium (£)PII
medical_cover_end_datedatePMI end datePII
buildings_contentstinyint(1)Has buildings/contents cover—
buildings_contents_providervarchar(150)B&C providerPII
buildings_contents_amountintB&C cover (£)PII
buildings_contents_premiumintB&C premium (£)PII
buildings_contents_end_datedateB&C end datePII
Protection cover required & lifestyle fact__protect_cover · fact__protect_lifestyle
FieldTypeDescriptionPIIOptions
cover.type_of_coverintCover type enum—
cover.purpose_of_covertextPurpose of cover—
cover.sum_assuredintSum assured required (£)PII
cover.term_of_coverintTerm (years)—
cover.application_typeintSingle / joint enum—
cover.benefit_typeintBenefit type enum—
cover.premium_typeintPremium type enum—
cover.premium_waivertinyint(1)Waiver of premium—
cover.deferred_periodintDeferred period (IP)—
cover.indexationtinyint(1)Indexation required—
cover.max_monthly_premiumintMax affordable monthly premium (£)PII
cover.client_prioritiestextClient priority narrative—
cover.is_relevant_lifetinyint(1)Relevant Life policy—
cover.corporate_case_identifiervarchar(255)Corporate case identifier (Relevant Life)—
lifestyle.height_cmintHeight (cm)SENS
lifestyle.weight_kgintWeight (kg)SENS
lifestyle.bmidecimal(4,1)BMISENS
lifestyle.is_smokertinyint(1)Smoker flagSENS
lifestyle.has_smokedtinyint(1)Historic smokerSENS
lifestyle.smoking_historytextSmoking history detailSENS
lifestyle.alcohol_consumptiontextAlcohol consumption detailSENS
lifestyle.recreational_drug_usagetextRecreational drug usageSENS
lifestyle.dangerous_sport_or_activitiestextDangerous sports / activitiesSENS
lifestyle.current_doctorsvarchar(150)Current doctorSENS
Protection — claim history & existing medical fact__protect_claim_history · fact__protect_existing_medical · fact__medical_conditions
FieldTypeDescriptionPIIOptions
claim.datedatetimeClaim dateSENS
claim.typeintClaim type enumSENS
claim.valueintClaim value (£)SENS
existing_medical.diagnosestextExisting medical diagnosesSENS
existing_medical.medicationtextExisting medicationSENS
existing_medical.date_startdateWhen the condition startedSENS
existing_medical.date_enddateWhen the condition ended (if applicable)SENS
medical_conditions.diagnosestextConsolidated diagnoses (structured)SENS
medical_conditions.statustinyintCondition status enumSENS
medical_conditions.severityvarchar(255)SeveritySENS
medical_conditions.medicationtextMedicationSENS
Protection — employer benefits, existing policies, family history, group schemes fact__protect_employer_benefits · fact__protect_existing_policies · fact__protect_family_history · fact__protect_group_schemes · fact__protect_insurance
FieldTypeDescriptionPIIOptions
employer_benefits.employervarchar(255)EmployerPII
employer_benefits.coversvarchar(150)Covers provided—
employer_benefits.cover_totalintTotal cover (£)PII
employer_benefits.duration_of_benefitintDuration (months)—
employer_benefits.type_of_coverintCover type enum—
existing_policies.providervarchar(150)Existing providerPII
existing_policies.policy_numbervarchar(100)Existing policy numberSENS
existing_policies.coverstextCovers provided—
existing_policies.cover_totalintTotal cover (£)PII
existing_policies.monthly_costintMonthly cost (£)PII
existing_policies.start_datedateStart datePII
existing_policies.end_datedateEnd datePII
existing_policies.term_yearssmallintTerm (years)—
existing_policies.premium_typetinyintPremium type enum—
existing_policies.in_trusttinyint(1)Held in trust—
existing_policies.type_of_coverintCover type enum—
existing_policies.keepingtinyint(1)Keeping the policy—
family_history.relationvarchar(150)RelationSENS
family_history.conditionvarchar(150)ConditionSENS
family_history.age_of_onsetintAge of onsetSENS
group_schemes.scheme_typetinyintScheme type enum—
group_schemes.employer_namevarchar(150)Employer namePII
group_schemes.scheme_providervarchar(150)Scheme providerPII
group_schemes.cover_amountintCover amount (£)PII
group_schemes.premium_paid_bytinyintPremium payer enum—
group_schemes.start_datedateStart date—
group_schemes.end_datedateEnd date—
insurance.voluntary_excessintVoluntary excess (£)—
insurance.compulsory_excessintCompulsory excess (£)—
insurance.ncd_yearsintNo-claims years—
insurance.building_styleintBuilding style enum—
insurance.securitytextSecurity measures in place—
insurance.claims_history_summarytextClaims history summaryPII
Medical questionnaire — measurements & GP fact__medical_questionnaire
FieldTypeDescriptionPIIOptions
gp_practice_namevarchar(255)GP practice nameSENS
gp_practice_addresstextGP practice addressSENS
gp_practice_visitsintGP visits in last 12 monthsSENS
current_doctorsvarchar(255)Current treating doctorsSENS
gender_at_birthtinyintGender at birth (underwriting)SENS
height_cmintHeight (cm)SENS
weight_kgdecimal(4,1)Weight (kg)SENS
waist_size_inchintWaist size (inches)SENS
dress_sizevarchar(255)Dress sizeSENS
is_smokertinyint(1)Smoker flagSENS
has_ever_smokedtinyintHas ever smoked enumSENS
smoking_historyvarchar(255)Smoking history detailSENS
Medical questionnaire — alcohol, drugs & lifestyle fact__medical_questionnaire
FieldTypeDescriptionPIIOptions
alcohol_weekly_unitsintWeekly alcohol unitsSENS
alcohol_specialist_consultedtinyint(1)Consulted a specialist about alcoholSENS
alcohol_notesvarchar(255)Alcohol notesSENS
recreational_drug_use_ten_yearstinyint(1)Recreational drug use (last 10 years)SENS
unprescribed_drug_use_ten_yearstinyint(1)Unprescribed drug use (last 10 years)SENS
methadone_use_ten_yearstinyint(1)Methadone use (last 10 years)SENS
recreational_drug_notestextDrug use notesSENS
dangerous_activities_regulartinyint(1)Regular dangerous activitiesSENS
dangerous_activities_detailsvarchar(255)Dangerous activity detailsSENS
regular_sports_or_pastimestinyint(1)Regular sports / pastimes—
motorcycle_ridertinyint(1)Motorcycle riderSENS
driving_offences_disqualified_five_yearstinyint(1)Driving offences / disqualification (5y)SENS
travel_high_risk_five_yearstinyint(1)High-risk travel (5y)SENS
travel_outside_uk_two_yearstinyint(1)Travel outside UK (2y)—
Medical questionnaire — conditions (Y/N + detail) fact__medical_questionnaire
FieldTypeDescriptionPIIOptions
diabetes_heart_conditiontinyint(1)Diabetes / heart conditionSENS
stroke_tia_vessel_surgerytinyint(1)Stroke / TIA / vessel surgerySENS
cancer_lymphoma_leukaemia_melanomatinyint(1)Cancer / lymphoma / leukaemia / melanomaSENS
brain_spine_cyst_tumourtinyint(1)Brain / spine cyst / tumourSENS
neurological_visual_disturbancetinyint(1)Neurological / visual disturbanceSENS
hospital_admission_psychiatrist_mental_illnesstinyint(1)Hospital admission / psychiatrist / MISENS
schizophrenia_bipolar_compulsive_fibromyalgia_metinyint(1)Schizophrenia / bipolar / FM / MESENS
positive_hiv_hep_b_hep_ctinyint(1)HIV / Hep B / Hep CSENS
raised_bp_cholesterol_veins_bloodtinyint(1)Raised BP / cholesterol / veins / bloodSENS
kidneys_bladder_prostatetinyint(1)Kidneys / bladder / prostateSENS
stomach_oesophagus_boweltinyint(1)Stomach / oesophagus / bowelSENS
gall_bladder_liver_pancreastinyint(1)Gall bladder / liver / pancreasSENS
lungs_breathingtinyint(1)Lungs / breathingSENS
lupus_fibromyalgia_arthritis_jointtinyint(1)Lupus / FM / arthritis / jointSENS
anxiety_depression_mental_illness_fatiguetinyint(1)Anxiety / depression / fatigueSENS
growth_lump_polyp_tumourtinyint(1)Growth / lump / polyp / tumourSENS
chest_pain_heart_paralysis_neurologicaltinyint(1)Chest pain / heart / paralysisSENS
mole_freckletinyint(1)Moles / frecklesSENS
thyroid_conditiontinyint(1)Thyroid conditionSENS
ears_hearingtinyint(1)Ears / hearingSENS
eyes_visiontinyint(1)Eyes / visionSENS
_detailstext (×21)Each condition has a matching *_details field for free-text detailSENS
Medical questionnaire — recent activity fact__medical_questionnaire
FieldTypeDescriptionPIIOptions
medication_treatment_fourteen_daystinyint(1)Medication / treatment (last 14 days)SENS
hospital_referral_investigationstinyint(1)Hospital referrals / investigationsSENS
absent_from_work_two_weekstinyint(1)Absent from work (2+ weeks)SENS
waiting_test_resultstinyint(1)Waiting test resultsSENS
experienced_symptoms_not_sought_advicetinyint(1)Unaddressed symptomsSENS
doctor_nurse_to_see_next_three_weekstinyint(1)Upcoming doctor/nurse appointment (3w)SENS
unexplained_bleeding_weight_loss_lumptinyint(1)Unexplained bleeding / weight loss / lumpSENS
mole_freckle_changedtinyint(1)Mole / freckle has changedSENS
cough_three_weekstinyint(1)Cough lasting 3+ weeksSENS
other_symptom_first_timetinyint(1)Other first-time symptomSENS
covid_symptomstinyint(1)COVID symptomsSENS
covid_positivetinyint(1)COVID positive testSENS
Medical questionnaire — family history fact__medical_questionnaire
FieldTypeDescriptionPIIOptions
family_heart_attack_stroke_angina_diabetestinyint(1)Heart attack / stroke / angina / diabetesSENS
family_cancertinyint(1)CancerSENS
family_cardiomyopathytinyint(1)CardiomyopathySENS
family_multiple_sclerosistinyint(1)Multiple sclerosisSENS
family_muscular_dystrophytinyint(1)Muscular dystrophySENS
family_polyposis_colitinyint(1)Polyposis coliSENS
family_polycystic_kidney_diseasetinyint(1)Polycystic kidney diseaseSENS
family_motor_neurone_diseasetinyint(1)Motor neurone diseaseSENS
family_huntingtons_diseasetinyint(1)Huntington's diseaseSENS
family_parkinsons_diseasetinyint(1)Parkinson's diseaseSENS
family_alzheimers_diseasetinyint(1)Alzheimer's diseaseSENS
family_other_conditiontinyint(1)Other family conditionSENS
_detailstext (×12)Each family history flag has a matching *_details text fieldSENS

Every file attached, generated, signed, received. Document record plus bank-statement metadata (auto-extracted), Initial Disclosure Documents, suitability-report content and template versioning, and the Terms & Conditions library.

Document record document · document__customer · document__metadata
FieldTypeDescriptionPIIOptions
idbigintDocument ID—
uuiduuidStable external identifier—
namevarchar(255)Filename (auto-renamed by AI on upload)—
pathvarchar(255)Storage path. Raw bytes only via short-lived signed URLSENS
mimevarchar(255)MIME type—
sizebigintByte size—
contentslongtextExtracted text contentPII
contents_extractblobStructured extract (binary)PII
category_idintDocument category—
category_sub_idintDocument sub-category—
statetinyintDocument state (draft / final / signed / archived)—
user_idbigintFK → user. Uploader—
case_idbigintFK → case—
application_idbigintFK → case__application—
customer_id_verification_idbigintFK → customer_id_verification if IDV-generated—
entrust_idvarchar(255)Entrust reference if externally stored—
document__customer.customer_idbigintFK → customer. Document linked to customer—
document__metadata.account_numbervarchar(255)Bank statement account number (extracted)SENS
document__metadata.datedateBank statement reporting date (extracted)—
document__metadata.closing_balancedecimal(15,2)Bank statement closing balance (extracted, £)PII
Initial Disclosure Documents initial_disclosure_document · initial_disclosure_document__customer
FieldTypeDescriptionPIIOptions
idbigintIDD ID—
uuiduuidStable external identifier—
namevarchar(255)IDD name—
pathvarchar(255)Storage path (signed-URL access only)—
mimevarchar(255)MIME type—
sizebigintByte size—
preselectedtinyint(1)Preselected IDD for new customers—
customer_idbigintFK → customer. Customer the IDD was served to—
accepted_attimestampWhen the customer accepted the IDD—
Suitability reports suitability_report · case__protection_suitability_report · case__application_suitability_report · suitability_report_template · suitability_report_template_version · protection_suitability_report_template
FieldTypeDescriptionPIIOptions
suitability_report.idbigintSuitability report ID—
suitability_report.contentlongtextGenerated report bodyPII
suitability_report.edited_contentlongtextAdviser-edited bodyPII
suitability_report.application_idbigintFK → case__application—
suitability_report.protection_idbigintFK → case__protection—
suitability_report.template_idbigintFK → suitability_report_template—
suitability_report.template_version_idbigintFK → suitability_report_template_version—
suitability_report.generated_bybigintFK → user. Generating user—
template.namevarchar(255)Template name—
template.typeenum('protection','mortgage')Template type—
template_version.versionintTemplate version number—
template_version.contentlongtextTemplate body—
template_version.requires_ai_processingtinyint(1)AI processing required to render—
template_version.is_activetinyint(1)Currently active version—
Terms & conditions library terms
FieldTypeDescriptionPIIOptions
idbigintTerms version ID—
uuiduuidStable external identifier—
versionvarchar(50)Version string (e.g. "v3.1")—
titlevarchar(255)T&Cs title—
contenttextT&Cs body—
effective_fromtimestampEffective from—
effective_untiltimestampEffective until—

Two immutable audit streams (OwenIt audits + structured audit_log), plus the change reconciliation layer that tracks client-portal and external writes, and the check__workflow template layer that defines what the AI file-audit runs.

Audit events (OwenIt Auditing) audits
FieldTypeDescriptionPIIOptions
idbigintAudit event ID—
eventvarchar(255)Event type (created / updated / deleted / restored)—
operationvarchar(255)Operation detail—
auditable_typevarchar(255)Polymorphic type of the audited entity—
auditable_idbigintPolymorphic ID of the audited entity—
user_typevarchar(255)Polymorphic type of the actor—
user_idbigintFK to actor—
old_valuestextPrevious field values (JSON)PII
new_valuestextNew field values (JSON)PII
urltextURL of the request that caused the change—
ip_addressvarchar(45)Actor IP at time of changePII
user_agentvarchar(1023)Actor user agent—
tagsvarchar(255)Audit tags—
case_idbigintFK → case (when relevant)—
customer_idbigintFK → customer (when relevant)—
created_attimestampWhen recorded—
Audit log (structured) audit_log
FieldTypeDescriptionPIIOptions
idbigintAudit-log ID—
eventvarchar(255)Event name—
descriptiontextHuman-readable description—
subject_typevarchar(255)Subject polymorphic type—
subject_idbigintSubject polymorphic ID—
subject_snapshotlongtextSubject full snapshot at event timePII
causer_typevarchar(255)Causer polymorphic type—
causer_idbigintCauser polymorphic ID—
changeslongtextStructured change set (JSON)PII
case_idbigintFK → case—
customer_idbigintFK → customer—
created_attimestampWhen recorded—
Change reconciliation (client portal & external writes) change · change__item
FieldTypeDescriptionPIIOptions
change.idbigintChange ID—
change.uuiduuidStable external identifier—
change.modelvarchar(255)Target model name—
change.model_idbigintTarget model ID—
change.actiontinyintAction enum (create / update / delete)—
change.author_typetinyintAuthor type enum (adviser / client / system)—
change.author_user_idbigintAuthor user ID where applicable—
change.case_idbigintFK → case—
change.customer_idbigintFK → customer—
change.fact_find_idbigintFK → fact__find (when fact-find-driven)—
change__item.fieldvarchar(255)Field that changed—
change__item.originaltextPrevious valuePII
change__item.newtextNew valuePII
change__item.typevarchar(150)Data type of the field—
change__item.conflicttinyint(1)Conflict flag (concurrent edit)—
change__item.conflict_statetinyintConflict state enum—
Check workflows (template layer for AI file-audit) check__workflow · check__workflow_category · check__workflow_question
FieldTypeDescriptionPIIOptions
check__workflow.sectionvarchar(255)Workflow section—
check__workflow.slugvarchar(255)Workflow slug—
check__workflow.activetinyint(1)Workflow currently active—
check__workflow_category.category_idbigintDocument category tied to workflow—
check__workflow_question.slugvarchar(255)Question slug—
check__workflow_question.questiontextQuestion text—
check__workflow_question.pass_answervarchar(255)Answer that represents a pass—
check__workflow_question.criteriatextCriteria narrative—
check__workflow_question.classvarchar(255)Question class (for grouping / execution)—

Everything that happened on the case or customer. Spatie activity log, full AI-transcribed calls with provider infrastructure, in-platform chat, tasks and notifications, plus the adviser scratchpad / script tables that capture real-time working state during calls.

Activity log (Spatie / default Laravel) activity_log
FieldTypeDescriptionPIIOptions
idbigintActivity ID—
log_namevarchar(255)Log name / channel—
descriptiontextHuman-readable description—
eventvarchar(255)Event name—
subject_typevarchar(255)Subject polymorphic type—
subject_idbigintSubject polymorphic ID—
causer_typevarchar(255)Causer polymorphic type—
causer_idbigintCauser polymorphic ID—
propertieslongtextStructured properties (JSON)PII
batch_uuiduuidBatched activity group identifier—
urltextSource URL—
case_idbigintFK → case—
customer_idbigintFK → customer—
Calls — session record call
FieldTypeDescriptionPIIOptions
idbigintCall ID—
started_attimestampStart time—
ended_attimestampEnd time—
directionvarchar(255)Inbound / outbound—
fromvarchar(255)From numberPII
tovarchar(255)To numberPII
statetinyintCall state enum—
external_idvarchar(255)Provider call reference—
datalongtextProvider payloadPII
transcriptlongtextFull call transcript (Deepgram)PII
summarytextAI-generated call summaryPII
document_idbigintFK → document. Recording file—
user_idbigintFK → user. Advisor—
customer_idbigintFK → customer—
lead_idbigintFK → leads—
case_idbigintFK → case—
Calls — infrastructure call_history · call_states · call_webhook_payloads
FieldTypeDescriptionPIIOptions
call_history.provider_idvarchar(255)Provider-side unique ID—
call_history.statusvarchar(255)Call status (ringing / answered / missed …)—
call_history.answeredtinyint(1)Call was answered—
call_history.answered_byvarchar(255)Who answered (name / number)PII
call_history.recording_idvarchar(255)Recording reference—
call_history.segmentslongtextPer-leg segment detailPII
call_states.statevarchar(255)State machine label—
call_states.call_typevarchar(255)Call type—
call_states.recording_filenamevarchar(255)Recording filename—
call_states.stateslongtextFull state transition log—
call_webhook_payloads.provider_idvarchar(255)Provider ID—
call_webhook_payloads.actionvarchar(255)Webhook action—
call_webhook_payloads.payloadlongtextRaw webhook payloadPII
In-platform chat (Ask JammJar etc.) chat__conversation · chat__message
FieldTypeDescriptionPIIOptions
chat__conversation.idbigintConversation ID—
chat__conversation.user_idbigintFK → user—
chat__conversation.case_idbigintFK → case—
chat__conversation.customer_idbigintFK → customer—
chat__conversation.call_idbigintFK → call—
chat__message.messagetextMessage bodyPII
chat__message.sendertinyintSender enum (user / assistant / system)—
Tasks & notifications task · notifications
FieldTypeDescriptionPIIOptions
task.titlevarchar(255)Task title—
task.descriptionlongtextTask descriptionPII
task.statustinyintTask status enum—
task.prioritytinyintTask priority enum—
task.typetinyintTask type enum—
task.due_datetimestampDue date—
task.case_idbigintFK → case—
task.customer_idbigintFK → customer—
task.lead_idbigintFK → leads—
task.application_idbigintFK → case__application—
task.document_idbigintFK → document—
task.team_idbigintFK → team—
task.user_idbigintFK → user. Assignee—
notifications.typevarchar(255)Notification type (class-based)—
notifications.notifiable_typevarchar(255)Notifiable polymorphic type—
notifications.notifiable_idbigintNotifiable polymorphic ID—
notifications.datatextNotification payloadPII
notifications.read_attimestampRead timestamp—
notifications.linkable_typevarchar(255)Deep-link type—
notifications.linkable_idbigintDeep-link ID—
Scratchpad & call scripts (adviser working-state) scratchpad · script · script_section
FieldTypeDescriptionPIIOptions
scratchpad.user_idbigintFK → user—
scratchpad.script_idbigintFK → script—
scratchpad.call_state_idbigintFK → call_states—
scratchpad.notestextFreeform adviser notes during the callPII
scratchpad.checked_sectionslongtextSections marked complete during the call—
scratchpad.is_activetinyint(1)Currently-active scratchpad—
script.namevarchar(255)Script name—
script.descriptiontextScript description—
script.is_defaulttinyint(1)Default script—
script.is_activetinyint(1)Active—
script_section.titlevarchar(255)Section title—
script_section.contenttextSection script content—
script_section.sort_orderintSection order—

Fields flagged PII and SENS are subject to minimum-necessary principles. Option 1 events deliberately carry a minimal PII subset — summaries, flags, and references — not raw detail. Option 2 REST and Option 3 MCP tools carry full detail where permitted, scoped by service-level credentials and access-controlled at retrieval time. Document payloads are accessed via short-lived signed URLs, never raw object-store paths. All columns, types and provenance above reflect the current JammJar production schema (jammjar_sample, MariaDB 10.11) — not target-state or MCP-era additions.

Source-of-truth data map

For each shared entity, which system is authoritative — critical for conflict resolution when both systems can update the same record.

EntitySource of truthRationaleConflict resolution
Case / ApplicationJammJarOperational — adviser is working hereLast-write-wins with event log
Client (PII)JammJarCaptured at fact-find; GDPR responsibilityOneView read-only
Compliance outcomeJammJarAI check engine produces the assessmentImmutable once complete
Commission statementOneView / SBGSBG reconciles against lender paymentJammJar receives as read-only
Firm / Adviser directoryOneViewSBG onboards firms; FCA recordsJammJar syncs nightly
Network policy / rulesOneViewNetwork governanceJammJar receives as config

Key integration decisions — open for discussion

  • Authentication & SSO: SBG's CTO has indicated a preference for OAuth 2.0 single sign-on from OneView into JammJar — adviser logs into OneView, clicks through, lands authenticated. This is included in Option 1 and carries through the other options. OneView acts as the identity provider.
  • Tenancy boundary: JammJar runs database-per-client isolation. For SBG networks, do we treat the network as one JammJar tenant, or each AR firm as its own tenant? Affects data-model shape and commercial structure.
  • Commission data flow: JammJar tracks procuration and advice fees on each application today but does not maintain a dedicated commissions ledger. If feeding OneView's commission surface is in scope, we'd add this as part of the integration build.
  • Network policy / workflow config: Can SBG push network-specific compliance questions into JammJar's workflow engine? A worthwhile decision to take before the data contract is finalised — it shapes how tenant-specific oversight is implemented.
  • Smartr365 coverage: Whatever integration depth is chosen with JammJar, the existing gap on the Smartr365 book persists. Worth deciding whether JammJar's footprint explicitly includes migrating those firms over time.

Dependencies

The integration architecture above is the "art of the possible". What actually dictates pace is not JammJar's roadmap — it's the engineering resource on SBG's side of the integration. This section lays out, plainly, what each commercial posture unlocks or constrains.

Customer / Partner
SBG pays JammJar to build
Slow — constrained by SBG-side resource

JammJar interfaces with SBG's engineering team to agree interface contracts and onboard events. SBG is an IT organisation, not an engineering one — the hold-up is not JammJar's velocity; it's the availability of people inside SBG who can hold the other end of the integration. Any timeline proposed is conditional on SBG hiring or reallocating that capacity.

What gates progress SBG engineers to own the OneView side of the contract
Minority Investment
SBG invests, JammJar prioritises
Faster — roadmap alignment

With SBG as an investor rather than just a customer, JammJar can allocate engineering disproportionately to this integration. The same engineering-capacity constraint on the SBG side still applies, but JammJar has more latitude to push harder and to absorb friction that a paying customer wouldn't be entitled to.

What gates progress Still SBG engineering availability, but JammJar runs faster on its side
Acquisition
SBG owns JammJar, we build OneView
Fastest — single engineering org

Under acquisition, there is one engineering team building on both sides of the integration. JammJar engineers become OneView engineers. The dependency dissolves — what was a cross-organisation integration project becomes a single roadmap owned end-to-end. Shane gets a turnkey engineering capability implanted into SBG without having to build it from scratch.

What gates progress Internal prioritisation only — no cross-org handshake
Plain reading: any timeline proposed under the Customer / Partner model is fanciful unless SBG commits to hiring the engineers who would hold the other end of the integration. Under Investment, JammJar can push harder; under Acquisition, JammJar builds OneView itself.
Deliverables › Commercial Models
Deliverable 03

Commercial Models

Two commercial frames — the DA SaaS proposition that SBG can take to market, and the commercial structure for the OneView integration itself. Every number below is adjustable; projections recalculate live.

Part 1 — DA SaaS Proposition

Packaging JammJar as a value-add feature available to PMS members — offered to Directly Authorised firms in the mortgage club and Bankhall support-services base. First-mover advantage in a market where most CRMs are either network-locked or legacy-heavy.

BASE CASE · 5-YEAR OPPORTUNITY
£4.2M gross ARR by Year 5 — the revenue opportunity SBG unlocks with JammJar

The DA SaaS market produces meaningful revenue for both sides. Base case assumes 600 addressable firms × 2.5 advisers × cumulative 6%–40% penetration × £200 per adviser per month × 15% SBG markup × 0% churn. Any penetration above this is additional upside; conservative and growth cases are one slider move away.

Year 1
£248k
6% · 36 firms · 90 seats
Year 2
£414k
10% · 60 firms · 150 seats
Year 3
£704k
17% · 102 firms · 255 seats
Year 4
£1.16M
28% · 168 firms · 420 seats
Year 5
£1.66M
40% · 240 firms · 600 seats
5-year gross ARR from software subscriptions · Base case
£4.18M

Minimum fee floor · £1.13M — in order to engage JammJar as a partner, SBG commits to a minimum annual fee ladder (£162k Y1 → £292k Y5, based on 5%–9% penetration × £180 per adviser per month). The numbers above are the Base revenue view; the floor is the contractual minimum that sits underneath.

DA SaaS revenue model

3-year projection · adjust any input below · Base case
Market (DA firms in PMS Mortgage Club — to confirm with Shane)
Addressable DA firms (PMS) 600
Average firm size (advisers) 2.5
Penetration % (firms signed — cumulative)
Year 1 6%
Year 2 10%
Year 3 17%
Year 4 28%
Year 5 40%
Pricing (per adviser / month) JammJar charges £265 — this is the list price ceiling
Price / adviser / month £200
Commercial
SBG markup % (on top of JJ price) 15%
Annual net churn % 0%
Total ARR (gross, from software subscriptions)
Year 1
£—
Year 2
£—
Year 3
£—
Year 4
£—
Year 5
£—

Year 5 breakdown

Firms signed (Y5)—
Total seats (Y5)—
JJ price / seat / mo—
Marked-up price / seat / mo—
Gross ARR to market (Y5)—
SBG markup revenue (Y5)—
JammJar revenue (Y5)—

Go-to-market — three routes

Three structural options for how JammJar reaches the DA market through SBG. Detailed view sits alongside the Engagement Models on Deliverable 04.

RouteDescriptionSBG roleJammJar roleRevenue treatment
A · Pure referral SBG introduces JammJar; JammJar sells and supports the end firm directly. Marketing + endorsement Sales + delivery + support 10% of Y1 fees to SBG
B · Joint go-to-market Branded as a PMS/Bankhall product; JammJar powers it under the bonnet. Branding + primary customer relationship Platform + delivery + L2 support SBG markup on JammJar price
C · SBG acquires JammJar SBG takes the JammJar product to market, transitioning service spend from members into committed software spend. Capital + distribution + brand + team Tech + operations + support 100% revenue to SBG P&L — software-revenue (high-multiple) rather than service-revenue (low-multiple)

Part 2 — OneView integration commercial framing

Separate from the DA SaaS proposition. SBG is the customer here, paying JammJar to deliver the OneView integration and operate it on an ongoing basis. No revenue share — SBG isn't reselling, SBG is consuming.

ONGOING
Platform fee
£200k/ year
3-year minimum commitment

Flat annual fee for the OneView integration running on JammJar's platform — infrastructure, uptime, security, compliance and baseline support. Same across any integration depth (event-driven, REST, or MCP).

ONE-OFF
Build cost
£1,000/ developer / day
Rough order of magnitude per phase

Phased delivery aligned to the OneView Integration options:

  • Phase 1 · Event-driven — low touch, narrow surface area
  • Phase 2 · REST interop — extends Phase 1 with pull + drill-down
  • Phase 3 · MCP service layer — agent-consumable tool surface

Precise day-count depends on Shane's team availability — see Dependencies on Deliverable 02.

USAGE
Per-adviser fee
£5–£15/ adviser / month
Proportional to scale of use

A small per-adviser monthly fee tied to the size of SBG's network using OneView. Keeps commercials proportional to consumption without the friction of usage-based metering per tool call.

Indicative annual run-rate
~£360k / year
£30k / month, on top of the platform fee, at indicative network scale · moves up or down with adviser count and negotiated per-adviser rate.
Minimum commitment to JammJar £600k over 3 years (platform fee only, before build and usage)
Indicative usage run-rate ~£360k / year (per-adviser fee at indicative network scale — on top of the platform fee)
Revenue treatment Customer spend — no revenue share (SBG is the customer, not the reseller)
Deliverables › Engagement Model
Deliverable 04

Engagement Model

Three models for how SBG and JammJar could work together, plus analysis of how JammJar would deliver core CRM services to the PMS side of the business.

The three engagement models

P
Commercial Partnership
StructureContract only
CapitalNone
ControlVia contract terms
SpeedSlowest · rollout-dependent
I
Minority Investment
StructureEquity + commercial
Capital£750k – £2.5M (indicative)
ControlInfo rights · board observer
SpeedFast · weeks, not months
A
Acquisition
Structure100% purchase
Capital£12–20M (indicative)
ControlFull · integration
SpeedFast · can close quickly

Partnership — detailed view

JammJar delivers via commercial contract only. SLA-backed, multi-year term with mutual exit provisions. SBG is a paying customer; the speed of integration depth is constrained by SBG-side engineering availability (see Dependencies).

Suited to SBG if…

  • Preference to avoid balance-sheet exposure
  • Limited appetite for integration complexity in the short term
  • Comfort with the slowest of the three routes for deeper integration — event-driven push is quick to ship, but anything richer is gated on SBG-side engineering capacity

Trade-offs

  • No equity upside if JammJar valuation grows
  • Exclusivity relies on contract terms rather than shared ownership
  • Strategic influence limited to what the contract defines — no board-level voice
  • Integration depth capped by SBG engineering availability

Minority investment — detailed view

SBG takes a minority equity stake alongside the commercial arrangement. Capital commitment in the £750k – £2.5M range (indicative). Information rights and board observer seat.

Suited to SBG if…

  • Strategic alignment with JammJar's trajectory
  • Interest in equity participation in a growing AI-CRM player
  • Desire for influence without full operational control
  • Keen to take a position early, ahead of a full acquisition — a small position now with the ability to buy more (including outright) in future

Trade-offs

  • Capital commitment · balance-sheet impact
  • Minority position is a stake, not full ownership — influence is medium, not controlling
  • Longer path to full strategic control if that becomes the direction

Acquisition — detailed view

SBG acquires JammJar 100%. Full integration into the group, leveraging JammJar's technology as core infrastructure for both the AR network and the DA market — and leveraging JammJar's engineering team as SBG's AI-native build capability going forward.

Suited to SBG if…

  • Strategic intent to own the AI-CRM capability outright
  • Appetite to secure the team and the product together as a single asset
  • Shane wants a turnkey solution to implant a team of AI-native engineering whiz kids into SBG — the deal delivers the people as well as the product
  • Intent to transition service spend from members into committed software spend on SBG's own P&L
  • Commitment to becoming a technology-led group

Trade-offs

  • Largest capital commitment of the three models
  • Post-acquisition planning carries the usual integration considerations across people, systems and brand
  • Brand question — JammJar brand vs. SBG/Sesame brand on the adviser-facing surface
  • Governance restructure — board composition, reporting lines, approval thresholds

JammJar delivering core CRM to PMS

A separate but related question: how would JammJar actually deliver CRM services to the PMS side of the business, under any of the three models above?

PhaseActivityDurationKey dependencies
0 · DeliveryCommercial agreement signed. Tenant provisioning. SBG branding applied. Onboarding processes defined.6–8 weeksLegal · branding assets
1 · Pilot5–10 pilot DA firms onboarded. Structured feedback and iteration cycle. Support model tested.8–12 weeksFirm selection · JammJar success team
2 · Go-to-marketAssisted launch to PMS/Bankhall member base. Marketing collateral. First OneView integration live.Quarter 3OneView Option 1 complete · GTM ready
3 · ScaleSales-assisted growth. Network-level rollouts. Advanced integrations (API, MCP). Cross-sell to Sesame network.Year 2+Proven Go-to-market metrics · sustained demand

Support model

  • L1 support: SBG-branded helpdesk handling adviser queries. Staffed by existing SBG support teams (minimal training overhead).
  • L2 support: JammJar support team handling platform-level issues. 4-hour SLA during business hours, same-day for critical.
  • L3 support: JammJar engineering on-call rotation. 1-hour response for P1 incidents.
  • Implementation: Dedicated JammJar success manager per 50 firms during onboarding. Reduces to shared model at scale.

How each model compares

A side-by-side view of what each engagement model offers SBG on the dimensions that typically drive the decision.

DimensionPartnershipMinorityAcquisition
Strategic alignmentContractual — defined by the terms of the agreementShared — information rights plus board observerFull — single P&L, single board
Equity participationNone — service spend onlyMinority stake, participates in valuation upsideFull ownership
Integration depthEvent-driven push is quick; richer depth gated on SBG-side engineering capacityAligned incentives make joint engineering work easier to prioritiseShared ownership — integration is a first-class internal workstream
Influence on roadmapDefined in contractMedium — roadmap conversation, not unilateralHigh — full direction-setting
Speed to commercial go-liveFastest — contract onlyFast — transaction in weeksLonger — diligence, close, integration planning
!
Network proof point. Captured from a 5-hour working session with Cornerstone Finance on 20 April 2026. Published here in full fidelity. Confidential — SBG Executive only.
Deliverables › Cornerstone Meeting
Annex · Network proof point

Cornerstone Finance · what a 300-adviser network said about JammJar

Cornerstone Finance — a 300-adviser, 114-firm AR network — are an important customer of SBG's who have been on Acre for years. Having seen an earlier JammJar demo, their leadership team committed a full working day on 20 April 2026 to conducting their own deep technical due diligence on JammJar. They entered the day as early Acre adopters who were actively seeking an alternative because of specific concerns about staying. This annex records what they tested, how they reacted, and the conclusions they reached. The short version: Cornerstone's own due diligence ratifies every capability claim made in this proposal about the JammJar vs Acre comparison.

SBG customer · Acre user · independent technical DD

This is a customer who matters to SBG, who has run Acre for years, who ran their own deep technical due diligence on JammJar — and whose findings ratify everything stated elsewhere in this proposal about the Acre comparison.

Who they are to SBG
An important customer already inside the SBG ecosystem — a 300-adviser, 114-firm AR network running its own operation on Acre for years.
What this meeting was
A follow-up technical due diligence session, not a first-encounter sales demo. Cornerstone set the agenda and stress-tested JammJar against years of day-to-day Acre experience.
Why SBG leadership should care
Their independent verdict — from experienced Acre practitioners, not from JammJar — corroborates the capability claims in Deliverable 01 about where JammJar leads and where the gap-to-parity work sits.
“
I have quite a few concerns about staying with Acre.
— Cornerstone leadership, closing remarks
After 5 hours of JammJar walkthrough · 20 April 2026
Cornerstone entered the meeting holding a multi-year Acre contract and a candid position: they like Acre as a starting point but have specific concerns about staying, and are actively looking for a better option before committing further. The session was their own technical due diligence on JammJar — not a sales demo. By the close, the leadership team were discussing October 2026 go-live and an end-of-May decision milestone on the board decision to switch.

Meeting at a glance

5h
Working session
Cornerstone HQ, 20 Apr 2026
300
Advisers in network
Across 114 AR firms
~2.6
Advisers per firm
Long-tail of 1–3 person firms
Acre
Current CRM
Multi-year contract in place
Oct '26
Target go-live
Decision needed end of May
Board
Decision level
5 shareholders, unanimous
Why this matters to SBG

A live network seeing JammJar as a credible replacement for Acre — unprompted, on first serious exposure.

Cornerstone are not an SBG member network. They are a comparably structured AR network (300 advisers, 114 firms, Acre incumbent, training-led support model) who chose to commit five hours to understanding JammJar. The observed pattern gives SBG a pre-scripted view of how an SBG AR network would likely respond if JammJar were made available inside Sesame.

01
Acre's moat is convenience, not capability. Karl characterised Acre during the session as "a bunch of grids" — a tool that wins on familiar guide-rails rather than on the frontier. Cornerstone's leadership, having used Acre for years, did not disagree. The moment JammJar was demonstrated end-to-end in their own technical DD, the conversation shifted from what Acre does to what a modern platform ought to do.
02
The network admin layer is the unlock — with work required. Cornerstone's specific requirement — hierarchical admin, feature flags, push-down automations, fleet-wide MI — maps directly onto what SBG would need for Sesame ARs. The underlying infrastructure is present in JammJar's architecture; the network-admin layer itself would need to be built on top of it. That build was scoped and discussed during the meeting, not glossed over.
03
Attrition risk is knowable, not speculative. Cornerstone said openly that a CRM switch will cost some advisers at the tail of their careers. They also said the firms at the frontier of their network will look elsewhere if the network can't offer the best platform. The problem SBG will face is identical — and the same framing applies.

How the session unfolded

The meeting was deliberately unstructured — Cornerstone steered toward the topics they cared about, JammJar demonstrated against their prompts. The order below reflects the actual flow, not a pre-agreed agenda.

1
Cornerstone's own support & training model
The session opened with Cornerstone explaining their differentiator: they plant themselves into member firms. In-house training capability manager, own frontline team triaging, monthly outbound call campaign, hypercare in the first 90 days. Training is not outsourced — it is core USP.
ContextUSP
2
Current CRM landscape — Cornerstone's view of Acre after years of use
Cornerstone are early Acre adopters and set out their position plainly: Acre was "a breath of fresh air" for advisers arriving from Intelligent Office, Mortgage Keeper or Prime, and is a capable product against that baseline. However, after years of daily use they hold specific concerns about staying with it, and were in the meeting precisely because they are actively seeking an alternative. Karl characterised Acre during the session as "just a bunch of grids" — functional, but not the frontier of what a modern SaaS platform looks like.
ContextFrank
3
Mortgage journey walkthrough — live case
Karl ran a full mortgage journey against a live demo tenant. Cornerstone opted to create a new case "and see how it develops" — call-recording, AI fact-find extraction, document auto-classification, 27Tec sourcing, DIP path, notes-to-structured-data, Experian consent model, portal invite, IDV, WhatsApp integration.
DemoEnd-to-end
4
Data model, configurability & audit depth
Deep-dive on the underlying data model — fact-find as dynamic chapters, per-tenant database isolation, feature flags down to field level, configurable lead stages, bespoke automation rules, network-level push-down of templates and workflows. Cornerstone probed hard on where customisation stops and platform control begins.
Architecture
5
Compliance, MI and file audit
JammJar demoed AI-driven file audit flagging regulatory issues on upload. Cornerstone's compliance lead ran a series of real-world queries — vulnerability reporting, verbatim call transcript search, DSAR handling, evidenced consent logging. Fees tied to products, advisers, date ranges and lenders — fully queryable.
ComplianceRegulatory
6
Real MI from a live JammJar customer
Chris presented real anonymised before/after numbers from a customer: cases tracked in the system moved from 694 → 2,353 over a matched 153-day period post-JammJar, driven by the fact that advisers stopped using the CRM purely as a business register. Cornerstone repeatedly stopped the demo to ask about these numbers.
EvidenceAdoption
7
Strategic roadmap — lender APIs, agentic sourcing
Chris walked through JammJar's direction of travel: direct lender APIs (HSBC live, Halifax in progress), dynamic sourcing beyond 27Tec's 6-field limitation, lender-side data distribution deals with Lloyds and Leeds BS. JammJar's positioning: "a single platform operating system — not a CRM", sitting between lenders, brokers, borrowers and comparison sites.
StrategyVision
8
Commercials, onboarding & decision timeline
Closed with explicit asks: detailed pricing menu, phased migration model (not big-bang), October 2026 target go-live, and end-of-May decision requirement. Cornerstone stated they would table the decision as a board agenda item.
CommercialNext steps

What Cornerstone asked — and what they were told

The questions below are the substantive ones Cornerstone put to Karl and Chris during the session, grouped by theme. Paraphrased where the original was conversational; direct quotes where the wording carries the signal.

Platform & feature depth
Q How does audio get into the system — phone, Teams, in-person?
A Three routes: phone integration (3CX standard, mobile app channel available), Meet/Teams/Slack/Google integration (configuration-only, no extra charge), or upload audio to a case from any source including Plaud devices. Face-to-face microphone capture is trivial to build — not shipped because no one has yet asked for it.
Q Does the AI process in real-time or wait until the end?
A Waits until the end by design. Passes the full transcript through ~30 loop iterations to populate fact-find sections. Live-streaming was considered but explicitly rejected — it would require constraining how the adviser works. Current belief: the value is in letting the adviser be unconstrained, then automating the admin.
Q If I rename a payslip to something misleading, does it still classify correctly?
A Yes. Filename is not passed to the model — classification is content-based. Two years of training data behind the classifier. Naming conventions can also be enforced in reverse: documents are renamed on insert using configurable templates (customer name, date, category, subcategory).
Q Is the fact-find schema fixed or extensible?
A Hundreds of fields across mortgage, protection and GI. Fact-find itself is a data model with chapters as related tables. Fields adapt dynamically (permanent employment shows employer and role; retired shows pension source; self-employed shows company structure). Every field in the model is passed to the AI as a candidate to populate.
Q Do advisers adopt the call-recording feature, or avoid it?
A The behavioural resistance to recording is real. JammJar's answer: the value of the feature is strong enough that advisers opt in voluntarily because they want the email and fact-find extraction output. Carl's Zoopla analogy — when adoption is driven by the carrot, not the stick, it actually happens.
Network architecture & governance
Q Could we configure rules and automations at network level, not per firm?
A Yes — and this is the architectural change for a network customer. Each firm is its own tenant with its own database. A hierarchical layer above those tenants gives Cornerstone push-down control over workflow automations, templates, documents, trigger warnings, and feature flags. Individual firm configurability is selectable per feature.
Q Can we control who can define lead stages, or automations, at what level?
A Feature flags extend right down to field level. "Can this user edit this field?" is a feature flag. "Can this firm build bespoke automations?" is a feature flag. Network admins can lock any of those, selectively, per firm.
Q What reporting does the network get? Can we see MI across the 300 advisers?
A Yes — reports are either object-level filtered views or time-series reports. Network-level reports aggregate across tenants. JammJar proposed building a standard network-level insights pack that includes pipeline, MI, compliance flags, adviser performance, referral quality — so Cornerstone's relationship managers have the same data that customers see.
Q Can our members' data be exported nightly for back-up / DSAR / "when they leave"?
A Yes. Some JammJar customers receive nightly CSV extracts of every table via SFTP or to an S3 bucket. Cornerstone flagged they'd want to gate this behind controls — they're nervous about firms being allowed to request raw data dumps they can't secure. JammJar can configure per-firm.
Compliance & file audit
Q Can we search across all calls for specific content — like every time a fee was mentioned?
A Yes, and demoed live. Free-text search across transcript bodies, or — more usefully — AI-driven compliance queries against the full call (e.g. "did the adviser describe their regulated status and any fees?" returns a grounded natural-language answer with the evidence). Acre has no equivalent.
Q What about vulnerability reporting? We need aggregate AND case-level data.
A Each vulnerability flag is a structured field linked to the case. Both case-level drill-down and aggregate reporting (percentage of portfolio flagged, breakdown by type) available. Cornerstone confirmed this is material for them — FCA "right data" returns are getting more demanding year-on-year.
Q How do you handle DSARs?
A Internal tool: run a subject query across the database, generate a full report including calls, documents, every field. That report goes to the requesting firm to review and redact. No manual trawling required.
Q Does the file audit replace our human sense-check process, or augment it?
A Augment — and Cornerstone's sense-check team would shift from exhaustive file review to focused review of AI-flagged exceptions and high-risk items. File-check is mandatable before the advisor can hit apply; network admins control that rule. Cornerstone said this would free up their team for higher-value work.
Commercial & onboarding
Q How do you actually migrate a network of 300 advisers off Acre?
A Phased. Not big-bang. Start with new advisers through induction, bring early adopters across for good-news stories, then drag the reluctant majority. Data migration is the choke-point on any phased approach — JammJar runs bridges during the phased window. JammJar side: Karl, Kieran, Chris, Dave. Cornerstone side: users, support, training leads.
Q When do you actually need us to have made a decision?
A To hit an October 2026 go-live — ideally before end of May. July–August is dead for scheduling. The commercial must be fully understood, phased migration plan agreed, and SBG's own evaluation process resolved. JammJar committed to delivering a detailed pricing menu and comparison framework immediately.

What was shown — and how Cornerstone reacted

An important customer of SBG, on Acre for years, ran their own deep technical due diligence on JammJar. Across the 18 distinct capabilities demonstrated during the session, here is how they responded.

12
Strongly positive
Capabilities Cornerstone recognised as differentiators — typically with visible architectural recognition and probing follow-up questions.
4
Balanced · concerns raised
Capabilities where Cornerstone saw value but wanted to stress-test edge cases, surface adoption concerns, or clarify scope.
2
Gaps flagged
Areas where Cornerstone identified material gaps that JammJar doesn't yet address — captured in full, not glossed over.

Takeaway for SBG: an experienced Acre user, running their own diligence with no sales framing applied, landed 12‑of‑18 at strongly positive — ratifying the capability claims made elsewhere in this proposal about the JammJar vs Acre comparison. The 4 balanced responses and 2 gaps are recorded verbatim below.

Response text is a direct paraphrase or quote from the session, not JammJar's framing.

Capability demonstrated Signal Cornerstone's response (paraphrased or verbatim)
AI fact-find extraction — call → structured fields, ~30-pass processing Strong positive Probing questions throughout. Tested with edge cases (notes-only path, handwritten-to-upload path). No competing product cited.
Document auto-classification & renaming Strong positive "Standard naming conventions — documents can come in as a mash of rubbish — we will never at a network be able to enforce naming conventions" — resolved live by JammJar's rename-on-insert feature. Visible relief.
File audit with AI-flagged exceptions Strong positive Compliance lead explicitly said this would shift their sense-check team to higher-value work. Positioned as the feature that "Acre just cannot do".
Verbatim call search + AI compliance queries across calls Strong positive Reacted as a genuinely novel capability. "You can even pick out a particular bit" — demoed searching "fee" across transcripts and AI-summarising regulatory status compliance.
Per-tenant database isolation + network admin layer Strong positive Visible architectural recognition. Repeatedly returned to the question of network-level push-down and per-firm controls — and was reassured each time. "That's the kind of stuff advisers like".
Feature flags down to field level Strong positive Recognised immediately as the lever for managing a heterogeneous AR network. No equivalent control surface in Acre.
27Tec sourcing integration (live in platform) Positive Acknowledged as table-stakes. Cornerstone are on 27Tec already. Clean pass-through of fact-find data into sourcing, user credentials cleanly resolved.
iPipeline protection integration (in dev — ~8 weeks) Raised as gap Acknowledged and understood — in dev with a realistic timeline. Not a deal-breaker. Cornerstone want it live for go-live.
Experian credit check with verbal consent model Strong positive The on-call consent flow (adviser asks verbally, logged as auditable evidence, credit run instantly) was called out as genuinely novel. Acre requires email-link consent.
Customer portal with IDV / fact-find / document sharing Positive Demoed via invite link + gated password. Cornerstone asked about chat — JammJar explicitly said that's WhatsApp, not portal. Chat-in-portal is off-roadmap.
WhatsApp Business integration (live) Positive Native UI inside JammJar matching the WhatsApp Web interface. Meta template pre-approval handled by JammJar. Cornerstone raised adviser-vs-team number routing as a follow-up.
Real customer MI — 694 → 2,353 cases tracked in matched 153-day period Strong positive Repeatedly returned to in conversation. Recognised that the uplift was driven by advisers actually using the system — not just better reporting.
Strategic direction — single platform OS, lender APIs, agentic sourcing Strongly positive Cornerstone asked about Lloyds banking group discussions, product criteria matching, AI cost model for the next 5 years. "It is really impressive" — from a self-described "not prone to compliments" attendee.
Direct lender APIs (HSBC live; Halifax, NatWest, Barclays in progress) Balanced Cornerstone's view: "advisers don't use the Halifax API because they never remember to". JammJar and Cornerstone agreed — the value is there but adoption is the challenge. Positioned as supplementary, not foundational.
Customer portal AI chatbot Won't build JammJar explicitly: "we are not putting an AI chatbot in the customer-facing portal". The AI is for the broker, not the replacement of the customer interaction. Cornerstone comfortable with this position.
Kanban UI Gap flagged On the roadmap, not shipped. Cornerstone did not press hard on this.
Introducer / estate-agent portal view Partial — planned standalone app Cornerstone has a home-builder referral relationship that wants live visibility. JammJar explained the plan: standalone introducer portal app. Not in current scope but roadmapped.
SMS / native chat tooling Not offered WhatsApp is the answer. No SMS. Cornerstone understood the reasoning — Meta templates give a structured compliance track.
Cornerstone's frank framing
Acre is a big reason why people join us — so we need to overcome that as a challenge. We're in discussion at the moment with two firms with a lot of advisers, between fifty and a hundred both of them, and the challenge on both of them is that they both really like Acre.

Why Acre wins on first exposure — and where it tops out

During the session Karl set out the view on where Acre's strength sits; Cornerstone, as early Acre adopters who have used it for years, corroborated it candidly. The characterisation below is JammJar's read on the category, articulated by Karl during the meeting — the Cornerstone leadership did not push back on any of it. That corroboration from an experienced Acre user is itself the point.

It's very griddy, like Excel. It's just dynamic, you can have columns and rows and everything works on that basis. It's much easier to use than Intelligent Office, Lifecycle, Mortgage Keeper, Smartr to an extent.
Karl, during the session · where Acre wins
If you've worked in any industry other than mortgage advice over the last five years, you come and look at it and you go — it's a bunch of grids. What else is it doing?
Karl, during the session · on Acre's ceiling
It gives you guide rails. Those advisers who are busy and do crappy admin — that's where Acre wins. Those guys aren't using the cool things that Acre can do — they just really like the guide rails to keep them to the end so they know they're not going to get in trouble.
On why advisers cling to Acre
What you guys do — the cool stuff is much more intuitive than theirs. You don't have to go do anything to make it work, it just does it. I think that's the win for us.
Cornerstone leadership · on where JammJar takes the lead

The resolution path Cornerstone articulated

Cornerstone did not look at JammJar and conclude Acre was finished. They looked at JammJar and concluded the transition is the work. Their own prescription for how to manage the switch, volunteered during the meeting:

  1. Show the art of the possible in JammJar alongside the feature comparison — pair the 128-feature matrix with end-to-end product demos.
  2. Focus the first 90 days of training on "here's how you do in JammJar what you do in Acre" — bridge the mental model before introducing the uplift.
  3. Then, beyond 90 days, show the delta — the admin savings, the automation, the compliance uplift — and help members configure forward roadmap.
  4. Anticipate attrition. Some advisers at the tail of their career will not switch regardless. That is priced in.
  5. Weigh the upside. More progressive advisers will leave Cornerstone (and, by analogy, SBG) if the incumbent platform can't take them to the frontier.
The SBG parallel

The same tension applies to Sesame's AR network.

The firms Sesame wants to retain are the firms most likely to leave if the platform stalls. The firms Sesame is happiest with on legacy are the firms that cost least to keep — and deliver least. This is not new information, but Cornerstone's unprompted articulation of it is a rehearsal of how your own network population will respond to the same proposition.

The evidence Cornerstone surfaced, that advisers cling to CRM guide-rails and resist change regardless of whether the new thing is better, is the same retention risk the SBG evaluation has been probing throughout. Cornerstone's prescription above is the workable answer — and directly tests whether JammJar's training, support, and migration machinery are up to the task.

What a network actually requires from a CRM

Cornerstone's requirements emerged as the session progressed. They are recorded here as the explicit asks they made — each one also applies to SBG.

01
Hierarchical admin layer above tenants
Each firm is its own tenant with its own database. Above that sits a network admin who can push down automations, templates, trigger warnings, documents, and settings. Firms cannot override network-level rules unless explicitly permitted.
JammJar architecture supports — additional work for network layer
02
Feature flags at field level
Granular control over what every firm (and every user within a firm) can see, edit, and build. Lead stages, automation rules, template creation — all gateable by the network admin.
Shipped — feature flags already run to field level
03
Network-level MI and reporting
Aggregate dashboards across all firms. Pipeline performance by firm. Adviser-level performance flagged vs baseline. Referral quality by source. Compliance flags by type. Vulnerability exposure. Support-team intervention data.
Build — JammJar to produce standard network insights pack
04
Nightly data extracts per firm, gated by network
Nightly CSV / SFTP / S3 extracts available to firms who should have them — but network admin decides which firms get raw data and which get aggregated reporting only. Removes the "only find out when you try to leave" anxiety.
Already built for MAB and other customers
05
Mandate-able compliance controls
Cornerstone's sense-check team should be able to mandate "file-check must run before apply is pressed", network-wide. Network admins set the rule; firms inherit it. Date-ordering of audit checks configurable.
Build — partially available, network-level mandate to be finalised
06
Fee management tied to products, advisers, dates, lenders
Fee splits by AR, product type, indemnified vs non-indemnified, commission terms. Must align to the network's commercial model, not the firm's. Cornerstone currently handle this outside Acre — a primary reason their operations are strained.
Shipped — fee model already fully structured in JammJar
07
Referral routing with multi-tenant cross-over
Cross-network referrals — mortgage adviser fact-find passed to in-house protection team in a different tenant, with referral tracking and conversion reporting. Sending adviser writes notes; receiving adviser inherits the full fact-find.
Build — architecture exists, cross-tenant flow to be finalised
08
Training and hypercare data visibility
Cornerstone's relationship managers need visibility of new-user adoption curves — "is this adviser completing their tasks, running calls, submitting applications?" — so their team can intervene during the first 90 days. Login-as-user for coaching is also required.
Shipped — impersonation, adoption dashboards already in platform

What was agreed, tabled, or left open

The final 45 minutes of the session moved to commercials, migration and next steps. The content below is a record of what was explicitly stated — not JammJar's framing of it.

Open ask

Detailed pricing menu — required before board

Cornerstone explicitly requested a detailed pricing menu covering all relevant categories so they can model last year's performance and anticipated year-ahead performance against current Acre spend. Direct quote from leadership:

That pricing I think is really important to us, Karl — so like a detailed menu of all our pricing, so we can kind of run the numbers on performance last year, anticipated performance in those categories this year, and then we can compare it.
To be delivered by JammJar.
Timeline

October 2026 go-live target — decision by end of May

The explicit timeline agreed in the room:

  • End of April 2026Detailed pricing menu delivered to Cornerstone
  • Early–Mid May 2026Board meeting — 5 shareholders, unanimous requirement
  • End of May 2026Decision deadline — provisioning cannot wait further
  • June – September 2026Phased migration window — new advisers onto JammJar first, early adopters second, remainder last
  • October 2026Full network on JammJar
We're on the clock as well.
Confirmed by Cornerstone's CEO.
Migration model

Phased, not big-bang

Cornerstone explicitly rejected a big-bang migration. Their own playbook — established when they moved to Acre — starts with new advisers through induction, then early adopters for good-news stories, then drags the reluctant majority. JammJar agreed this is the right model.

Data migration during a phased window is the main operational cost and the reason JammJar deploy a dedicated team (Karl, Kieran, Chris, Dave) during onboarding. Cornerstone's own users, support team and training leads will be paired with them.

Model agreed in principle.
Timeline & board decision

October go-live target · board decision by end of May

Cornerstone's CEO set the timeline during the session. An October 2026 initial go-live is the target — which means the commercial decision has to be made by end of May 2026 so that provisioning, migration prep, and training build-out can run through the summer (June / July / August / September).

Cornerstone asked JammJar for detailed pricing so they can run the numbers against last year's performance and anticipated performance in each category, and bring the comparison to their next board meeting as a formal agenda item. The board is five shareholders; all five will be in the room.

This is relevant for SBG because the commercial structure SBG lands with JammJar sets the envelope for what Cornerstone (and any other SBG network in the same position) can be offered. Commercial clarity is on Cornerstone's critical path.

Cornerstone said they will share findings with Richard Harrison directly.
Deck summary · what to take to SBG leadership

What Cornerstone shows about the JammJar opportunity for SBG.

Cornerstone is a customer SBG cares about. They have run Acre for years. They volunteered a full working day of their own senior time to run a proper technical due diligence on JammJar. Their findings, summarised below, ratify every material claim in this proposal about the Acre comparison — and sharpen the picture of what SBG stands to gain, and what still needs building, if JammJar is brought inside Sesame.

01
An experienced Acre user independently ratifies the capability comparison. 12 of 18 capabilities landed as strongly positive — including file-audit-with-AI, verbatim call search, document auto-classification, and AI fact-find extraction — each one positioned by Cornerstone themselves as something "Acre just cannot do". The capability-weighted lead of +9.6 points in Deliverable 01 is not JammJar's self-assessment in isolation; it matches what a senior Acre practitioner concluded in five hours of hands-on testing.
02
Acre's moat is narrower than its multi-year contracts suggest. Cornerstone hold a multi-year Acre deal and had already started looking elsewhere. "Very griddy, like Excel" and "a bunch of grids" — framings used during the session and not disputed by Cornerstone — describe a product that wins on guide-rails and familiarity, not on the frontier. An SBG network facing the same attrition-risk calculus has a shorter incumbent-advantage window than the contracted term implies.
03
The network-admin layer is the unlock — and it is a build, not a feature. Cornerstone's requirements — hierarchical tenants, push-down rules, feature flags to field level, fleet-wide MI — map directly onto what SBG would need for Sesame ARs. The underlying infrastructure to support this layer is present in JammJar's architecture; the network-admin layer itself would need to be built on top. This was scoped openly during the session, not glossed over, and it is the single most important development commitment that any SBG engagement would include.
04
Adviser attrition is knowable and manageable, not speculative. Cornerstone articulated the same adviser-segmentation pattern SBG will face — frontier-first firms adopt quickly because the productivity uplift is real; late-career advisers resist regardless. Their own prescribed approach (phased migration, 90-day bridge-then-uplift training, new advisers through induction first) is workable and JammJar has the tooling to support it. The risk is bounded, not open-ended.
05
There is a decision clock running. Cornerstone have a board-level agenda item and an end-of-May decision milestone toward an October 2026 go-live. Whatever SBG decides about JammJar, the competitive landscape in the UK mortgage-CRM market is moving — and experienced networks are voting with their diligence time. The case for engaging sooner rather than later is not hypothetical.
Coverage validated

Where Cornerstone confirmed JammJar works, and where it doesn't yet

Across the five representative case types that reflect the breadth of day-to-day activity in a PMS-club context, Cornerstone — as experienced Acre practitioners — are satisfied that JammJar delivers on three, leads on one, and flagged two that need development.

Works today
Regulated mortgage
Standard purchase · remortgage · complex cases
JammJar handles the full regulated mortgage flow end-to-end. Cornerstone's file audit and suitability report walkthrough was against a regulated case and they were satisfied the platform covers the standard-to-complex range their advisers see daily.
Works today
Buy-to-let
Including limited-company BTL · non-regulated
JammJar handles both personal-name and limited-company buy-to-let, including the SPV structures common in portfolio-landlord work. Cornerstone's verdict was that the platform works perfectly for their BTL volume.
Better than Acre
Protection & GI
Protection only · general insurance attached
JammJar's protection and general-insurance handling was flagged as materially better than Acre — integrated sourcing through iPipeline, tighter fact-find capture, and suitability-report integration make protection-only and GI-attached cases meaningfully smoother.
Development required
Equity release
Referral today · first-class flow is a build
Equity release is handled today as a referral flow. Becoming first-class for ER cases — dedicated fact-find fields, bespoke suitability template, lifetime-mortgage sourcing integration — is a scoped build, not a capability JammJar claims today.
Development required
Commercial mortgage
Not covered end-to-end today
Commercial mortgage is outside JammJar's current end-to-end flow. Cases can be recorded and tracked, but bespoke fact-find, affordability models, and commercial-lender integrations would need to be built before commercial-mortgage brokers are fully served.
Full session material — meeting flow, verbatim Q&A, capability reactions by capability, the Acre-tension quotes, network requirements stated in the room, and commercial outcomes — is in the tabs above. This summary picks only the salient parts.
Deliverables › Annex · Risks & mitigations
Annex B · Risks & Mitigations

Risks & mitigations

Framed around the decision SBG is being asked to make. Part one: the risks of not doing what this proposal recommends. Part two: the risks of the proposal itself, and how each is mitigated.

Decision framing

The risks that matter are the risks of not acting.

A growing proportion of SBG's PMS Mortgage Club members are moving onto Acre — a CRM now owned by a future competitor to SBG. SBG needs a viable AI-native alternative, internal engineering capability to deliver the OneView integration it wants, and a flagship CRM partner capable of holding the other end of that integration. This proposal addresses each of those directly. The register below starts with what it costs not to act, then lays out the risks of the proposal itself and the mitigations that sit against them.

4
Risks of not acting
3
Risks of this proposal
100%
Mitigated if proposal proceeds
01

The risks of not doing what this proposal recommends

Each of these exists today, independent of JammJar. The proposal mitigates all four in one engagement.

Risk 01 · Competitor CRM penetration in the member base

A large and growing proportion of SBG's members — specifically in the PMS Mortgage Club — is running on Acre, a CRM that is now owned by a future competitor with whom SBG has active commercial hostilities. Every renewal that defaults back to Acre deepens that competitor's foothold inside SBG's own member base and hands them operational data about SBG's firms. SBG needs a plan to slow the flow of members onto Acre and to shift renewing customers onto a viable alternative. Without that plan, the network is funding a competitor's CRM growth through the member decisions SBG enables.

Mitigated by: JammJar becomes the AI-native alternative positioned inside the PMS Mortgage Club, giving SBG a credible destination for renewing Acre customers and for net-new members — without displacing Smartr365 as the network CRM of choice.
Risk 02 · Internal engineering mirroring capability

SBG's in-house engineering team does not today have the kind of mirroring capability — AI-native services, event-driven integration, cross-tenant data layers — needed to deliver the OneView solution described in this proposal across the CRM base. Every quarter that passes without that capability being built or partnered is a quarter where OneView's depth of oversight stands still while the regulatory bar keeps rising. Building this capability cold would take years and cost millions.

Mitigated by: JammJar has the engineering bench, the AI stack, and the architecture patterns (event-driven, REST, MCP) ready to deliver — and would hold the other end of the OneView integration through whichever depth SBG chooses.
Risk 03 · No flagship CRM partner for the integration

Delivering OneView integration at any meaningful depth requires a CRM partner at the other end who is technically capable, commercially aligned, and strategically predictable. Today, the closest thing SBG has in the PMS base — Acre — is owned by a competitor. Smartr365 does not expose an API. Without a flagship CRM partner, the OneView roadmap stalls at whatever depth the platforms available today permit.

Mitigated by: JammJar fills the flagship-partner role — API-native, AI-native, commercially aligned with SBG rather than a competitor, and technically capable of delivering all three integration depths (event-driven, REST, MCP).
Risk 04 · No AI-automation partner for the capabilities this proposal describes

The AI workflows described in this proposal — fact-find extraction from call transcripts, file audit at document upload, agentic suitability reporting, parallel lender assessment — are not a set of features that can be bolted onto a traditional CRM. They are a full AI engineering programme. Building them internally at SBG would take years, cost millions, and still need a commercial software partner to operate at scale. Without that partner, the capability gap to market-leading CRM propositions widens every quarter.

Mitigated by: JammJar already operates all of these workflows in production with real customers (MAB live, others). Engaging JammJar buys the AI-automation capability off the shelf rather than building it from scratch.
02

The risks of this proposal — and how each is addressed

Three risks to track as the engagement moves. Each has a named mitigation and is a matter of delivery discipline, not proposition weakness.

Risk 05 · Change programme to land adoption inside the member base

Converting members from their current CRM — principally Acre — onto JammJar requires a real change programme on the SBG side. RCAMs (Regional Key Account Managers) need to be deployed, trained, incentivised and given targets around PMS Mortgage Club conversion. Change of this kind is inherently disruptive: adoption curves can be slower than forecast, especially in the first twelve months while the field team learns the product and builds conviction. No churn is forecast in the model because members have options, but the ramp-up profile needs to be taken on a balanced view rather than at the aggressive end.

Mitigated by: The Commercial deliverable ships Conservative / Base / Growth scenarios side-by-side, with every input slider exposed. The Base case is built on a 6% → 40% cumulative penetration ladder that is deliberately not heroic; the Conservative case is 20% below that. A £1.13M five-year fee floor sits underneath as the contractual minimum if the curve underperforms. RCAM engagement model can be co-designed pre-pilot.

Risk 06 · SBG-side engineering capacity to meet OneView integration dependencies

The OneView integration depths beyond Option 1 (event-driven push + SSO) require SBG-side engineering to hold the other end — new REST endpoints to consume, MCP clients to build, data layers that connect firms and networks to OneView's identity model. If SBG's internal engineering capacity does not match the ambition, the delivered depth stalls at whatever SBG can hold, and the programme slips relative to what JammJar can deliver unilaterally.

Mitigated by: Options are structured as depth choices, not sequential phases — SBG can start at Option 1 (deliverable by JammJar alone against today's schema) and move to Option 2/3 at the pace engineering capacity allows. Every Option 2/3 surface area is flagged with the SBG-side work it implies so scope can be right-sized. Joint planning session recommended ahead of commercial commitment.

Risk 07 · P&L exposure — JammJar is not yet profitable

Whichever engagement model SBG chooses, the commercial relationship brings with it the usual P&L considerations of backing a growth-stage software company. JammJar is not yet profitable. Under a Commercial Partnership this is a supplier-concentration consideration; under a Minority Investment or Acquisition it becomes a direct P&L exposure on SBG's books that needs balancing against the strategic upside. This is not a proposition risk — it is a risk inherent to engaging with any growth-stage software business.

Mitigated by: The Engagement Model deliverable lays out three routes — Commercial Partnership, Minority Investment, Acquisition — with the P&L and balance-sheet implications of each called out. Full financial diligence materials are available on request to support whichever route SBG selects.

01 · PMS / DA Platform Review

The capability matrix is an interactive tool with 128 features scored across 13 categories, weightable by persona (Balanced, DA firm, Network, AI-first, Ops-heavy). Full details and live exploration are available in the web version — see the interactive page for JammJar 83.3 vs Acre 73.7 under balanced weighting, and the roadmap-impact view for post-build capability projections.

Live URL: jammjar-capability-analysis.netlify.app/#crm

Deliverables › PMS / DA Platform Review › Roadmap Impact
Deliverable 01 · Roadmap Impact

Roadmap Impact

Every feature where Acre currently wins, the JammJar build required to reach parity, and the engineering effort to deliver it — expressed as a dev-day range. Post-roadmap score shown against today's JammJar score.

Headline — what the roadmap delivers

JammJar today
83.3
vs Acre 73.7 — lead of 9.6pts
JammJar post-roadmap
97.4
lead of 23.7pts over Acre
Total effort
~200–335*
dev-days* · ≈10–17 engineer-months*
Build items
21
distinct builds · consolidate all 31 Acre-wins features

Ranges reflect engineering uncertainty: the low end assumes a clean build on existing infrastructure; the high end includes discovery, edge-case handling, and QA. Several items share implementation effort — the six pre-built reports in the Reports & Dashboards category are a single build, not six separate ones.

* All dev-day figures on this page are indicative and require full scoping before they become delivery commitments. Engineer-month figures are derived from dev-days at 20 working days per engineer-month; they inherit the same caveat. Priority-band totals (P0/P1/P2 below) and the "Total effort" headline are sums of per-item indicative ranges — not scoped estimates.

By priority

PriorityBuild itemsDev-day range*Engineer-months*Notes
P0 — Regulatory 3 38–64* 1.9–3.2* RMAR reporting + dedicated compliance view. Non-negotiable for DA firms.
P1 — Revenue / Daily 6 72–120* 3.6–6.0* Kanban, pipeline config, dashboards, payments-settled module. Daily-use shortcomings.
P2 — Nice-to-have 12 88–151* 4.4–7.5* SMS, Zapier cert, OAuth, portal messaging, referral tracking UI, misc.

Detailed roadmap

Sorted by category. Each row is a feature JammJar would build to close a current Acre advantage. Dev-day estimates are engineering-only — excludes design, PM overhead, and release.

* All dev-day estimates are indicative and require full scoping to be considered committed delivery ranges.

Category Feature JammJar build Priority Current (JJ/Acre) Dev days

Method & caveats

  • Source: every feature where Acre currently outscores JammJar in the capability matrix. Post-build scoring assumes JammJar reaches Acre's score for each feature (i.e. parity, not necessarily superiority).
  • Dev-day ranges: engineering days only. At 20 working days per month per engineer, total spans ≈10–17 engineer-months. Parallelisable across 2–3 engineers, so calendar delivery could be ~4–6 months if staffed appropriately. All dev-day figures in this plan are indicative and require full scoping before becoming delivery commitments.
  • Shared effort: several Acre-wins rows share one build (e.g. "Dashboard Types", "Pipeline Report", "Revenue Report", and "Adviser Performance Reporting" are all solved by the Dashboard Types + Pre-built Reports build). The 21 items below consolidate all 31 Acre-wins features.
  • Not included: categories where JammJar already leads (AI & Automation, Lead Management, Client Records, etc.) — these continue to advance regardless. Also excludes net-new capability not driven by Acre parity (e.g. lender-criteria agentic sourcing).
  • Influenceable: priorities are JammJar's current view. SBG can reorder — one outcome of an engagement model with SBG influence on roadmap is that P1/P2 items important to the PMS firm base can be promoted.

Export full evaluation report

We'll stitch all four deliverables plus the executive summary into a single print-optimised view. Your browser's Print dialog will open — choose Save as PDF as the destination.

Sesame
Simulation
go to admin
SW
⚡ Performing file audit · case #4471 Patel, Amrita
jammjar.file_audit.run · workflow template: standard_residential_v2.1
Initialising…
Pipeline
Findings
0 red 0 amber 0 green
Waiting for pipeline to surface findings…
Simulation