Data Run
What It Is
A Data Run is the continuing account of an initial migration package as its datasets load into Rhythm. Implementation staff use it when an association’s information spans several kinds of record and more than one owning application. The run connects those separate jobs so staff can follow the package as a whole and assess what still needs attention.
The package manifest provides the producer’s identity, destination and dataset declarations. Registration compares those declarations with completed uploads, establishes dependency waves and saves the run with its steps. It does not load the business records. The same package can have later runs after an earlier attempt ends, so the package identity and the identity of one execution serve different purposes.
A run preserves each dataset’s owning application, job reference and reported counts. Its summary adds the dataset counts into package totals. A separate readiness assessment identifies obstacles to customer use; completion alone does not establish a successful reconciliation.
What It Is Not
A run does not replace the individual data jobs that validate and save records. It also differs from provisioning, which creates the workspace and its initial configuration. The implemented package purpose is initial migration into a workspace being prepared for use, rather than a recurring integration delivery into an active workspace.
Readiness is an assessment of the recorded load, rather than an enforced activation gate. The current activation action does not consult that assessment. Nor does a cancelled run prove that every child job stopped: some downstream cancellation failures are logged without preventing the run from becoming cancelled.
How It Is Used
Implementation staff upload and register the package, then start the run with their own authority. They continue reading it while jobs progress. Those reads also advance coordination by recording completed work and submitting eligible datasets; an unwatched run does not advance in the background.
Staff inspect reported counts and read records back using producer keys. If a mapping problem requires a clean load, they reset the workspace and register a corrected package. An operator with activation authority opens the workspace after reviewing the migration. A migration tool can perform the same API sequence.
Its Facets
Package and manifest. The manifest describes what should arrive and where it belongs. Upload comparisons check sizes and available digests, but a declared digest on a large file can remain unverified.
Steps and waves. Steps retain the jobs for individual datasets. Waves express dependencies and identify datasets eligible to proceed together. A blocked dataset receives one further attempt.
Run state. State distinguishes registered work, active coordination, a pause and the final outcomes. The retained state explains whether staff can continue the same run.
Summary and readiness. Counts and blockers answer different questions. Shortfalls are reported, while excess counts currently do not create a readiness blocker.
Loading state. The workspace lifecycle separates migration from ordinary customer work. That lifecycle belongs to the workspace service, which the run consults.
Reset. Reset clears the loaded records while retaining the agreed security, configuration, uploads and run history.
Activation. Activation has separate authority from import management and admits the customer’s staff to the workspace.
How It Relates
Data jobs perform the record changes; uploads hold the input files; producer keys support reconciliation. Workspace lifecycle services provide loading, reset and activation. The run coordinates these concerns without owning the applications’ business records.
What It Could Become
The product should enforce readiness before activation and make unresolved child-job cancellation visible. Staff also need reliable handling of failed submissions, unexpected progress responses and inconsistent counts. Dedicated migration screens or a background driver are possible extensions; Membership’s declared operations need further implementation before a run can load them.