ERC-1594 is the core lifecycle and transfer-validity layer inside the ERC-1400 family, not a full issuer-identity or compliance product.
The most important interface move is separating transfer execution from transfer validity checking through canTransfer and canTransferFrom.
The second key move is allowing transferWithData, transferFromWithData, issue, redeem, and redeemFrom to carry arbitrary bytes payloads, making offchain authorization injection part of the standard surface.
ERC-1066-style reason signaling is central to the design because it allows wallets, exchanges, and other integrations to inspect why a transfer would fail before paying gas to attempt it.
isIssuable is a meaningful governance surface: once it returns false, the spec says it must stay false and no further issuance can occur.
The broader Security Token Standard README confirms that the family was intended as a foundational, jurisdiction-flexible base that can sit under many different compliance designs.
Specific source signals worth retaining
ERC-1594 draft motivation: strongest source for why offchain authorization data and preflight transfer checks were treated as core security-token requirements.
ERC-1594 interface section: best concise source for the exact split between transfer validity, data-carrying execution, and issuance/redemption lifecycle events.
Security Token Standard README: best source for the family-level goal of standardizing compliant-token interfaces without hard-coding one identity model or jurisdictional regime.
Polymath explainer: useful narrative source for how the family authors framed ERC-1594 alongside ERC-1410, ERC-1643, and ERC-1644.
Why this entry belongs in the corpus
It gives the tokenized-asset compliance cluster a stronger lower-middle comparison point between minimal hook standards like ERC-1462 and richer systems like ERC-3643 or Tokeny.
It makes three layers easier to compare separately: transfer prechecks, offchain authorization injection, and issuance/redemption lifecycle control.
The durable insight is that a large share of security-token compliance can be modeled as queryable transfer validity plus explicit lifecycle events before identity and monitoring stacks are added.