Data Processing Agreement

Last updated: 7 October 2026

This DPA applies automatically when your organisation uses AllAddin. By using the service, you (the Controller) appoint MeliUX Ltd (the Processor) to process personal data on your behalf under the terms below. No separate signature is required unless your procurement team requests one - email hello@alladdin.dev with "DPA request" in the subject line for a countersigned copy.

1. Definitions

"Controller" - your organisation, the entity that determines the purposes and means of processing personal data via AllAddin.
"Processor" - MeliUX Ltd, a company registered in England and Wales, which processes personal data on the Controller's behalf to provide the AllAddin service.
"Data Protection Laws" - the UK General Data Protection Regulation (UK GDPR), the Data Protection Act 2018, and any successor legislation.
"Personal Data", "Processing", "Data Subject", "Sub-processor" - as defined in the UK GDPR.

2. Scope of processing

2.1 Purpose

The Processor processes Personal Data solely to provide the AllAddin service to the Controller: receiving natural-language prompts from the Controller's users, forwarding them to an AI model, returning generated responses, and running the features those users invoke (for example room data sheet exports, compliance checks, procurement records and share links). Processing also includes authentication, rate limiting, usage tracking, and error monitoring necessary to operate and secure the service.

Separately, MeliUX Ltd keeps improvement-corpus submissions (the prompt, generated code and outcome of a completed turn) to improve the service, as an independent controller relying on legitimate interest. This is on by default; users can switch it off, and administrators can switch it off for all users, as described in the Privacy Policy.

2.2 Categories of Personal Data

Category	Examples
Identifier data	Hashed authentication token, IP address, browser user-agent
Usage data	Request timestamps, token consumption counts, route names, HTTP status codes
Content data	Natural-language prompts and structured summaries of the Revit model context (element counts, categories, parameter names, and other metadata selected by the add-in at the time of the prompt); generated code, its error text and printed output, which can include values read from the model. Never raw Revit project files (the detail library row below is the one exception, and holds single drafting views only).
Feature data	When a user runs the feature: room data sheet values, the differences between two dashboard snapshots, exported dashboard tables, EIR documents with the model title and element names, keynote and element descriptions; and, where the user saves them, procurement records (costs, quantities, suppliers, approvals, approver names) and compliance rule libraries.
Snapshot data (opt-in)	When a user explicitly uploads a model snapshot: element identifiers, categories, levels, worksets, and the parameters selected during capture. Never the underlying Revit file or its geometry.
Published workspace data (share link)	When a user explicitly publishes a share link: a frozen snapshot of the selected dashboard (element identifiers, categories, the parameters shown and, by default, 3D geometry). Encrypted on the user's device (AES-256-GCM) before upload and stored as ciphertext only in an EU-jurisdiction Cloudflare R2 bucket; the Processor holds the wrapped key separately. Never the underlying Revit file.
Detail library data (opt-in, per Controller)	When a user or the Controller's library admin explicitly adds a drafting view to the Controller's detail library or a private stash: a small Revit file containing that one drafting view, a thumbnail image, and a record (detail id, name, tags, scale, the adding user's label, timestamps, review decisions). Stored in an EU-jurisdiction Cloudflare R2 bucket under the Controller's tenant key, served through time-limited links to that Controller's tokens only, deleted when the Controller's admin removes the detail or the Controller requests deletion of its library. Never the Controller's project models.
Contact data (waitlist only)	Email address, optional free-text note

2.3 Data subjects

Employees, contractors, and authorised users of the Controller who interact with the AllAddin add-in or the alladdin.dev website.

2.4 Duration and deletion

Processing continues for the duration of the Controller's use of the service. Upon termination, the Processor deletes Personal Data within 30 days, except where retention is required by law. Audit logs and security events are automatically deleted on a 90-day rolling basis regardless of termination.

Export of data in a machine-readable format (for portability purposes) is available on request with up to 30 days' turnaround; email hello@alladdin.dev.

3. Processor obligations

Process Personal Data only on the Controller's documented instructions (which are: provide the AllAddin service as described in the Terms of Service).
Ensure that persons authorised to process Personal Data are bound by confidentiality obligations.
Implement appropriate technical and organisational security measures (see section 5).
Assist the Controller in responding to Data Subject rights requests (access, erasure, portability, etc.) within the timelines set out in the UK GDPR.
Assist the Controller with data protection impact assessments and prior consultations with the ICO where required.
Delete all Personal Data at the end of the service, with machine-readable export available on written request within the same 30-day window.
Make available information necessary to demonstrate compliance and allow for remote audits as set out in section 7.
Notify the Controller without undue delay (and in any event within 72 hours) upon becoming aware of a Personal Data breach.

4. Sub-processors

The Controller authorises the Processor to engage the following Sub-processors. The current Sub-processor list is maintained on the live Sub-processor register, which is the authoritative source for this DPA. The Processor will update the register before adding or replacing a Sub-processor; Controllers are advised to review it periodically. A Controller who objects to a new Sub-processor may terminate the service within 30 days of the update without further obligation.

Each Sub-processor publishes its own Data Processing Agreement which incorporates UK/EU Standard Contractual Clauses (SCCs) or a UK International Data Transfer Agreement (IDTA) as applicable. Transfers are supplemented by technical measures on our side: encryption in transit (TLS 1.2+) and pseudonymisation of authentication credentials at rest (a token is sent to our backend with each request, inside the TLS connection; the record we keep for an issued token is a truncated SHA-256 hash of it, not the token).

5. Security measures

All data in transit encrypted via TLS 1.2+ (provided by the sub-processor cloud platform).
Published share-link payloads are encrypted on the user's device (AES-256-GCM) before upload and stored as ciphertext only in an EU-jurisdiction Cloudflare R2 bucket; the payload key is held separately (wrapped), so no single sub-processor holds both key and ciphertext. Payloads are deleted when the link is disabled, or by a nightly clean-up within a day of expiry.
Detail library files are stored in the same EU-jurisdiction Cloudflare R2 bucket, under a per-tenant key prefix, encrypted at rest by the storage provider (they are not client-encrypted, since the Processor must serve them back to every token of that tenant), and served only through time-limited links minted for an authenticated token of the owning tenant.
Database hosted on Railway's managed PostgreSQL in the EU (Netherlands), which provides encryption at rest in line with its platform security policy.
Authentication tokens are sent with each request inside the TLS connection. The record kept for an issued token is its SHA-256 hash (first 12 hex characters stored), not the token.
Per-token and per-IP rate limiting to mitigate abuse.
Security event logging (failed auth, rate-limit hits) for incident detection, retained on a 90-day rolling basis.
Audit logs (request metadata, token usage) retained on a 90-day rolling basis.
Sentry error monitoring with PII collection explicitly disabled (send_default_pii=False).
Content Security Policy headers applied to JSON API responses.
No cookies, third-party tracking pixels, or third-party analytics scripts. Server-side aggregate page-view logging on the alladdin.dev website stores hashed (daily-rotating) IP and (two-hour-rotating) session identifiers only; no persistent identifier is retained. See the Privacy Policy for details.
Source code version-controlled on GitHub; commits signed; deployments via Railway auto-deploy from the main branch.

6. Data Subject rights

The Processor will promptly assist the Controller in fulfilling Data Subject requests. Where a Data Subject contacts the Processor directly, the Processor will redirect the request to the Controller unless the Controller instructs otherwise. Contact: hello@alladdin.dev with "Privacy request" in the subject line.

7. Audits

The Controller (or an independent third-party auditor appointed by the Controller, under an NDA acceptable to the Processor) may conduct a remote audit of the Processor's compliance with this DPA once per calendar year, upon 30 days' written notice. "Remote audit" means a documentary review via shared screen and written answers to a reasonable list of questions; on-site audits are by mutual agreement only and are not ordinarily required. The Controller bears the cost of the audit. The Processor may satisfy this obligation by providing equivalent third-party audit reports (if any become available) in lieu of a direct audit.

8. Breach notification

The Processor will notify the Controller without undue delay, and in any event within 72 hours, after becoming aware of a Personal Data breach. The notification will include the nature of the breach, categories and approximate number of Data Subjects affected, likely consequences, and measures taken or proposed to address the breach.

9. Governing law

This DPA is governed by the laws of England and Wales. Any disputes will be subject to the exclusive jurisdiction of the courts of England and Wales.

10. Relationship to other agreements

This DPA supplements and forms part of the Terms of Service. In the event of a conflict between this DPA and the Terms, this DPA prevails with respect to the processing of Personal Data. The Privacy Policy describes the Processor's data practices in plain language for end users.