ADR-0014: Assignment privacy and co-determination

Status: proposed (2026-10-12), awaiting legal review and, for German deployments, works-council review. Input: docs/legal/assignment-assessment.md.

Context

Expertise-aware assignment suggests and optionally applies reviewers and assignees. The feature may be a high-risk AI system under Annex III point 4 of the AI Act (obligations from 2 December 2027, Regulation (EU) 2026/1744), processes employee data under the GDPR and is very likely subject to co-determination under § 87(1) No. 6 BetrVG. Classification is open until counsel signs off. The design must be acceptable under every outcome in the decision table of the assessment (§7) and allow the stricter outcomes without rework.

Decision

Modes and gates

• RepoPolicy.assignment.mode is off | shadow | suggest | apply; default off. shadow computes and stores suggestions visible to instance admins only and writes nothing to GitHub. suggest shows candidates in the dashboard and optionally as one comment; a human assigns.
• apply is effective only when all hold, checked by the API when the policy is saved and again by the worker before every publish (effectiveMode downgrades to suggest otherwise):
  1. Instance legal sign-off flag is set (stored append-only in assignment_legal_sign_offs, readable but not writable by tenant-scoped workers, so the worker can re-check it under withTenant): { outcome: 'A' | 'B' | 'C', permittedModes, documentRef, signedOffAt }. Only instance:manage can set or clear it; every change is audited. outcome and permittedModes follow the decision table; without the flag, assignment runs in shadow only (results visible to instance admins, no comments, no API writes).
  2. Explicit per-repository opt-in by a tenant admin, audited, with a confirmation text naming the effects.
  3. Works-council mode is off, or the tenant's works-agreement attestation explicitly permits apply.
• In the hosted edition the instance flag records the provider's assessment; each tenant additionally records its own deployer attestation (DPIA done, employees informed, works agreement where required) before suggest leaves shadow. Hosted instance admins act for the processor, so hosted shadow results are stored for evaluation but not shown per person to anyone.

Works-council mode

• Tenant setting employment: { country, worksCouncil: 'yes' | 'no' | 'unknown', attestation? }. The setup wizard asks before assignment can be enabled; the country is prefilled from the instance locale and the GitHub organisation location, never decided from them alone.
• Works-council mode is on when country is DE and worksCouncil is not no, and when the answer is missing. Turning it off requires a tenant admin to confirm that no works council exists, audited.
• In works-council mode: the feature stays off (no shadow computation, no familiarity cache) until an attestation that co-determination is complete (reference to the works agreement, date), following the decision table of the assessment (§7); team-level metrics only (forced); apply refused unless the attestation allows it; per-person views and exports disabled; retention at the shortest configured values.

Inputs and outputs

• Inputs are a closed allowlist: CODEOWNERS ownership, time-decayed commits, blame and reviews on the affected paths, similar-issue fixers, current open assignment counts, availability intervals, privacy flags. Excluded: anything measuring speed, volume, quality or acceptance per person, personal traits, calendar content (full list in the assessment, §2). New factors need an amendment of this ADR and renewed legal review.
• The familiarity cache is keyed by path and person and holds only decayed per-path values; no per-person totals, rankings or historised scores are computed or stored.
• No per-person scores are shown publicly or returned by any API outside the single request's explanation. Comments name only the suggested people and their explanation facts; other candidates, numbers and ranks are never published.
• Explanation facts come from a fixed set of templates, each mapped to an allowed input: owner of a path per CODEOWNERS; changed or reviewed N of the affected files in the last D days; worked on similar issue #N; currently N open reviews or issues; available; suggested together with @x to spread knowledge of these files (no statement about the person's experience). Wording is team-neutral and the comment carries the automated-output notice.

People's controls

• Individual opt-out in the user's settings: the person is never auto-picked or suggested, and remains assignable manually. Opt-out needs no reason and is not visible to other users.
• Team-level-metrics-only switch (tenant): disables every per-person view and endpoint in assignment and analytics; endpoints return 404, tested.
• Availability is opt-in; ICS feeds are reduced to OOO from/to at import.

Learning

• Manual reassignment within the window records feedback_events(reassigned) with the repository, the factor values of the suggested and the chosen person, and no free text.
• Learning adjusts only per-repository factor weights (bounded, shown in the UI). No per-person parameter is learned; being reassigned away never lowers a person's future suggestions.

Audit, transparency, retention

• Every applied assignment writes an audit entry: repository, target, chosen people, mode, policy version, explanation facts, and the actor who enabled apply. Manual overrides of applied assignments are recorded as feedback, not as audit against the person.
• A transparency page, readable by every tenant member, lists the inputs, excluded data, mode per repository, retention, opt-out and the responsible contact configured by the tenant.
• Retention defaults (tenant-configurable, shorter in works-council mode where allowed): assignment records and explanations 6 months; availability intervals 30 days after their end; reassignment feedback 6 months; familiarity cache recomputed, not historised; audit entries per the audit-log policy and pseudonymised on deletion requests.

Consequences

• The feature can ship in shadow and suggest before sign-off without blocking on legal outcomes; apply needs counsel.
• High-risk readiness: logging, instructions for use (intended purpose, prohibited uses, excluded inputs), human-oversight controls and risk documentation are produced with the feature, so a conformity assessment by internal control is possible before 2 December 2027 if required.
• Accuracy may be lower than with richer signals; the eval gate compares against baselines using only the allowed inputs.
• Customers who change inputs in a fork change the intended purpose and may become providers themselves; the instructions for use say so.

Confirmed defaults

Confirmed by the maintainer on 2026-10-13:

1. Works-council mode without a works agreement keeps the feature off, not shadow.
2. In the hosted edition, shadow results are visible to nobody.
3. GitHub "Busy" status is read only for people who opted in to availability.

Open

• Counsel's classification outcome and permitted modes (assessment §8).
• Jurisdictions other than Germany with co-determination (e.g. Austria).
• Retention periods outside the high-risk case.