← The Conferral Metrics Standard

Conferral Metrics Standard · proposed addition

The session-origin distribution

v1.1 · proposed, not part of the standard · supersedes Initiated Share v1.0 · free to quote with attribution

Status: a proposal, not part of the Conferral Metrics Standard. It is published here so it can be argued with, implemented, or refused. It has not been computed on any real product, and it has not been shown to measure what it is named for. The essay that led to it explains why the measure it replaces was retired.

Usage does not explain its own origin.

A session can begin because a person arrived with something to do. It can begin because a person configured a scheduled service and the result arrived. It can begin after an expected transaction or a safety notice. It can begin because the product proposed useful next work. It can begin because the product tried to bring someone back.

Those sessions should not be added together and then interpreted as though they expressed the same relationship. The answer is a distribution, not a score.

What this replaces, and why

A previous version of this proposal, published on 31 August 2026 as Initiated Share v1.0, split sessions in two: prompted and initiated. It treated the split as evidence about wanted versus captured use.

That interpretation was defeated the same day. A user can authorise a product to do work later; the product notifies them when the result is ready; they open it. Under v1.0 that session counted as prompted, so the number fell precisely because a delegated service worked as requested. Both ChatGPT and Gemini document exactly this pattern in their official help material.1 2

The prompt was the delivery mechanism of a prior grant, not evidence of capture. Initiated Share v1.0 is retired. Unprompted initiation survives here as one class among eight.

Definition

The session-origin distribution is the percentage of eligible sessions assigned to each disclosed origin class during a stated period.

Before computing it, publish the session start and end rules, the inactivity threshold, the cross-device identity treatment, the qualifying origin window, the exclusions, and the missing-data rule. A distribution without those fields cannot be reproduced or compared with anyone else’s.

The eight classes

The classes are mutually exclusive. Apply them in the order below and retain the first class the evidence supports.

ClassDefinitionDefault interpretation
1. User-configured scheduled deliveryThe session follows delivery of a recurring or one-time task the user explicitly configured, with a current authorisation record linking the delivery to that task.Evidence of a prior grant for the stated task. It does not establish satisfaction, outcome quality, or continuing authorisation outside that scope.
2. User-authorised event triggerThe session follows a condition the user explicitly asked the product to monitor — a delivery, a price, a filing, a specified change.Evidence of conditional prior authorisation. Interpretation depends on whether the condition, timing and action stayed inside the grant.
3. Expected transactional or safety noticeThe session follows a notice necessary or reasonably expected to complete a transaction, report service state, or protect an account or a person.Service or protective communication, reported separately from re-engagement. Necessity and proportionality remain open questions.
4. Accepted product suggestion at task entryThe product proposed a task or next action at an entry surface before qualifying work began, and the user affirmatively selected it.Observable acceptance of a suggestion. Not evidence of reflective endorsement or welfare. The session rule must distinguish an ambient app open from the start of qualifying work.
5. Product-authored workflow promptThe product selected the timing or the purpose of a prompt intended to advance work, without a specific user-created schedule or event grant for that occurrence.Ambiguous product proactivity. Evaluate expectation, relevance, task outcome, frequency and ease of control. Do not classify it as capture by default.
6. Marketing or re-engagement promptThe session follows a product-authored message whose primary purpose is to cause return or additional use, rather than to deliver a specific prior request, transaction or safety need.A candidate for capture analysis, not proof of harm. Report targeting, frequency, defaults, user control and downstream outcome.
7. Unprompted user initiationThe observable record is complete enough to establish that no qualifying product-originated trigger occurred inside the published attribution window.Describes initiation without a qualifying prompt in the observed scope. It does not establish endorsement, deliberateness, welfare or appropriate reliance.
8. UnknownThe evidence cannot establish origin because the trigger, identity, authorisation, exposure or attribution link is missing or ambiguous.Missingness is a result. Publish it; do not allocate it to a preferred class.

Report each class as a percentage of eligible sessions. The eight should sum to 100 percent after rounding. Report the counts as well, and the percentage of sessions excluded before classification.

Do not convert the classes into a weighted score. No evidence presently justifies weights, and there is no universal order from best to worst. A scheduled delivery can be useful or stale. An unprompted return can be deliberate or compulsive. A product-authored prompt can be relevant or extractive. The distribution exists to keep unlike things apart so they can be evaluated against authorisation, outcome and control evidence — not to rank them.

The minimum record behind it

An earlier version of this argument said the number was a query rather than a project. For withdrawal events that is roughly true. For session origin it is not. A meaningful distribution may require a controlled prompt taxonomy, a link from each delivery to the authorisation that created it, cross-surface identity, notification exposure states, a versioned attribution window, and a defensible way to represent unknown cases.

At minimum, retain:

  • session identifier, start rule, and start time;
  • origin event and trigger identifier where known;
  • origin class and classifier version;
  • authorisation identifier, scope, creation time and current state, where applicable;
  • sent, delivered, displayed and opened states, where available;
  • attribution-window version;
  • task or session outcome, where defined; and
  • the missingness reason for any unknown classification.

The absence of a field is not permission to infer it. If authorisation cannot be linked, report the observable trigger and the missing authorisation state.

How to read it

Read changes by class. Do not read it as a contest for the highest unprompted share.

If user-configured scheduled delivery rises and the associated tasks are completed well, the product may be delivering more service under prior grants. If marketing or re-engagement rises while task outcomes stay flat, there is reason to inspect whether growth is coming from additional value or additional prompting. If unknown rises after a cross-device change, the measurement system may have deteriorated rather than user behaviour changing.

Each of those readings needs companion evidence. The distribution does not measure trust, consent, conferral, welfare or appropriate reliance. Its value is narrower: it stops unlike forms of use disappearing inside one session count.

The second measure: Withdrawal Rate

Withdrawal Rate is the count of qualifying events in which people reduce or end a product’s prompting, access, permission, connection, delegated scope or relationship, divided by a defined eligible population, per period.

Countable events include notifications disabled, a feature muted or switched off, a permission or scope revoked, a connected account disconnected, a task abandoned after the product acted without confirmation, a downgrade, an uninstall, an account closure. Report event types separately before considering any aggregate.

Withdrawal is not a direct measure of trust. A low rate can reflect satisfaction — or hidden controls, friction, lock-in, an absence of alternatives, or no opportunity to withdraw at all. A high rate can follow a harmful change, or show that a usable control is finally working. Report withdrawal opportunity, control exposure, friction, complaint behaviour, re-granting and available alternatives alongside the rate. A product event that preceded a withdrawal did not necessarily cause it.

This too remains a proposed diagnostic, not a validated measure.

What publishing either one would, and would not, prove

It would not prove a product deserves reliance.

A self-defined measure is easy to imitate if the definition can move, unfavourable periods can quietly not appear, and nothing follows from misstating it. Publication becomes informative when the definition is fixed in advance and versioned when it changes, unknowns and bad periods stay visible, corrections are preserved and dated, and the claim can be checked. Independent assurance would strengthen it further.

The amendment that produced this page demonstrates one thing only: a published definition was changed when a counter-case defeated it. That is not evidence the replacement is valid.

How this proposal could fail

  1. Independent classifiers may be unable to assign the classes consistently from the same evidence.
  2. Real product schemas may be unable to establish origin or authorisation without unacceptable missingness or cost.
  3. The classes may fail to separate cases that require different product decisions.
  4. A simpler established measure may answer the same question with less burden.

Evidence for any of those should narrow, revise or retire this proposal. Send a counter-case, or a product already publishing a qualifying measure, and the correction will be dated on this page and logged at the corrections record.

Sources

1. OpenAI, “Scheduled tasks in ChatGPT”, official Help Center, retrieved 31 August 2026.
2. Google, “Schedule actions in Gemini Apps”, official Gemini Apps Help, retrieved 31 August 2026.

This specification answers criterion 2 of the Conferral Design Scorecard — what a product knows about where its own usage came from. The scorecard’s anchors for that criterion were revised on 31 August 2026 to match it.

The rest of the standard. Seven further metrics, with measurement playbooks and the rules that keep them honest, are at the Conferral Metrics Standard. The definitions there are free and stay free.

Related: The two numbers nobody publishes · The Conferral Metrics Standard · The corrections record