Skip to content

Conformance

Status: v0.1 (Draft)
Type: Normative
Normative language: The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.

1. Overview

This document defines how an implementation (an “actor”) makes a conformance claim to the Addressable Intelligence Commons (AIC) for v0.1, and the minimum observable requirements associated with Layers 1.0–1.5.

AIC conformance is intentionally limited to: - semantic interoperability requirements, - required published declarations, - and minimal continuity semantics (optional unless claimed).

AIC conformance does not imply certification, endorsement, or enforcement.

2. Conformance claim format (required)

An actor claiming conformance MUST publicly state:

  • AIC version (e.g., 0.1)
  • Supported layer range as a contiguous prefix starting at Layer 1.0 (e.g., 1.0-1.3)

An actor MUST NOT claim support for any layer it does not implement.

An actor SHOULD provide a link (or retrieval method) to its Actor Description.

2.1 Example claim (informative)

Conforms to AIC v0.1, Layers 1.0–1.3. Actor Description: https://example.org/aic/actor.json

3. Layer conformance requirements

3.1 Layer 1.0 conformance (Acts & Dispositions)

An actor conforming to Layer 1.0 MUST:

  1. Support required acts: Accept messages explicitly labeled as one of:
  2. INFORM, ASK, REQUEST, PROPOSE
  3. Return required dispositions: For each message, produce a response that can be classified as exactly one of:
  4. ACCEPTED, REFUSED, DEFERRED, COMPLETED, FAILED
  5. Provide minimal response payload:
  6. include the disposition, and
  7. include a result for COMPLETED, or
  8. include a refusal/error category for REFUSED/FAILED, or
  9. include a deferral indication for DEFERRED

An actor MAY infer acts as a convenience, but MUST support explicitly labeled acts.

3.2 Layer 1.1 conformance (Capability Declaration)

An actor conforming to Layer 1.1 MUST:

  • publish a Capability Declaration that includes at least:
  • actor identifier (actor_id)
  • supported acts
  • supported input/output representations
  • interaction modes (sync, deferred, or both)
  • material limits (or unspecified)
  • document how the declaration is retrieved.

3.3 Layer 1.2 conformance (Qualifiers)

Layer 1.2 is optional unless claimed.

If an actor claims Layer 1.2 conformance, it MUST: - publish which qualifiers it supports, and - implement the semantics of each supported qualifier as defined in Interaction Semantics (Layers 1.0–1.5).

An actor MUST NOT claim support for a qualifier it does not implement.

3.4 Layer 1.3 conformance (Governance Declaration)

An actor conforming to Layer 1.3 MUST:

  • publish a Governance Declaration that includes at least:
  • retention posture
  • refusal categories
  • authority boundaries
  • human escalation posture (if applicable)
  • ensure refusal/error categories emitted in REFUSED/FAILED responses are drawn from the published refusal categories (or a clearly versioned successor set).

3.5 Layer 1.4 conformance (Coordination Semantics)

Layer 1.4 is optional unless claimed.

If an actor claims Layer 1.4 conformance, it MUST:

  • support correlation identifiers or explicitly state that it does not.
  • if correlation identifiers are supported:
  • echo the correlation identifier in responses when provided by the sender.
  • if idempotency is claimed:
  • document how idempotency is expressed and what guarantees are provided.

3.6 Layer 1.5 conformance (Continuity Artifacts)

Layer 1.5 is optional unless claimed.

If an actor claims Layer 1.5 conformance, it MUST:

  • support producing and consuming continuity artifacts as specified:
  • commitments (when provided) MUST include: identifier, scope, conditions/assumptions, and expected completion signal if applicable.
  • receipts (when provided) MUST include: identifier, reference to request and/or commitment, final disposition (COMPLETED or FAILED), and result/error details.

If the actor issues continuity artifact references, it MUST ensure their stability for at least the period declared by its retention posture.

4. Profiles and transport mappings

An actor MAY publish one or more profiles (informative or normative) that map AIC semantics onto a specific substrate (e.g., HTTP).

If an actor requires a profile for interoperability in its environment, it MUST: - publish the profile, and - state clearly whether it is required for interaction with that actor.

AIC v0.1 itself does not require any specific profile.

5. Versioning and compatibility

An actor MUST treat its conformance claim as versioned:

  • If the actor changes the meaning of any declared field, act handling, or disposition mapping in a way that can break clients, it SHOULD:
  • update its Actor Description updated_at, and
  • document the change in a public changelog.

Actors SHOULD support backward-compatible evolution of representations and declarations when feasible.

6. What conformance does not mean

AIC conformance MUST NOT be interpreted as: - security assurance, - privacy assurance, - safety certification, - legal compliance, - or a guarantee of availability, correctness, or performance.

AIC defines shared semantics and declarations only.

Next: Glossary