Authoring and grants

A server-driven document describes a screen without describing a query. A fragment says put the agreement summary here through a capability:// reference, never an endpoint or a SQL statement. That indirection is what lets one document be content-authored, device-cached and rendered three ways without any of them widening what the viewer may see or do.

Publishing is not granting

A capability publishing a view proves the view exists. It does not prove this release may use it. Every reference a document uses must appear in the release's explicit grants.

grants: {
  views: ["capability://agreements/summary"],
  intents: ["capability://agreements/amend"],
}

A reference is resolved wherever it occurs: at a prop key, inside an array, nested in either, or in an action's parameters. Arrays are the ordinary shape for list props, so that is the common case rather than an edge one.

Least privilege inside one page

A page assembled from several teams' fragments would otherwise give every fragment the union of everything any of them needs. grants.fragments narrows a subtree, inherited by its children.

fragments: {
  "payment-panel": { views: ["capability://settlements/balance"] },
}

Narrowing is an intersection with the grants already in force. A fragment entry can only ever narrow, so there is no path by which a subtree gains a reference the release did not grant. Naming one that the release does not grant is reported as fragment_grant_exceeds_release rather than silently ignored, because an entry that quietly does nothing is worse than one that fails.

Fragment ids are unique within a tree but may repeat across variants, so two variants sharing an id share an entry. Give them distinct ids when they need distinct narrowing.

Variants have to be enumerated

Experiment arms and personalization are document.variants. Every selectable tree is declared, validated against the same grants as the default tree, and covered by the release digest.

Enumeration is what makes the invariant enforceable. "Selection may never widen grants" is unenforceable as a rule if selection happens at request time, because you cannot validate a set you cannot enumerate. A selector that can produce a tree outside the release is a selector whose output was never checked.

One document, several brands

document.supportedTokenSets lets one authored document be promoted per brand. Each promotion pins exactly one resolved token set, so a release digest still identifies precisely what a viewer received.

Carrying several token sets inside a single release would author once at the cost of that property. It is far harder to regain than to keep.

Content systems

A content system authoring documents is expected and supported. It becomes an authorization surface only if what it produces reaches a renderer without promotion. Run validateSduiRelease on every publish, against the tenant's current grants — grants are fixed per release, and a content system can author a new document at any time.