Why SOM Exists: Designing a Semantic Object Model
Every agent browsing framework today sends the DOM to an LLM. Some strip tags. Some convert to markdown. Some use accessibility trees. All of them are trying to solve the same problem: the Document Object Model was designed for rendering engines, not for reasoning.
SOM is our answer. Not a better DOM parser - a different representation entirely.
The Cost of the DOM
Take the Wikipedia homepage. The full DOM is 47,000 tokens. Most of those tokens are noise: class="mw-parser-output", data-mw-section-id="0", style="display:inline-block;vertical-align:middle". Layout instructions. Accessibility attributes. Event handler metadata. Rendering hints.
An agent trying to find the featured article doesn't need any of this. It needs the text, the structure, and the interactive elements. Everything else is wasted context window.
What SOM Preserves
SOM extracts three things from a page:
- Structure - Headings, sections, lists, tables. The semantic hierarchy of the content. Not the layout grid.
- Content - Text, links, images with alt text. Deduplicated, cleaned, and ordered by document flow.
- Interactive elements - Forms, buttons, inputs, selects, links. Everything an agent might need to act on, with enough context to identify each one.
SOM does not preserve:
- CSS classes or inline styles
- Layout information (flexbox, grid, positioning)
- ARIA attributes beyond what's semantically meaningful
- Script or style elements
- Duplicate content (nav bars repeated in mobile and desktop views)
- Tracking pixels, analytics, or advertising markup
The Compression Question
Wikipedia compresses from 47,000 tokens to 4,500. That's 10.4x. But the ratio isn't the point.
The point is that those 4,500 tokens contain everything an agent needs to understand the page. It's not lossy compression where you throw away quality. It's a projection - like reducing a 3D scene to a 2D blueprint. The blueprint contains less data, but it contains the right data for the task.
Design principle: SOM is not "the DOM with stuff removed." It's a separate representation compiled from the same source. The compiler makes semantic decisions about what matters.
Regions
SOM organizes content into regions - semantic blocks that correspond to how a human would describe the page. "The navigation bar." "The main article." "The sidebar with related links." "The footer."
Each region has a role (nav, main, article, complementary, footer) and contains the content and interactive elements relevant to that section. The compiler uses HTML5 semantic elements, ARIA landmarks, heading hierarchy, and heuristic analysis to identify region boundaries.
This means an agent can ask "what's in the main content?" without scanning the entire page. The structure is already there.
Link Deduplication
Modern web pages include the same link multiple times - in the nav bar, in a card component, in "read more" links, in the footer. The DOM has all of them. SOM deduplicates: each unique destination appears once, in the most semantically meaningful context.
The Specification
SOM is a specification, not a feature. The full reference is in the SOM Reference docs. We want other engines to implement it. The goal is a standard representation for agent-web interaction, the same way HTML is a standard for document rendering.
Plasmate's SOM compiler is the reference implementation. It's Apache 2.0 licensed. Use it, critique it, improve it.