PBI Schema Authoring

Physical model structure work through manage_schema. Keep edits explicit, ordered, and dependency-aware.

Safe edit order

1. Inspect current state: list_model { "operation": "list", "spec": { "type": "tables" } }, then repeat for columns and relationships (spec.type takes exactly one value per call).
2. Before renaming or deleting, check consumers: manage_dependencies { "operation": "used_by", "spec": { "target": { "type": "column", "table": "<table>", "name": "<column>" } } } (spec.target is required on every call, with the object's singular type); { "operation": "summary", "spec": { "target": ... } } to gauge impact breadth.
3. For multi-object or risky edits, pin a rollback point first: manage_model_changes { "operation": "pin_checkpoint", "name": "before-<edit>" } (name is required), and prefer dry_run: true on the write.
4. Apply the manage_schema operation (create_table, update_column_properties, create_calc_column, create_relationship, create_hierarchy, create_partition, refresh_partition, …) with per-item identifiers inside each bulk item.
5. Validate after the edit: a scoped run_query { "operation": "execute", "query": "<validation query>" } that exercises the changed relationship, column, or partition.

Branch by task

• Tables, columns, calculated columns, visibility, formatting, date-table marking: column-and-table-authoring-guide.
• Relationships — re-check filter direction, inactive relationships, and ambiguity before applying: relationships-guide.
• Hierarchies: hierarchies-guide. Calendars and date tables: calendar-guide.
• Partitions and refresh scope: partitions-refresh-guide. Incremental policy design: incremental-refresh-policy-guide.

Guardrails

• Confirm destructive changes and refresh-impacting edits with the user before execution.
• Keep schema changes separate from semantic rewrites unless the task explicitly spans both.

Report results

After schema work, report:

1. Each operation applied, with table and target names.
2. Whether dry_run or transaction was used and the outcome.
3. Dependency-check results for renamed or deleted objects.
4. The validation query run and its result.
5. The checkpoint or transaction available for rollback.