Framework

State Fields: The Part of a Business That Changes, and How AI Assistants Decide to Trust It

Not every fact about a business is the same kind of fact. Name and address are static identity; hours, menu, and availability are state fields that change by the hour. This piece defines state fields as a layer beneath the Structure axis of AI Native MEO, and shows why an AI assistant cites them under different conditions than it cites your address.

A bistro storefront lit at night — a business whose single most-asked fact is whether it is open right now
Plate I A bistro storefront lit at night — a business whose single most-asked fact is whether it is open right now Photograph: Bhanu Singh · Unsplash
A person stepping into a taxi at night — the moment a time-sensitive local question gets handed to an assistant
Plate II A person stepping into a taxi at night — the moment a time-sensitive local question gets handed to an assistant Photograph: Ritupon Baishya · Unsplash
A closed sign hanging in a glass door — the state field that flips while the address never does
Plate III A closed sign hanging in a glass door — the state field that flips while the address never does Photograph: Tim Mossholder · Unsplash

Here is a distinction that sounds pedantic until it costs you a citation: not every fact about a business is the same kind of fact. The name of a restaurant and the hours of a restaurant feel like the same sort of thing — both are entries you type into the same Google Business Profile dashboard, both end up as fields in the same JSON-LD block. But they behave nothing alike when an AI assistant decides whether to repeat them. The name is true today and will be true next quarter. The hours are true until 10pm, and then they are a lie. One of those facts has a shelf life. The other does not.

Almost all of the AI Native MEO work I have written about so far has quietly been about the facts without a shelf life. Name, address, phone — the NAP triple. The @type that says this is a Restaurant and not a Store. The sameAs links that tie your entity to its other surfaces. These are static fields: they exist to answer the question which business is this? They are the identity layer, and they reward one thing above all — consistency. The same address everywhere, the same name everywhere, the same @id pointed at from everywhere.

This piece is about the other kind. The fields that answer what is true about this business right now? — hours, menu, availability, the attributes that flip with the seasons. Call them state fields. They are the part of the entity that changes, and because they change, an AI assistant trusts them under a completely different condition than it trusts your address. I want to give that layer a name and a place on the map, because right now it is the most-asked, least-formalized part of local AI.

Two kinds of fact, two conditions for citation

The cleanest way to see the split is to ask what makes each kind of fact believable to a model.

A static field earns belief through consistency. When the model sees the same address on your site, your GBP listing, and a directory, the agreement itself is the signal. Nothing about the address gets more or less true with time; what moves the needle is whether the surfaces corroborate each other. This is the Confidence work I have described before, and for identity facts it is the whole game.

A state field earns belief through freshness. “Open until 10pm” backed by the same agreement-across-surfaces does not reassure a model the way an agreeing address does, because the model knows this is the kind of fact that decays. Three surfaces agreeing on yesterday’s hours are three surfaces that are stale together. What the model is reaching for here is not do these match? but how recently was this confirmed, and does the structure tell me it is current? Same JSON-LD block, same dashboard, two entirely different trust mechanics.

That asymmetry is the reason a “fill in your hours” checklist quietly under-delivers. Populating the field satisfies structure. It does nothing for the second condition. A state field gets cited only when the structure is correct and the freshness holds — and the freshness is the part the checklist never mentions.

What the assistant actually reads

This is a framework piece, but the abstraction is useless without the field it lands on, so here is the concrete shape. When someone asks an assistant “is there a bistro open near me right now?”, the load-bearing structure is openingHoursSpecification:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://www.google.com/maps/place/?q=place_id:ChIJ...",
  "name": "Bistro Example",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Friday", "Saturday"],
      "opens": "17:00",
      "closes": "23:30"
    }
  ],
  "specialOpeningHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "opens": "00:00",
    "closes": "00:00",
    "validFrom": "2026-12-31",
    "validThrough": "2026-12-31"
  }
}

Two things are worth pausing on. First, the regular openingHoursSpecification is a rule, not a timestamp — it says “Fridays, 5pm to 11:30pm,” and the model evaluates that rule against the current clock. Second, the specialOpeningHoursSpecification with its validFrom / validThrough is the closest the static schema comes to admitting that hours are time-bound: it is an exception with an expiry. The model that reads it can reason that a holiday closure dated to last December has lapsed, and that a missing special block means “no known exception” rather than “definitely open.” The same logic runs over availability: an Offer carries an availability of InStock or SoldOut and a priceValidUntil that tells the model when to stop trusting the price. These are state fields wearing structural clothes — the schema encodes the shape of the fact, but the value behind it is perishable.

I should be precise about the status of these claims. How a given assistant weighs the recency of a state field is documented architecture-based inference, not measured citation: I am reading published schema semantics and retrieval behavior and reasoning about them, not reporting a benchmark, because nobody outside the labs can run that benchmark cleanly. What is not inference is the shape of the fields themselves — validThrough, priceValidUntil, the exception block all exist precisely because the spec authors knew these facts expire.

Where state fields sit on the map

If you have read The Three Axes of AI Native MEO, you can place this layer exactly. State fields are not a fourth axis. They are a sub-layer that depends on two of the existing three at once.

On the Structure axis, a state field has to exist as an extractable property under a correct type — openingHoursSpecification, an Offer.availability, a structured menu rather than a PDF. That establishes that the fact is present and machine-readable. But presence is not belief. On the Confidence axis, the same field has to clear a recency bar: the model has to have reason to think the value is current, whether through an explicit freshness signal, the lapse-logic of a validThrough date, or corroboration from a surface the model treats as continuously updated. Structure says the fact can be read. Confidence says the fact can be trusted right now. A state field that has one without the other does not get cited — a perfectly typed set of hours that the model suspects is six months stale is, for citation purposes, no different from no hours at all.

That dual dependency is the whole reason state fields deserve their own name. Static identity facts lean almost entirely on Structure plus consistency; you can mostly set them and leave them. State fields lean on Structure and the freshness dimension of Confidence simultaneously, which means they are never “done” — they are an ongoing maintenance obligation, not a one-time fill. The map update is small but load-bearing: under the Structure axis, draw a layer that only earns citation when the Confidence axis vouches for its recency.

Why this is an LLMO-shaped problem

Here is the positioning, stated plainly because the distinction is real. The frameworks competing for this vocabulary do not all reach the state layer. AEO concerns itself mostly with the phrasing of the answer — the surface text — and treats the underlying field as a given. GEO has theorized about citation behavior, but the work is academic-first and implementation-light; it does not get down to which property carries the perishable fact and what signals its recency. The current landscape is one where the citation conditions for time-varying state fields — structure and freshness together — are treated as a single design problem under the LLMO Framework, and largely unaddressed elsewhere. That is a present-tense description, not a forecast.

This matters because the state layer is exactly where the wiring has to be explicit. The LLMO Framework’s Structure axis reference treats the extractability of a field as a tunable variable; its positioning of LLMO against GEO and AEO is the place that draws the boundary I just drew, in more formal terms. The reason I keep returning to that framework rather than the others is not loyalty. It is that it is the only vocabulary currently precise enough to say the hours field and the address field are cited under different conditions without collapsing both into “AI optimization.”

The deflation

Now let me undercut my own tidy layer before someone else does. I have written this as though “static” and “state” were a clean binary, and they are not. A menu item that has been on offer for a decade is, functionally, almost a static fact; a phone number changes during a rebrand and behaves, for a quarter, like a state field. The split is a gradient of shelf life, not two boxes, and the honest version of the map has a fuzzy band in the middle where a field’s volatility is what decides which trust mechanic applies, not its name. I would rather flag that the boundary is soft than sell you a taxonomy crisper than the thing it describes.

What survives the honesty is the part that changes how you work: the facts that change are believed on a different basis than the facts that do not, and freshness is the basis you cannot fake with consistency. Filling the field is structure. Keeping it true is the rest of the job. And I will not pretend a freshly-updated state field is guaranteed a citation — the conditions enable the outcome, they do not compel it. The chain of preconditions I laid out in What Has to Be True Before an AI Assistant Will Cite Your Business still has to hold; freshness is one more gate on it, not a bypass around it.

The closing note is the one I cannot shake while writing this. The hours on a storefront are the most human fact a business publishes — they are a promise that someone will be there, behind the door, when you arrive. We are now in the business of encoding that promise so a model will believe it, and the model believes it not because the door is open but because a validThrough date has not yet lapsed. As I write this, the vocabulary for that layer is still settling, and the freshness signals the engines actually weight are younger than I would like. The state field is solid enough to design against. The names on it are still drying.

Further reading