TIER docs

Legal & Privacy: Deploying TIER Where Per-Developer Measurement Is Regulated

v0.7.0 organizations: Use the credential scope map for current administration and report access. This guide remains separate from the data inventory and trust limits.

⚠️ This document is not legal advice. It is deployment and positioning guidance written by engineers, not lawyers. Employment law, works-council obligations, and data-protection rules vary by country, by industry, and over time, and they turn on facts specific to your organization. Before deploying TIER in a way that measures named individuals, consult your own legal counsel, your Data Protection Officer (DPO), and — where one exists — your works council or employee representative body. Nothing here creates a compliance guarantee.

Why this document exists

TIER attributes AI token spend to outcomes. Named coaching cards are available on real servers: root keys read everyone, node keys (including read-only keys) read their dated branch and personal keys read their holder. Cards require neither viewer declarations nor positive verified spend. Card opens require a writable real server and must commit their view log before construction, under the holder-key rules. TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual. In several of TIER's target markets, measuring the performance of named employees is legally constrained — sometimes requiring prior co-determination or works-council agreement, sometimes restricted outright under data-protection law. Adopters need to understand that exposure before their legal and HR review, not after.

This guide covers: what TIER actually measures and stores; the EU labor-law exposure of per-developer measurement; TIER's posture under GDPR Article 22 (automated profiling); when a Data Protection Impact Assessment (DPIA) is indicated; the works-council consultation prerequisites; and a jurisdiction-by-jurisdiction decision table for choosing a deployment mode.

TIER's stance, in writing

TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual. TIER sets weighted merged work beside captured AI usage for coaching conversations; its positioning is grade the work, not the worker, by policy rather than by mechanism. Team reporting and access controls reduce disclosure but do not validate individual figures.

Two independent reasons make this the right posture:

  1. Legal. In co-determined jurisdictions (below), using a measurement system as an input to individual appraisal is precisely the use that triggers the heaviest obligations, and can be unlawful without prior agreement.
  2. Methodological. Per-developer TIER is easily distorted — by task mix, pairing, seniority, review load, and the incentive to game any number that is tied to a person's evaluation. TIER measures spend efficiency of a body of work, which is a team-and-portfolio property, not a fair proxy for individual worth.

The per-developer view is for coaching (a developer and their manager looking at how that person works with AI) and for engineering diagnosis (for example, "which spend is missing an issue reference?"). Make organizational decisions from team-level numbers.

What developer mode is (v0.7.0). It is a coaching view that a developer and their authorized branch holders read together, seeing the same numbers. A tool that shows named people's numbers can be used to monitor individual performance, whatever you intend, so the rest of this document applies to it in full. TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual. TIER cannot enforce that stance. It shows numbers; it cannot stop someone from copying one into a review. Only your written policy, or a works agreement where one applies, can.

Access and retention controls. Real servers always require issued keys. Root reads everyone; node keys read their dated branch and personal keys read self. Named cards and root compliance exports log before construction and fail closed when auditing is unavailable. The person can inspect their own view log on My card. Declarations, static/shared credentials and server reporting modes are removed. Root erasure remains available, and the org erasure route records its name-free person_erased audit row. The developer list has no TIER order. Use the credential scope map for who creates people, issues keys and reads reports. It links the separate rules for branch administration, personal-key custody and dated card access. These API controls do not restrict a host owner who can read the database file.

In real writable servers, named usage and outcomes are pruned at startup and daily: 90 days by default, 60–365 days configurable. Name-free historical totals remain in roll-ups. A permanent watermark refuses older named writes; widening the window works forward only and cannot restore pruned history. Server reporting modes are retired. Every real writable server initiates retention, including before its first watermark. Org audit names age out under the configured window. View logs have their own retention policy. Restrict access to the local database as well as the API.

What TIER measures and stores (and what it never touches)

The single most important fact for a privacy review: TIER never stores prompt or completion content, source code, or file contents, outside the free text of raw GitHub webhook payloads (below), and never sends any of it anywhere you have not already sent it: the optional reverse proxy passes prompts on to the provider you chose. Its parsers are field allowlists — token counts and metadata only. One opt-in switch, worktree attribution (off by default), widens the read when turned on, to find which branch the work was on. It decodes the file paths (file_path, notebook_path, path) from every tool call in every session file it scans, including sessions in repositories you did not configure, which are then dropped with nothing stored; it reads a git reflog, whose lines carry the committer's name and email and, for a commit, its subject line, only for a linked worktree of a repository you configured that those paths or the session's own folder are in, and for any other project it reads only the .git pointer and worktree admin files, never its reflog. It never reads the files the paths name, keeps none of those reflog fields and stores no path in an event, but the live watcher's checkpoint row keeps the absolute path of the worktree it is carrying, and spend in another repository's worktree is stored as unattributed:foreign-repo, without that repository's name or path; the full list is in privacy.md.

Parents no longer carry (#1016); only message groups labelled isSidechain:true can use carry. Worktree attribution stays opt-in and off by default. Activation requires recorded gates, the operator's security rulings and an explicit operator decision. No new accuracy figures have been measured.

Full, code-grounded detail is in docs/privacy.md (guarantee verified against the code on 2026-07-04). In summary, TIER stores in a single local SQLite file, with no external transmission by default:

The privacy guarantee bounds content. It does not by itself resolve the labor-law question, because the developer identifier plus cost attribution is personal data about a named individual regardless of whether any prompt text is stored. That is the subject of the rest of this document.

Organization access and separate installations

A v0.7.0 organization tree scopes delegated API access within one installation. It does not turn that installation into a service for mutually untrusted tenants. TIER remains single-tenant with no cross-team/cross-entity data isolation: every org table uses tenant_id='', and developer identifiers remain global within the database. Root administration and host access remain trust boundaries; a node key's branch limit does not constrain the host owner.

For a deployment review, record the people and key inventory boundary, including subtree padding, the one server per developer rule, and the federation acceptance limit. Separate database files and host access controls are still needed when separate installations are the intended boundary. Include the child upstream SSRF residual in the deployment's network review. For a transfer between installations, the graft snapshot boundary states what remains at the receiving server after source erasure or consent withdrawal.

EU labor-law exposure of per-developer measurement

In much of the EU, systems that monitor employee performance or behavior are subject to co-determination or works-council consultation before they may be introduced. Per-developer TIER, which shows an efficiency number for each named developer, is squarely the kind of system these rules govern. The threshold is generally the capability to monitor individual performance, not whether you subjectively intend to use it that way.

Germany — Betriebsrat co-determination (§87 BetrVG)

Under §87(1) No. 6 of the Betriebsverfassungsgesetz (BetrVG), the works council (Betriebsrat) has a mandatory co-determination right over the introduction and use of "technical devices designed to monitor the behavior or performance of employees." German case law reads this broadly: a system that is objectively suitable for monitoring individual performance is covered even if that is not its stated purpose. A per-developer TIER deployment is very likely in scope.

France — CSE works-council consultation

In France, introducing a tool capable of monitoring employee activity generally requires prior information-and-consultation of the CSE (Comité Social et Économique) (see, broadly, Art. L2312-38 of the Code du travail), and employees must be informed in advance of any system used to monitor their activity. The CNIL (the French DPA) has repeatedly emphasized proportionality and transparency for workplace monitoring. Per-developer measurement without prior CSE consultation and employee information is a live legal risk.

Netherlands — works council consent (WOR Art. 27)

Under the Wet op de ondernemingsraden (WOR), the works council (Ondernemingsraad) has a consent right (instemmingsrecht) under Article 27 over decisions to adopt, amend, or withdraw arrangements for personnel monitoring or for processing personal data of employees, including systems that monitor presence, behavior, or performance. Adopting per-developer TIER without the OR's prior consent can make the introduction voidable.

Other EU/EEA jurisdictions

Most EU/EEA member states have an analogous works-council consultation or co-determination regime for employee-monitoring systems (e.g. Italy's Art. 4 of the Statuto dei Lavoratori, which restricts remote monitoring of workers). Assume consultation is required and confirm locally. The safe default in any EU/EEA jurisdiction is team-only aggregate reporting plus advance consultation.

GDPR Article 22 posture (automated profiling)

GDPR Article 22 restricts decisions "based solely on automated processing, including profiling," that produce legal effects or similarly significantly affect an individual. TIER's designed posture keeps it clear of Article 22:

Independently of Article 22, per-developer cost attribution is personal data under GDPR. The usual obligations apply: a lawful basis (legitimate interest will require a balancing test and is weakened by any appraisal use), transparency to the data subjects, data minimization, purpose limitation, and storage limitation. Team-only aggregate reporting that cannot single out an individual is the strongest data-minimization posture.

When a DPIA is indicated

A Data Protection Impact Assessment is required under GDPR Article 35 when processing is "likely to result in a high risk" to individuals — explicitly including "systematic and extensive evaluation of personal aspects ... based on automated processing, including profiling" and "systematic monitoring." Several EU DPAs list employee monitoring on their mandatory-DPIA lists.

Practical guidance:

Works-council consultation prerequisites (checklist)

v0.7.0 availability: Named coaching cards are available on real data to the holder, root and dated branch node keys; the per-issue report remains denied in real-data reporting. tierd demo shows its own invented data read-only in a private temporary database and cannot load yours (code: internal/api/identity.go, identityRoutePolicies, identityBoundary; internal/api/coaching.go, handleCoaching; cmd/tierd/demo.go, runDemo).

Where a works council or equivalent body exists, treat the following as prerequisites before per-developer TIER goes live. Adapt to local law with counsel:

  1. Engage early. Bring the works council in at the design/decision stage, not after deployment. In Germany the co-determination right precedes introduction.
  2. Limit the purpose in writing. TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual. State the coaching purpose, what is measured, and the methodological limits.
  3. Describe the data. Provide the docs/privacy.md field list: what is stored, the no-content guarantee, retention bounds, and the conditional PII stores (watcher state, raw webhook payloads).
  4. Prefer the least-intrusive mode. Offer team-only aggregate reporting as the default; justify any per-developer processing against necessity and proportionality.
  5. Agree who may view, how views are logged, and how long data is kept. Name who may see a developer's numbers (for example, the developer and their declared manager); agree an audit log of who viewed what; set a retention period; and say how the single-tenant local database is protected. Per-viewer credentials, view logging and bounded retention are built; the agreement must specify their configuration and who administers them.
  6. Reach the required instrument — a Betriebsvereinbarung (DE), CSE information-and-consultation record (FR), or OR consent (NL) — before go-live.
  7. Provide transparency to employees and a route to raise concerns.
  8. Complete the DPIA and reconcile it with the consultation outcome.

Deployment decision table: team-only vs per-developer, by jurisdiction

The recommended deployment mode depends on where your developers are employed (the location of the employees measured, not the company HQ). "Team-only" here means reporting that never surfaces an individual developer's performance.

Current technical availability: Server mode selection is retired. Named reports follow root, dated-branch and personal-holder scopes; name-free monthly comparisons retain k/complementary suppression. There is no server flag that disables all named reports for authorized holders. The deployment table below describes organizational restrictions, not an available mode switch. See identity access.

Jurisdiction of measured employees Recommended mode Prerequisites before go-live Rationale
Germany (DE) Team-only Betriebsrat co-determination; works agreement (§87 BetrVG) if any individual-level capability remains; DPIA Per-developer monitoring is co-determined under §87(1) No. 6; suitability to monitor is enough to trigger it.
France (FR) Team-only Prior CSE information-and-consultation; advance employee notice; DPIA Monitoring tools require CSE consultation and transparency (Code du travail L2312-38; CNIL guidance).
Netherlands (NL) Team-only OR consent under WOR Art. 27; DPIA Personnel-monitoring arrangements need works-council consent before adoption.
Other EU / EEA Team-only (default) Local works-council consultation; DPIA; lawful basis + transparency Most member states have analogous monitoring-consultation regimes; confirm locally.
UK Team-only. Named coaching cards: available in v0.7.0 through issued holder keys under the access rules above UK GDPR lawful basis + DPIA; transparency; ICO employment-monitoring guidance No works-council co-determination regime, but ICO expects a DPIA and proportionality for monitoring.
US (at-will, non-union) Team-only. Named coaching cards: available in v0.7.0 through issued holder keys under the access rules above Internal policy; transparency; TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual. Fewer statutory constraints, but the coaching-not-appraisal stance still applies; state privacy laws may add duties.
Anywhere with a collective agreement / union Follow the agreement Whatever the agreement requires A collective bargaining agreement can impose obligations beyond statute regardless of country.

How to read this table: The team-only restrictions in the table must be implemented through deployment and organizational policy. TIER no longer offers an aggregation-mode switch that disables named holder views.

Per-developer deployment in a co-determined jurisdiction should not go live until both (a) the required works-council instrument is in place and (b) a DPIA has been completed. TIER is built for coaching, not for evaluating developers. Per-person figures are not accurate enough to judge an individual.

Summary

Erased people and later imports (#1491, ruling A⁗)

TIER keeps this record so a completed erasure stays effective. Your organisation decides the legal basis with its counsel.

On an erasure request, if any identifier has an import trace, TIER stores one unlinked keyed hash for each canonical ID, alias and mapped source name. A batch row mapped to someone else is not a trace. If erasure deletes a mapping row whose target is someone else, it also records that source name; a wrong exclusion is reported and reversible. Applied-batch plaintext source-name rows for the erased mapped person are deleted. Retention ageing makes no entry and never deletes entries. The record holds no figures, timestamp or link between identifiers and uses its own HMAC domain. Hashes never appear in API output, logs, audit rows, receipts, previews or data-subject exports. Those compliance artifacts state the record's existence in fixed wording, without checking membership or counting entries.

The record is not anonymous: anyone holding the database could test a guessed identifier. It matches on the identifier alone, so the same identifier from any source is excluded, including a different person. Preview and apply leave a match behind, rechecking inside the apply transaction, with this report line naming nobody: “One or more people were left behind so a completed erasure stays effective.” The bundle is not refused; lookup failure refuses the import. A wrongly excluded person has to come forward because the report names nobody; root can release them. A different (renamed) identifier evades the record. A person erased here with no import trace is not recorded, except this clash case, so a later first import can recreate them. A staged copy can remain for 24 hours.

Entries are kept until root clears them or the database is deleted, with no timer. A clear removes only the named identifier; a returning person with several identifiers needs one clear each. Root states either “new consent” or “a different person with that identifier” (the API value is different person with that identifier). The response is identical whether or not an entry existed. Each clear is audited without the identifier, hash or entry count. An audited clear-all states “our counsel refused this record”. There is no dashboard control. Nothing in the release waits for counsel, and no Article is cited as the record's legal basis. The secret and entries share the database file. Entries do not survive a restore from an older backup that predates them: restoring it loses newer entries and undoes those erasures. Re-run erasures after a restore.

See the root API commands for one-identifier clear and counsel-refusal clear-all.