visualizationlisted

# Visualization Guide — human-track views at pipeline decision points Where the **human** sees what the AI is about to do, at the gates of `docs/human/PIPELINE.md`. This is the **human track** — the **agent** documentation track is separate (GRACE: in-code, not human-read; see `AGENTS.md`, `skills/grace-ontology/SKILL.md`). The two coexist and **do not render into each other**. ## Why (the risk this closes) A plan can be internally consistent while omitting a requirement or adding an assumption. A compact visual gives the human a reviewable view of scope, structure and dependencies before work is turned into tickets. Mermaid is the default portable format, not a mandatory design method. --- ## Three rules ### Rule 1 — Write the viewpoint contract before notation Start with the stakeholder decision, then choose concern and scale, and only then select notation. For every durable gate view, write `docs/views/<view-id>.json` and validate it against `viewpoint.schema.json` before rendering: ```json { "$schema": "../../viewpoint.schema.json", "version": "1", "view_id": "story-payment-capacity", "stakeholder": "operations_manager", "decision": "where to add capacity before peak load", "story_ref": "US-17", "concern": "flow_and_overflow", "scale": "system", "focal_elements": ["incoming_orders", "processing_bucket", "overflow_queue"], "actors": ["operations_manager"], "metaphor": { "name": "buckets_and_overflow", "mapping": {"bucket": "worker_pool