Semantic pattern · Traceable block decomposition

Payment gateway block decomposition

Three blocks, one root, each with a stable ID a reader can cite directly. The diagram shows only a badge, a name, and a short flow — inputs, outputs, constraints, and implementation paths live in the metadata, not the canvas.

Payment gateway block decomposition Traceable block decomposition of a payment gateway into card authorization, fraud screening, and settlement ledger, with a stable ID, inputs, outputs, constraints, and an implementation path carried as metadata on each block. TIER 0 · ROOT TIER 1 PAY-001 Payment Gateway request → settlement PAY-001-01 Card Authorization card → token PAY-001-02 Fraud Screening token → score PAY-001-03 Settlement Ledger release → ledger

THE HEADLINE

Every block gets a stable ID

The badge is the citable handle — "PAY-001-02" means one specific block, permanently. A reader, a review, or a compliance record can point at it directly instead of describing a box's position on a page.

The canvas shows the minimum

  • ID badge, name, and one short flow line
  • Inputs/outputs/constraints stay off-canvas
  • Carried in data-block-* attributes instead
  • Same node primitives, zero new SVG grammar

Registry export on demand

The full record — every attribute on every block — projects into a JSON sidecar on request. Regenerated from the diagram itself, never hand-maintained separately from it.

payment gateway block decomposition example · schematic system