Use-case profiles
Development status: Being explored — The design is being explored for opinionated starting profiles that would help teams choose confidentiality and performance settings for common use cases. No profile is defined publicly or available; the public interface and support are not settled, and nothing is publicly available for live use.
Before you read: What you could build: intended application patterns.
Will there be ready-made starting configurations for common use cases? That is the intention being explored, but no profile is defined yet. This is the primary page for use-case profiles. It explains what a profile is intended to be and why, how a team would use one once profiles exist, what is not yet defined, and which responsibilities would stay with the team.
What a use-case profile is intended to be
Status of this section: Being explored — no profile is defined.
The design is being explored for opinionated starting profiles that would help teams choose confidentiality and performance settings for common use cases.
- A starting configuration. A profile would be an opinionated starting configuration for a common kind of use, intended to help a team choose confidentiality and performance settings without deciding every setting from scratch.
- A recommendation, not a promise. A profile would be a recommended starting point. It would not be a promise about outcomes.
- Interaction not yet specified. How a profile would interact with an application’s own settings is not yet specified publicly.
Why profiles are intended
Applications differ in how much confidentiality they need and in how quickly they need results. Choosing settings well for a new kind of application takes experience that a team may not yet have. Profiles would capture recommended starting choices for common situations.
Starting from a documented recommendation is intended to make choices explicit and easier to review: the team, and anyone reviewing its work, could see which recommendation it started from and what that recommendation is documented to be suited for.
Teams with unusual needs would still need to make and review their own choices. A profile would be a place to start, not a substitute for the team’s judgement.
How profiles would be used
Status of this section: Being explored — describes how profiles would be used once defined and released; none can be used today.
Once profiles are defined and released, the planned experience would be:
- Pick the closest profile. When starting a project, a team would pick the profile closest to its use case.
- Read its documentation. Documentation for each profile would explain what it is suited for, what it is not suited for and its limitations.
- Meet profiles where settings are chosen. The intended onboarding experiences for applications and for organisations would point to profiles at the point where settings are chosen; see Submitting work and retrieving results and Onboarding an organisation.
What is not defined yet
- No profile names, contents, settings or parameters are published.
- Which use cases would receive profiles is not settled.
- No figures of any kind are published for any profile.
- How a profile would interact with an application’s own settings is not specified.
Until these are defined and released, no decision should be based on assumptions about what a particular profile would contain.
Responsibilities
- Fit. The team would remain responsible for checking that a profile fits its data, its users and its obligations.
- Policy decisions. Choosing a profile would not replace the organisation’s own policy decisions about approvals, key custody and who may see which data; see Organisation workflows with shared approval and custody choices.
- Not advice. A profile would not be advice, whether legal, regulatory or about security.
Assumptions, trust and limitations
- Profiles would reflect design recommendations, not assurances.
- Profiles would depend on confidentiality capabilities that are simulated in the experimental implementation, which provides no confidentiality protection; see Confidential computation.
- A recommendation suited to a common situation may not suit a specific one.
Not yet available, and how this page will grow
Once profiles are defined and released, this page would list each profile with its intended use and limitations, and exact settings would appear in versioned reference. Further technical reference is not yet available. Approved public references would be listed once approved; none are listed yet.
What this page does not claim
This page does not claim:
- that any profile is defined or available;
- any profile name, setting or content;
- any figure for any profile;
- that any profile makes an application suitable for a particular use, or provides any legal, regulatory or compliance assurance.
Anything not stated here as available should be treated as unavailable.
Related pages
- Organisation workflows with shared approval and custody choices — where profiles meet approval and custody decisions.
- Onboarding an organisation — the intended onboarding experience, previewed conditionally.
- What you could build: intended application patterns — the patterns profiles are intended to support.
- Submitting work and retrieving results — the planned developer experience where settings would be chosen.
- Confidential computation — the capability whose settings profiles would recommend, and its status.
Glossary
References
No approved public references yet.
