Every submission Rhythm creates has an identifier, and that identifier starts with the space the submission belongs to. This article explains why that matters and why Rhythm will not save a submission when its details do not match its space.
A Submission's Identifier Starts with Its Space
When you create a submission, Rhythm builds its identifier from the identifier of the space it belongs to. If the submission is mirrored, the identifier also includes a reference to the record it mirrors, so you can trace the mirror back to its source.
Rhythm sets the identifier when the submission is created, so you cannot move the submission to another space by changing its space later. Rhythm will refuse that save. If the submission belongs in a different space, create a new submission in that space instead of editing the existing one.
What "Origin" Means, and Why a Mismatch Is Refused
Every submission records where it came from. For a mirrored submission, the origin is the application and record it mirrors. For a Portal submission, the origin shows that it came from a Portal form. Rhythm recalculates this origin information every time you save, so it reflects where the submission actually came from rather than any origin value included in the request.
Each space accepts only submissions with the matching origin. An abstract space accepts abstracts, an award space accepts award applications, and so on. If the submission's origin does not match the space where you are saving it, Rhythm refuses the save and names the mismatched origin and space, for example:
Submission origin "award_application" not applicable to space abstract:2026-conference
If you see a message like this, check that the submission, or the record being mirrored, is the kind of record the target space is meant to collect. You can also see this when you create a submission through a Custom Data Task import. An import template that otherwise looks correct can still fail with the same origin mismatch if the data it creates does not match the target space's kind. More generally, a Custom Data Task cannot target one specific space the way it can for simpler record types. Because a submission spans multiple areas of the platform, the task cannot limit its processing to a single space or app context.
A submission must also include the source record or form setup it depends on. Rhythm requires that reference, but it does not confirm on its own that the referenced record still exists.
Why a Submission Cannot Borrow Another Space's Type, Process, Bucket, or Round
A submission's type, submission process, bucket, and round all belong to a specific space's configuration. Rhythm refuses to save a submission that points to a type, process, bucket, or round from a different space. This keeps each submission tied to the configuration for its own space, so any bucket or round you see on a submission exists within that same space's setup.
Tip
This check confirms that a type, process, bucket, or round identifier belongs to the correct space. It does not separately confirm that the bucket or round is still active. If a submission's bucket or round looks unfamiliar, check whether it was later deleted or deactivated in the space's review setup.
Related
For how a mirrored submission gets its identifier and stays linked to its source, see Mirrored Submissions Explained. For what happens when a submission's source record, event, or award is later deleted, see Removing and Protecting Submissions.