How to Solve the “AI Doesn't Understand Our App” Problem Yourself

How to create, host, document, and maintain your own AI Mobile Context infrastructure.

Blue Jetty is not required to publish structured context about your mobile app.

You can define the format, host it on your website, connect it to your existing links, and maintain it yourself. If that suits your team, this is the blueprint.

The reason to do it is straightforward. Much of what makes your app useful lives inside the app. Your website and store listing can explain the broad proposition, while leaving an AI assistant to piece together which experiences exist, when they are relevant, and where to send someone next.

AI Mobile Context (AMC) is publisher-authorized context that tells AI assistants what an app does, when it is relevant, and where to send the user next.

A packet is a machine-readable way to publish that context. It can start small. A few well-described experiences and reliable destinations are a perfectly sensible first release.

Here is what goes into making it useful beyond that first release.

1. Decide what your packet represents

Start with the questions a potential user might ask, then identify the app information needed to answer them accurately.

For a relationship-management app, that could mean reminders, interaction notes, recurring check-ins, supported platforms, and the right installation link. For a booking app, it might include appointment types, locations, eligibility, and selected bookable experiences.

Describe:

• Identity: the app, its publisher, website, and supported platforms.
• Relevance: capabilities, use cases, audiences, and meaningful limitations.
• Experiences: the specific parts of the app that address those needs.
• Destinations: where a user should go for each experience.
• Conditions: availability, eligibility, geography, and applicable offers.
• Sources and time: who supplied the information and when it was updated.

The model should follow the product. A timer app does not need an inventory system. A ticketing app may benefit from selected current events.

A useful hierarchy might be:

App → experience → selected item → applicable offer → destination

Use only the layers that help someone understand or choose the app. You are publishing enough context to reach the experience; the experience itself can stay inside your product.

2. Design the contract

JSON is a reasonable starting point. Clear field names, short descriptions, and explicit relationships make the information inspectable by people and software.

Here is an illustrative fragment for a fictional cycling app. These are example fields, not a Blue Jetty submission format:

{
  "schemaVersion": "1.0",
  "app": {
    "id": "app_coastal_rides",
    "name": "Coastal Rides",
    "publisher": "Coastal Rides Ltd",
    "website": "https://example.com"
  },
  "experiences": [
    {
      "id": "experience_route_planning",
      "name": "Coastal route planning",
      "useCases": ["planning a coastal bike ride"],
      "destinationId": "destination_route_planner",
      "source": "publisher",
      "updatedAt": "2026-09-10T12:00:00Z"
    }
  ],
  "destinations": [
    {
      "id": "destination_route_planner",
      "url": "https://example.com/routes",
      "purpose": "route_planning"
    }
  ]
}

Then define the rules around it:

• Keep identifiers stable when names or URLs change.
• Specify required fields, optional fields, enums, and reference rules.
• Define timestamp meanings and time zones.
• Separate publisher assertions from independently observed evidence.
• Validate syntax, types, relationships, and permitted destinations.
• Document what happens when a field is omitted.

That last point matters. An absent offer field might mean the publisher has not supplied offer information. It should not automatically mean the app has no offers.

Publish a schema and test valid and invalid examples. A schema can validate the shape of a claim; editorial and product review still determine whether it is accurate.

3. Host it somewhere stable

Choose a canonical HTTPS endpoint, such as https://example.com/app-context.json.

Serve valid JSON with Content-Type: application/json. Make the public representation accessible without a login, JavaScript execution, or a cookie-consent interaction. Keep private data out of the generator, including account details, internal notes, credentials, and unpublished commercial information.

Set an explicit caching policy. Use validators such as ETags where appropriate, and make sure a release can invalidate old CDN content. An expiring offer needs a different freshness policy from an app description.

Check the entire delivery path: origin, redirects, CDN, bot protection, response size, and error handling. A healthy origin is little comfort if your edge serves a challenge page instead of JSON.

The endpoint should survive a website redesign.

4. Give crawlers several ways to find it

A published URL still needs a path leading to it.

Add descriptive links to your server-rendered HTML. The registered describedby relation expresses that a linked resource describes the current resource, without requiring a particular description format. It does not establish the description's authority by itself. RFC 6892

For example, your page head could include both a direct packet reference and a reference to an accompanying llms.txt file:

<link rel="describedby"
      href="https://example.com/app-context.json"
      type="application/json">
<link rel="describedby"
      href="https://example.com/llms.txt"
      type="text/plain">

If you publish llms.txt, include a clear link to the same packet there. Treat it as an additional discovery convention, not a universal crawler requirement.

A visible footer link gives readers and link-following clients another route:

<a rel="describedby" href="https://example.com/app-context.json">
  Official App Information for AI Assistants
</a>

You can also expose the relationship through an HTTP response header:

Link: <https://example.com/app-context.json>; rel="describedby"; type="application/json"

HTTP Link headers provide a standardized way to communicate typed links. RFC 8288

If you adopt a well-known discovery location, follow the applicable specification and registration rules. The /.well-known/ namespace has a defined registration process; inventing a path there does not make it an established standard. RFC 8615

Redundancy gives different clients different routes to the same source. Some inspect HTML links, some process metadata, and some follow references from other documents. These paths improve the opportunity for discovery without guaranteeing that any particular AI service will follow them.

5. Now make it recognizable

Imagine encountering your packet without knowing your company or its engineering conventions.

What is this file? Who publishes it? Does available mean listed, in stock, or available to this particular user? Is the destination a website, an app link, or a template? Is updatedAt the last content change or merely the last time the endpoint ran?

Those questions belong in the contract.

Publish:

• The format name and schema version.
• A stable schema URL and readable documentation.
• Definitions for fields, relationships, and destination types.
• Source and timestamp semantics.
• Examples, including incomplete and unavailable information.
• Compatibility and deprecation rules.

Link this material from the packet so an unfamiliar consumer can locate it.

Publishing information and publishing an interpretable contract are different jobs.

A bespoke implementation can expose the same underlying information. Unless you document its semantics, discovery conventions, and versioning, each consumer must infer more of the meaning independently.

A consistent, documented format provides a reusable contract. That is an interoperability advantage, not evidence that an AI provider prefers a particular vendor or has adopted the format.

You also do not need to invent every convention yourself. Reuse established identifiers, link relations, and public schemas where they fit.

6. Now get someone else to recognize it

There is another difference between publishing a documented format and establishing a shared convention.

You can design an excellent app-context schema for one app. You can document every field, version it carefully, and expose it through several discovery paths.

An AI system may still interpret a bespoke packet. But if a consumer is going to support a format repeatedly, the obvious question is: how many publishers does that work help it understand?

If one app uses a bespoke contract, supporting that contract helps a consumer understand one publisher.

If hundreds or thousands of apps use the same documented contract, the same work can help a consumer understand an entire class of publishers.

Reuse changes the incentive. A consumer can apply one set of field meanings, destination rules, and compatibility expectations repeatedly. The work becomes useful in more places.

That is the potential advantage of a shared convention, not a claim about Blue Jetty's current adoption or any crawler's preferences. Reach alone does not establish a standard, and consumers still decide what to retrieve and use.

So if you build your own packet format, you may also be building a protocol with one user.

That is a perfectly valid choice. Just include it in the build-versus-use calculation.

The engineering work is yours to organize: schema, links, offers, freshness, monitoring. The coordination work involves other people choosing to reuse the same contract. Your team can ship the first. It cannot unilaterally ship the second.

Self-hosting and shared conventions are compatible, too. You can operate your own endpoint while adopting an existing public contract where its terms and semantics fit. Copying a JSON shape is the easy part; staying compatible is what makes the reuse meaningful.

7. Connect user intent to the right experience

“A fitness app” is a category. “Helps someone plan a coastal ride” explains relevance to a request.

The following are hypothetical publisher-supplied mappings, not claims about particular companies or live inventory:

Plan a bike ride near the coast

• Useful app context: Route-planning capability and selected suitable routes.
• Possible next destination: Route planner or a named route.

Find something suitable to watch with children

• Useful app context: Relevant titles and current regional availability.
• Possible next destination: A title page.

Order a specific meal

• Useful app context: A current restaurant/menu match and service area.
• Possible next destination: Menu or item page.

Find tickets for a particular event

• Useful app context: Event identity and current availability.
• Possible next destination: Event details or booking.

More precise context can help an assistant assess fit before a user clicks anything. Then destination information can improve the next step.

These are separate opportunities. A packet may clarify why the app is relevant even when the best available destination is its homepage.

For current inventory, publish only what you can substantiate and maintain. Do not turn a general capability into an invented item, availability claim, or URL.

8. Implement the mobile handoff

Once you identify an experience, decide how a user reaches it on each supported platform.

Use your existing universal-link and Android App Link setup where appropriate. These mechanisms associate web destinations with apps; implementing the association and handling incoming URLs remain part of the mobile application. Apple universal links, Android deep links

Define the intended behavior for:

• iOS and Android.
• Installed and not-installed states.
• Web and store fallbacks.
• Unknown platforms.
• Signed-out users and restricted experiences.
• Preserving a destination after installation, where your existing stack supports it.

Test actual journeys on devices. A URL returning HTTP 200 does not establish that it opens the intended screen.

A general store link can be a useful fallback. For an intent-specific journey, a supported destination link can preserve more of what the user was trying to do.

9. Preserve the links your measurement stack expects

If you use AppsFlyer, Branch, Adjust, or Kochava, start with the links your team already configures and tests.

Keep the publisher-designated URL intact unless your contract explicitly permits particular substitutions. Do not strip parameters, replace the tracking domain, or assume every provider uses the same deep-link fields.

Document each supported link's destination, platform behavior, fallback, and relevant campaign parameters. Consult your provider's current documentation before introducing parameterized links.

An MMP is optional. A direct HTTPS destination may be exactly what the app needs.

Blue Jetty makes app context available to AI assistants, which may use some, all, or none of it depending on the task. Your existing MMP measures eligible downstream activity when users follow your links. No attributed conversion does not, by itself, tell you whether an assistant retrieved or used the context.

10. Give offers a lifecycle

An offer needs enough detail for a consumer to understand who can use it and how.

At minimum, consider:

• Name, description, and stable ID.
• Applicable experience or product.
• Code, when required.
• Eligibility and geographic restrictions.
• Start time, expiry, and time zone.
• Terms URL.
• Publisher-approved destination.
• Expected code parameter and whether the app supports prepopulation.

If a code travels through a link, define the exact allowed parameter, encoding rules, and final destination behavior. Arbitrarily appending ?code=... to a shortened or signed URL is not an implementation strategy.

The app must still recognize the code and enforce eligibility and redemption rules. Publish offers aimed at AI-referred users when that is a real publisher policy, with terms that explain what qualifies.

Schedule activation and expiry. Support early withdrawal. Make sure cached representations cannot keep advertising a withdrawn offer indefinitely.

An offer's expiry is part of the data model, not a calendar reminder.

11. Add dynamic content only when it earns its place

Some products benefit from current objects: appointments, hotel stays, events, menu items, tickets, or selected products.

That is an extension of the DIY system described here, not a claim that Blue Jetty currently supplies live inventory integrations for these categories.

For each dynamic source, establish:

• Stable IDs and an authoritative publisher feed or API.
• Source timestamps and maximum acceptable age.
• Availability, eligibility, and expiry semantics.
• A supported destination for each published object.
• Update, deletion, and cancellation behavior.
• Validation and failure handling.

A failed refresh should preserve valid information where it remains usable. Time-sensitive claims must still expire: yesterday's successful feed does not establish today's availability.

Start with selected objects that materially improve relevance or the handoff. Avoid exporting a whole database simply because you can.

12. Assign an owner and a publishing workflow

Someone needs to be responsible when product changes a feature, growth changes an offer, or engineering changes a route.

Give the packet a named owner and a review path. Use staging, validation, access controls, change history, and a way to restore the last good publication.

Before publishing, an authorized person should review the actual content for accuracy, rights, privacy, and the level of detail the company is comfortable exposing on the public web.

If an agent helps build the system, start with read-only inspection and a proposed change set. Get human approval before it changes the website or publishes app information.

A release checklist is a good home for packet maintenance. The app and its public description should not drift into separate products.

13. Make freshness explicit

Define which changes trigger an update: features, destinations, platform support, geography, offers, and selected content.

Distinguish the last content change from the last fetch or validation. A freshly generated timestamp must not make old source information appear new.

Store-release monitoring can prompt a review, but a new version number does not tell you which claims changed. Assign that review to someone who knows the release.

Use different freshness policies for different records. A capability description may stay accurate for months. An appointment slot may not survive the afternoon.

14. Monitor the system you published

Track endpoint health, response failures, latency, cache behavior, stale records, broken destinations, and requests for older versions.

Use server-side request observations for crawler activity. Record the requested resource and time; distinguish declared user-agent identity from any separately verified identity. Minimize retained personal data.

Keep the measurement boundaries clear:

• Packet requests: retrieval of your published resource.
• Context use: whether an assistant incorporated information into an answer, requiring separate evidence.
• Downstream activity: eligible visits, opens, installs, or conversions measured through your existing systems.

A packet request is an observation of retrieval. What happens next needs its own evidence.

Track changes to the packet alongside requests. That gives your team a useful history when investigating what a consumer could have seen at a particular time.

15. Maintain the format as well as the content

Eventually, you will add a field, introduce a new destination type, or retire an old representation.

Decide what is backward-compatible. Keep examples and schemas synchronized. Test consumers you actually support, retain useful compatibility fixtures, and document migration behavior.

Avoid changing the canonical URL just because the payload evolves. Where a breaking change needs a separate version, give consumers an explicit migration path.

You now have an endpoint, a contract, documentation, a publishing workflow, and operational ownership.

That is a small piece of infrastructure. It is entirely reasonable to build it. It is also reasonable to give it a place in your maintenance budget.

Your DIY checklist

• [ ] Define the app identity, experiences, use cases, and destination model.
• [ ] Establish stable IDs and source attribution.
• [ ] Document optional fields, timestamps, and availability semantics.
• [ ] Publish a schema, examples, and compatibility policy.
• [ ] Build a validated packet generator with safe public-data boundaries.
• [ ] Host a stable HTTPS endpoint with appropriate caching.
• [ ] Publish HTML, visible-link, and appropriate HTTP discovery references.
• [ ] Link any accompanying llms.txt to the canonical packet.
• [ ] Document platform destinations and fallback behavior.
• [ ] Test supported mobile journeys on devices.
• [ ] Preserve existing MMP URLs and permitted parameter semantics, if used.
• [ ] Add eligibility, terms, activation, expiry, and withdrawal for offers, if used.
• [ ] Add bounded publisher feeds and stale-data handling for dynamic records, if needed.
• [ ] Establish review, permissions, change history, and rollback.
• [ ] Monitor endpoint health, retrieval, destination failures, and freshness.
• [ ] Keep documentation and validation aligned as the format changes.
• [ ] Name the person responsible after launch.

Or don't

You can absolutely build this yourself. For some teams, owning the format and its operations will be the right choice.

Or use Blue Jetty.

The core context infrastructure is free today.

Your team owns the app, its information, and its destinations. We maintain the context infrastructure.