Features are what applications have. These are properties of every system we ship, enforced by the pipeline that builds it and evidenced in documents you can hand to a board, an auditor or an insurer.
Right-to-be-forgotten is a real endpoint on every API we ship, not a promise. It walks your data's reference graph and, field by field, cascades, redacts or retains, exactly as your retention policy requires.
"Erase the person, keep the invoice": deleting a customer's identity without destroying the financial records you're legally required to keep.
What it is
A working right-to-be-forgotten, a subject-access export built from the same map of your data, and a Record of Processing (ROPA) inventory, generated from the system itself, not written by hand.
How it's built in
Every field is classified when the system is designed: personal data, sensitivity, and what erasure means for it (delete, redact or retain). The erasure endpoint applies exactly that policy across the reference graph; the subject-access export and the ROPA come from the same per-field classifications.
The evidence you receive
The erasure endpoint, the subject-access export and the ROPA inventory, documented in the conformance report that ships with your system.
evidence → erasure endpoint · SAR export · ROPAThe tooling enforces your retention policy; deciding what's lawful to keep remains your data controller's call, as it should.
Every field is classified for sensitivity when the system is designed. Combined with live record counts, that yields a standing answer to the question every board eventually asks: if this leaked, what exactly would be exposed — and what might it cost? Per record type, before anyone asks.
A straight answer for your board and your insurers, produced in advance and refreshed as your data grows.
Detail 02/A · sensitivity × volume × regime, per record type
Refreshed from the live system · read as a gauge, never measured off
What it is
A per-record-type exposure profile: what a breach of each part of your system would expose, under which regulatory regime, with an indicative cost band attached.
How it's built in
The same per-field sensitivity classifications that drive the privacy tooling are combined with live record counts on the running system (sensitivity × volume × regime), so the answer stays current without anyone maintaining it.
The evidence you receive
A standing breach-exposure report, per record type, refreshed from the live system.
evidence → breach-exposure reportThese are indicative bands for prioritisation and insurance conversations, not an actuarial figure, and every report says so.
Indicative onlyTo most software, your data is text, numbers and dates. To ours, it's email addresses, postcodes, phone numbers, websites: real-world concepts with rules.
Schedule 03/A · declared types
One declaration · three layers · they cannot disagree
What it is
Every field in your system is declared as the real-world thing it is, and carries that concept's rules wherever the data travels.
How it's built in
One declaration drives the form control, the API validation and the database column together, so the three layers can never disagree about what a valid email is, and junk can't get in at any door.
The evidence you receive
Every field and its declared type is listed in the system inventory of your conformance report: you can read exactly what your data is.
evidence → conformance reportEvery build passes static security analysis (SAST) and dependency scanning before it can become a release. And where a system serves more than one client, isolation is proven by a test, not a policy document: it logs in as one client and attempts to read another's data, on every release. It has to fail for the build to pass.
Detail 04/A · the three gates, shown in line
Return path shown dashed — a change that fails any of them cannot become a release.
What it is
Static security analysis, dependency scanning and a live tenant-isolation proof: properties of the pipeline, not tasks on a checklist.
How it's built in
The checks run as mandatory gates on every build. A change that fails any of them cannot become a release; there is no manual override and no path around the wall.
The evidence you receive
The security section of the conformance report, plus the passing isolation log from the release that built your system.
evidence → conformance report · isolation logEvery interface is assembled from component templates certified to WCAG 2.2 AA by automated accessibility testing in the build pipeline: certify the components once, and every screen assembled from them inherits the result.
Increasingly a procurement requirement; always the right thing.
Detail 05/A · certify the component once, every screen inherits the result
Every screen assembled from a passing component · not just the ones an audit samples
What it is
Interfaces that meet WCAG 2.2 AA (contrast, keyboard access, screen-reader semantics) on every screen, not just the ones an audit happened to sample.
How it's built in
The accessibility tests run against the component templates themselves, in the build pipeline, on every build. A component that fails never ships, so a screen built from passing components can't quietly regress.
The evidence you receive
A WCAG 2.2 AA statement for your application, backed by the pipeline's test results.
evidence → WCAG AA statementMost of every system we ship is generated from the audited platform. The part that's written by hand — the workflows and rules that make your business yours — is exactly the part that escapes every audit in ordinary software. Here it doesn't: hand-written logic passes through the same gate wall as everything else, machine-checked on every build.
What it is
A governed track for the hand-written part. Custom code can't call dangerous APIs, reach out to the network unannounced, bypass the data layer or carry embedded secrets. And every custom behaviour must state, in plain English, what it does and why.
How it's built in
A build gate reads the custom code itself. Banned calls, undeclared network access, raw database queries and credentials in code each fail the build outright, and a custom endpoint or rule with no declared intent never ships. Where hand-written logic needs authority beyond the calling user's (confirming a booking when its payment succeeds, say), that authority must be declared: what it may change, and the business reason. The pipeline extracts what the code actually writes and refuses any build that exceeds its declarations. The gate runs everywhere the code does: as it's written, in review, and in the pipeline.
The evidence you receive
The elevation register, in your conformance report: every piece of hand-written logic, what it does, and, where it acts above user privilege, exactly what it may change and why, in writing. The gate's pass is part of the build record of every release.
evidence → elevation register · build gate logMachine checks set the floor, not the ceiling: every line of custom logic is also reviewed by a person before it can merge; the gate just means that review never starts from unsafe code.
The reason we can make guarantees at all is the way we build →One audited platform, a pipeline of mandatory gates, and evidence as a by-product of building.
End of document