The "contract structural" family contains which five patterns, and what recurring problem drives most of them?

Contract Registry, Data Contract, Embedded Permission, Factory Contract, and Incentive Execution — most exist because deployed smart-contract code is immutable, so upgrading, controlling, and maintaining it needs deliberate structure.

Smart contracts are programs, so classic software-design ideas apply — but the chain adds a twist: once deployed, a contract's code (which is just data) can't be changed, and on a public chain more code means more storage and execution cost. The five patterns address that:

• Contract Registry — look up the latest version of a contract by a stable name, enabling upgrades.
• Data Contract — keep data in a separate contract so logic can be upgraded without migrating data.
• Embedded Permission — build access control into each contract function.
• Factory Contract — an on-chain template that mints consistent contract instances.
• Incentive Execution — pay callers to trigger maintenance functions that won't run on their own.

Upgradeability (Registry, Data Contract), access control (Embedded Permission), consistency (Factory), and self-maintenance (Incentive Execution) are the four needs.