Trusted context

Trusted context is information the application establishes from sources it trusts before Core evaluates a consequential action. It tells Core who is acting, which account or tenant is involved, where relevant facts came from, and how current those facts are. A proposal is not permission or proof.

What the application supplies

In an existing architecture, the host might combine an authenticated session from its identity system, account scope from its backend, a bounded record from a CRM or database, and a policy or snapshot revision. Core receives that bounded context from the host. It does not authenticate the user, query the database, or decide which external system is authoritative.

For each important fact, ask once:

• Who or what supplied it?
• Which account, tenant, or operation does it apply to?
• How current is it?

The host should carry the source and revision with the context and keep the scope exact. A user or model assertion cannot create trusted context or override the identity, tenant, or snapshot supplied by the host.

Why source and freshness matter

Context is admitted before grounding and authorization. It gives those stages a stable identity, scope, and snapshot to use. It also gives later verification the binding needed to interpret evidence. A stale or foreign record can look plausible while referring to the wrong account or an earlier policy state.

Missing, malformed, overlarge, foreign, contradictory, or stale context fails closed. Depending on the lifecycle point, the host may refresh it, request clarification, or expose an unresolved result; it must not silently repair or broaden the context. Trusted authorization context still does not prove an external effect.

Example: changing a company billing contact

A support application receives a request to change the billing contact for a company account. The request could come from a web UI, support copilot, or API workflow. Its backend supplies the authenticated staff identity, company account, CRM record revision, and applicable policy context.

The application can then ground the request and authorize that exact account and change. A model-generated claim that the requester is an administrator cannot override the host-supplied identity or tenant. If the CRM revision is stale or belongs to another account, the host refreshes or fails closed before dispatch.

Responsibilities

The host owns authentication, tenant isolation, context acquisition, freshness policy, credentials, privacy, and the choice of authoritative sources. Core supplies bounded lifecycle classification and safe claim projection for the context it receives. Neither trusted context nor a provider acknowledgment establishes that the billing contact was actually changed; an independent authoritative read is needed for effect truth.