Freshness and Provenance: The Missing App Discovery Data

An app fact without a source and time context is weaker than it looks. “This restaurant accepts reservations,” “this class is available,” or “this trail supports offline maps” may have been accurate when published and wrong today. AI retrieval can make the problem more visible because a fluent answer often hides the age and authority of the underlying evidence.

The solution is not one universal trust score. It is a data model that keeps publisher assertions, observations, and derived judgments separate.

Start with authority

Different sources are qualified to make different claims. An app developer can authoritatively describe its native content ID, intended deep link, and source modification time. An app store can identify a listing and current storefront metadata. An independent index can observe that a URL redirected or that two sources agreed at a particular time.

Those facts should not collapse into one mutable document. If an index-derived value is written back into the publisher namespace, the audit trail disappears. If a publisher can self-declare final trust or verification, the assessment loses meaning.

A clean architecture retains at least four layers:

1. publisher submission;
2. normalized canonical record;
3. append-oriented evidence;
4. derived assessments and public projections.

Search documents can be regenerated from those layers. They should not become the source of truth.

Use more than one timestamp

“Last updated” is ambiguous. Capture:

• when the source says the fact changed;
• when the index fetched or observed it;
• when normalization accepted it;
• when a destination was last checked;
• when the public profile was regenerated.

These timestamps answer different questions. A feed fetched today may contain an entity last changed six months ago. A destination checked yesterday may still belong to an entity whose availability expired last week.

Google’s structured data guidelines emphasize accurate, current, visible information. Even outside rich results, this is a useful operational standard: never make structured markup look fresher than the content readers can see.

Preserve evidence instead of overwriting it

For each material field, retain a source identifier, exact source URL where permitted, observation time, extraction method, confidence, and content hash. When the value changes, append the new observation and update the current projection. This makes drift and disputes explainable.

Failed refreshes require special care. Do not delete a known-good catalog because a remote request timed out or one batch was malformed. Stage the new version, validate it, and publish atomically only after the acceptance policy passes. Isolate bad records and return auditable errors.

Make assessments transparent

Freshness, verification, and destination health are judgments based on evidence. Store components and reasons rather than only a composite number. A retrieval consumer should be able to distinguish:

• developer-authoritative and recently fetched;
• publicly corroborated but unclaimed;
• syntactically valid but never resolved;
• stale source with a still-live destination;
• current source with a broken route.

This supports safer ranking and clearer user explanations. It also makes policy thresholds reversible as evidence improves.

Publish only what the user needs

Provenance does not require exposing private feeds, credentials, or entire source payloads. A public selection record can identify authority class, relevant observation dates, and evidence counts while withholding sensitive collection details. The destination should lead back to the app experience rather than recreate it.

Blue Jetty keeps publisher claims, source timestamps, index observations, and destination checks distinct. Retrieval clients can inspect why one record is more current or usable than another and change their choice when the evidence changes.

Freshness is not a badge. It is a process with timestamps, failure handling, and accountable sources.