Observation and action are separate grants. A remembered sentence needs inspectable terms.
What replaces apps
isn't apps.
It's rituals.
An assistant that knows when to ask.
And when to leave you alone.
You remember the app.
You initiate. The task waits until you go looking.
The task waits for your moment.
The assistant initiates within a window you choose.
A design hypothesis about initiative, not a forecast that apps disappear or proof of reduced effort.
Apps won by organizing everything into tasks you have to open. That model is exhausted. You have 3 banking apps, 4 subscriptions, 12 notifications — and you still get double-charged because you didn't open the right app at the right time. The next wave of computing (ambient agents, XR glasses, Android XR) removes apps entirely. How do you design agent initiative that is helpful without being creepy? How do you ask for permission to act on someone's behalf while they're cooking dinner? How do you preserve trust when you act without being asked?
The brief’s provocation. App counts and future claims are illustrative; monitoring cannot prevent every billing error.
Someone winding down at home who wants help with recurring charges, without turning dinner into another admin session.
A shared definition of a useful interruption: timely, permitted, understandable and easy to decline.
Initiative needs boundaries.
A proposed daily cap on unsolicited prompts. A ceiling, never a quota to fill.
Private text first. User-set quiet windows, not inferred presence or surveillance.
What happened, what is pending and which permission and source support it.
Permission. Timing. Proof.
Make the agreement memorable.
“Watch for duplicate charges while I’m offline.”
Explain the benefit in ordinary language. Then specify the records, review window, duration and how to stop.
Spend attention deliberately.
“This can wait until tonight.”
Check permission, timing and remaining budget before delivery. Batch related findings instead of competing for attention.
Keep the reason within reach.
“Request sent. Refund pending.”
Start with a readable status. Let the person inspect the observation, their authorization and the provider’s response.
Try giving an assistant permission.
The task: investigate two matching $12 subscription charges and, if appropriate, request a refund. Try changing the time, withholding permission or exhausting the budget.
Remember → Find transactions → Review → Request refund
Choose scope → Wait for your window → Review → Confirm → Track
No agreement yet. Observation is off.
A user-opened review costs no additional interruption units. Neither gaze nor a nod authorizes a financial request in this prototype.
The person decides.A complete permission-to-receipt flow.
No measured tap savings, time savings or trust improvement claimed.
A day with room left for living.
Three units is an initial design hypothesis. Quiet periods take precedence over available budget. A held item spends nothing until it is delivered.
One brief, low-stakes prompt. 1 / 3 units used.
| Pattern | Cost | Decision rule |
|---|---|---|
| Whisper | 1 unit | One low-stakes observation, up to 12 words, within a chosen window. |
| Nudge | 2 units | A batch or more demanding review, up to 20 words, within a chosen window. |
| Intervention | 3 units | Reserved for a separately opted-in, time-sensitive category. Not enabled in this demo. |
| Hold / user-opened review | 0 units | Waiting is silent. Opening the queue is the person’s initiative. |
No automatic urgency override. If the remaining budget is too small, defer. An emergency-alert service would require its own explicit policy; this financial-admin concept is not one.
A useful invitation needs clear terms.
“While you’re offline” describes delegated work. The system uses the schedule you choose; it does not infer sleep, cooking, company or location.
Explain the decision. Keep the evidence.
Request accepted.
Money has not been returned yet.
- Finding
- Two Acme Cloud charges · October 1
- Observation permission
- October 18 · Read selected records
- Action permission
- October 22, 9:04 pm · Request confirmed
- Source
- billing_api · request_demo_2847
- Interruption
- 1 unit · Chosen wind-down window
Inspect the illustrative source record
L2847 request_id: request_demo_2847 L2848 amount_requested_usd: 12.00 L2849 request_status: accepted L2850 refund_status: pending L2851 observation_grant: OBS-101 L2852 action_grant: ACT-202 L2853 user_confirmation: explicit
Why did you notice?
The person authorized reading specific records. Matching dates and amounts triggered a review, not a conclusion.
Why did you act?
The person explicitly confirmed this $12 request. An earlier monitoring agreement did not authorize it.
Did it work?
The provider accepted the request. “Refunded” is reserved for a later confirmation that money was returned.
Rules another team can inspect.
GHOST Protocol v0.1 defines four content patterns. Each includes a trigger, permission boundary, budget rule and fallback.
Permission narrative
PN–01“Watch for duplicate charges while I’m offline.”
- Structure
- Benefit + scope + chosen review rhythm, followed by explicit terms.
- When
- Before the first observation, after expiry, or when scope expands.
- Budget & length
- Invitation up to 12 words; terms are exempt. Setup is user-initiated and costs 0 units.
- Boundary
- Read-only does not mean act-on-my-behalf. Show revocation and expiry controls.
Ritual whisper
RW–01“Two $12 charges match. Review them?”
- Structure
- Verified observation + invitation to review.
- When
- Grant active, chosen window open, quiet mode off, budget available.
- Budget & length
- 1 unit, up to 12 words for a simple observation. Related items may be batched as a 2-unit nudge.
- Boundary
- Do not imply a duplicate is confirmed or mention a ritual the system did not observe.
Trace receipt
TR–02“Request sent. Refund pending.”
- Structure
- Status + amount + date + observation grant + action grant + source.
- When
- After a confirmed request, failed attempt or unresolved provider response; available on demand.
- Budget & length
- Readable summary first. Evidence has no arbitrary word limit. In-flow status costs no new unit.
- Boundary
- No “saved” or “refunded” claim without supporting evidence. Unknown stays unknown.
Budget hold
BH–01“Held for your next review window.”
- Structure
- Queued item + reason + next eligible window.
- When
- Quiet period, insufficient budget or outside the chosen window.
- Budget & length
- 0 units while held. Show only inside a user-opened queue; do not send a notification about not notifying.
- Boundary
- Recheck permission and relevance before delivery. Revocation stops queued outreach.
Inspect the decision contract
OBSERVATION INPUTS selected_records · observation_grant · grant_expiry user_schedule · quiet_period · remaining_units · event_id DELIVERY GATES / evaluated in order 1. Active, in-scope grant? Otherwise do not observe. 2. Already delivered? Do not spend again. 3. In a chosen window, outside quiet time? Otherwise hold silently. 4. Enough units for this pattern? Otherwise queue. 5. Deliver once and record the cost. ACTION GATES Review the specific records and proposed amount. Require separate, explicit confirmation for the request. A provider response of 'accepted' means pending, not refunded. If the response is unknown, block blind retries. OUTPUTS pattern_id · copy · decision_reason · budget_delta observation_grant_id · action_grant_id · source_id · status AUTHORITY Authored strings and deterministic rules drive this prototype. A model could propose copy; it cannot expand permission or invent observations, causes, urgency, settlement or source records.
Governance and edge cases
Content design owns language and disclosure requirements. Engineering owns permission enforcement, event deduplication, time zones, idempotency and provider-state integrity. Privacy, accessibility and localization reviews precede release. Every pattern change should include its version, owner, rationale, examples, exceptions and test evidence.
Production work would need scoped account selection, grant renewal, daylight-saving handling, expiry on actual time, secure storage and a consistent queue across devices. Revocation stops future observation and outreach; retention and deletion of existing receipts require a clearly stated policy. This browser demo keeps state only until reset or reload.
Designing initiative, not more notifications.
Relevant to a Staff UX Writing / Content Design, XR discussion: a bounded initiative system with inspectable decisions. Independent work, with no Google commission, endorsement or production outcomes implied.
Turns “be helpful without being creepy” into enforceable gates for permission, timing, quiet periods and cost.
Defines what can be said, which evidence is required and when the system must remain silent. No trained model or research validation is claimed.
Four patterns share a decision contract, event ledger and proposed review ownership. Another team can examine both the rule and its failure case.
Separates reading records, delivering a prompt, authorizing a request and confirming its outcome. Each has different language and evidence.
How I would evaluate it
“Trust per interruption” is a research question, not a score produced by this prototype.
- Permission recall: can people describe what they agreed to, what the assistant cannot do and how to revoke access?
- Timing: ask whether each interruption was welcome. Track deferrals, dismissals and missed relevant items alongside completion.
- State comprehension: can people distinguish a possible duplicate, a refund request and a completed refund?
- Budget fit: test different caps and batching rules over time, including people with different schedules and access needs.
No formal participant study, live account integration or XR hardware testing has been conducted.
GLASS asks where content belongs.
RITUAL asks when it should arrive.