Mydentify was rebuilt so a person and a software agent can reach the same public facts through interfaces suited to each reader. The human page remains primary. Structured data, feeds, and Markdown representations make that page easier for other systems to interpret.
This approach is agent-readable, not an assertion that a file can force an AI system to cite or recommend a product.
The product record comes first#
Machine readability is not a formatting trick. It starts with a coherent data model.
Mydentify separates:
- Product identity and canonical domain.
- Intent: what a person wants to accomplish.
- Claims connecting a product to an intent.
- Evidence supporting those claims.
- Ownership and correction rights.
- Sponsorship and independent ranking.
- Directory records, submission paths, and observed attributes.
If those concepts are blended into one marketing paragraph, publishing JSON will only make the ambiguity machine-readable.
Human-readable HTML is the foundation#
Public Mydentify pages render meaningful titles, descriptions, links, and content in the initial HTML response. Important navigation uses normal anchor links. Canonical URLs identify the intended record.
This is traditional web quality, and it benefits everyone. A person with JavaScript disabled, a search crawler, an accessibility tool, and an agentic browser all need a stable representation of the page.
Google's link guidance is deliberately unglamorous: use crawlable anchors and descriptive text. Agent-readable architecture builds on the same basics.
Structured data describes the page#
Mydentify uses JSON-LD for relevant public entities and pages. Examples include product, article, breadcrumb, collection, and FAQ structures where the visible content supports them.
Structured data should match what the person can see. Google's structured-data guidelines warn against misleading or hidden markup. Mydentify does not add schema types merely because they might produce a rich result.
Public feeds reduce extraction work#
Mydentify publishes:
- A public product catalog.
- A public intent catalog.
- An OpenAPI document.
- An API catalog for discoverable endpoints.
- Markdown representations for product, intent, and article pages.
- An XML sitemap and article RSS feed.
These formats provide stable fields and URLs. They do not replace the canonical HTML pages; they give software a cleaner path to the same public information.
llms.txt and ai.txt have different jobs#
The llms.txt file is a concise map of Mydentify's purpose, major pages, route patterns, and public resources. The convention is emerging and optional. Chrome Lighthouse describes llms.txt as a machine-readable website summary for LLMs and agents, not as a guaranteed ranking signal.
The ai.txt file states usage permissions, restrictions, attribution preferences, and action boundaries. It tells an agent not to invent Directory Scores, pricing, or rankings and not to submit a product or purchase placement without explicit approval.
Neither file is access control. Private data remains protected by authentication and authorization.
Agent skills describe safe actions#
Mydentify publishes a discoverable agent-skills catalog. A skill can explain how to research directories, interpret product discovery, or prepare a submission. External actions remain confirmation-gated.
This distinction matters: making a workflow discoverable is not permission to execute it. Read-only research can be autonomous; submission, payment, and sending product information require user approval.
The AI-agent rail sponsorship guide applies that boundary to a concrete paid action, from live inventory research through approved checkout.
Evidence and uncertainty remain visible#
Agents can sound certain when the underlying record is not. Mydentify stores verification and evidence separately so a reader can distinguish a directly verified fact from an inferred or stale one.
Unknown values should be omitted or labeled unknown, not filled with a plausible default. Sponsored placement should remain labeled. Directory data should include a checked date when time sensitivity matters.
What this architecture can and cannot do#
It can:
- Make public pages easier to crawl and parse.
- Reduce ambiguity about canonical records.
- Provide structured fields for retrieval and comparison.
- Express usage boundaries and preferred attribution.
- Help people verify the source behind a claim.
It cannot:
- Guarantee inclusion in a model's training data.
- Force an assistant to cite Mydentify.
- Guarantee a Google or AI-search ranking.
- Make an unsupported product claim trustworthy.
- Replace third-party reputation and editorial references.
The architecture is valuable because it is honest infrastructure. It improves access to the public record while preserving the difference between evidence, interpretation, and promotion.
Read how AI agents discover products, what Cloudflare Wallets mean for sellers, explore why discovery is changing, or inspect Mydentify's public llms.txt.
See How We Checked It
We name the source, record the review date, and separate reported claims from our own checks. Read the methodology and editorial policy before citing a finding or sending a correction.
Put this guide into practice
Open the ai discovery tools hub, then choose the check that matches your next decision.
Found an outdated fact? Report a correction.
Back to articles