Vocabulary Reference
21 properties across two implementation tiers. Each entry includes a definition, expected value, implementation guidance, what to avoid, and a worked example.
Foundation Tier
Foundation properties address the core gap: most brands provide no structured signal for AI identity, recommendation accuracy, or page intent. These can be implemented on any existing site without backend changes.
A plain-text statement of brand positioning written for LLM retrieval. More specific than schema.org description. Should include differentiation, audience, and category framing.
Guidance
This is the answer to the question an AI system will be asked most often about your brand: "what is [brand] and who is it for?" Write it as if you are briefing a knowledgeable friend who will then speak about your brand in conversation. Aim for two to four sentences. It should be specific enough that it could not describe your nearest competitor without modification.
What to avoid
- Generic claims that apply to every brand in your category
- Aspirational language about where you are going
- Jargon that requires industry context to decode
- More than four sentences
Example
"rosetta:positioning": "Nodal Strategy is a marketing infrastructure consultancy specialising in AI readiness for the queried era. We help brands build the machine-readable layer that ensures accurate representation in AI-mediated discovery."Guidance on tone and register for conversational representation by AI systems.
Guidance
This property describes how your brand says things, not what it says. Descriptive sentences work better than adjective lists. Keep it to three to five guidance sentences specific enough that two different writers following it would produce responses that sound like they come from the same brand.
What to avoid
- Instructions about content rather than register
- Contradictory guidance like 'professional but casual'
- Descriptors that apply to every brand — 'authentic', 'transparent', 'human'
- Adjective lists without context
Example
"rosetta:brandVoice": "Direct and specific — makes claims with evidence rather than assertion. Conversational in register but not casual. Avoids marketing inflation. Uses plain language over jargon. Short sentences preferred."Which web era this content is primarily designed for. Allows evaluation tools to assess infrastructure intent.
Guidance
Primarily for evaluation and audit tools. linear refers to broadcast-era content. navigated refers to content designed for the search era. queryable refers to content designed for the queried era — structured for machine comprehension. This property is honest self-assessment, not aspiration.
What to avoid
- Declaring queryable on pages where Brand Rosetta properties have not been implemented
- Using this property as a marketing claim rather than an infrastructure descriptor
Example
"rosetta:era": "queryable"URL of the primary llms.txt file for this domain.
Guidance
Connects the page-level structured data to the site-level llms.txt declaration, giving AI crawlers a direct path from any page to the authoritative site-wide brand document.
What to avoid
- Pointing to a placeholder or incomplete llms.txt
- Using a relative URL rather than an absolute URL with full domain
Example
"rosetta:llmsTxtURL": "https://yourdomain.com/llms.txt"Declaration of which AI crawler access policy this site has implemented.
Guidance
Surfaces the robots.txt configuration as a machine-readable declaration. Declare the policy that matches your actual robots.txt configuration. This property is honest infrastructure signalling, not a preference statement.
What to avoid
- Declaring a more permissive policy than your robots.txt actually implements
- Declaring blocked and expecting AI systems to represent your brand accurately
Example
"rosetta:crawlerPolicy": "structured"Specific scenarios in which this product or service is the right choice. More granular than schema.org audience. Written for AI recommendation contexts.
Guidance
Write use cases as complete scenarios, not audience labels. "Serious road runners training for events from 5km to marathon distance" is a use case. "Runners" is an audience label. Include three to six distinct use cases.
What to avoid
- Audience demographics without scenario context
- Use cases your product serves poorly
- Marketing language — use cases should read as objective scenario descriptions
Example
"rosetta:useCase": [
"Road running from 5km to marathon distance at training and tempo pace",
"Daily training shoe for heel-to-midfoot strikers seeking cushioned response",
"Performance upgrade from entry-level without moving to racing flat price point"
]Explicit statement of what this product or service is not designed for. Reduces AI misrepresentation and inappropriate recommendations.
Guidance
One of the most underused levers in AI readiness and one of the most valuable. AI systems frequently recommend products in contexts where they are a poor fit because they work from positive signals only. notSuitedFor provides the negative signal directly.
What to avoid
- Exclusions that are obvious from the product category
- Over-excluding — if the list is longer than five or six items the product may have a positioning problem
- Vague exclusions — 'not for everyone' is not a useful signal
Example
"rosetta:notSuitedFor": [
"Trail running on technical or loose terrain",
"Heavy lateral movement sports such as tennis or basketball",
"Minimalist or zero-drop preference",
"Gym use or cross-training"
]Declaration of the primary action this page is designed to drive. Provides AI systems with the intended outcome of engagement with this page — independent of whether a transactional endpoint exists to fulfil it.
Guidance
Most pages that exist to drive an action do not declare that action in structured data. rosetta:pageIntent fills this gap. It is not a transactional capability declaration — it does not require an endpoint. It is a statement of what the page is designed to accomplish. Distinct from rosetta:supportedActions, which declares what is currently wired.
What to avoid
- Declaring more intent than the page actually supports
- Omitting this on pages where the intent is obvious to a human — that apparent obviousness is precisely what AI systems cannot infer
- Using this as an aspirational claim
Example
"rosetta:pageIntent": ["purchase", "enquire"]Extended Tier
Extended properties require additional investment — an embedded AI chat interface, a live product API, or a transactional endpoint. Each is independent; implement any subset that matches your current infrastructure.
Evidence or proof points that substantiate the primary product claim. Distinguishes claim from substantiation for AI systems making recommendations.
Guidance
AI systems making recommendations increasingly prefer substantiated claims. Write it as a factual statement, not a marketing sentence. The most effective reason to believe is specific, verifiable, and tied directly to the primary product claim.
What to avoid
- Repeating the primary claim rather than substantiating it
- Vague or unverifiable evidence
- Award claims without context
Example
"rosetta:reasonToBelieve": "Lightstrike Pro midsole independently tested at 87% energy return by the University of Calgary Biomechanics Lab."The primary value this product or service delivers. Functional, emotional, or commercial.
Guidance
Name the one value most central to why buyers choose you over alternatives. Keep it to one sentence. It should complete the phrase: "the primary reason someone buys this is because they get..."
What to avoid
- Listing multiple value dimensions — choose the most important one
- Confusing value with features
Example
"rosetta:elementOfValue": "Elite racing midsole technology at daily trainer price."The specific occasion, need state, or decision moment this product or service addresses.
Guidance
Where rosetta:useCase describes the ongoing scenario your product serves, targetMoment describes the trigger — the specific point in time or circumstance that makes someone ready to buy. Describe the moment, not the person.
What to avoid
- Describing a demographic rather than a moment
- Overlapping too heavily with rosetta:useCase
Example
"rosetta:targetMoment": "Runner who has plateaued in entry-level footwear and is ready to invest in performance technology but is not yet committed to the price point of a dedicated racing flat."Ordered guidance for how a conversation about this page should progress when accessed by an AI agent. Not a script — a suggested sequence that respects user agency while routing toward useful outcomes.
Guidance
Design the flow the way a skilled sales consultant would approach the conversation. Establish context first, then qualify, then narrow, then route to action. Use four to five steps. Each step should be a question or topic to establish, not a scripted line.
What to avoid
- More than five steps
- Scripted responses rather than routing guidance
- Steps that assume information the user has not provided
- Skipping qualification and jumping directly to purchase routing
Example
"rosetta:conversationalFlow": {
"step1": "Establish running context — surface, distance, and pace goals",
"step2": "Understand current footwear and what is prompting the change",
"step3": "Confirm size and any fit considerations",
"step4": "Establish colourway preference from available options",
"step5": "Check availability and route to purchase or enquiry"
}The single most useful next question or action from this page context. Primary nudge for AI interactions when full conversational flow is not followed.
Guidance
If conversationalFlow is the full routing map, nextAction is the most important single turn. Think about the one question that most reliably moves a conversation from interest to useful outcome. Write it as an instruction to the AI, not as the question itself.
What to avoid
- Replicating the first step of conversationalFlow without adding standalone value
- Writing it as the question to ask the user rather than as guidance for the AI system
Example
"rosetta:nextAction": "Ask what size the customer normally wears before discussing colourway options or availability."An array of likely follow-up questions with suggested handling guidance.
Guidance
After a primary recommendation, buyers typically have a small set of predictable follow-up questions. Declaring them gives AI systems authoritative handling guidance rather than inferred answers. Focus on questions that most often determine whether a buyer proceeds or hesitates.
What to avoid
- Generic questions that apply to all products in the category
- Guidance that is too vague to act on
Example
"rosetta:suggestedFollowUps": [
{
"question": "Does it run true to size?",
"guidance": "Runs true to size for standard width. Recommend half size up for wide feet."
},
{
"question": "How does it compare to the Adizero SL?",
"guidance": "More cushioning and durability than the SL. Strider Pro suits higher mileage; SL suits tempo and race-day."
}
]A suggested follow-up prompt for AI interfaces to surface after a natural dwell period. Mimics conversational attentiveness rather than immediate interruption.
Guidance
Encodes the timing signal of a good human consultant — a prompt to surface after the user has had time to engage with the content. Write it as conversational text the AI interface could surface directly to the user. One sentence.
What to avoid
- Sales language or urgency signals
- Prompts that require context the AI does not have
- Identical prompts across all products
Example
"rosetta:delayedPrompt": "Still exploring? I can help you work out whether this is the right shoe for your training — just tell me what you're training for."URL of an endpoint returning the full product or service catalogue in structured JSON.
Guidance
Solves JavaScript-rendered catalogue invisibility without requiring architectural changes. An AI agent with tool use can call the endpoint and retrieve the full catalogue in one request.
What to avoid
- Declaring this before the endpoint is built and tested
- Pointing to an endpoint that requires authentication the AI agent cannot provide
Example
"rosetta:catalogueAPI": "https://yourdomain.com/api/products?format=json"URL of an endpoint that returns real-time product availability.
Guidance
Marks the boundary between passive and active AI readiness. The endpoint should accept product, size, and colour parameters and return availability, price, and alternatives. Build and test the endpoint before declaring it.
What to avoid
- Declaring the property before the endpoint is built and tested
- Pointing to an endpoint that requires authentication the AI agent cannot provide
Example
"rosetta:inventoryAPI": "https://yourdomain.com/api/inventory"Documentation of parameters accepted by the inventory API endpoint.
Guidance
Documents the API so AI agents can call it correctly without separate developer documentation. Write it as a summary section of an API reference — parameter names, types, required/optional status, and response format.
What to avoid
- Vague descriptions that leave parameter format ambiguous
- Omitting the response format
Example
"rosetta:inventoryAPIParams": "Required: product (string, product ID). Optional: size (string, UK sizing e.g. 9 or 9.5), colour (string, exact catalogue name). Response: available (boolean), alternatives (array), price (number), currency."URL of an endpoint that supports purchase, reservation, booking, or enquiry completion by AI agents.
Guidance
Where the inventory API answers 'is this available?', the transactional endpoint answers 'can I act on it?'. This is the most advanced Brand Rosetta property. Start with enquire or reserve before committing to purchase.
What to avoid
- Declaring a purchase endpoint without appropriate security measures
- Supporting more actions than your fulfilment infrastructure can reliably handle
Example
"rosetta:transactionalEndpoint": "https://yourdomain.com/api/transact"Explicit declaration of which actions an LLM agent can execute against this page's transactional endpoint. Distinct from rosetta:pageIntent, which declares the page's intended outcome.
Guidance
Where rosetta:pageIntent tells an AI system what a page is designed to accomplish, rosetta:supportedActions tells it what a live endpoint will actually accept. These are not always the same. Declaring both is honest and useful — the AI knows the goal and the current limit.
What to avoid
- Declaring purchase before the payment flow is agent-ready and secured
- Confusing this with rosetta:pageIntent — intent and executable capability are different
- Declaring actions the endpoint does not actually support
Example
"rosetta:supportedActions": ["reserve", "enquire"]Plain-text instruction for how an AI agent should check availability for this product or service.
Guidance
Bridges the gap between the AI agent's general capability and your specific API implementation. Write it as a direct instruction naming the property where the API URL is declared, the parameters it expects, and what the agent should do with the response.
What to avoid
- Omitting this when inventoryAPI is declared
- Writing it as a description of the API rather than an instruction to the agent
Example
"rosetta:checkAvailability": "Call rosetta:inventoryAPI with product ID, size, and colour before completing a recommendation. If available is false, surface the alternatives array."