Sub-Initiation Requests

What Are Sub-Initiation Requests?

Sub-initiation requests (Spec 235, shipped June 2026) let a submissive formally initiate certain relationship actions rather than waiting for a Dominant to propose them. The submissive addresses the request to a specific Dominant in the hierarchy, optionally adds a personal message, and submits. The Dominant receives it as a pending request and chooses to approve or decline. All decisions are recorded with a timestamp and audit trail.

This mechanism is designed around explicit mutual consent: no action takes effect until a Dominant actively approves. A declined request leaves no lasting record on either party's profile beyond the request log.

Request Types

There are six request types. Each triggers a different backend action on approval.

Privilege Request

Ask a Dominant to grant you a temporary privilege — a relaxation of a standing protocol or rule. When submitting, you choose a privilege category and give it a title. Optional fields let you specify an expiry date and add context.

Available privilege categories:

• Task choice — freedom to choose which tasks to complete from a set
• Schedule freedom — flexibility around ritual or task timing
• Orgasm self-serve — permission to self-manage without asking
• Protocol pause — temporary suspension of a specific protocol
• Custom — any privilege not covered by the above

Partner Request

Ask a Dominant to formally recognise a partner relationship with you in the hierarchy. On approval, the backend records the relationship association. Use this when you and a Dominant have agreed informally but want the dynamic reflected in Helm.

Negotiation Request

Ask a Dominant to open a limits-negotiation session with you. On approval, the Dominant starts the negotiation session; the submissive participates in response. Use this to revisit limits in a structured way rather than ad hoc.

Switch Role Request

Ask a Dominant to designate you as a switch within the hierarchy. On approval, your role designation is updated to reflect switch status.

Collaring Advance Request

Ask a Dominant to advance the collaring stage of the relationship. When submitting, choose the stage you are requesting to move to and add any context message.

Available collaring stages:

• Exploring
• Consideration
• Training
• Collared
• Owned
• Custom

Keyholder Request

Ask a Dominant to become your keyholder in the chastity system. This request type has its own dedicated sheet on the Chastity page rather than using the generic request flow. See the Chastity guide for details on the keyholder relationship.

How a Submissive Submits a Request

1. Open the request sheet
   The entry point depends on the request type. Keyholder requests appear on the Chastity page (tap "Request a Keyholder" — visible only if Dominants exist in your org). For other request types, locate the relevant section in the app (Autonomy, Collaring Chronicle, etc.) and look for the request action button.
2. Select a Dominant
   A dropdown lists all admin and owner members of your hierarchy. Choose the Dominant you are addressing the request to. You must select one before the submit button becomes active.
3. Fill in type-specific fields
   Depending on the request type, additional fields appear — privilege category, collaring stage, expiry date, and so on. Complete any required fields. Optional fields add context but are not mandatory for submission.
4. Add an optional message
   A free-text field lets you explain your request in your own words. This message is stored on the request record and visible to the Dominant when they review it.
5. Tap "Send Request"
   The request is created with a status of pending. A success state confirms it was sent. The sheet can then be dismissed. The request now appears in the Dominant's pending requests queue and in your own request history.

To withdraw a pending request before the Dominant has acted on it, open your request history and use the withdraw action. Withdrawal sets the status to withdrawn and removes it from the Dominant's queue.

What Happens on Approval

When a Dominant approves a request, the backend runs the corresponding executor inside a database transaction:

• Privilege: the privilege grant is recorded and, if an expiry date was set, scheduled to lapse at that date
• Partner: the partner relationship association is created
• Negotiation: the limits-negotiation session is opened and the Dominant is notified to begin
• Switch role: your switch designation is updated
• Collaring advance: the collaring stage is advanced to the requested stage
• Keyholder: the Dominant is assigned as your active keyholder

The request record is updated to approved, and resolvedAt and resolvedByUserId are stamped. The approved card disappears from the Dominant's pending queue. You will see the effect of the approval in the relevant section of the app (Chastity, Autonomy, Collaring Chronicle, etc.).

What Happens on Decline

Declining a request is a two-step action for the Dominant: pressing "Decline" shows a confirmation prompt ("Confirm Decline"). An optional decline message can be added before confirming. On confirmation:

• The request status is set to declined
• The optional decline message is stored on the request record
• The request card is removed from the Dominant's pending queue
• No backend effect is applied — the dynamic is unchanged

The two-step confirmation prevents accidental declines. An error inline on the card (without removing it) is shown if the decline API call fails, so the Dominant can retry.

The Dominant's Pending Requests View

Dominants see all pending requests addressed to them in the Pending Requests section. Each card shows:

• The submissive's display name
• The request type (e.g., "Keyholder Assignment")
• The optional message, if provided
• Approve and Decline buttons

When there are no pending requests, an empty state is shown. No live notification badge appears in the navigation; Dominants should check this section when they receive a notification about a new request.

Audit Trail

Every request record retains the full history of its lifecycle. The stored fields are:

• status — current state: pending, approved, declined, or withdrawn
• createdAt — when the submissive sent the request
• updatedAt — last status change
• resolvedAt — when the Dominant approved or declined (null if pending or withdrawn)
• resolvedByUserId — the Dominant's user ID (null if pending or withdrawn)
• declineMessage — the Dominant's optional explanation on decline
• message — the submissive's optional message at submission
• payload — any type-specific structured data (privilege category, collaring stage, etc.)

Records are retained after resolution. Neither the submissive nor the Dominant can delete a request record after it has been submitted.