Start with the content that must remain reusable: headings, text, media, links, and repeatable items. Add presentation choices only when an editor genuinely needs them. A narrow model is easier to migrate, translate, search, and deliver through an API.
Give Structured Content a Shape Editors Can Use
A content model is only useful when an editor can understand it without reading the implementation. Field names should match the job at hand. Constraints should prevent real mistakes. Optional fields should remain optional.
PagibleAI defines elements in JSON schema and renders them with Blade. Editors get a focused form; developers keep a small, reviewable contract between stored content and the frontend.
{
"testimonial": {
"label": "Testimonial",
"fields": {
"quote": {"type": "text", "required": true},
"name": {"type": "string", "required": true},
"role": {"type": "string"},
"image": {"type": "image"}
}
}
}A model has three readers
The editor
Needs plain labels, sensible defaults, and enough structure to avoid cleanup later.
The frontend
Needs a stable data shape that a Blade view or API client can render without guesswork.
The next developer
Needs a schema small enough to review and extend without tracing hidden conventions.
PagibleAI in practice
Model the content your team already understands
Follow a concrete example from schema definition to editable field and Blade output.