Why Everything in the CMS Is an Object
Kugel Platform's object model in plain language: governed objects, contracts, versions and locks, block-level addressing, agent-only notes, and the limits of the model.
4 min read By Platform Documentation Guide #Architecture #Publishing
Architecture
One model for every part of a site
A landing page, a footer menu, a colour theme and an article look unrelated in a browser. On Kugel Platform they are all governed objects: typed records kept in the site's own database, each with a contract, a history and one shared way to change it. Agents and people follow the same rules, so a change made by either can be checked, traced and reversed in the same way.
For a marketing team the payoff is control at speed. An agent can rewrite one headline without touching the rest of the page, every result can be tied back to the exact change that produced it, and nothing reaches readers by accident.
Object, contract, version, lock
Governed object. A record with a stable id, a type, a body and a history that is never pruned. There are 25 types today, from page, article and menu to offer, form, experiment and editorial voice.
Contract. The live rule book for one type: which fields exist, which edits are allowed, which checks run and how strict each one is, and whether publishing needs a human. Agents read the contract before they act, so the running system decides what is legal, not remembered documentation.
Version and content revision. Two counters. The version moves on every write, including locks and publishes. The content revision moves only when the content itself changes. Approvals pin a content revision, so approving an object approves exactly what was read.
Lock. Before editing, a writer checks the object out and receives a lock. Every edit carries the lock and the version it was based on, so two writers cannot silently overwrite each other.
Addressable down to the block
Objects are not edited as one blob. A page is an ordered list of sections, each with its own id. A composed section is a small tree of layout blocks, each with its own id. An article is an ordered list of nodes, such as a hook, an argument, a piece of evidence or a call to action, each with its own id and its own agent-only notes about the job that block does.
Those ids stay the same when the content changes. That is what lets an agent edit one block with only short summaries of its neighbours as context, lets a comment attach to a single element, and lets tracking report which section or block a reader actually saw.
Agent-only notes never leave the store. They are stripped when the reader copy is built, the renderer prints only reader-facing fields, and validation checks the reader copy again before anything publishes.
Example: changing one headline
Suppose a landing page's hero headline needs a sharper promise. An agent reads just that section, with the page's purpose and the neighbouring sections in summary. It checks the page out, dry-runs the new headline and applies a patch that changes that one field.
The section keeps its id, so the analytics history for that hero stays attached. The object's history records who made the change and how their identity was established. Every patch operation has an exact inverse, so the change can be undone without hand-editing anything.
What the model does not mean
Files in the code repository are copies. Publishing writes an export of each object into the repository, but those files are generated output. Editing them changes nothing durable.
There is no free-form escape hatch. Pages are built from registered section types and typed layout blocks. An agent cannot inject its own HTML, CSS or scripts.
Each site keeps its own objects. Sites share one engine, but not records, credentials or policies.
Published is not live. A successful publish proves an export exists. Readers see the change after a release or, for campaign pages, after the snapshot switch.