Bones Core: Your Own Content Model, One Set of Facts

The short answer

Bones Core is the part of Bones 9 that every site runs on. It lets an organisation describe the kinds of information it manages, keep each fact once, and publish it everywhere it is needed. Bones 9 is in development and is not generally available, and there is no release date.

Bones is the web platform we make. Bones 8.0 runs our larger sites today. Bones 9 is being rebuilt as an application on Laravel, in three parts: Bones Core, the Customer Portal and the Staff Console.

The problem: the same facts in too many places

Most websites do not start messy. They grow that way. A site begins as a set of pages. Then come a database for one feature, an integration with another system, a plugin or script that adds structured data for search engines, and a spreadsheet someone keeps for the things that did not fit anywhere else.

Each of those is maintained separately, and the same facts end up in several versions:

• A service is described one way on its page and another way in the structured data behind it.
• Opening hours are changed on the contact page but not in the footer, the map listing or the feed another system reads.
• A case study is updated while the service pages that mention it still show the old version.

Page templates also decide what content can look like. If the template has no place for a new kind of information, it ends up squeezed into a text box, where nothing else on the site can use it. And the machine-readable information that search engines and AI tools read drifts out of date, because nobody sees it.

None of this is anyone's fault. It is what happens when a website is treated as a set of pages instead of a system.

What Bones Core is being designed to do

In Bones 9, an organisation defines the types of information it manages, such as services, projects, case studies, people or locations. Each type has its own fields and its own relationships to the others, and it is defined in the admin rather than in code.

Records are then created against that model. A record is drafted and then published, with a review step wherever the organisation wants one, rather than going live the moment someone saves it. An audit trail is designed to record who changed and published what.

The same records then drive:

• the public website – the pages people read;
• integrations – connections with the other systems an organisation uses;
• machine-readable output – Schema.org JSON-LD, produced by AIDI;
• export and import – so the information can move in and out.

The point is that a fact is stored once. When it changes, every place it appears is generated from the same record, instead of being copied by hand. That matters for people, who see consistent information, and for machines, which read the same facts in the structured data as people read on the page. We explain why that matters for search and AI in why AI systems prefer structured websites.

An example

This example is illustrative. The content types, fields and approval steps are set up for each organisation.

A business publishes a new case study. Its content types might include services, case studies, articles, reviews and its company details. Marketing drafts the case study and a director approves it. The case study is linked to the services it supports and to the client's review.

When it is published, the case study page and those service pages update, with their structured data. Nobody has to remember to edit each of them.

The same idea works for other kinds of organisation. A school changing its term dates, or a council changing a library's opening hours, would change one record. The pages and structured data that depend on it would follow. The Bones page shows all three examples side by side.

How it fits with the portal and the console

Bones 9 is made of three connected parts:

• Bones Core – the part every site runs on, described in this article.
• The Customer Portal – being designed so a client organisation can see its installations, the people who use the portal, support tickets and invoices in one place.
• The Staff Console – our team's side of the same system, for running the installations we look after.

The core holds the content. The portal and the console sit around it: one for the client organisation, one for us.

Where it stands today

Bones 9 is in development and is not generally available, and there is no release date. The core is being built in stages; its specifications are drafts, reviewed in stages before anything is approved. The Bones 9 core platform case study records what is being built.

The idea is not new to us. Bones 8.0, our own PHP platform, already keeps content as structured data and generates pages and structured data from one set of content for our larger sites today. Bones 9 takes that further, as a full application. The story of how Bones got here is in Bones from 8.0 to 9.0. AI assistance in Bones is planned, not built.

What this means for you now

Until Bones 9 is ready, our larger sites run on Bones 8.0. If you want a site built on Bones today, that is done through Bones Implementation, starting with a Structural Blueprint from Structural Strategy.

Your content and data belong to you. Bones itself remains DBETA's proprietary platform, and the terms for using it are set out in your agreement.

If the wider question is how software like this gets built carefully, with AI tools inside a reviewed process, see our AI-assisted software engineering service.

Underneath the detail, the core comes down to one decision: a fact should be kept in one place and published from there. The pages and the structured data are both designed to be generated from that one place.