What this document is
This is the evidence record for Bellwether Ltd’s software: the personal data it holds, the protections around that data, the checks it passed before release, and every piece of bespoke logic it contains. It is produced automatically from the same source as the running system and regenerated on every release — so it always describes exactly what is deployed, never an earlier version, and none of it is written by hand after the fact.
Keep it with your compliance records. Sections 2–4 are written for you and whoever handles your data-protection obligations; section 1 is the evidence an auditor or insurer will ask for; the indented technical notes serve your IT advisers.
- 1Assurance checks — the automated tests this software passed before it could be released.
- 2Personal data — every field that holds personal data, classified field by field.
- 3Individual rights — a person’s right to see their data (Article 15) and to have it erased, each one audited action.
- 4Breach exposure — an indicative ranking of what a breach could cost, per record.
- 5Custom logic — the bespoke code in this system and the authority it was granted.
- 6AI & assistant — the AI this system uses, and the rules that contain it.
- 7Document details — exact versions and provenance, for your technical team.
Automated assurance gates
These checks run automatically before any version of this software can be released, and a failure blocks the release — the build you are running could not exist without passing them.
Checks marked Platform certify the SDUK Studio platform this system is generated from: they run on every platform change, and every build — including this one — inherits the certified result. Checks marked This build run against this project’s own output; where one is still to come, it is marked rather than claimed.
The template spine scans clean (0 error-severity findings) in tool-repo CI on every change. Per-project SAST over the generated api/ is a later phase.
Template dependencies carry no High/Critical advisories in tool-repo CI. Per-project lockfile scanning is a later phase.
The UI component set is axe-certified at WCAG 2.2 AA in tool-repo CI (no serious or critical violations). Automated tooling verifies roughly a third of WCAG success criteria — it is not a substitute for a manual audit. Per-project smoke over the deployed UI is a later phase.
The generated access-control engine is verified in CI (Gate B): a generated API is booted and a user bound to one scope is proven unable to read another scope’s rows — in list results and by direct id (no IDOR) — alongside an unforgeable-token check. This certifies the isolation the template produces. Per-project verification against this project’s own grants and data is a later phase.
The assistant’s agent loop is verified in CI against a deliberately hostile model: even a fully compromised AI cannot read outside the signed-in user’s permissions, cannot see classification-redacted fields, cannot write or execute anything (all changes queue for a human to confirm), cannot be driven by instructions planted in record content, and cannot exfiltrate beyond a hard result cap. This certifies the containment architecture every generated assistant inherits; live model-behaviour checks run as an on-demand evaluation suite.
The security, dependency and accessibility gates certify the TEMPLATE SET this build was generated from — audited once in the generator’s CI and inherited by every project (a released generator only ships from green CI). Per-project scans over this build’s own generated api/ and deployed ui/, plus the tenant-isolation proof, are a later phase and are marked accordingly.
Personal-data inventory
Every field in this system that holds personal data is declared and classified below, entity by entity. This is the map your data-protection lead needs for a GDPR Article 30 record of processing activities, and it is what the erasure and breach-exposure sections are computed from.
Reading the table: sensitivity runs 1 (low — e.g. a job title) to 5 (highest — data whose exposure could cause serious harm). “Special category” marks GDPR Article 9 data (health, ethnicity and similar), which carries stricter legal obligations. “On erasure” is what happens to the field when a person asks to be deleted.
activity
| Field | Personal | Sensitivity | Special category | On erasure | Retention basis |
|---|---|---|---|---|---|
recording |
Yes | 4 | — | Redact | Legitimate interest |
transcript |
Yes | 4 | — | Redact | Legitimate interest |
summary |
Yes | 3 | — | Redact | Legitimate interest |
follow-up-draft |
Yes | 2 | — | Redact | Legitimate interest |
company
| Field | Personal | Sensitivity | Special category | On erasure | Retention basis |
|---|---|---|---|---|---|
phone |
No | — | — | Redact | — |
address |
No | — | — | Redact | — |
notes |
Yes | 2 | — | Redact | Legitimate interest |
contact Data subject
| Field | Personal | Sensitivity | Special category | On erasure | Retention basis |
|---|---|---|---|---|---|
first-name |
Yes | 2 | — | Redact | Legitimate interest |
last-name |
Yes | 2 | — | Redact | Legitimate interest |
email |
Yes | 2 | — | Redact | Legitimate interest |
mobile |
Yes | 2 | — | Redact | Legitimate interest |
job-title |
Yes | 1 | — | Redact | Legitimate interest |
linkedin |
Yes | 1 | — | Redact | Legitimate interest |
marketing-consent |
Yes | 1 | — | Redact | Consent |
consent-date |
Yes | 1 | — | Redact | Consent |
notes |
Yes | 3 | — | Redact | Legitimate interest |
opportunity
| Field | Personal | Sensitivity | Special category | On erasure | Retention basis |
|---|---|---|---|---|---|
name |
No | 2 | — | Retain | Legitimate interest |
value |
No | 3 | — | Retain | Legitimate interest |
probability |
No | 2 | — | Retain | Legitimate interest |
next-action |
Yes | 2 | — | Redact | — |
product
| Field | Personal | Sensitivity | Special category | On erasure | Retention basis |
|---|---|---|---|---|---|
unit-price |
No | 2 | — | Retain | Legitimate interest |
quote-line
| Field | Personal | Sensitivity | Special category | On erasure | Retention basis |
|---|---|---|---|---|---|
unit-price |
No | 2 | — | Retain | Legitimate interest |
line-total |
No | 2 | — | Retain | Legitimate interest |
quote
| Field | Personal | Sensitivity | Special category | On erasure | Retention basis |
|---|---|---|---|---|---|
discount-pct |
No | 3 | — | Retain | Legitimate interest |
total |
No | 3 | — | Retain | Legitimate interest |
notes |
Yes | 2 | — | Redact | — |
task
| Field | Personal | Sensitivity | Special category | On erasure | Retention basis |
|---|---|---|---|---|---|
details |
Yes | 2 | — | Redact | Legitimate interest |
This classification inventory is the input to an Article 30 ROPA; it does not by itself capture processor/transfer detail.
Access & erasure
If a person asks you to delete their data, this system can honour it: one administrative action removes or redacts everything declared in the inventory above, as a single all-or-nothing operation, and writes a permanent audit record proving when it happened and what was covered — without exposing the erased values.
Erasable data subjects: contact. Each field’s disposition (redact / delete / retain) is declared in the inventory above; “retain” is used only where a legal basis requires it.
And if a person asks what you hold about them — a subject access request under Article 15 — one read-only administrative action exports everything this system holds about that person, field by field, each value labelled with its classification. It is separate from erasure and separately permission-controlled.
Runtime erasure endpoint: available — POST /api/admin/erasure executes the declared policy in one transaction (redact / delete per field) and writes an immutable audit record; grant-gated, with a dry-run preview.
Right of access (Article 15) export: available — GET /api/admin/subjects/<entity>/<id>/export returns everything held about a data subject as structured data, each field annotated with its classification; read-only and separately grant-gated from erasure.
What a breach could cost
An indication of what a data breach could cost per exposed record, based on the sensitivity of the fields each part of the system holds. Use it to prioritise — it shows which records deserve the tightest access — and as a starting point for a conversation with your insurer. These are indicative figures for ranking risk, not an insurance valuation.
| Records about | Max sensitivity | Special category | Per record | Severity |
|---|---|---|---|---|
| activity | 4 | — | £120–£300 | High |
| company | 2 | — | £20–£60 | Low |
| contact | 3 | — | £50–£150 | Medium |
| opportunity | 3 | — | £50–£150 | Medium |
| product | 2 | — | £20–£60 | Low |
| quote | 3 | — | £50–£150 | Medium |
| quote-line | 2 | — | £20–£60 | Low |
| task | 2 | — | £20–£60 | Low |
Indicative risk-ranking only; not an actuarial valuation.
Method: Indicative bands anchored to IBM Cost of a Data Breach 2026 · band 2026.1 · GBP.
Custom logic — the elevation register
Most of this system is generated code operating inside strict permission rules. Where it needed bespoke behaviour, that code is listed here — and anywhere it is permitted to do something the signed-in user could not do directly carries a written business reason, checked against the code by machine on every build. Nothing that is not on this list can reach production.
POST /quote/:id/discount
quote.discount-pct, .total · updatequote, quote-lineopportunity.afterUpdate
Every custom-logic handler in this system, with its declared authority. An "elevation" is a write a handler performs above the invoking user's own grants — each one is declared in advance with a business reason, machine-checked in CI (extracted write surface ⊆ declarations ∪ caller grants), and listed here in writing.
Artificial intelligence in this system
This system uses AI — including an in-app assistant, “Kylie” — under the same permission rules as everything else. The assistant can only see what the signed-in person asking it can see: every lookup runs through this system’s own permission engine, as that person. It cannot change anything itself — anything it drafts is queued for a person to review and save under their own account — and every AI call is logged for cost and timing, never content.
| Service | Purpose | Provider |
|---|---|---|
answer-ai | Language model — answers, drafting, extraction | anthropic |
speak | Text to speech (spoken replies) | openai |
transcribe | Speech to text (voice input, dictation) | openai |
49 derived tools over 11 record types and 2 reporting views · voice in & out.
Containment is a release-blocking CI gate — see “AI assistant containment” in section 1. The AI model itself is runtime-configurable per deployment (never hard-coded into this build), and behavioural checks run as an on-demand evaluation suite against the live system.
Provenance
For your technical team: the exact software versions this report was generated from and alongside. The report is produced by the same build that produced the deployed system, so these versions identify both.
Generated 2026-08-19T08:20:42.000Z·@sduk/generator@0.115.0·node-mysql@0.64.0·mysql
Breach-exposure figures are indicative risk-ranking, not an actuarial valuation. Assurance gates marked “template-set” certify the shared spine every project inherits; per-project evidence over this build’s own output populates in a later phase.