UCP Well-Known Manifest PDF Guide: 9 Setup Resources

Last quarter, a mid-size home goods brand came to us convinced their agentic commerce integration was live. They had a manifest sitting at the right URL, their dev team had signed off, and a shopping agent could technically read the file. Then a real purchase agent tried to complete a checkout and hit a wall: the payment capabilities block referenced an endpoint that returned a 404, the manifest declared a currency the store no longer supported, and the schema version was two revisions out of date. The file passed a casual eyeball test and failed the only test that mattered. That gap between “the manifest exists” and “the manifest works” is exactly why we put together this UCP well known manifest PDF guide, a set of downloadable, printable resources our team uses on every implementation so nothing slips through.

If you are searching for a UCP well known manifest PDF guide, you probably want two things: a reliable reference you can keep open while you edit JSON, and a checklist you can hand to a teammate without a two-hour handoff call. This article delivers both. We walk through the nine resources we actually distribute to clients, in rough order of how much time each one saves, plus a strategic framework for rolling out your manifest, a KPI section with 30/60/90 day targets, and answers to the questions people ask us most about where to download UCP documentation as a PDF.

TL;DR

Start with the spec, not the shortcut: The single most valuable PDF in any UCP well known manifest PDF guide is the annotated manifest schema reference, because roughly 90% of the failures we see trace back to a mismatched schema version or a malformed capabilities block, not exotic edge cases.
Validation is not conformance: According to UCP Checker, which independently monitors 16,291+ storefronts, roughly 70% pass full UCP validation, but a conformant manifest is not the same as an agent being able to complete a real checkout, so pair every PDF checklist with a live end-to-end purchase test.
Print the checklists, version the JSON: Our highest-leverage habit is keeping the manifest under version control and the review checklists as printed PDFs during launch week, which cut our average time to detection for a broken manifest from days to under 30 minutes.

Why a PDF Guide Still Matters for Something as Live as a Manifest

Before we get into the list, one honest question: why would a machine-readable, constantly-evolving artifact like a UCP well-known manifest need a static PDF at all? Because the failure mode is human, not technical. The manifest lives at a fixed, discoverable path, typically your domain followed by the well-known directory, and agents fetch it automatically. But the people editing it, reviewing it, and signing off on it work in meetings, in handoffs, and under deadline pressure. A printed or offline PDF is the artifact that survives a Slack thread going cold and a lead engineer going on vacation.

We treat the PDF layer as the operational memory around the manifest. The JSON itself is the source of truth for machines. The PDFs are the source of truth for the humans who have to keep that JSON correct across schema updates, catalog changes, and payment provider swaps. If you are new to the underlying protocol, our definitive guide to what UCP is sets the context, and this article assumes you already know a manifest is the discovery document that tells agents what your store supports.

1. The Annotated Manifest Schema Reference PDF

This is the resource we hand out first, every time, because it prevents the most common and most expensive failure. The annotated schema reference is a field-by-field walkthrough of the well-known manifest structure with every required key, its data type, allowed values, and a plain-English note on what happens if you get it wrong. Where the raw specification says a field is a string, our annotated version says exactly which string formats agents in the wild actually accept, and which ones we have watched silently break checkout.

Standout feature: inline failure notes. Next to the schema version field, for example, our annotation reads that a version mismatch causes agents to fall back to a default assumption or refuse the manifest entirely, and we list the last three valid version strings so nobody hardcodes a stale one. Next to the payment capabilities block, we flag that declaring a capability you cannot actually fulfill is worse than omitting it, because it invites an agent to attempt a flow that dead-ends.

We keep this PDF to roughly 12 pages. Anything longer and reviewers skim it. We structure it so the required fields occupy the first four pages, optional-but-recommended fields the next four, and edge cases the rest. For the deeper mechanics behind these fields, we point engineers to the UCP technical architecture deep dive, which explains why the schema is shaped the way it is.

Best for: the engineer writing or editing the JSON by hand.

2. The Manifest Placement and Discovery Checklist PDF

A perfect manifest at the wrong URL is a broken manifest. This one-page checklist covers where the file must live, how it must be served, and how to confirm an agent can actually find it. We have lost hours to manifests that validated locally but returned the wrong content type over HTTPS, or that were blocked by a caching rule nobody remembered setting.

Reduce discovery failures: the checklist forces you to confirm the file is served at the canonical well-known path, over HTTPS with a valid certificate, with the correct JSON content type header, and without a redirect chain that agents may not follow. We include the exact curl command to fetch the file the way an agent would, so verification takes 30 seconds instead of a debugging session.

Cache and CDN traps: we dedicate a section to caching because it burns people. If your CDN caches the manifest for 24 hours, every correction you make is invisible to agents for up to a day. Our checklist recommends a maximum cache TTL of 300 seconds for the manifest specifically during any active rollout, then loosening it once stable. This single line has saved clients from the exact three-day silent-failure scenario we opened with.

Best for: DevOps and whoever owns your web server or CDN config.

3. The Payment and Fulfillment Capabilities Worksheet PDF

The capabilities blocks are where manifests move from “technically valid” to “commercially real.” This worksheet is a fill-in-the-blanks PDF that maps every payment method, currency, region, and fulfillment option your store actually supports to the corresponding manifest declaration. The discipline here is brutal honesty: you declare only what you can complete end to end.

What this achieves: it forces alignment between your manifest and your real checkout. We have seen manifests declare support for a payment method that the store had quietly disabled, and manifests advertising international shipping to regions the store did not ship to. Each mismatch is a live invitation for an agent to start a transaction that fails, which damages your standing with the very agents you want routing purchases to you.

Standout feature: the reconciliation column. Every row has a checkbox confirming a human tested that exact capability in a live or staging checkout within the last 30 days. Undeclare aggressively: our rule of thumb is that if you cannot point to a passing test, you remove the capability from the manifest until you can. A smaller, fully honest manifest converts better than a bloated, aspirational one. This is closely tied to how agentic commerce conversion rates behave in practice, where trust and completion rate matter more than breadth of declared options.

Best for: the commerce or operations lead who knows what the store truly supports.

4. The Platform-Specific Setup PDF for Shopify

If you run Shopify, a generic guide will leave you guessing about the parts that Shopify handles for you versus the parts you must configure. Our Shopify-specific PDF covers where the manifest surfaces on a Shopify domain, which pieces the platform or an app populates automatically, and which fields you still need to override manually. Context matters here: according to UCP Checker, which independently monitors 16,291+ storefronts, roughly 70% pass full UCP validation, and that tracked set skews heavily toward Shopify, so most public examples you will find are Shopify-shaped. That is useful, but remember a conformant manifest is not the same as an agent being able to complete a real checkout on your specific store.

Standout feature: the app-versus-manual matrix. It lists each manifest field and marks whether Shopify or a UCP app handles it, whether you configure it in theme or settings, and whether it needs manual JSON. For the full walkthrough we pair this PDF with the Shopify UCP integration guide, which covers the platform mechanics step by step.

Best for: Shopify merchants who want to know exactly what is automated and what is on them.

5. The Platform-Specific Setup PDF for WooCommerce

WooCommerce gives you more control and therefore more ways to get the manifest wrong. Because Woo runs on your own hosting, you own the file placement, the serving headers, and the caching behavior that Shopify would abstract away. This PDF walks through generating and serving the manifest from a WordPress and WooCommerce environment, including the plugin approach and the manual approach.

What this achieves: it closes the hosting-control gap that trips up self-hosted stores. We call out the two failure points unique to Woo: a security plugin or a permalink rule that blocks the well-known directory, and a page cache that serves a stale manifest to agents. Both are invisible in the WordPress admin, so the PDF includes the exact external checks to run.

Falling-behind risk: self-hosted stores are disproportionately likely to skip this work entirely, which is why we wrote up why WooCommerce stores risk falling behind without UCP. If your competitors on hosted platforms are getting discovered by agents and you are not serving a valid manifest, the gap compounds quietly. The companion WooCommerce UCP integration guide is the detailed reference behind this PDF.

Best for: self-hosted WordPress and WooCommerce store owners.

6. The Manifest Validation and Testing Protocol PDF

Validation and testing are two different things, and conflating them is the mistake that cost our opening client three days. This PDF separates the two clearly. Validation confirms the JSON is well-formed and schema-conformant. Testing confirms an agent can actually discover, read, and act on the manifest to complete a purchase.

What this achieves: it establishes a two-gate release process so a file never ships on schema-pass alone. Gate one is automated validation against the current schema, which you can wire into CI so a malformed manifest never merges. Gate two is a live end-to-end test where a real or simulated agent attempts a full checkout using only what the manifest declares.

Time to detection: the protocol sets a target of detecting a broken manifest within 30 minutes rather than whenever a customer or a lost sale surfaces it. We do this with a scheduled synthetic check that fetches the manifest, validates it, and attempts a lightweight capability probe every 15 minutes, alerting on the first failure. Given the caveat that validation alone overstates real-world readiness, this gate two testing is the difference between the reported 70% pass rate and stores that actually convert agent traffic.

Best for: QA, and any team that has ever shipped a “valid” file that did not work.

A manifest that validates but cannot complete a real checkout is not a smaller success, it is a more dangerous failure, because everyone believes it is done.

7. The Schema Version Migration Runbook PDF

UCP is not static. The schema evolves, and a manifest that was perfect last quarter can drift out of conformance without you touching a single line. This runbook PDF is the procedure for migrating your manifest from one schema version to the next without downtime and without breaking agents mid-transaction.

What this achieves: it turns a version bump from a fire drill into a routine, low-risk operation. The runbook lists each breaking change between versions, the fields affected, and a rollback step if a new version misbehaves in production. We keep a changelog appendix so anyone can see what changed and when.

Rotation schedule: we recommend reviewing the manifest against the latest schema on a fixed 30-day cadence rather than reacting to breakage. During any migration, we drop the cache TTL to 300 seconds so corrections propagate fast, then restore it. Understanding where the standard is heading helps you anticipate migrations, which is why we read the runbook alongside the future of UCP agentic commerce in 2026 and beyond and, for competitive context, UCP vs ACP: which standard will rule the agentic web in 2026.

Best for: whoever owns the manifest three months from now, which may be you.

8. The Beginner’s One-Page Quick Start PDF

Not everyone touching the manifest is an engineer. Marketing leads, founders, and account managers need to understand what the manifest is and why it matters without reading a schema. This single-page PDF explains the well-known manifest in plain language: what it is, where it lives, what it tells shopping agents, and what happens if it is wrong.

What this achieves: it gives non-technical stakeholders enough shared vocabulary to make good decisions and ask the right questions. When a marketer understands that the capabilities block is a promise to agents, they stop asking to advertise options the store cannot fulfill.

We derived this page from our UCP for beginners guide, condensed to the ten things a non-engineer must know. It is the PDF we attach to the first email in any new engagement so the whole team starts from the same picture rather than each person forming their own mental model.

Best for: onboarding non-technical stakeholders and executive sign-off.

9. The Hub-Versus-DIY Decision Matrix PDF

The last resource is not about editing the manifest, it is about deciding whether you should be editing it by hand at all. This decision matrix PDF walks you through the tradeoffs between maintaining your own manifest and configuration versus using a managed hub that generates, serves, validates, and version-migrates the manifest for you.

What this achieves: it makes the build-versus-buy decision explicit instead of a default. The matrix scores your situation across engineering capacity, number of storefronts, rate of catalog change, and tolerance for silent failure. Teams with a single stable store and strong engineers often do fine self-managing. Teams with multiple storefronts, frequent catalog changes, or no dedicated engineer to own migrations almost always come out ahead with a hub.

Point solutions do not scale: the matrix leans on the reasoning in why UCP versus custom AI integrations do not scale and the head-to-head in the UCP hub versus custom integration comparison guide. The recurring cost of a DIY manifest is not the initial setup, it is every schema migration and every catalog change forever after.

Best for: decision-makers choosing an implementation path before writing any JSON.

The MANIFEST-Ready Framework: 5 Steps From Zero to Conformant

The nine PDFs above are the reference material. This framework is the sequence we run them in. We call it MANIFEST-Ready because each step compounds on the last, and skipping one is how manifests end up validating but not working.

Step 1, Map your real capabilities. What this achieves: it establishes ground truth before you write a single line of JSON, so your manifest describes the store you actually operate. Using the capabilities worksheet PDF, you list every payment method, currency, region, and fulfillment option you can complete end to end, and you delete anything you cannot test. This is the step most teams rush and most regret.

Step 2, Author against the annotated schema. What this achieves: it produces a well-formed manifest on the first pass instead of through trial and error. With the annotated schema reference open, you write the JSON field by field, matching every type and allowed value, and you pin the current schema version explicitly rather than assuming a default.

Step 3, Place and serve correctly. What this achieves: it makes the manifest discoverable to agents, which is the whole point of the file. Using the placement checklist, you serve the file at the canonical well-known path over HTTPS with the correct content type and a short cache TTL, then confirm with the curl command that an agent would see exactly what you intended.

Step 4, Validate then test end to end. What this achieves: it separates schema conformance from real-world readiness so you never ship on validation alone. Gate one runs automated schema validation in CI. Gate two runs a live checkout attempt using only the manifest’s declared capabilities. Only when both pass does the manifest go live.

Step 5, Monitor and migrate on a schedule. What this achieves: it keeps the manifest conformant as the schema and your catalog evolve, preventing silent drift. You wire up a synthetic check every 15 minutes for fast detection and review against the latest schema every 30 days using the migration runbook.

Section checklist:

Ground truth first: Complete the capabilities worksheet and delete every untested declaration before authoring JSON.
Explicit version: Pin the current schema version string rather than relying on any agent default.
Canonical serving: Serve at the well-known path over HTTPS with correct content type and a 300 second cache TTL during rollout.
Two gates: Never promote a manifest that has passed validation but not a live end-to-end checkout test.
Fast detection: Run a synthetic manifest check at least every 15 minutes with alerting on first failure.
Scheduled review: Re-check against the latest schema every 30 days, not only when something breaks.

Ship a Manifest Agents Actually Trust With UCPhub

Every PDF in this guide exists to close the gap between a manifest that validates and a manifest that converts, and that gap is precisely what our Universal Commerce Protocol platform is built to eliminate. Instead of hand-maintaining JSON, wiring your own synthetic checks, and chasing schema migrations every 30 days, UCPhub generates, serves, validates, and version-migrates your well-known manifest automatically, with live end-to-end checks so you catch a broken flow in minutes rather than after three days of lost agent traffic. If you would rather your team spend its time on the store and let us own the manifest, talk to us about your setup or explore the UCPhub platform to see how the whole pipeline fits together.

Measuring Success: 30/60/90 Day KPIs for Your Manifest

A manifest is not a one-time deliverable, it is a live surface you measure like any other conversion-critical asset. Here is how we track a manifest rollout across the first 90 days, formatted so you can drop it straight into a review doc.

First 30 days, get to genuine conformance:

Validation pass rate: Reach 100% automated schema validation pass in CI, with zero malformed manifests reaching production.
End-to-end completion: Achieve at least one passing live checkout test driven solely by the manifest’s declared capabilities, since validation alone overstates readiness.
Discovery confirmation: Confirm the manifest is fetchable at the canonical well-known path with correct headers from an external check, not just locally.
Time to detection: Stand up synthetic monitoring and demonstrate a sub-30-minute detection of a deliberately broken test manifest.

Days 31 to 60, prove it converts and holds:

Capability honesty: Reach 100% reconciliation, meaning every declared capability has a passing test within the trailing 30 days.
Agent completion rate: Begin tracking the share of agent-initiated checkouts that complete successfully, targeting steady week-over-week improvement.
Zero silent failures: Record zero incidents where a manifest problem was found by a customer or lost sale rather than by monitoring.
Cache correctness: Verify corrections propagate within your configured TTL by pushing and confirming a test change.

Days 61 to 90, make it durable:

Migration readiness: Complete at least one dry-run schema migration using the runbook so a real bump is routine, not a fire drill.
Uptime of discovery: Sustain 99.9% or better manifest availability across the quarter.
Ownership clarity: Confirm a named owner and a written review cadence exist so the manifest does not decay when the original author moves on.
Coverage growth: Where the store can support it, expand declared capabilities only after each new one passes a live test, never before.

Practitioner Wrap-Up and Next Steps

If you are just getting started, do not try to download all nine PDFs and internalize them at once. Start with two: the annotated schema reference and the placement checklist. Those two alone prevent the majority of failures we see, because most broken manifests are either schema-malformed or served incorrectly, not victims of exotic edge cases. Author a minimal, brutally honest manifest that declares only what you can test, get it discoverable, and run one live checkout test. That is a real milestone. If instead you are auditing a manifest that already exists, invert the order: start with the validation and testing protocol and run gate two immediately, because a file that has been “live” for months is exactly the kind that validates while quietly failing real checkouts. Find the gap first, then work backward to the schema and capabilities worksheet to fix it.

Next Steps:

Download and open the annotated schema reference and placement checklist, then fetch your current manifest with the exact curl command an agent would use and compare it field by field.
Run one live end-to-end checkout driven only by your manifest’s declared capabilities, and delete any capability that does not pass.
If self-managing the migration cadence sounds like a recurring cost you would rather avoid, book a setup review with UCPhub and let the platform own validation, serving, and schema migrations.

Frequently Asked Questions

Is there a PDF guide for UCP well known manifest setup?

Yes, and this article is our list of the specific PDFs we use and distribute. There is no single official government-style PDF that covers everything, because the manifest is a living, machine-readable artifact tied to an evolving schema. What works in practice is a small library of focused PDFs rather than one monolithic document: an annotated schema reference, a placement checklist, a capabilities worksheet, platform-specific setup guides, a validation protocol, and a migration runbook.

Our strong recommendation is to treat these PDFs as the human layer around the JSON, not as a replacement for reading the current schema. The schema itself is always the source of truth for machines, and it changes. A PDF’s job is to make the human process around that schema repeatable: who reviews, what they check, and how they confirm the manifest works rather than merely validates. If your PDF guide does not include a live end-to-end test step, it is incomplete regardless of how thorough the schema section is.

Where can I download UCP documentation PDF?

The most reliable path is to work from current, dated documentation rather than a random PDF that may already be stale, since a manifest that matched last quarter’s schema can quietly fall out of conformance. We keep our own reference material current and link the underlying long-form guides throughout this article, including the definitive guide to what UCP is and the UCP technical architecture deep dive, which together cover the concepts most PDF guides try to condense.

If you need an offline PDF for a review meeting or a client handoff, our practical advice is to generate it from a current source and stamp it with a date and the schema version it targets. An undated documentation PDF is a liability, because the reader has no way to know whether it reflects the current schema. The single most important metadata on any UCP documentation PDF is the schema version it was written against and the date it was produced.

What does the UCP setup PDF include?

A complete setup PDF includes six things in our experience. First, the annotated schema with every required field, its type, allowed values, and the consequence of getting each one wrong. Second, placement and serving instructions covering the canonical well-known path, HTTPS, content type headers, and cache behavior. Third, a capabilities worksheet that maps your real payment, currency, region, and fulfillment support to manifest declarations. Fourth, a validation and testing protocol that separates schema conformance from a live checkout test.

Fifth, a migration section describing how to move between schema versions without downtime, including a rollback step. Sixth, a monitoring plan with a concrete detection target, ours is under 30 minutes via a synthetic check running at least every 15 minutes. If a setup PDF omits the testing and monitoring pieces and stops at “here is a valid example manifest,” it will lead teams straight into the trap of shipping a file that validates but does not complete real checkouts.

How is a valid manifest different from one that actually works?

Validation confirms your JSON is well-formed and conforms to the schema. Working means an agent can discover the manifest, read it, and use only its declared capabilities to complete an actual purchase. These are genuinely different, and the difference is where most real failures hide. According to UCP Checker, which independently monitors 16,291+ storefronts, roughly 70% pass full UCP validation, but that figure describes schema conformance across a Shopify-skewed tracked set, not the share of stores where agents can truly check out. A conformant manifest is not the same as an agent being able to complete a real checkout.

The practical fix is a two-gate release process. Gate one is automated validation in CI. Gate two is a live end-to-end checkout test using only the manifest’s declared capabilities. We refuse to promote a manifest that has cleared gate one but not gate two, because a “valid” but non-working manifest is more dangerous than an obviously broken one: everyone believes the work is done, so no one is watching.

How often should I update my well-known manifest?

On two triggers. The scheduled trigger is a 30-day review against the latest schema, so version drift never accumulates into a surprise. The event trigger is any change to your real capabilities: a new payment method, a dropped currency, a changed shipping region, or a catalog change that affects declared options. Both matter, because the manifest can fall out of sync either because the schema moved or because your store did.

During any active update we drop the manifest cache TTL to around 300 seconds so corrections reach agents quickly, then restore a longer TTL once stable. If maintaining that cadence across multiple storefronts sounds like a standing tax on your engineering time, that is exactly the case where a managed approach earns its keep, as we lay out in the UCP hub versus custom integration comparison guide.

Do I need different setup steps for Shopify versus WooCommerce?

Yes, meaningfully. On Shopify, the platform and UCP apps automate several manifest fields and handle serving for you, so your work concentrates on the declarations that are specific to your catalog and the fields you need to override. Our Shopify UCP integration guide walks through exactly which parts are automated and which are on you.

On WooCommerce, you own the hosting, so you also own file placement, serving headers, and caching, plus two Woo-specific traps: security plugins or permalink rules that block the well-known directory, and page caches that serve a stale manifest. The WooCommerce UCP integration guide covers both approaches. Self-hosted stores also carry more risk of skipping this entirely, which is the theme of why WooCommerce stores risk falling behind without UCP.

Should I hand-maintain the manifest or use a hub?

It depends on four factors: your engineering capacity, how many storefronts you run, how often your catalog changes, and your tolerance for silent failure. A single stable store with strong engineers can reasonably self-manage. Multiple storefronts, frequent catalog changes, or the absence of a dedicated owner for schema migrations tilt the decision toward a managed hub, because the real cost of a DIY manifest is not the initial build, it is every migration and catalog change thereafter.

We spell out the reasoning in why UCP versus custom AI integrations do not scale. The short version: point solutions look cheap on day one and expensive by day ninety, because the manifest is not a project you finish, it is a surface you maintain as long as agents are shopping your store.

What happens if my manifest declares a capability I cannot fulfill?

You invite an agent to start a transaction that dead-ends, which is worse than not offering the option at all. Agents build trust in stores that reliably complete what they advertise, and a failed checkout is a strong negative signal. Over-declaring to look more capable backfires: it lowers your effective completion rate and can discourage agents from routing future purchases to you, which is the opposite of what you want as AI agents become the primary shoppers.

Our rule is to undeclare aggressively. If you cannot point to a passing live test for a capability within the trailing 30 days, remove it from the manifest until you can. A smaller, fully honest manifest outperforms a larger aspirational one, because in agentic commerce a completed checkout beats a broad menu of promises you cannot keep.