Design a data schema with AI: entities, ownership and migration boundaries

A worked example: where the task becomes difficult

A fictional service app tracks customers, jobs and job visits. One job can require several visits, so putting a single visit date on the job will fail later. Describe real examples and cancellation behavior before asking for tables. Use controlled identifiers and a relationship diagram, then check whether the model supports the product’s ordinary and exceptional workflows.

Decisions to make before implementation

Choose authoritative identifiers, required fields, uniqueness and deletion behavior. Separate derived values from stored facts where useful. Define ownership and access alongside relationships, not after the interface is complete. Plan compatible migrations for existing records and identify who has permission to apply them. Avoid adding every possible future feature to the first schema.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• List real entities and representative relationships from the product task.
• Define constraints, ownership and lifecycle with normal and exceptional examples.
• Draft schema and a migration plan against the existing database.
• Apply only through authorized tooling and verify reads, writes and access rules.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Model customers, jobs and multiple visits from these examples. Inspect the existing schema first. Define ownership, constraints and deletion behavior, then propose a compatible migration. Separate generated SQL from applied state. Include direct constraint and access checks using controlled records; do not assume database permission from code access.

Failure modes that an attractive preview can hide

A schema can compile while failing the business contract, such as allowing duplicate job references or deleting shared customers unexpectedly. Test constraints directly. Do not claim production tables exist because a migration passed an isolated syntax check. Keep migration preparation, application and live validation as distinct evidence.

Technical references: MDN: form validation

Acceptance checks and the evidence to retain

Keep the entity map, constraint rationale, migration state and verified operations. Record unresolved ownership decisions before generating dependent screens.

Specific answers

Common questions