Skip to content

Charter (Layer 0)

Status: v0.1 (Draft)
Scope: This Charter defines the purpose, boundaries, and publication posture of the Addressable Intelligence Commons (AIC).
Normative language: The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.

0.1 Purpose

The Addressable Intelligence Commons (AIC) exists to publish a minimal, vendor-neutral, standards-oriented semantic and normative layer that enables interoperable interaction among addressable intelligent actors across heterogeneous network substrates.

AIC focuses on shared meaning, declarations, and conformance language required for predictable integration, without prescribing transport, deployment model, or implementation architecture.

0.2 Scope (Layers 0–1.5)

For v0.1, AIC is limited to:

  • Layer 0: charter, principles, non-goals, and publication posture.
  • Layers 1.0–1.5: minimal interaction semantics, capability and governance declarations, and continuity artifacts (definitions and requirements), expressed in a transport-agnostic manner.

AIC documents MAY include informative profiles that illustrate how the semantics can be realized over common substrates (e.g., HTTP+JSON), but such profiles MUST NOT be required for conformance unless explicitly designated as normative.

0.3 Principles

AIC publications MUST adhere to the following principles:

  1. Interoperability first: Prefer definitions and requirements that enable independent implementations to interoperate with minimal coordination.
  2. Minimalism: Specify the smallest set of concepts that materially reduce ambiguity in interaction.
  3. Transport neutrality: Do not mandate a wire protocol, endpoint structure, SDK, or hosting model.
  4. Vendor neutrality: No proprietary control points, exclusive registries, or paywalled dependencies.
  5. Federation and voluntary participation: Adoption is voluntary; AIC provides shared language, not enforcement.
  6. Clarity and testability: Normative statements SHOULD be auditable and testable through observable behavior and published declarations.
  7. Compatibility with existing standards: Where appropriate, reuse or align with established terminology and mechanisms (e.g., media types, RFC 2119 language) without claiming to supersede them.

0.4 Non-goals (explicit exclusions)

AIC MUST NOT define, require, or imply:

  • A platform, hosted service, marketplace, or centralized coordination service.
  • An “agent framework” architecture, runtime, or orchestration system.
  • Application or UI design patterns, product requirements, or end-user workflows.
  • Reputation systems, scoring, blacklists, enforcement mechanisms, or coercive compliance.
  • A global identity regime or mandatory identity provider.
  • A mandatory registry or naming authority (beyond what is necessary to reference documents and versions).
  • A comprehensive safety policy; only the minimal governance declarations needed for interoperability are in scope.

0.5 Publication posture and document types

AIC publishes documents in two categories:

  • Normative: defines requirements for conformance and interoperability.
  • Informative: provides examples, profiles, and explanatory guidance.

Each document MUST clearly identify whether it is normative or informative. Within documents, normative requirements MUST be stated using RFC 2119 keywords.

All normative definitions MUST be: - versioned, - stable enough to implement, - and designed to evolve conservatively.

0.6 Conformance claims

An implementation claiming conformance to AIC MUST:

  • state the AIC version it conforms to, and
  • state the highest layer it supports (e.g., “AIC v0.1 Layers 1.0–1.3”).

Implementations MUST NOT claim conformance to layers they do not implement. Partial conformance MUST be expressed only as support for a contiguous prefix of layers unless a future AIC conformance document specifies otherwise.

(See Conformance for precise requirements.)

0.7 Governance and change control (minimal)

AIC evolves through public iteration on published documents.

Changes to normative content MUST:

  • preserve backward compatibility when feasible,
  • clearly identify breaking changes,
  • and be accompanied by rationale sufficient for implementers to assess impact.

AIC does not grant any party special rights to control implementations. The Commons is defined by its public documents and their open revision history.

0.8 IANA / registry posture (none required)

AIC v0.1 does not require any IANA assignments or centralized registries. If future work identifies a need for registries, they MUST be optional, federatable, and not required for basic interoperability.

0.9 Security and privacy considerations (charter-level)

AIC documents MUST acknowledge that:

  • intelligent actors may process sensitive data,
  • deployments vary widely in trust boundaries,
  • and interoperability requires explicit disclosure of relevant boundaries.

Accordingly, AIC layers in scope MAY require actors to declare limited governance-relevant properties (e.g., retention posture, refusal categories) sufficient for counterparties to make informed integration decisions, without mandating enforcement mechanisms.

Next: Interaction Semantics (Layers 1.0–1.5)