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#

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 and 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 and authority and trust.

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.

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.

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 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 and the 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
• Planning
• Providers
• Authority

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.