Compute
Data profiles Compute accepts and refuses
The eight data profiles, what each one admits and rejects, and why regulated or credential-bearing content is refused outright rather than accepted with a warning.
The eight data profiles
| Profile | What it admits | What it rejects |
|---|---|---|
shared_public | Content that is already published or lawfully public | Anything you have not confirmed is public |
shared_deidentified | Records whose direct identifiers you removed before sending | Records that remain re-identifiable, and identifiers you meant to strip but did not |
shared_customer_approved | Your own content, approved for this processing by someone in your organization who can authorize it | Content nobody in your organization approved for this use |
shared_native_test | Bounded test material for checking a native capability | Production content borrowed for a test run |
shared_synthetic_seed | Generated material with no real person or record behind it | Synthetic material derived from real records you did not deidentify |
rejected_regulated_secret | Nothing. This is a refusal class | Regulated content and secret-bearing content |
rejected_credential | Nothing. This is a refusal class | Keys, tokens, passwords, signed URLs and every other credential |
rejected_unsupported | Nothing. This is a refusal class | Anything outside the five accepted profiles above |
How the five accepted profiles differ
- Public is a fact about the content, not about your intent to share it. If you cannot point to where it is public, it is not
shared_public. - Deidentified is your work, done before you send. Compute does not deidentify on your behalf.
- Customer approved carries an approval from a person in your organization who holds that authority. It is the profile for your own business content.
- Native test is bounded material used to check a capability. Keep production records out of it.
- Synthetic seed has no real subject behind it. Material generated from real records is not synthetic until it is also deidentified.
What each profile does not decide
A data profile is not a residency rule, a retention window, or an approval to spend. Those are separate settings with separate authorities.
A profile also does not widen a workflow. The workflow you choose states which profiles it accepts, and your quote repeats that.
The three rejected classes are refusals
Regulated content, secret-bearing content and credential content are refused. They are not discouraged, and they are not accepted with a caution.
Anything outside the accepted classes lands in rejected_unsupported. A profile you cannot name for your input is a reason to narrow the input, not a reason to guess.
Where the decision is made
- You classify the input before you send it, using your own knowledge of the records.
- Validation reads the frozen snapshot and checks bytes, schema and item identity against the workflow's declaration.
- Admission refuses a job whose declared profile does not match the workflow.
What a refusal returns
A refusal is a typed non-success outcome. It carries a safe reason and a non-empty next action, and it never becomes a silent partial run.
The safe reason names the constraint that failed. It does not quote your content back to you, because refusal records stay content-free.
Common next actions are narrowing the input, deidentifying it before resending, choosing a workflow that accepts the profile, or removing the credential the input contained.
Credentials inside an input
A credential found inside your data is refused under rejected_credential, whatever the surrounding content was for.
Treat that refusal as an exposure. Rotate the credential at the system that issued it, then resend the input without it.