{
    "id": 1079458,
    "title": "The complete payload",
    "slug": "complete-payload",
    "type": "page",
    "url": "https://teas.co.uk/wiki/complete-payload/",
    "modified": "2026-11-15T01:40:49+00:00",
    "excerpt": "The complete payload is Lee Samuel Tucker's name for the full, structured answer a business hands an AI assistant in a single trip: what the product is, what it costs, whether it is in stock, the proof behind each claim, its limits, and the route to buy it.",
    "content_text": "In capsule: The complete payload is Lee Samuel Tucker's name for the full, structured answer a business hands an AI assistant in a single trip: what the product is, what it costs, whether it is in stock, the proof behind each claim, its limits, and the route to buy it. Lee groups it into four parts: product truth, claim boundaries, a citation graph and an action layer.\nThe complete payload is the practical side of a truth entity. Lee uses the term to describe the difference between an assistant having to piece together an answer from a page made for human eyes and an assistant being handed a prepared, checkable answer by the business itself. At teas.co.uk, the independent tea shop he runs from Tunbridge Wells, it is the reason products carry structured data behind their ordinary pages.\nA tea example: one trip instead of a dozen\nImagine someone asks an assistant for a strong loose leaf breakfast tea, no bags, under ten pounds. Working from ordinary web pages, the assistant has to make many separate trips: one for the page, one for the price, one for the picture, another to find a checkout link, with every trip a chance for one fact to disagree with another. It may end up with a low confidence guess and no source.\nAs Lee puts it: \"The complete payload turns those dozen trips into one.\" The assistant asks once and gets the product, its price and stock, the facts it needs to judge the request, the sources behind those facts and a link to buy, all drawn from the same record the shop's own page uses.\nThe more a customer says, the more this matters. A full request of the kind Lee calls Premium Intent, with its context, constraints and budget, can only be met if every fact it depends on comes back together and agrees.\nThe scenario is illustrative. The structure behind it is what the shop is built around.\nThe four parts\n\nProduct truth. Exact names, values with their units, the price and the stock position.\nClaim boundaries. What a product is, what it is based on, and what it should not be bought for. See claim boundaries.\nCitation graph. Each claim linked to the supplier document or other source behind it, so a reader can check it.\nAction layer. The checkout link and the rules that say where everything resolves, ready for an assistant to act on with the customer's permission.\n\nLee's longer description adds context around those four: the brand, relevant Tea Wiki and recipe pages, the main product image and its records, related products, and a short way for the assistant to report whether the route worked.\nWhat is built today\nBuilt and live: every product on teas.co.uk has structured data behind its page, including identifiers, prices, availability, source links and price per cup, all read from one checked set of product facts introduced with version two on 10 May 2026. Since 6 October 2026, an assistant can, with the customer's approval, search, compare and fill a basket through the teas.co.uk MCP server. The customer checks the basket and pays on teas.co.uk, and the assistant never sees their card details.\nThe extra fields in Lee's longer description are the full design. Not every one is returned for every product on the live site yet, so the list above describes the aim rather than a promise about any single product.\nWhat the complete payload is not\nIt is not a scrape of a web page, and it is not marketing copy in a different format. It does not hand over payment: the customer pays on the shop's own checkout. It does not oblige an assistant to use it or to cite the shop.\nLee is open about a risk here. The companies running assistants could take a clean answer and serve it inside their own walls, without ever sending the customer or the credit back. His answer is that live stock, the checkout and the shop's accountability for its own claims stay with the shop, and that clean outside sources are cheaper for an assistant than building everything itself, so it still has reasons to route the customer there. That is an argument, not a result. The shop's Under the Hood pages publish what it can and cannot see of that journey.\nWhere the term comes from\nThe idea came from Lee's work rebuilding teas.co.uk in 2026. He started calling it the complete payload in June 2026 to describe what the rebuilt shop should hand an assistant when it asks about a product, and to name the gap between an answer pieced together from pages and an answer the business prepares itself. We don't know whether anyone has used the name before, but it suits what we've built.\nQuick reference\n\nDetail\nInformation\n\nTerm\nThe complete payload\n\nMeaning\nA full, structured, sourced answer about a product, given to an assistant in one trip\n\nUsed by\nLee Samuel Tucker, founder of teas.co.uk\n\nUsed at teas.co.uk since\nJune 2026\n\nOpposite or contrast\nAn assistant scraping a page made for human eyes and guessing\n\nRelated\nTruth entity, claim boundaries, Premium Intent, built versus planned\n\nWhat others have found\nOutside research and reporting that bears on this, with links to the original sources.\n\nGoogle's guide to product structured data and the schema.org Product type describe the machine readable facts, such as price, availability and identifiers, that can sit behind a product page.\nThe Model Context Protocol, the standard behind the teas.co.uk MCP server, is an open standard introduced by Anthropic in November 2024 for connecting AI assistants to outside tools and data. Its documentation is at modelcontextprotocol.io.\nSearch Engine Journal's Agentic commerce: what SEOs need to consider explains ACP and UCP, two of the protocols built so that assistants and shops can complete a purchase together.\nKevin Indig argues in Search Engine Journal that in agentic commerce \"product truth wins\", because new protocols let assistants plug straight into a business's own systems instead of crawling its pages (How do you compete in agentic commerce?).\nllms.txt is a proposed standard for a plain text file that tells language models what a site contains and where to find it.\n\nRelated terms\n\nTruth entity: the owned source the payload is drawn from.\nClaim boundaries: one of its four parts.\nPremium Intent: the full, detailed requests a payload is built to answer.\nBuilt versus planned: how Lee separates what is live from what is intended.\n\nSources and further reading\n\nUnder the Hood, teas.co.uk, including how assistants can shop the site.\nLee Samuel Tucker, Tea Wiki entry.\nLee Samuel Tucker's builder vocabulary.\n\nThe bottom line on the complete payload\nThe complete payload is a business answering an assistant properly the first time: the facts, the limits, the proof and the way to buy, together. At teas.co.uk the core of it is live in every product's structured data and in the MCP server, while the fuller version Lee describes is still being checked against what production returns.\nMore from the tea wiki\n\nWhat's inside a tea shop built for AI to read (from the teas.co.uk newsroom)\nThe structural reversal\nThe squeeze (the four tolls)\nWide versus deep\nLee Samuel Tucker's builder vocabulary\nLee Samuel Tucker\nThe whole Tea Wiki, A to Z",
    "contentSignals": "ai-train=yes, search=yes, ai-input=yes",
    "links": {
        "apiCatalog": "https://teas.co.uk/.well-known/api-catalog",
        "llmsTxt": "https://teas.co.uk/llms.txt",
        "mcp": "https://teas.co.uk/mcp",
        "mcpSetupGuides": "https://teas.co.uk/ai/",
        "mcpCard": "https://teas.co.uk/.well-known/mcp/server-card.json",
        "primaryAgenticRouteAuthority": "https://teas.co.uk/.well-known/teas-primary-agentic-route-authority.json"
    }
}