Jay Speakman / RITUALGHOST Protocol / An initiative model
Independent conceptAgent behavior designCompanion to GLASS
RITUAL / 02

What replaces apps
isn't apps.
It's rituals.

An assistant that knows when to ask.
And when to leave you alone.

Explore the working protocol
WIND-DOWN9:00 pmCOFFEEQUIETYour rhythm. Your permission.
RoleJay Speakman · Concept & content design
SystemPermission · Timing · Evidence
StatusSpeculative · Browser simulation
01 / TASK

You remember the app.

UserOpen appReadAct

You initiate. The task waits until you go looking.

02 / RITUAL

The task waits for your moment.

PermissionObserveAskTrace

The assistant initiates within a window you choose.

A design hypothesis about initiative, not a forecast that apps disappear or proof of reduced effort.

The problem / speculative framing
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.

The person

Someone winding down at home who wants help with recurring charges, without turning dinner into another admin session.

The product team

A shared definition of a useful interruption: timely, permitted, understandable and easy to decline.

01 / Constraints

Initiative needs boundaries.

Permission
Scoped

Observation and action are separate grants. A remembered sentence needs inspectable terms.

Attention
3 units

A proposed daily cap on unsolicited prompts. A ceiling, never a quota to fill.

Social
Quiet

Private text first. User-set quiet windows, not inferred presence or surveillance.

Evidence
A receipt

What happened, what is pending and which permission and source support it.

02 / GHOST Protocol

Permission. Timing. Proof.

01 / PERMISSION AS NARRATIVE

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.

Warm language introduces an agreement; it does not replace explicit controls.
02 / INTERRUPTION BUDGET

Spend attention deliberately.

“This can wait until tonight.”

Check permission, timing and remaining budget before delivery. Batch related findings instead of competing for attention.

The cost reflects required attention and stakes, not word count alone.
03 / PROVENANCE WHISPER

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.

A source line supports an explanation. It cannot stand in for one.
03 / Interactive walkthrough

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.

Phone / Task initiated by you

Remember → Find transactions → Review → Request refund

RITUAL / Prompt initiated within your agreement

Choose scope → Wait for your window → Review → Confirm → Track

RITUAL / LIVE SIMULATION0 / 3 used today
Activity & held items
Why the system did this

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 assistant can notice.
The person decides.
A complete permission-to-receipt flow.
No measured tap savings, time savings or trust improvement claimed.
04 / Interruption budget

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.

Illustrative day / cumulative units usedBudget is not a trust score
3210Morning coffeeCooking / quietWind-down
“Three renewals this week. Review?”

One brief, low-stakes prompt. 1 / 3 units used.

After the capAnother non-urgent finding waits for the next permitted review window.
Proposed cost model / charged once at unsolicited delivery
PatternCostDecision rule
Whisper1 unitOne low-stakes observation, up to 12 words, within a chosen window.
Nudge2 unitsA batch or more demanding review, up to 20 words, within a chosen window.
Intervention3 unitsReserved for a separately opted-in, time-sensitive category. Not enabled in this demo.
Hold / user-opened review0 unitsWaiting 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.

05 / Permission as narrative

A useful invitation needs clear terms.

System-centered

Allow Double-Charge Monitoring?

This app would like to send you notifications.

Don’t AllowAllow

The system’s capability is clear.
The person’s agreement is not.

Scheduled wind-down / illustrative view
Ritual language + scoped control

“Want me to watch for duplicate charges while you’re offline?”

Read selected transaction records. Bring findings to your review windows. Ask before requesting any refund.

Review the agreement →

“While you’re offline” describes delegated work. The system uses the schedule you choose; it does not infer sleep, cooking, company or location.

06 / Trace receipt

Explain the decision. Keep the evidence.

RITUAL / EXAMPLE RECEIPTPending
$12refund requested

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
Three separate questions

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.

07 / Pattern library

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.

08 / What this demonstrates

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.

Ambiguous problem → concrete policy

Turns “be helpful without being creepy” into enforceable gates for permission, timing, quiet periods and cost.

Model behavior design

Defines what can be said, which evidence is required and when the system must remain silent. No trained model or research validation is claimed.

Systems & governance

Four patterns share a decision contract, event ledger and proposed review ownership. Another team can examine both the rule and its failure case.

Technical & human clarity

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.

  1. Permission recall: can people describe what they agreed to, what the assistant cannot do and how to revoke access?
  2. Timing: ask whether each interruption was welcome. Track deferrals, dismissals and missed relevant items alongside completion.
  3. State comprehension: can people distinguish a possible duplicate, a refund request and a completed refund?
  4. 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.

Two companion explorations

GLASS asks where content belongs.
RITUAL asks when it should arrive.