Presentation ownership

Packages never ship client code, and Fruitful never guesses how to render a package's records. The split is deliberate, and it decides what fails and how.

The package owns

• its record Lexicons and its View Lexicon;
• buildView, a deterministic function from root record and related records to a View;
• the compact and expanded surface templates, in A2UI v0.9.1, naming an exact trusted catalog;
• the actions that open the item elsewhere, each resolved against the validated View;
• generated presentation examples that validation compares against.

Fruitful owns

• the catalog implementations: React components, styling, accessibility, responsive behavior, native interaction semantics;
• the Activity shell around the surface: headline, provenance, selection, actions;
• the persistence of the View and surfaces with the exact resolution digest.

The resolution is the authority

Clients render the persisted View and surfaces from the resolution that produced them. They do not rediscover presentation from a mutable package tag, and they do not infer UI from record fields. Two people following the same feed on the same release see the same thing, and a person who has not updated keeps seeing what their resolution produced.

Fail closed, never fall back

There are four outcomes for an Activity item: the package Presentation View, native media, a saved page capture, or Presentation unavailable. A missing, invalid, mismatched, or unsupported presentation is the fourth. It is never silently replaced by opening the website, and there is no generic record renderer to hide an incomplete package. Website is an explicit action the View declares with a valid URL.

Provider-neutral by construction

Package UI is dispatched by the resolution, never by provider name, content type name, or archetype. A branch on "if LinkedIn" anywhere in the client is a boundary failure. When the catalog lacks a component a package needs, the fix is a catalog component every package can use.