One block model, two surfaces
Giant Context does not store a web page as a page or an email as an email. It stores content as blocks. A block is a typed unit, a button with its options, an image with its caption, a divider with its style. A page is a list of them. An email is a list of them. The same list can become either one, because the block is the thing that is real and the page and the email are two ways of rendering it.
That matters because a website and an email are not the same medium. A web page is modern HTML in a forgiving browser. An email is a hostile target, tables inside tables, a decade of client quirks, no reliable stylesheet, rules that were old when the browser was young. The two are rendered by different engines. What they share is the model above them.
Two engines, one vocabulary
The website takes a block and renders it to HTML. The email app takes the same block and renders it through MJML, which compiles down to the table-based markup that survives in an inbox. A button is a button in both places, with the same options, variant and size and radius and alignment. It is drawn as a styled element on the site and as a table cell that survives the inbox. The person who placed it in the builder thought about a button, not about either rendering.
Here is the button block on its way to the inbox, rendered to MJML:
The button block, rendered to MJML
<mj-button href="/signup" background-color="#ff5722" border-radius="8px" align="center">Start free</mj-button>MJML compiles that to the nested tables an email client will honor. The same block on the website becomes a styled element the browser takes directly. One definition, two very different outputs.
The email blocks were built to match the website blocks feature for feature, on purpose. When the website button gained an outline variant and a border radius, the email button gained them too. The MJML compiler learned to express them in a way an email client would honor. The work is keeping the two vocabularies identical, so that anything you can say on the page you can also say in the mail and have it render correctly in both.
Engine
HTML, taken by the browser
MJML, compiled to nested tables
The button becomes
a styled element
a table cell that survives the inbox
Environment
modern, forgiving
hostile, a decade of client quirks
variant, size, radius, alignment
Kept in feature parity
The drift you do not pay for
Without one model, the shape is two systems. A website builder over here, an email template tool over there, each with its own idea of what a button is. They start close and come apart. The brand color changes and the site updates and the email is a season behind. The logo is replaced everywhere except the footer of the newsletter. Nobody decided the email should look older than the site. It just drifted. Consistency across two separate systems is manual. Manual consistency decays.
One model does not drift from itself. Brand lives in the blocks and the theme they read from, defined once. A change to it is a change everywhere it renders. The website and the email are current with each other because they are the same content seen twice, not two copies kept in step by hand. Consistency stops being a task and becomes a property.
Consistency stops being a task and becomes a property.
Structure is what a machine can hold
The same property serves a second reader. A block is structured. HTML is not. A page of markup lets anything sit anywhere. To know what it means you have to parse it and guess. A list of blocks is typed. A button with its options, a heading with its level, a divider with its style. The meaning is in the shape, not inferred from it.
For a person that is merely tidy. For a model it is decisive. An AI asked to work over raw HTML is reasoning about presentation, tags and styles and nesting, looking for the content inside it. An AI working over blocks is handed the content already separated from its rendering, in named fields with known limits. It is a far stricter starting point. A model that writes into blocks is writing into slots that constrain what it can produce. Constraint is exactly what brand voice needs. You cannot hold a brand steady across freeform text. You can hold it steady across a structure that only permits certain moves.
That is the bet under the block model. The platform already made it once, feeding its AI structured events rather than raw logs. Blocks turn the same instinct on the content itself. Today it keeps a website and an email in agreement. What it sets up is a system where the content is legible enough, and bounded enough, for a machine to generate and govern it without losing the voice, because the voice is enforced by the structure and not left to the prose. The same decision that stops the email from drifting from the site is the decision that will let an AI hold the brand.
Define it once
The move is to model the real subject once, as structure, and let the surfaces render it. It is the instinct the platform was built on, the architecture before the product. A page and an email are renderings. The brand is a set of values the blocks read. The content is a list of typed units, not a document. Done that way, two outcomes you would otherwise fight for come for free, a website and an email that agree, and a structure a machine can be trusted to write inside. The page was never the thing. The blocks were.
Have questions?
If you're interested in my work or Giant Context, contact me!