Legal · Data protection
Privacy Policy
This draft explains the data flows visible in the current website code and identifies the facts the operator must confirm before a hosted service is offered.
Effective date: [insert publication date] · Status: draft pending the confirmations below
1. Scope and roles
Evidence Layer is the product name used by this website. The repository does not confirm the legal person or business that operates it. The operator must identify the controller for each processing activity before publication. Under the GDPR, a controller determines the purposes and means of processing; a processor handles personal data on a controller’s behalf under documented instructions. One organisation can have different roles for different activities.
If a future customer connects source material, the customer may be controller for that material while Evidence Layer may act as processor for specified service operations. The actual roles depend on who determines each purpose and must be set out in the service agreement and, where required, a data processing agreement. Evidence Layer may separately act as controller for its own account administration and security purposes. These are role descriptions to assess, not a final assignment of legal roles.
2. Current website and service state
The Evidence Explorer displays only workspace records that the server returns after verifying the signed-in account; it does not substitute synthetic records. The web code also contains Supabase Auth session and recovery flows and server-side workspace requests to an Evidence Service when the corresponding configuration is present. Those flows can involve an email address, account identifier, session data, workspace identifier, workspace name, and role. The operator must confirm which environments are live, what each vendor stores, and where it is processed before this text is published as a complete notice.
The public website does not generate answers with OpenAI or DeepSeek and does not connect customer source documents to a language model. Historical benchmark runs used public Real-World v1 and separately frozen synthetic evaluation materials in offline evaluations. Any future JEV, language-model, source connector, or hosted retrieval integration requires a reviewed data-flow notice before it is enabled. This policy makes no representation about a provider’s retention or training settings; those settings and contractual terms must be checked for each integration.
3. Data categories and purposes
| Category | Purpose | Current status |
|---|---|---|
| Account data: email, account identifier, authentication and recovery session data | Sign-in, account recovery, session security, and responding to account requests | Authentication code exists; actual live configuration and retention require confirmation |
| Workspace data: workspace identifiers, names, and membership role | Display or provision an authorised personal workspace | Server-side workspace API integration exists when configured; not source-document retrieval |
| Request and device data: IP address, browser headers, timestamps, and security events | Website delivery, abuse prevention, troubleshooting, and security where collected by the host or service | Provider logging and retention are not established by this repository and must be confirmed |
| Queries, candidate text, source references, and evidence selections | Potential future retrieval, ranking, provenance, and answer-context preparation | Not accepted by public pages; authenticated workspace content is handled by the service under the access boundary |
| Operational metrics: token counts, request duration, retrieval volume, estimated costs, and evidence-selection statistics | Potential future usage reporting, reliability monitoring, cost estimation, and product evaluation | Not currently exposed as customer usage telemetry in the web app; may be personal data if linked to an account or run |
4. GDPR legal bases
The controller must select and document an Article 6 basis for each actual purpose before processing. The table gives possibilities for assessment; it does not state which basis the unidentified operator currently relies on.
| Purpose | Possible Article 6 basis to assess | Required confirmation |
|---|---|---|
| Provide a requested account or contracted feature | Article 6(1)(b), where processing is objectively necessary for a contract or pre-contract steps requested by the person | Confirm the service/contract and data necessity |
| Protect sessions, prevent abuse, and maintain service security | Article 6(1)(f), where a documented legitimate-interest assessment supports the processing; Article 6(1)(c) only for a specific legal obligation | Document the purpose, necessity, balancing, and retention |
| Optional analytics or marketing, if introduced | Article 6(1)(a) consent where appropriate; device storage/access rules may separately require consent under applicable ePrivacy law | Do not activate optional tracking before the required consent and controls exist |
| Future customer-content retrieval or provider processing | Depends on the customer/controller relationship and the particular service purpose; Article 6 must be assessed per activity | Confirm roles, instructions, notices, contracts, and any required separate provider-transfer authorisation |
Reference: GDPR, Regulation (EU) 2016/679, Article 6.
5. Minimisation, retention, security, and access
Data should be limited to what is needed for a stated purpose, kept accurate where relevant, and deleted or anonymised when no longer needed. A final schedule must define retention for account records, recovery events, workspace metadata, access logs, support requests, source content, benchmark records, and backups: [insert confirmed periods and deletion process]. The actual host and provider retention settings must be included.
Controls visible in the code include server-side identity verification, cookie-backed authentication, and server-side forwarding of a verified session token to workspace API routes. The source-read boundary defaults to deny access unless a trusted boundary is provided. This is not a certification or a complete security statement. The operator must verify encryption, production access, key management, backups, audit coverage, incident handling, and vendor controls before making service-wide security claims.
6. Your rights and how to exercise them
Depending on the circumstances and applicable law, you may ask for access, rectification, erasure, restriction, or portability; object to processing based on legitimate interests; and withdraw consent where consent is the basis. You may also complain to the competent supervisory authority. Rights have conditions and exceptions under the GDPR.
Send requests to [insert monitored privacy contact]. The controller must verify the request proportionately, respond within applicable time limits, and explain any refusal. If Evidence Layer is acting as a processor for a customer, direct the request to that customer/controller; the processor should assist as required by its agreement.
Reference: GDPR, Articles 12–22.
7. Processors, providers, and international transfers
The repository identifies integrations with Supabase Auth and a configurable Evidence Service, and documents deployment of the website through Vercel. This is not a verified subprocessor register. Before publication, the operator must name each entity, purpose, processing location, retention, contractual role, and onward recipient. OpenAI, DeepSeek, and TypeSafe/JEV appear in separate benchmark tooling; they are not connected to answer generation by the public website. Their use for any future customer workload requires a fresh review and notice.
If personal data is transferred outside the EEA, the controller and processor must identify a valid Chapter V transfer mechanism for the actual transfer. This may include an adequacy decision or appropriate safeguards such as Standard Contractual Clauses, with any required transfer assessment and supplementary measures. No destination, adequacy decision, or safeguard is asserted here because vendor regions and contracts have not been verified.
References: EDPB guidance on international transfers and GDPR Chapter V.
8. Cookies and browser storage
The authentication implementation uses cookies for session and recovery flows. The theme preference is stored in browser local storage. No analytics or advertising tag was found in the application source reviewed for this draft; the hosting platform and any future tools may have separate storage or logs that still need an inventory. Before adding non-essential tracking, the operator must provide clear information and obtain valid consent where required, with a way to change or withdraw it.
Reference: EDPB FAQ on cookies and consent.
9. Account deletion requests
A signed-in person can create an account-scoped deletion request from the account panel. The request is idempotent, and accepting it blocks access to the account's data immediately. The current implementation does not offer cancellation after acceptance.
The implemented deletion slice removes the principal's source grants, member (non-owner) workspace memberships, and evidence and relationships in workspaces where the account is the sole active owner and no other active members exist. It records a content-free audit event for each successful deletion: actor, workspace, resource identifier, action, and result. It does not store the deleted text in that audit record.
This slice retains workspaces and owner memberships, evidence and relationships in shared workspaces, the source catalogue and snapshot metadata, stored objects, and the authentication identity. A request therefore does not yet achieve complete account erasure, and stored files or published snapshots are not deleted. Terminal purge and full erasure require separate work and are not offered by this interface.
If a request fails or is blocked, the account remains denied rather than silently returning to service. Requests, statuses, and the implementing scope are shown in the product and in the project's deletion documentation.
10. Changes and contact
Material changes to processing should be reflected here before the affected feature is activated. For privacy questions, contact [insert verified privacy contact]. The legal operator, postal address, effective date, and complaint contact remain publication blockers.