The last three Runtime Snapshots posts built a stack. named the three ways it can see: vision, accessibility tree, and runtime perception. I called it runtime structural perception; the name has since settled.) A structured runtime snapshot answers the questions an action loop actually has: what can I see right now, what can I act on right now, what's disabled or hidden or covered or loading or stale, which element identities will survive the next action, which text is the task and which is nav and chrome and framework residue, what changed since the last step.
Concretely, it carries the gap between what the HTML says and what the page is:
form#login (action=/auth)
input[email] "[email protected]"
input[password] required
button[submit] "Sign in" [disabled]
div.error.hidden "Invalid credentials"
The disabled submit button and the not-yet-visible error are exactly the kind of state that decides whether the next action does anything. They're ambiguous in pixels, often incomplete or unreliable in a thin accessibility view, and present but noisy in raw DOM. SiFR, the Structured Interface Representation used by . The public category and evidence surface is at , and the Runtime Snapshots index lives at
This is part 18 of the Runtime Snapshots series - exploring how structured browser data changes the way we build, test, and ship software. #16 named the three architectures; #17 made them share a session; this one is about what any of them perceives before it acts.
If you've built or used browser agents - where did yours fail first: perception, planning, or action?
SOCIAL SHARE CARD GENERATOR