# Profiles and assurance

"Profile" names several independent composition axes in One. They are related
but never interchangeable: a language profile governs an authored body, a
projection profile governs generated contract values, a provider profile
governs a selectable physical realization, an environment profile describes
desired operating conditions, and an assurance policy states how much evidence
a root requires. Collapsing them into one "profile" or one "environment name"
erases real consequences.

## The five profiles

| Profile | Identity | What it owns |
| --- | --- | --- |
| Implementation-language profile | `one.language.<source>#Name@lane` | Pins exactly one `SourceLanguageDefinition` and one `LanguageProjectionProfile`; governs how an authored implementation body is checked, built, and realized |
| Projection profile | `one.projection.<target>#Name@lane` | Owns nominal contract mapping and a complete disposition table for every applicable semantic item |
| Provider profile | A Planning-owned `ProviderProfileClaim`, resolved into an exact `ProviderProfileReference` | Provider ID and descriptor revision, profile ID, derived complete claim revision, and the exact catalog-resolution variant |
| Environment profile | A desired environment and policy preset | Intended operating conditions; never a trust level |
| Assurance policy | An Authority-owned policy selected by the root | The minimum evidence class the root actually requires |

An implementation-language profile and a projection profile are distinct typed
namespaces. They must never reuse one exact identity, even when an
implementation profile references a projection profile internally. See
[languages and SDKs](/one/platform/languages) and
[OCS](/one/reference/ocs).

A provider reference is exact because a profile ID alone is not executable
authority. Multiple profiles may reference one exact provider descriptor
revision, and every claim is resolved independently. The resolution variant
carries the trust posture: the development variant carries
`UnverifiedDevelopment`; the Accountable variant carries the exact provider
subject and Authority trust-acceptance revision; the governed variant
additionally carries the exact namespace, assurance-case, registry-policy, and
governed-admission revisions. See
[providers and adapters](/one/platform/providers) and
[authority and trust](/one/platform/authority).

## Progressive assurance

The same semantic contracts and stages apply from local development to
production, but the evidence required is progressive:

- `UnverifiedDevelopment` is command-scoped. It is valid only for the exact
  selected command and workspace, supports no durable release, and cannot
  become a durable release claim.
- `Accountable` binds one exact ecosystem subject to one live Authority
  `TrustAcceptance` (`one.authority.trust#Accept@1`), aggregated as
  `one.providers.trust#Accountable@1`. It is a durable, attributable,
  root-owner acceptance — not independent verification.
- Governed resolution requires current namespace authority, exact package and
  claim binding, artifact or external-revision identity, complete support
  dispositions, required boundary conformance, and non-stale integrity,
  provenance, and revocation evidence. Providers aggregates these into an
  `AssuranceCase` and a `GovernedAdmission`.

```mermaid
flowchart LR
  D["UnverifiedDevelopment<br/>command-scoped"] --> A["Accountable<br/>one exact subject + TrustAcceptance"]
  A --> G["Governed<br/>AssuranceCase + GovernedAdmission"]
```

The standard policy coordinates are `one.authority.policy#Development@1`,
`one.authority.policy#Accountable@1`, and `one.authority.policy#Governed@1`.
A root selects one exact policy; an organization may publish its own policy
that consumes the same contracts. See
[plan, build, and apply](/one/lifecycle/plan-build-apply).

## Eligibility is dimension-based

Eligibility is decided from the exact dimensions above. A "higher tier" in one
dimension cannot repair a semantic incompatibility or missing evidence in
another. Environment labels never select or upgrade trust, and a first-party
origin grants no hidden privilege — One-maintained providers traverse the same
namespace, conformance, admission, selection, artifact, grant, binding, and
runtime validation as third-party providers.

An owner acceptance cannot convert a false, incompatible, unsafe, or
unsupported contract claim into an eligible realization, and provider-authored
bytes cannot contain their own acceptance. Contract-owned semantic and safety
requirements remain mandatory regardless of the accepting principal.

## Freshness and revocation

There is no universal wall-clock freshness duration. Each evidence category
records its observed or issued time plus a contract- or policy-owned maximum
age. A governed catalog may require a stricter duration for a target
environment or effect envelope, but never a weaker one.

Admission at planning and binding checks the applicable current time and
uncertainty, expiry, revocation snapshot, and maximum age. Stale required
evidence is `MissingEvidence`. An unchanged package or a passing historical run
never extends freshness, and retaining a prior package does not retain fresh
admission evidence.

## Worked example: an implementation profile

The `using` clause is the sole authored language selector. `one.lock` resolves
it to one exact profile revision, which resolves exactly one
`SourceLanguageDefinition`, language release, frontend contracts, projection
profile, and dependency constraints:

```one
one 1

impl acme.orders#OrdersRust@1
    realizes acme.orders#Orders@1
    using one.language.rust#OwnedAsync@1
    config
        edition = 2024
        warnings = deny
    source
        // ordinary Rust body
```

The implementation profile is a governed contract instance, not a concrete
compiler, artifact, or proof that the body conforms. Analysis produces an
`ImplementationAnalysisReceipt` that makes the exact source candidate eligible
for root selection; post-Build artifact and conformance evidence separately
gates binding and admission. See
[add implementations](/one/authoring/implementations) and
[the lock](/one/reference/lock).

## Normative owner & evidence

Contracts owns the source-language-definition, implementation-language-profile,
projection-profile, and analysis-receipt meta-contracts, while each namespace
owns its profile instances. Planning owns canonical provider profile claims;
Providers owns ecosystem resolution, `AssuranceCase`, and `GovernedAdmission`;
Authority owns trust acceptance and assurance policies.

- [Contracts](https://github.com/muijf/one/blob/main/systems/contracts/AGENTS.md)
- [Planning](https://github.com/muijf/one/blob/main/systems/planning/AGENTS.md)
- [Providers](https://github.com/muijf/one/blob/main/systems/providers/AGENTS.md)
- [Authority](https://github.com/muijf/one/blob/main/systems/authority/AGENTS.md)

Executable evidence for the current profile and assurance implementations is
the owning crate tests for `one.authority.policy` trust profiles, Planning's
provider-profile resolution, and Providers' admission contracts, together with
the Developer Interface check and build tests. Installation and adoption
behavior is covered by [install and update One](/one/start/install).