V01 of the package DDL: the charts, positions, and executions tables per ADR-0002 (as amended) and the storage contract's field set (ADR-0003 decision 3).

Table names, the surrogate primary key's column type, and the Postgres schema all come from the resolved StatifierPersistence.Ecto.Config - the same struct the generated schemas are built from. The engine identity columns (content_hash, session_id, execution_id) are text with their unique indexes regardless of the configured key scheme: the identity guard never touches a surrogate key.

This migration always emits :binary (bytea) for the three blob columns (identity_blob, chart_blob, position_blob) and does not read Config's :blob_type option. A custom :blob_type whose underlying database type is still binary (an envelope-encrypting type that dumps to and loads from raw bytes, for example) needs no DDL change - this migration already matches it. A :blob_type that dumps to a different underlying type (text, jsonb, a Postgres domain) needs the host to alter those three columns itself; this helper does not do it for them.

Each of the three tables carries the host's :leading_columns, if it configured any, immediately after id and in the order given - the one place a column the host owns can sit at a fixed ordinal position, since a column a later ALTER TABLE adds lands at the end. They are added as configured and nothing more: a default or a NOT NULL is a later migration of the host's own.

Two further options shape these three tables and nothing else. Under timestamps_position: :leading the inserted_at / updated_at pair follows the leading columns instead of closing each table, and :column_collations gives a text column declared here the collation named for it. Both exist so a host that once wrote these tables by hand can be matched column for column; the default for each is the layout above, unchanged.