This page describes a designed model, not shipped behaviour. The grant form and all four connection paths are specified and unbuilt. The limits enforced today are on Boundaries.
The reader grant
A grant is issued per reader, not per key. One grant governs every path that reader uses.
Mechanism: the grant is a guided form in your own permission screens. Beacon proposes a configuration and has no path to apply one. Verify: open a grant and read it back — every field is stated, none inferred from another.
Reader classes
Three classes. Each reads its own separately built copy of your data.
Mechanism: restricted information is absent from the copy an external reader reads, excluded when that copy is built rather than removed per request. Verify: a request for an excluded figure returns the same refusal however it is phrased.
The four connection paths
A path changes the transport and the audience. It never changes the figure, its definition, or the reader’s ceiling.
Mechanism: all four serve one stored set of values; none holds a calculation of its own. Verify: request one figure over two paths — same number, same calculated-at stamp.
Published retrievals
The retrieval set is closed and published. It grows by versioned, documented additions.
Mechanism: no retrieval accepts an expression or a free-text query. Verify: the table above is the whole surface; a call outside it fails rather than assembling a total. Boundaries states why no query interface exists.
Requests outside a grant
A request beyond the grant is refused whole and logged. It is never partly served, never trimmed to fit, and never answered with a narrower figure standing in for the one asked for. Mechanism: scope is checked before retrieval, so a failing request produces a reason and what would make the value available, not a value. Verify: the access log lists every request and its disposition, refusals included. The refusal reasons are listed in Boundaries.Revocation and expiry
Every grant carries an expiry. Revoking one fails the reader’s next request. Mechanism: revocation applies at the source with no propagation delay, and nothing held on the reader’s side is treated by Beacon as still valid. Verify: revoke a grant, then repeat that reader’s last call — it returns a refusal, not a stale figure.Reader grants and agent permissions
Two objects, two screens. A reader grant states what someone else’s software may read out of Beacon. Agent permissions state what Beacon’s own agents may do inside your systems. Mechanism: separate objects on separate surfaces; neither widens the other. Verify: revoking a reader grant changes no agent permission, and removing an agent’s permission changes no reader grant.What a granted read returns
No figure is served bare, on any path, to any reader.
Mechanism: the response is assembled with the figure and cannot be requested without it. Verify: count the fields on any response — a figure arriving alone is a defect, not a compact form.
Related: Boundaries · Connector catalogue · Data model