Feedback Data Processing Addendum

Audience: Customer privacy review, security review, procurement, DPO. This addendum to the Data Processing Agreement (DPA) specifies how AssetShop collects, processes, retains, and (where permitted) anonymizes operator feedback events used to improve service performance over time.

1. Purpose

AssetShop's services improve with use. Operator feedback - which recommendations were actioned, which proved correct, which were dismissed as false positives - is the cheapest signal to make detection sharper. This addendum specifies what is collected, how it is used, and what is never collected, so that customer privacy and tenant isolation are preserved by design.

2. The two layers

2.1 Layer 1 · Per-tenant adaptation (default ON, customer can opt out)

Feedback events recorded in your tenant are used to adapt detection thresholds within your tenant boundary only. No event payload, threshold value, or derived statistic from one tenant is ever observed by another tenant. Standard EWMA learning (alpha=0.1 default), clamped to operator-set hard bounds. The operator can pin (force-constant) any threshold or reset to default at any time.

2.2 Layer 2 · Cross-tenant aggregates (default OFF, explicit opt-in)

If and only if a customer explicitly opts in via the tenant feedback configuration UI, anonymized aggregate statistics may be computed across opted-in tenants. Aggregates pass three formal gates before any value egresses the tenant boundary:

1. K-anonymity floor (K≥5 by default): an aggregate must combine signals from at least K opted-in tenants. Below the threshold, the gate returns a privacy-gate error and no value is published.
2. Differential privacy (Laplace mechanism, epsilon=1.0 default): calibrated noise is added to numeric aggregates before publication. The smaller epsilon, the more privacy, the more noise. Each aggregate publishes the epsilon used.
3. Per-day query budget: 12 queries per aggregate definition per day by default, preventing disclosure via iterated querying.

3. What is collected (categorical feedback events only)

Each feedback event has the following shape:

• event_id: UUID v7-style identifier
• tenant_id: which customer tenant generated the event
• kind: one of recommendation.surfaced, recommendation.actioned, recommendation.outcome, recommendation.dismissed, recommendation.flagged_false_positive, query.executed, query.useful, query.unhelpful, signal.threshold_crossed, export.completed
• signal_type: a stable identifier for which detection signal (e.g. tail_spend_consolidation)
• actor: { kind: user|system|byo_ai_consumer, id, role }
• properties: categorical labels only (e.g. { domain: 'procurement', industry_bucket: 'mfg', tenant_size_bucket: 'mid' })
• occurred_at: ISO 8601 timestamp
• hash: SHA-256 of the canonical event payload, used solely for audit chain anchoring

4. What is never collected

Defense-in-depth: feedback events are rejected at ingest if any of the following are detected:

• Property keys matching PII-like patterns: name, email, phone, address, tax_id, duns, ssn, supplier, vendor, customer, po_number, invoice_number
• Property values matching email-shaped patterns (containing '@' and '.')
• Property values exceeding 64 characters (free-text disallowed)
• Property keys outside the approved categorical schema (when used as aggregate filters)

The approved categorical schema for cross-tenant aggregate filters is restricted to: domain, signal_type, industry_bucket, tenant_size_bucket, tenant_region_bucket, outcome_window_bucket.

5. Tenant consent procedure (GDPR Article 7 compliant)

Consent is per-tenant, granular, and revocable:

• Per-tenant adaptation: default ON. Tenant administrators can disable via the feedback configuration UI; takes effect immediately. New events from disabled tenants are silently dropped.
• Cross-tenant aggregates: default OFF. Tenant administrators must explicitly opt in. Withdrawal is immediate; from the moment of withdrawal, the tenant's signal stops contributing to new aggregates.

Every consent change is recorded in the audit chain (event_kind: feedback.consent.updated) with previous + next values and the acting user_id. This is required by GDPR Article 7(1) (controller must be able to demonstrate consent).

6. Retention

Feedback events are retained for 365 days by default. Tenant administrators may configure a shorter retention window via the feedback configuration UI. Per-tenant adaptive threshold records retain only the aggregate counts (TP/FP/TN/FN) and current threshold value; raw event references are not retained beyond the retention window.

Anonymized aggregate publications are retained indefinitely along with their hash + the audit chain anchor. The retention of aggregates does not pose a privacy risk because the underlying tenant signals are not recoverable from the aggregate (this is the formal property of differential privacy).

7. Audit trail

Every feedback-related action is recorded in the AssetShop audit chain with the following event kinds:

• feedback.event.recorded · an event was ingested (hash anchored, raw event remains in tenant store only)
• feedback.consent.updated · a tenant changed its consent posture (previous + next recorded)
• feedback.threshold.adapted · a per-tenant threshold drifted as a result of an observation
• feedback.threshold.bounds_updated · operator updated bounds, alpha, or pinned/unpinned adaptation
• feedback.threshold.reset · operator reset a threshold to default
• feedback.aggregate.published · an anonymized cross-tenant aggregate egressed (hash + tenant_count + epsilon recorded; tenant_ids NEVER recorded)

The audit chain anchors to Base L2 on the customer's tier cadence (60-min default; 15-min on Pro+ freshness-SLA add-on). Audit events are independently verifiable via the open-source @assetshop/verify-cli.

8. Customer rights

Each customer has the following rights with respect to feedback data:

• Withdraw consent: disable per-tenant adaptation and/or cross-tenant opt-in at any time; effect is immediate.
• Export own feedback data: receive a complete export of all feedback events in your tenant (categorical labels only; no raw event payloads exist because none are collected).
• Delete: request deletion of all feedback events older than a specified date; AssetShop will purge within 30 days and confirm via audit chain entry.
• Pin and reset: pin any adaptive threshold to prevent drift, or reset to default at any time.
• Inspect: view the full audit trail of consent changes, threshold drifts, and aggregate publications for your tenant via the platform UI or audit chain query.

9. Honest framing · what this addendum does NOT solve

Transparency about limits:

• This addendum prevents AssetShop from leaking tenant data via aggregates. It does not prevent a malicious tenant from manipulating its own signal to influence aggregate output. That is a different threat (Sybil / poisoning); we treat it via the K-anonymity floor (one malicious tenant cannot dominate an aggregate of K≥5).
• Differential privacy provides a formal upper bound on information leakage per query, but it is not absolute zero. We disclose the epsilon used so customers can independently assess.
• This is not "AI learning." It is principled statistics (EWMA + K-anonymity + Laplace DP). The techniques are 30-70 years old with well-understood properties. We do not claim more than we deliver.

10. References

• DPA §11: data export and audit chain export commitments
• MSA §12.14, Exhibit G: operator-hours reallocation covenant (separate from feedback data, also customer-bound)
• F-09 Privacy Policy: master privacy policy this addendum extends
• F-15 DPA Template: standard data processing agreement this addendum supplements
• Trust Center · Services that learn with use

This Feedback Data Processing Addendum is provided as a counsel-ready draft and supplements but does not replace the Data Processing Agreement (F-15).