Trust & Security Pack

1. Executive Summary

CaseFlow Automation Ltd provides a SaaS platform that helps UK credit hire professionals analyse insurer correspondence, draft responses, and receive strategic case guidance, all supported by AI cross-referenced against a curated legal knowledge base.

Security and privacy are built into the platform's architecture, not bolted on. Our approach is grounded in data minimisation, privacy by design, and honest framing of what our controls achieve and where their limits lie.

2. About CaseFlow & Scope

Service Description

CaseFlow Automation (CreditHire Assist) is a browser-based SaaS platform for UK credit hire professionals. Core features include:

• Correspondence analysis: identifying insurer arguments and cited authorities
• AI-assisted reply generation, cross-referenced against curated case law
• Live case advice with conditional strategic guidance
• Basic Hire Rate (BHR) challenge support with locality-based availability analysis
• Case law library, guidance notes, liability assessment, and response templates

Service Boundary

Hosting Region

The platform is hosted in the European Union via managed cloud infrastructure. Data residency is EU-based.

3. Trust Model & Security Principles

• Privacy by Design & Default: Data minimisation is architectural. Digital PDFs are processed locally in the browser on every upload surface; PII is masked before any analysis AI call (the OCR reading step for scanned pages is transcription only and precedes masking); and retention is purpose-limited.
• Least Privilege: Row-Level Security (RLS) enforces per-company data isolation at the database level. Users can only access their own company's data.
• Defence in Depth: Controls operate at multiple layers: browser, network, application, database, and AI prompt level.
• Transparency: We use honest language about what our controls achieve. We say "attempts to mask" rather than "guarantees removal". We document limitations alongside capabilities.

4. Data Governance & Privacy (UK GDPR)

4.1 Controller / Processor Roles

Lawful basis: Contractual necessity for providing the Service; legitimate interest in providing efficient legal support tools.

4.2 Data Classification

4.3 Three-Layer Privacy Architecture

Layer 1: Local PDF Processing. On every upload surface, text-based PDF files are processed entirely in the user's browser using Mozilla's PDF.js (the same library used by Firefox). No text-based PDF file is uploaded to any server. The user reviews extracted text before choosing to submit it for analysis. The one exception: a scanned (image-only) PDF or photograph cannot be read by the browser; the page itself is read by the AI (OCR) under no-training terms, on a transcription-only instruction, and the returned text is masked before any analysis call. Depending on the tool the file is either uploaded to a private temporary storage bucket and deleted immediately after processing, with a scheduled daily job removing any object older than 24 hours as a safety net, or held in memory for a single request and never stored.

Layer 2: PII Masking Gateway (in transit). Before any text is sent to the AI model, it passes through a mandatory server-side masking gateway that uses pattern-based rules tuned for UK claims data. Detected identifiers (titled names, bare/untitled names in labelled or salutation/sign-off contexts, emails, phone numbers, VRMs, NI numbers, driving licence numbers, IBAN, card numbers, sort codes, account numbers, policy/claim references such as POL, CLM, REF, CLAIM, POLICY, FILE, BHR, CHR, CHO, TPI and structured formats like 24-ABC-123456, street addresses) are replaced with neutral placeholders such as [NAME_REDACTED] or [VRM_REDACTED]. UK postcodes are deliberately preserved because they are material to basic-hire-rate and locality arguments; a separate output-side scrubber removes any postcode the AI introduces that was not present in the original input.

Layer 3: At-Rest Masking (in storage). The same masking patterns are reapplied via PostgreSQL BEFORE INSERT/UPDATE triggers using the database function public.mask_pii(). Records persisted to correspondence, ai_replies, case_advice, preemptive_letters and taxi_risk_assessments contain placeholders rather than raw identifiers, so saved history is masked even in the event of unauthorised database access.

The masking gateway is a mandatory processing step. Coverage is enforced by an automated test in continuous integration: every function that calls the AI must apply masking, and any exception must be named in that test with a written reason. The named exceptions are scanned pages, engineer report PDFs and dashcam media, which the AI reads as files before there is any text to mask. Because masking relies on the surrounding text, errors introduced when a scan is read can stop an identifier being recognised that would be caught in a typed document. Each invocation logs the count and categories of items masked. Original values are never logged.

4.4 Data Retention & Deletion

CreditHire Assist is designed not to retain personal case data. Uploaded text and the outputs the tool generates are deleted immediately when the user is finished, on session close. A continuous scheduled purge runs as a backstop, so nothing is ever retained beyond 24 hours. Users save anything they need to keep to their own systems (a copy button is provided in-app) and re-run the task if required.

We do not use client data to train AI models. Data is used solely to generate the specific output requested by the user.

Special category data: The Service is not intended for special-category data and users are asked not to submit it. We recognise that in credit hire work, health, injury or vulnerability information can incidentally appear in free-text correspondence. Where it does, the same safeguards apply (masking, data minimisation, encryption and immediate deletion), and as data controller the customer remains responsible for the Article 9 lawful basis.

4.5 Post-Upload Scrubbing of Residual PII

If, after upload, a user identifies that personal data slipped past the masking gateway, the affected record can be:

• Re-masked in place: the same record is updated, the at-rest trigger re-applies mask_pii(), and the previous unmasked text is overwritten in place (no historical row is retained for masked tables).
• Deleted entirely by the user from their history (correspondence, replies, advice, letters).
• AI provider records: the provider makes no retention statements for gateway traffic, so we cannot confirm deletion at the provider. Its use of the data is restricted to delivering the service, and training on it is prohibited.

To request a bulk scrub or audit, contact info@caseflowautomation.co.uk; we aim to action within 5 working days.

4.6 Data Subject Rights

The platform supports the exercise of data subject rights including access, rectification, erasure, and portability. Users can delete their own correspondence and AI outputs. Company-level data deletion is supported on contract termination.

4.7 International Transfers

Platform data is hosted in the EU. Where AI model inference involves processing outside the UK/EEA, this occurs under the provider's enterprise data processing terms which include Standard Contractual Clauses (SCCs) and prohibit the use of input/output data for model training.

5. Security Architecture

5.1 Hosting & Infrastructure

• Hosted on managed cloud infrastructure with EU data residency
• TLS encryption for all data in transit
• AES-256 encryption for data at rest
• Managed database with automatic backups, point-in-time recovery, and encrypted backup storage
• Infrastructure managed by established cloud providers with SOC 2 Type II and ISO 27001 certifications

5.2 Application Security

• All AI interactions are mediated through server-side functions. Users never interact with the AI model directly.
• System prompts and knowledge base content are injected server-side; users cannot modify or view underlying instructions
• Input validation and sanitisation on all user-submitted data
• No API endpoint allows arbitrary prompts to the AI model
• Content Security Policy headers, HTTPS-only access

5.3 Network Security

• HTTPS (TLS) enforced for all connections
• API rate limiting on authentication and AI endpoints
• Server-side functions operate in isolated execution environments with no persistent state between invocations

6. Identity & Access Management

6.1 Authentication

6.2 Role-Based Access Control (RBAC)

Roles are stored in a dedicated user_roles table, separate from user profiles, and enforced via database-level security functions.

6.3 Data Isolation

Every database table containing client data enforces Row-Level Security (RLS) policies. These policies are evaluated at the database level on every query and cannot be bypassed by the application layer. A user from Company A cannot access, view, or modify data belonging to Company B, even if they manipulate API requests.

7. AI Governance & Model Risk Management

7.1 AI Use Cases & Human Oversight

AI is used exclusively for decision-support. It drafts, analyses, and suggests. It never makes legal decisions, sends correspondence, or takes autonomous action.

Every AI output is presented as a draft requiring human review. Users must explicitly accept a disclaimer acknowledging this before accessing AI features.

7.2 Anti-Hallucination Controls

7.3 Data Controls for AI

• PII masking before transmission: All extracted text passes through the mandatory masking gateway before reaching the analysis AI model. The exceptions are scanned pages, engineer report PDFs and dashcam media, which the AI reads as files before there is any text to mask; the text read from a scanned page is masked before analysis. Because masking relies on the surrounding text, errors introduced when a scan is read can stop an identifier being recognised that would be caught in a typed document.
• No training on client data: Client correspondence and case details are never used to train or fine-tune AI models
• Prompt minimisation: System prompts include only the knowledge necessary for the specific task
• No persistent context: AI prompts are transient and are not stored or reused across sessions
• Server-side only: Users never interact with the AI model directly. All prompts are constructed and transmitted server-side.

7.4 Model Selection & Governance

• Models are selected centrally for their suitability for legal text analysis and are not configurable by end users
• AI model providers process data under enterprise data processing terms that prohibit training on input/output data
• Model changes are tested and validated before deployment

8. Monitoring, Logging & Incident Response

8.1 Logging & Audit Trail

8.2 Monitoring

• Server-side function execution is monitored via managed cloud logging
• Usage dashboards available to company managers (team activity) and platform administrators (aggregate metrics)
• Automated health checks on AI inference endpoints

8.3 Incident Response

In the event of a suspected security or AI safety incident:

1. Detect and Triage: Identify the scope and severity of the incident using available logs and monitoring
2. Contain: Affected AI features can be disabled immediately at the platform level. User sessions can be terminated. API keys can be rotated.
3. Investigate: Audit logs allow identification of affected outputs, users, and timeframes
4. Notify: Affected clients are notified with details of the issue and recommended actions. Regulatory notification (ICO) within 72 hours where required under UK GDPR Article 33.
5. Remediate: Root cause analysis conducted; controls updated and tested before re-enabling affected features
6. Review: Post-incident review to update procedures and controls

8.4 AI-Specific Incident Actions

• Identify event type (fabricated case law, data leakage in output, unexpected model behaviour)
• Disable affected AI feature(s) at platform level
• Review prompt and masking logs to assess exposure
• Update system prompts, knowledge base, or masking rules as required
• Validate fix before re-enabling

9. Business Continuity & Disaster Recovery

10. Third-Party Risk & Sub-Processors

We engage the following sub-processors to deliver CreditHire-Assist. Their processing is governed by data processing terms no less protective than those we owe our customers. The list is reviewed regularly and updated on material change.

Lovable's published Data Processing Agreement, including the published sub-processor list, is available at trust.lovable.dev and is incorporated by reference. The hosting region for our project is EU (Europe, Ireland), evidenced at platform level. Transfers outside the EU at the AI inference layer are safeguarded through Standard Contractual Clauses at the Lovable-to-Google contractual layer, with the formal IDTA / UK Addendum to the EU SCCs and Transfer Impact Assessment documentation available via Lovable's Trust Center on B2B compliance request.

11. Compliance & Control Mapping

11.1 Regulatory Alignment

11.2 Control Mapping (Against ISO 27001 Domains)

12. Shared Responsibility

13. Appendices

Appendix A: Related Documents

Appendix B: Glossary

Appendix C: Contact and Enquiries

For security-related enquiries, DPIA collaboration, or to request further technical detail:

14. AI Safety & Security Policy

How we govern AI behaviour, prevent hallucination, and protect your data. Formerly published as a separate policy.

CaseFlow Automation Ltd uses AI to help credit hire professionals analyse insurer correspondence, draft responses, and receive strategic case guidance. This document explains the controls we have in place to ensure AI outputs are safe, accurate, and secure.

1. AI Governance Model

Approved Use Cases

AI is used exclusively for decision-support - it drafts, analyses, and suggests. It never makes legal decisions, sends correspondence on your behalf, or takes autonomous action.

Every AI output is presented as a draft requiring human review, never as a final document.

2. Anti-Hallucination Controls

Legal AI carries a specific risk: fabricated case names, invented citations, or misattributed principles. We address this with multiple layers of control:

3. Data Privacy & PII Protection

Our three-layer privacy architecture is designed to minimise the personal data that reaches the AI model and to ensure that any data persisted in our database is masked at rest. For full technical detail, see How We Protect Your Data. For our formal data processing commitments, see our Privacy Policy.

Layer 1 - Local PDF Processing

Text-based PDFs are processed entirely in the user's browser using Mozilla's PDF.js. The original file does not leave the device; only the extracted text is submitted for analysis, and only when the user explicitly chooses to do so. Scanned (image-only) PDFs that the browser cannot read are uploaded to a private temporary storage bucket for OCR, then deleted immediately after processing. A scheduled daily job removes any object older than 24 hours as a safety net.

Layer 2 - PII Masking Gateway (in transit to the AI)

Before any extracted text reaches the AI model, it passes through a mandatory server-side masking gateway that detects and replaces common UK identifiers (person names with or without a title, emails, phone numbers, VRMs, NI numbers, bank details, policy and claim references, street addresses, etc.) with neutral placeholders. The analysis AI works on masked text only. The one exception is the OCR reading step for scanned documents, where the model transcribes the raw page under no-training terms before masking is applied to the resulting text. Engineer report PDFs and dashcam media are also read by the AI as files, before there is any text to mask. Because masking relies on the surrounding text, errors introduced when a scan is read can stop an identifier being recognised that would be caught in a typed document. UK postcodes are deliberately preserved because they are material to basic-hire-rate and locality arguments. A separate output-side scrubber removes any postcode the AI introduces that was not present in the original input.

Layer 3 - At-Rest Masking (in the database)

Saved records (correspondence, AI replies, case advice and pre-emptive letters) are masked at the database level via PostgreSQL triggers calling public.mask_pii() before persistence. Even users with direct row access see placeholders rather than raw identifiers in saved records.

Bare Name Detection

Titled names (Mr/Mrs/Ms/Miss/Dr/Prof + surname) are masked. On a scanned document, a title misread when the page is read can prevent that, which is covered by the scanned-page exception. Bare/untitled names are masked only in high-precision contexts: field labels (e.g. Claimant:, Driver:, Insured:, Renter Name:, Full Name:), salutations (e.g. Dear John Smith), sign-offs, and "Re <name>" in email subjects. A non-person token list and a case-citation guard (any string containing " v " or " vs ") protect legal party names and company names so case authorities remain intact in AI outputs. A bare first name and surname in free prose with none of those cues may not be caught.

What We Don't Mask (and Why)

• Case party names in citations - e.g. "Lagden v O'Connor" is intentionally preserved so the AI can apply binding authority correctly.
• Contextual data - information that is only personally identifiable in combination (e.g. "blue Ford Focus") requires semantic understanding beyond pattern matching.

Post-Upload Scrubbing

If residual personal data is identified in a saved record after processing, the underlying row can be re-masked or deleted on request. AI provider prompts are processed under terms restricting their use to delivering the service and prohibiting training. CaseFlow keeps no prompt history of its own to scrub.

4. Data Handling & Retention

CreditHire Assist is designed not to retain personal case data. Uploaded text and the outputs the tool generates are deleted immediately when the user is finished, on session close. A continuous scheduled purge runs as a backstop, so nothing is ever retained beyond 24 hours. Users save anything they need to keep to their own systems (a copy button is provided in-app) and re-run the task if required.

We do not use your data to train AI models. Your correspondence and case details are used solely to generate the specific output you requested.

Special category data: The Service is not intended for special-category data and users are asked not to submit it. We recognise that in credit hire work, health, injury or vulnerability information can incidentally appear in free-text correspondence. Where it does, the same safeguards apply (masking, data minimisation, encryption and immediate deletion), and as data controller the customer remains responsible for the Article 9 lawful basis.

5. Access Control & Data Isolation

Company-Level Isolation

Every company on the platform operates in its own data silo. Row-Level Security (RLS) policies enforce that users can only access their own company's correspondence, case advice, templates, and history. There is no cross-company data access.

Role-Based Access

Authentication & Session Security

• Email-verified login with secure password hashing
• Concurrent session detection - only one active session per user
• Automatic session expiry for inactive users
• Invite-only registration - users must be invited by their company or a platform administrator

6. Prompt Security

All AI interactions are mediated through server-side functions. Users never interact with the AI model directly.

7. Model Selection & Third-Party AI

Model Governance

• The platform uses selected models via a managed AI gateway - models are chosen for their suitability for legal text analysis.
• Model selection is controlled centrally and is not configurable by end users.
• We do not fine-tune or train models on client data.

Data Processing Agreements

AI processing is routed through Lovable AI Gateway. The no-training commitments for input/output data sit in our platform provider's agreements with the AI model providers, rather than a separate Google enterprise agreement held by CaseFlow. Combined with our PII masking, this creates a layered protection model.

8. User Safeguards & Disclaimers

The platform employs a three-tier disclaimer framework to ensure users understand the nature and limitations of AI-generated content:

9. Audit & Accountability

• Activity Logging: All AI feature usage (analysis, reply generation, case advice, letter generation) is logged with timestamps, user IDs, and company IDs.
• PII Masking Audit: Each masking invocation logs the count and categories of items redacted - never the original values.
• Usage Dashboards: Company managers can view team usage statistics. Platform administrators can view aggregate usage across the platform.
• No Shadow Processing: AI is only invoked when a user explicitly requests it. There is no background AI processing of stored data.

10. Regulatory Alignment

11. Incident Response

In the event of a suspected AI safety issue (e.g. fabricated case law, data leakage, or unexpected model behaviour):

1. The affected AI feature can be disabled immediately at the platform level.
2. Audit logs allow identification of affected outputs and users.
3. Affected users and companies are notified with details of the issue and recommended actions.
4. Root cause analysis is conducted and controls are updated before re-enabling the feature.

15. Technical Overview

Architecture, AI capabilities and security at a glance. Formerly published as a separate overview.

CreditHire Assist is a proprietary SaaS platform purpose-built for UK credit hire professionals. It combines enterprise-grade AI with a comprehensive legal knowledge base to help teams analyse insurer correspondence, draft responses, and manage cases - all with industry-leading safeguards against AI errors.

Core Capabilities

AI & Anti-Hallucination Architecture

Our AI layer is powered by Google Gemini 3 - one of the most capable large language models available - but wrapped in our own proprietary safeguards:

Additional safeguards include a postcode fabrication scrubber (prevents invented locality data) and BHR vehicle challenge verification against known provider databases.

Data Privacy & Security

Infrastructure

Compliance