{
  "schemaVersion": "1.0",
  "id": "compliance-pii-flow",
  "title": "PII data-flow diagram with audit history",
  "slug": "compliance-pii-flow",
  "diagramFamily": "architecture",
  "goal": "Maintain a regulator-friendly data-flow diagram showing where PII / KYC / financial data moves between systems, what each system stores, and how the topology has evolved over time, by combining a structured data-classification inventory with a Zindex scene that carries an immutable audit trail.",
  "inputs": [
    "Data-classification inventory (typically a YAML/JSON file in compliance/ describing which fields each system stores and their classification)",
    "Trust-boundary configuration (which systems sit inside vs outside the company perimeter)",
    "Existing Zindex scene id (one per audited workflow - e.g. one for KYC, one for billing)",
    "Zindex API key with scene-write scope"
  ],
  "outputs": [
    "Updated persisted scene with one node per system, edges labelled by what data crosses (e.g. 'full PII (DPA)'), and a frame around any external trust boundary",
    "Rendered SVG suitable for inclusion in a SOC 2 / ISO 27001 audit pack",
    "Revision diff showing what changed between this audit cycle and the previous one (which is the auditor-facing answer to 'what changed since last quarter?')",
    "Per-revision watermark trail proving the diagram pinned to a specific date"
  ],
  "mcpTools": [
    "dsp_get_scene",
    "dsp_apply_ops",
    "dsp_validate_scene",
    "dsp_render_scene",
    "dsp_diff_scene",
    "dsp_list_revisions"
  ],
  "httpEndpoints": [
    "GET /v1/scenes/:id",
    "POST /v1/scenes/:id/applyOps",
    "POST /v1/scenes/:id/render",
    "GET /v1/scenes/:id/revisions",
    "GET /v1/scenes/:id/diff"
  ],
  "steps": [
    {
      "id": "fetch_scene",
      "label": "Fetch the persisted compliance scene",
      "description": "Compliance scenes are long-lived - one scene per audited workflow, with ten or twenty revisions stretching back over the audit history. Fetch the current revision before changing anything.",
      "mcp": "dsp_get_scene",
      "http": {
        "method": "GET",
        "path": "/v1/scenes/${SCENE_ID}"
      }
    },
    {
      "id": "read_classification",
      "label": "Read the data-classification inventory",
      "description": "Parse compliance/data-classification.yaml. Each entry maps a system to the data it stores and its classification (`public`, `internal`, `pii`, `kyc`, `financial`). Edges between systems are derived from which classification crosses each boundary.",
      "mcp": null,
      "http": null
    },
    {
      "id": "diff_against_scene",
      "label": "Compute the diff against the persisted scene",
      "description": "For each system in the classification, ensure a node exists with the expected nodeType (`actor`, `service`, `database`, `externalSystem`). For each data flow, ensure an edge exists with the expected label (e.g. 'full PII (DPA)' or 'tokenized'). Style PII-bearing edges with a red stroke; tokenized/hashed edges with green; internal-only edges in default. Frame any external-vendor systems inside a dashed trust-boundary frame so the auditor can see what data crosses the company perimeter.",
      "mcp": null,
      "http": null
    },
    {
      "id": "apply_ops",
      "label": "Apply the operation batch",
      "description": "Send the diff as one applyOps batch. Use a `revisionMessage` that reads like an audit-log entry - 'Q3 2026: add tokenization layer between webapp and customer vault'. The revision message will surface in `dsp_diff_scene` output and ends up in the audit trail.",
      "mcp": "dsp_apply_ops",
      "http": {
        "method": "POST",
        "path": "/v1/scenes/${SCENE_ID}/ops"
      }
    },
    {
      "id": "validate",
      "label": "Validate the new revision",
      "description": "Confirm the topology is valid. Pay attention to `LABEL_DUPLICATION_DETECTED` (two edges with the same label between different systems can confuse an auditor) and resolve before publishing.",
      "mcp": "dsp_validate_scene",
      "http": {
        "method": "POST",
        "path": "/v1/scenes/validate"
      }
    },
    {
      "id": "render",
      "label": "Render the data-flow diagram",
      "description": "Render to SVG. The watermark stamps scene-id + revision + date so the auditor always knows which version of the diagram they are looking at, with no separate metadata sidecar.",
      "mcp": "dsp_render_scene",
      "http": {
        "method": "POST",
        "path": "/v1/scenes/${SCENE_ID}/render",
        "exampleRequest": "{ \"format\": \"svg\", \"theme\": \"clean\" }"
      }
    },
    {
      "id": "diff_for_audit",
      "label": "Generate the audit-cycle diff",
      "description": "On audit cycles (typically quarterly), call `dsp_diff_scene` with `from=` the revision pinned at the start of the audit period and `to=` the current revision. The output is the canonical answer to 'what changed since last audit?' - far better evidence than a stack of dated screenshots.",
      "mcp": "dsp_diff_scene",
      "http": {
        "method": "GET",
        "path": "/v1/scenes/${SCENE_ID}/diff?from=${AUDIT_START_REVISION}&to=${NEW_REVISION}"
      }
    },
    {
      "id": "publish_to_audit_pack",
      "label": "Publish the SVG + diff to the audit pack",
      "description": "Drop the rendered SVG and the diff JSON into the audit-pack directory. Both are traceable back to the persisted scene by id + revision; auditors who want to verify the diagram against current systems can replay the workflow at the recorded revision number.",
      "mcp": null,
      "http": null
    }
  ]
}