← Lexenne
Deep-dive · v0.5 draft · 2026
SLF Deep-Dive · 02 / Grant taxonomy

The seven-type grant taxonomy.

What users grant, what providers store, where the source of truth lives, and why "give the agent access to my data" hides seven different operations.

Pressure-test this draft The taxonomy below is illustrated with examples across multiple domains rather than one extended worked example, because the architecture doc's anchor example (healthcare) is explicitly not the v0 wedge. The real test of the taxonomy is whether it is well-shaped for personal-knowledge sovereignty, not for the regulated domains where the distinctions are easiest to motivate. If a type reads under- or over-specified for an audience you care about, flag it.

"Grant the agent access to my data" is the most common framing in agent-authorization conversations. It is also the most misleading. The same English sentence can authorize a one-shot query, a cached working copy, a permanent mirror, a write-back stream, ongoing bidirectional sync, an autonomous action, or all of the above bundled. Each has different storage obligations, different audit surfaces, and different revocation semantics. SLF distinguishes seven types, each with its own evaluation rules and receipt semantics. Walking the seven is the work of this page.

The seven types

A · Catalog

For each type below: the verbatim definition from the architecture (§ 7.2), what the recipient is permitted to do, what they get to store, where the single source of truth (SSOT) lives, and a short illustrative example from a domain other than healthcare.

One implementation note up front: of the seven types, Read is the one implemented end to end in the slf-core v0 reference implementation, where its grant-to-scoped-read-to-receipt round trip runs green under the conformance suite. The other six are specified here and deferred to later versions. The taxonomy is the design surface; the build has started at the simplest type and works outward.

Type 1

Read

"Provider queries on demand; does not retain."
PermitsQuery the user's substrate at the moment of request, see the facts that survive lens and frame gates, discard results immediately. StoresNothing. Optionally a log that a query happened, not what was returned. SSOTEntirely with the user's substrate. Every subsequent query re-fetches.
ExampleA loan-origination system queries a borrower's employment history at the moment of underwriting, makes a decision, and discards the records. The next loan inquiry will re-query; the underwriter never holds a copy.
Type 2

Read-and-cache

"Provider may cache for performance; must refresh after TTL."
PermitsQuery once; store a time-bounded local copy; re-fetch on TTL expiry. The cache is for latency, not durability. StoresA time-bounded working copy with a valid_until timestamp. May be used locally, not disclosed onward without a separate grant. SSOTWith the user's substrate. The cache is derived; expiry triggers a refresh against the live substrate.
ExampleA messaging app caches a user's contact-availability statuses for five minutes to avoid re-querying on every keystroke. After five minutes, it re-fetches.
Type 3

Copy

"Provider stores their own copy; user's substrate remains canonical."
PermitsIngest disclosed facts into provider storage. Use autonomously without re-querying. Copy survives network unavailability and provider scaling decisions. StoresA full-fidelity working copy attributed to the provider's ingest timestamp, with provenance back to the user's substrate. Read-only unless paired with Write-back. SSOTWith the user's substrate, principle #12: "the user is always the source of truth." The provider's copy is derived, not authoritative.
ExampleA university copies a transfer student's transcript into the institutional record system so registrar workflows don't depend on the student's vault provider being reachable at the moment of registration. The student's substrate remains the canonical source.
Type 4

Write-back

"Provider may push updates to user's substrate as signed facts."
PermitsGenerate new facts about the user (lab results, transaction records, derived analytics, professional recommendations) and push them to the user's substrate as new signed assertions. StoresWrite-back authorizes delivery; storing the user's data is a separate grant. Provider keeps generation logs of what it created; if Copy is also granted, that copy persists. SSOTFor provider-generated facts, the user's substrate becomes the canonical home, signed by the provider with the provider's trust tier.
ExampleA bank pushes monthly transaction records and end-of-month balance snapshots to a customer's substrate as signed facts. The customer's substrate becomes the long-term audit log; the bank keeps its own accounting copy.
Type 5

Sync

"Bidirectional updates between provider's copy and user's substrate."
PermitsHold a working copy (like Copy), push updates back (like Write-back), and receive updates when the user changes facts. Active collaboration: both parties update; both parties see new state. StoresA live working copy with refresh obligations. Historical versions may be retained for audit; the user's substrate is the canonical version of current state. SSOTOperationally ambiguous; architecturally the user's substrate. When divergence happens, both signed versions coexist in substrate, each attributed to its author. The app layer resolves.
ExampleA user and an AI agent both iterate on a research document. The agent suggests edits; the user approves; both versions merge into the user's authoritative vault, with the agent's signature on the contributed edits.
Type 6

Action

"Provider/agent may take specific actions on the user's behalf."
PermitsPerform a named operation as if authorized by the user, book an appointment, submit an application, sign a contract, transfer funds, publish a post. Scoped to specific allowed_frames. StoresAction grants do not authorize storage of user data. They authorize actions. The provider logs every action taken, with frame and outcome forming the audit trail. SSOTThe outcome (appointment confirmation, application receipt) is generated by the provider and may be pushed back via Write-back. The grant itself, the user's signed authorization, is the SSOT for whether the action was permitted.
ExampleA candidate grants a job-board agent the Action frame "apply to roles matching criteria" with a per-application human-in-the-loop (HITL) review. The agent drafts; the user signs; the application submits.
Type 7

Compound

"A single grant combining several of the above."
PermitsMultiple grant types in one signed envelope. grant_types: ["Copy","Write-back","Sync"] would let a provider store, update, and remain synchronized in one relationship. StoresWhatever the component types authorize, with the most permissive retention rules among them governing each fact. SSOTWhatever the component types' SSOT rules require, user's substrate remains canonical for any fact that flows back.
ExampleA wealth manager holds Copy plus Write-back plus Action: they mirror the client's portfolio locally, post updated valuations, and execute pre-approved trades within stated bounds.

Source-of-truth discipline

B · SSOT

The architecture's Principle #12 reads: "The user is always the source of truth." Three operational disciplines preserve this across the grant types that allow retained working copies:

  1. Working copies are not new substrates. A provider's Copy is a derived view, carrying provenance back to the user's substrate as its source. It is not a fork; it is a mirror.
  2. Write-back is structural, not optional. When a provider generates new facts about the user, those facts must flow back to the user's substrate as signed assertions. The user's substrate is how the user stays current.
  3. Reconciliation is append-only with provenance. If the user's substrate and a provider's copy diverge, both versions coexist in the user's substrate, signed and attributed. Reconciliation flows toward the user's substrate.

One limit to state plainly: SSOT discipline is encouraged and detectable, not enforced. Like the gate-enforcement model, SSOT for cross-party deployments operates at the T3 (accountable-only) tier: the protocol cannot reach into a provider's storage to prevent the provider from treating their copy as canonical. At T0 (sovereign vault), the user is the only holder-of-record and SSOT is self-enforcing. What the protocol guarantees at T3 is that violations are detectable: every operation produces a Receipt SLF; the user can inspect what was disclosed; the rating system catches repeat offenders. A provider that silently treats their copy as authoritative will be caught in audit, not prevented from doing so in the first place.

Open tensions

C · Pressure-test surface
Tension · the wedge circularity

"The taxonomy is right because the healthcare example shows it works."

Healthcare is explicitly not the v0 wedge (architecture § 7.5 calls the example illustrative-only; the v0 wedge is personal knowledge, Patina and Grip). Regulated domains make the type distinctions easiest to motivate, but they are also where the user has the strongest extrinsic reasons to grant carefully. The real test of the taxonomy is whether the seven types are still load-bearing in personal-knowledge sovereignty, where users grant for convenience, not compliance. That test has not run yet.

Tension · Sync conflict resolution

"Sync handles bidirectional updates cleanly."

When two agents both hold Sync grants on the same facts and they update concurrently, the protocol does not specify who wins. The architecture (§ 7.3) defers resolution to the lens and app layer: divergent writes coexist as signed, attributed facts in the user's substrate, and the lens surfaces the most current or most trusted version depending on context. Worst case is two facts coexisting in substrate until the user reconciles, analogous to merging duplicate contacts on a phone. But for high-stakes domains (financial, medical), "the user reconciles later" is a load-bearing app-layer responsibility the spec does not own.

Tension · Copy vs. Read-and-cache enforcement

"Read-and-cache is meaningfully different from Copy at the protocol level."

The intended difference is retention obligation: Copy is permanent for the grant lifetime; Read-and-cache is TTL-bounded and discardable after expiry. Operationally, without active enforcement, a provider can claim Read-and-cache while behaving like Copy (never discarding). The protocol's defense is that receipts detect this: the same data being served on subsequent reads without a fresh query is visible in receipt patterns. Detectable bad behavior may be sufficient for some regulatory regimes; GDPR's right-to-erasure may demand more than detection.

Tension · Action grants and revocation mid-action

"Action grants are revocable like any other grant."

If an agent is mid-action when the user revokes the Action grant, what happens? The spec lists "Inter-agent communication and HITL friction" as an open question (§ 11) but does not directly answer mid-action revocation. Worst case: a financial transfer initiates under a valid grant, the user revokes the grant before the counter-party confirms, the action either completes (under a now-revoked grant) or aborts (with the counter-party in an inconsistent state). For high-stakes actions this needs explicit completion gates, which draft-00 of the OAuth composition spec touches on but does not formalize.

Tension · Compound grants and user consent

"Compound grants are convenient for real-world relationships."

A Compound grant bundling Copy, Write-back, Sync, and Action under one "Authorize" button is convenient and almost certainly under-consented. Users do not read permission cascades. The spec specifies that Compound grants are possible; it does not specify how users are asked to consent to them. The UX work belongs in Phase 3 product design; for now, naming Compound's consent risk is the responsible step.

Tension · where is Delete?

"Seven types cover every grant operation."

There is no Delete grant type. Deletion is structurally not something an agent does under a user grant; it is something the user does to their own facts via Retraction SLFs (signed superseding facts), or via revocation (ending ongoing access to the provider's copy). The protocol's pragmatic stance is that the provider's working copies are governed by revocation (end access) plus compliance obligation (which may legally require retention) plus downstream legal process (GDPR Article 17 data-subject requests). The taxonomy facilitates the request; compliance is downstream.

What this page does not claim

D · Overclaims to avoid

If you read this with a data-privacy, regulated-domain, or sovereign-personal-data lens and a type is missing, a tension is underplayed, or the multi-domain examples don't pressure-test the right thing, that is the feedback the draft needs. The taxonomy is at the stage where every distinction is up for revision. Contact details are in the header above.

← All SPA / SLF deep-dives