AIX 2.3 defines how canonical registries expose shared agent data through namespaces, scoped grants, lifetimes, resource scopes, obligations, audit records, and cross-agent handoff rules.

AIX 2.3 Addendum: Canonical Registry Contract #

AIX 2.3 is a sibling standard to AIX 2.2, not a replacement. AIX 2.2 governs field naming, hierarchical keys, validation tests, message envelopes, task types, and module manifests. AIX 2.3 adds the access contract for canonical registries: how shared agent data is namespaced, scoped, granted, audited, and handed across agent boundaries.

The migration path is additive. A field's camelCase name, hierarchy, and six-test validation result do not change when its namespace gains capability, tier, lifetime, resource-scope, or obligation metadata.

Canonical Registry Namespaces #

A namespace is a typed canonical store for a domain of ground facts. It is the single source of truth for that domain, versioned in place, read at dispatch time, and scoped so agents cannot silently drift into data they were not granted.

Namespace Rule	Meaning
Typed canonical store	The namespace has a declared domain, record shape, and owner.
Single source of truth	Agents read the registry rather than carrying private pinned copies.
Versioned in place	Records carry version and update metadata so reads can be audited.
Dispatch-time read	Agents retrieve current canonical facts when a task runs.
Scope-boundaried	Agents declare needed namespaces up front; expanding scope requires a new grant.

Five Orthogonal Axes #

AIX 2.3 defines registry access as a tuple of independent controls. Implementations should model these axes separately instead of folding constraints into ambiguous capability names or broad all-access tokens.

Axis	Purpose	Examples
Capability	What an agent may do in a namespace.	`records:read`, `records:write`, `schema:read`, `proposals:write`, `stream:read`
Tier	How sensitive the requested data is.	`public`, `professional`, `sensitive`
Lifetime	How long the grant survives.	`persistent`, `session`, `single-read`
Resource-scope	Which records or resource classes inside a namespace the grant covers.	specific base, category, profile section, record set, or document family
Obligations	Continuing conditions attached to use of the data.	`purpose-limitation`, `consent-required`, `human-approval-required`, `post-hoc-audit-required`, `redact-before-persist`, `session-only-use`, `no-further-forward`

Obligations have different enforcement modes. Pre-read gates and system-controlled storage paths can be enforced mechanically. Once a value enters an agent's free-text context, downstream-use obligations rely on agent compliance plus post-hoc audit. AIX 2.3 names that boundary directly instead of pretending every downstream constraint can be blocked technically.

Reserved Template Namespace #

New namespaces should be added by filling a standard template, then registering the namespace and its grant rules. The default shape is intentionally small so a new canonical registry is a configuration exercise before it becomes a design debate.

json

{
  "namespace_id": "{namespaceName}",
  "capabilities": ["records:read"],
  "tiers": ["public", "professional", "sensitive"],
  "lifetimes_supported": ["persistent", "session", "single-read"],
  "resource_scopes": ["{resourceClass1}", "{resourceClass2}"],
  "obligations": [],
  "audit_retention_days": 90,
  "issuance": "explicit-at-registration"
}

To add a namespace, clone the template, name the namespace, define its resource classes, narrow the allowed capabilities, tiers, lifetimes, or obligations if the domain requires stricter controls, then register the namespace through the governance process.

Cross-Agent Handoff #

Agent handoff must not become privilege escalation. When one agent hands work to another, the receiving agent does not inherit the sender's grants by default.

Handoff Path	Allowed Use	Constraint
Payload embedding	Public-tier values only.	Any obligations attached to the value travel with the payload.
Grant-forwarding transaction	Professional and Sensitive-tier values.	The receiving agent receives its own scoped, time-limited, audited grant.

Audit Contract #

Every canonical read should log agent identity, dispatch identity where available, namespace, resource, capability, maximum tier touched, grant type, timestamp, result, and obligation-fulfillment state. Results should distinguish success from denial by tier, capability, scope, lifetime, or obligation. Audit records should be retained for at least 90 days and exposed in a readable user-facing access trail.

Conformance Claims #

AIX 2.3 recognizes two levels of conformance.

Conformance Level	Requirement
INCUBATION-PROFILE conformance	The namespace shape is declared correctly, capabilities are enumerated, and a tier system is present.
Full conformance	All INCUBATION-PROFILE requirements, plus enforced lifetimes, resource scopes, audit records, explicit grant issuance, handoff controls, obligations, and denial paths in a running system.

Persona is an INCUBATION-PROFILE reference implementation for the tier axis only. It demonstrates per-field tier classification, but it is not a full AIX 2.3 reference implementation. Capability grants, namespace scopes, grant lifetimes, resource-scoped grants, obligation enforcement, and full audit logging remain full-conformance requirements.

Relationship to AIX 2.2 #

AIX 2.2 already established the naming discipline and module-manifest surface that AIX 2.3 extends. UMA platform keys introduced the need for registered capability and tier semantics; AIX 2.3 supplies the contract those future-facing keys require.

In short: AIX 2.2 names the fields and envelopes. AIX 2.3 governs how canonical registries expose them to agents safely.