Legal
Application Review Guidelines
Document details
Version: 1.1 (draft). Effective date: none — this draft is not yet in effect, and nothing in it is in force. Last updated: 30 August 2026. Responsible entity: [SPHEROMNI RESPONSIBLE ENTITY — TBD]. Governing law and jurisdiction: [PRIMARY JURISDICTION — TBD]. Contact: [PRIVACY CONTACT — TBD].
Change history:
- Version 1.1 — updated when third-party submission opened: any enrolled account can now author and submit entries, review decisions notify the author inside the product, and the review criteria apply in full.
- Version 1.0 — first draft, written at Milestone 19 from the store's actual review lifecycle. Not in effect.
Who reviews what, today
Any account that has accepted the Developer Agreement can now author store entries of its own — a web application or an external link, never code that ships inside Spheromni itself — and submit them for review. Review remains with Spheromni's single administrator role: the reviewer is not the author for a third-party submission, and the audit trail records the actor of every transition either way.
Self-review is permitted, and it is recorded rather than hidden: the platform allows exactly one super-administrator account, so a rule that the approver must differ from the submitter would make publishing impossible in every deployment this build supports. Instead the audit trail records the actor of every transition separately, so a submit and an approve by the same account appear as exactly that. When a second reviewer role exists, the separation check goes in and the trail already distinguishes the cases it needs to.
The lifecycle
A store entry is in one of four states: draft, in_review, published or delisted. Exactly five actions move it between them, and nothing else can:
- submit — The author puts an entry forward for review.
draft→in_review. No written reason is required, though one may be given. - approve — A reviewer publishes it into the catalogue.
in_review→published. No written reason is required, though one may be given. - reject — A reviewer sends it back to the author to change.
in_review→draft. A written reason is required — the server refuses this action without one. - delist — A reviewer withdraws a published entry from the catalogue.
published→delisted. A written reason is required — the server refuses this action without one. - relist — A reviewer restores a withdrawn entry.
delisted→published. No written reason is required, though one may be given.
A reason is required exactly where the action takes something away from somebody: sending an entry back, and withdrawing a published one. “Sent back with no reason” is the outcome that rule exists to prevent. A review note is at most 500 characters and is validated as prose — control characters and text-direction overrides are refused rather than stripped, because a stored note must be the note that was written.
Every transition is written to the store audit trail in the same database operation as the change itself, so a decision cannot exist without its record.
What a reviewer checks
Third-party submission is open, so the criteria below apply in full to every submitted entry.
It does what it says. The name, summary and category describe the actual application. No misleading claims, no keyword stuffing in the summary, no impersonation of Spheromni or of another publisher.
The permissions are minimal and honest. Every declared permission is one the application actually needs; nothing it does requires a permission it did not declare. Declared permissions are now enforced server-side as capability grants the user can revoke, and a submitted external application declares no permissions at all — its frame gets no bridge into Spheromni — so this check stands behind the honesty of the disclosure the user reads at install, not alone in front of it.
It is safe. No malicious code, no attempt to escape the sandboxed frame, no loading of code from an undisclosed source, no collection of data beyond the declared permissions, and no circumvention of a platform limit.
It respects the Acceptable Use Policy. The Acceptable Use Policy applies to applications in full, including its child-safety rule, which is absolute.
The rights are held. The submitter made it, or is licensed and authorised to distribute it, including every asset in it and including any external site or progressive web app it wraps.
It works. It loads, its core function operates, and it degrades honestly when something is unavailable rather than showing a control that does nothing — the same rule the first-party applications are held to.
It is accessible. Keyboard reachable, with accessible names on its controls, and a disabled control carrying the reason it is disabled.
It is adults-only. Spheromni has no age-appropriate mode, so an application aimed at children is out of scope for the platform as it stands.
What a reviewer will not do
A reviewer cannot read a user's files, and there is no control anywhere in the administration surface that could. A reviewer does not rank, feature or promote entries: there is no featured placement, no ranking and no store reviews or ratings anywhere in this build, so review outcome affects listing and nothing else. There are no paid placements and no way to buy one.
Timescales, and the absence of a promise
No review turnaround is promised, because none is measured. When a reviewer decides about an entry you submitted, a notification appears in your in-product notification center — that a decision happened, not which way it went — and the decision itself, with any written reason, is read in your own submission list. Spheromni still sends nothing outside the product: no email, no push, nothing that reaches you when you are not here.
Appeals
There is no appeal process for a store review decision in this build; the community appeals mechanism covers moderation decisions only. An earlier version of this page said an appeal route must exist before third-party submission opened; submission opened without one, and this page records that as the gap it is rather than quietly dropping the sentence. Until an appeal route exists, a rejection's written reason is the whole of the recourse — which is why a rejection without one is refused by the server.
Changes
Changes are recorded as a new version in the change history above. Questions: [PRIVACY CONTACT — TBD]. See also the Developer Agreement and the Marketplace Terms.