Working with Hyperscale is not a separate experience from standard Compliance. It is the same workflow with an execution choice added at the end.
The onboarding workflow
Onboarding a data source for Hyperscale-eligible workloads follows the same process already used for Continuous Compliance:
-
Create a connector for the data source.
-
Define structure by building a rule set.
-
Profile the data to identify sensitive/PII fields, then assign algorithms.
-
Create a job.
Nothing about these steps changes because Hyperscale is involved. The divergence only happens at the last step, when deciding where the job runs.
Choosing execution infrastructure
At job run time, a compatible job can execute on a standard Compliance engine or on a Hyperscale Orchestrator. This choice is what “optionality” refers to: the same job, same rule set, same algorithm assignments, run on whichever infrastructure fits the throughput need at that moment.
This choice is not unconditional. A job can only run on Hyperscale infrastructure if:
-
A Hyperscale Orchestrator exists in a connector mode matching the job’s data type. See Hyperscale Administration: Connector type and orchestrator scope
-
The user has been granted permission to opt in (see below), and
-
The job is configured as an On-The-Fly (OTF) job type. Hyperscale executions currently require this job type; jobs configured otherwise are not eligible.
Opt-in to Hyperscale execution
Running a job on Hyperscale infrastructure requires an explicit, discrete opt-in step at the job level. This is intentional, not a default behavior. It ensures two things are true before a job lands on Hyperscale infrastructure:
-
Permission. The user has been granted the ability to do so by an admin.
-
Intention. The user intends to run that kind of operation, since Hyperscale execution behaves differently from a standard engine run and should not happen by accident.
Power-user runtime tuning
Many Hyperscale jobs benefit from fine-tuning beyond the defaults. At job run time, a user can:
-
Update job-specific configurations for that run.
-
Set new job-level defaults, so the adjustment persists for future runs of that job rather than applying just once.
This is the second and third tier of the cascading configuration priority described in the overview. Job defaults already override the Orchestrator’s base configuration, and a runtime override updates those job defaults going forward as settings are optimized over time.