# docs/compliance/sub-processors.example.yml — annotated reference for the sub-processors schema
#
# This file is NOT generated. It shows both kinds of entries that appear in
# compliance/sub-processors.yml and explains what each field means.
#
# Generated artifact : compliance/sub-processors.yml
# Generator          : pnpm compliance:sub-processors
# Sources            : (1) docs/library-decisions/*.md  — frontmatter where is-sub-processor: true
#                      (2) compliance/sub-processors.manual.yml — hand-authored non-SDK vendors
#
# The two entry kinds are described below. Fields are rendered in a fixed order:
# package first, then remaining fields alphabetically.

sub-processors:
  # ── Kind 1: library-trace entry ───────────────────────────────────────────────
  # Sourced automatically from a library-decision file in docs/library-decisions/.
  # To register a library as a sub-processor, add these fields to its frontmatter:
  #
  #   is-sub-processor: true
  #   data-sent: "user email and display name for transactional notifications"
  #   region: EU
  #   dpa-signed: true
  #   sccs-required: false
  #   contact: https://acme-sdk.example/privacy/dpa
  #
  # The generator reads package, version, and decision from the existing trace
  # frontmatter and merges the sub-processor fields automatically.
  - package: "@acme/notifications-sdk" # npm package name (natural sort key; must match package: in trace)
    contact: https://acme-sdk.example/privacy/dpa # DPA / privacy contact URL
    data-sent:
      "user email address and display name for transactional notification delivery"
      # Plain-language description of what data is transmitted
    decision: approved # Carry-through from library trace (approved | rejected | …)
    dpa-signed: true # Data Processing Agreement in place with this vendor
    region: EU # Primary data-residency region for this processor
    sccs-required:
      false # Standard Contractual Clauses required for data transfer?
      # Required when region is outside the EEA and no adequacy decision
    source: library-trace # Fixed value for entries sourced from a library decision file
    version: "^2.3.0" # npm version specifier from the library trace

  # ── Kind 2: manual entry ──────────────────────────────────────────────────────
  # For sub-processors that are NOT npm packages (REST APIs, SaaS integrations,
  # infrastructure providers, etc.), create compliance/sub-processors.manual.yml
  # and add entries there. The generator merges this file at emit time and injects
  # source: "manual" automatically.
  #
  # Format for compliance/sub-processors.manual.yml (simple YAML list, no header):
  #
  #   - package: acme-email-service
  #     version: REST API v3
  #     data-sent: "user email address and message content"
  #     region: EU
  #     dpa-signed: true
  #     sccs-required: false
  #     contact: https://acme-email.example/legal/dpa
  #     decision: approved
  #
  # The "package" field is used as the sort key; use a slug-style identifier.
  - package: acme-email-service # Slug identifier for non-npm vendors (no @ prefix)
    contact: https://acme-email.example/legal/dpa
    data-sent: "user email address and message body for transactional email delivery"
    decision: approved
    dpa-signed: true
    region: EU
    sccs-required: false
    source: manual # Fixed value for entries sourced from sub-processors.manual.yml
    version: "REST API v3" # Non-npm version descriptor; use the API version or contract date