Generative AI can produce Divi layouts — that is no longer the question. The question is whether the generated values are actually what Divi 5 really stores. Anyone who has ever searched the Visual Builder for an attribute invented by an AI knows the problem: the JSON looks plausible, lands in the database — and the Visual Builder silently ignores it or renders something other than intended.
The Diviskit Agent tackles this problem at the root: the MCP server's preset emitter only writes Divi shapes whose evidence is proven. Everything else is rejected — not with a warning, but with a hard gate.
The problem: plausible JSON is not verified JSON
Language models generate Divi attributes from patterns found in docs, schema and training. That works surprisingly well for common cases — and breaks exactly where Divi 5 has its quirks: wrapper structures (title vs. module vs. content), preset buckets with panel IDs instead of attribute paths, font patterns with and without a separate weight field, hover states without a value wrapper. A shape that is 95 % correct is one that renders 5 % wrong in production.
The honest answer is not "better prompting" but an evidence registry: for every attribute family and every module cell, it is documented on what basis its shape is known.
The registry: evidence levels instead of gut feeling
verified-attrs.json is the evidence store of the Diviskit MCP server. Every pattern family (e.g. divi/font, module.decoration.spacing) and every module cell beneath it carries an evidence level:
- UNVERIFIED — guessed or unknown
- SCHEMA_OBSERVED — derived from schema/docs, never checked against a real site
- RUNTIME_VERIFIED — accepted at runtime
- VB_ROUNDTRIP_VERIFIED — survived a Visual Builder round-trip
- VB_PRESET_STORAGE_VERIFIED — proven byte-exactly in the canonical Divi preset storage
- CROSS_VERSION_STABLE — verified identically on at least two Divi versions
The emitter may only write cells at VB_PRESET_STORAGE_VERIFIED or above. If a cell is missing or sits below that level, the gate refuses the write with a clear error — EvidenceGateError — instead of dumping an unchecked shape into the database. Two rules make this robust: effective evidence is always min(pattern level, cell level), and missing module cells never implicitly inherit from the pattern level.
New: the evidence pipeline automates verification
Until now, this evidence came from tedious manual dumps: build a preset in the Visual Builder, export the stored record, document the shape. That was correct but not repeatable — and it was tied to a legacy project. Now the verification itself is automated, via two complementary paths:
capture: the storage round-trip
diviskit-preset capture takes an emitter shape, writes it to a scratch site via the REST route /preset/create, reads it back via /preset/inspect and compares the emitted and stored attribute sets byte for byte. A match proves: our canonical shape survives the real Divi storage path losslessly. A mismatch is logged as a drift signal — into the backlog, never as a silent downgrade.
adopt: ground truth from the Visual Builder
For cells the emitter does not cover yet, diviskit-preset adopt reverses the direction: build the preset once in the Visual Builder, then adopt it by ID — the stored shape is canonical by definition and is taken over as evidence. That replaces the manual dump workflow: no export file, no copy-paste, no guessing whether the dump really contains the stored bytes.
build-registry: deterministic instead of hand-crafted
The registry itself is a generated artifact. A generator merges the hand-maintained seed (existing evidence) with the capture files — append-only, reviewable, visible in the git diff. Matches on two different Divi versions automatically lift a cell to CROSS_VERSION_STABLE. A --check mode regenerates in memory and fails in CI if anyone hand-edited the generated file.
What this means in practice
- Reliable presets. When the agent writes a button, font or spacing preset, its shape is proven on a real Divi site via storage round-trip — not merely extrapolated from the schema.
- Drift detection on Divi updates. Run the capture suite against the dev site once: every shape Elegant Themes changed in an update shows up as a diff — before it lands in customer layouts.
- Honest errors instead of silent defects. Unverified combinations are rejected instead of written "on the off chance". The agent says what it does not know.
- Versioned safety. Currently, central cells (spacing on sections, heading and body fonts in both font patterns, button background, border and font) are verified identically on Divi 5.6.x and 5.13.x —
CROSS_VERSION_STABLE.
Security built in
Captures only run against sites that are explicitly allowed: --site must be listed in the allowlist environment variable DIVISKIT_VERIFY_SITES and match the WP_URL host of the credentials. Three checks before a single request goes out — an accident against production is structurally impossible. Capture presets are deleted again immediately after readback.
The difference to the competition
Divi AI and generic AI page builders produce plausible stacks of sections — and leave the checking to the user. The Diviskit approach turns that around: verification is part of the machinery. Every writable shape carries traceable evidence, every Divi version becomes a regression test, and the gap between "looks right" and "provably right" is closed.
The evidence pipeline is part of @diviskit/mcp-server (open source, GPL). If you want to dig deeper: data/registry-seed.json and data/evidence/ in the repository show the complete mechanism — including the backlog file that lists which cells get verified next.