Skip to content

Interaction Semantics (Layers 1.0–1.5)

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 the minimal semantic and normative layer for interoperable interaction among addressable intelligent actors (“actors”). It is transport-agnostic: it specifies meaning and required disclosures, not a wire protocol.

AIC interaction is described using: - Acts (what the sender is doing by sending a message), - Dispositions (how the receiver responds in terms of acceptance/refusal/deferral/outcome), - Capability and governance declarations (what an actor can do and under what stated boundaries), - Continuity artifacts (optional but standardized concepts for multi-step work).

1.1 Conformance target

An actor conforms to AIC Layers 1.0–1.5 at v0.1 if it: - implements the required acts and required dispositions (Layer 1.0), - publishes a capability declaration meeting Layer 1.1 requirements, - publishes a governance declaration meeting Layer 1.3 requirements, - and, if it claims Layer 1.5 support, produces and consumes continuity artifacts as specified.

2. Definitions

  • Actor: An addressable system that can receive messages and produce responses.
  • Message: A unit of communication from a sender to a receiver, expressed in some representation.
  • Act: The semantic intent of a message (e.g., asking a question vs requesting an action).
  • Disposition: A receiver’s semantic response category (e.g., accepted, refused, deferred).
  • Representation: The concrete format used to encode message content (e.g., JSON, text).
  • Capability declaration: A published statement describing what an actor supports.
  • Governance declaration: A published statement describing boundaries relevant to integration.
  • Continuity artifact: A structured concept representing ongoing work (e.g., a commitment or receipt).

3. Layer 1.0 — Acts and Dispositions

3.1 Required acts

An AIC-conformant actor (Layer 1.0) MUST support receiving messages that are explicitly labeled with one of the following acts:

  1. INFORM — Provide information for consideration; no response is required beyond acknowledgement or error.
  2. ASK — Request information (a question).
  3. REQUEST — Request the receiver to perform an action and/or produce an output.
  4. PROPOSE — Propose a plan, terms, or next step for acceptance or revision.

An actor MAY support additional acts, but MUST NOT redefine the meaning of the required acts.

3.1.1 Act labeling requirement

For interoperability, an actor MUST provide a way to determine the act of an incoming message by at least one of: - an explicit act field in the message representation, or - an unambiguous mapping defined in a published profile.

If act inference is used as a convenience, the actor MUST still be able to process explicitly labeled acts, and MUST document any inference behavior as non-normative convenience (i.e., not required of counterparties).

3.2 Required dispositions

For each received message, an actor MUST produce a response that can be classified into exactly one of the following dispositions:

  1. ACCEPTED — The actor will comply with the act as understood (possibly with conditions stated).
  2. REFUSED — The actor will not comply.
  3. DEFERRED — The actor is not completing the request now (e.g., queued, needs more info, or asynchronous).
  4. COMPLETED — The actor has completed the requested work and is returning results.
  5. FAILED — The actor attempted to comply but could not complete due to an error condition.

An actor MAY provide additional structured outcome detail, but MUST map outcomes to one of the required dispositions.

3.2.1 Disposition constraints

  • A response MUST NOT be simultaneously classified as multiple dispositions.
  • A response SHOULD include enough information for the sender to distinguish REFUSED vs FAILED vs DEFERRED.
  • If DEFERRED, the response SHOULD indicate what is needed to proceed (e.g., missing inputs) or how/when to check status, if such a mechanism exists.

3.3 Minimal response payload requirements

A Layer 1.0 actor response MUST include: - the disposition, and - either a result (for COMPLETED), or an error/refusal rationale category (for REFUSED/FAILED), or a deferral indication (for DEFERRED).

Free-text explanations MAY be included but SHOULD NOT be the only machine-actionable signal.

4. Layer 1.1 — Capability Declaration (minimal)

An actor claiming Layer 1.1 support MUST publish a capability declaration that includes, at minimum:

  • Actor identifier: a stable identifier within the actor’s chosen addressing scheme.
  • Supported acts: which of the required acts are supported (MUST include all required acts for Layer 1.0 conformance; MAY include extensions).
  • Supported representations: the representations the actor can receive and produce (e.g., text/plain, application/json), expressed in a way that can be matched by clients.
  • Interaction modes: whether the actor supports synchronous completion, deferral/asynchronous completion, or both.
  • Limits: any material constraints that affect interoperability (e.g., maximum input size, supported languages) expressed as coarse, implementation-declared limits.

The declaration MUST be retrievable via a documented method appropriate to the substrate (e.g., a well-known URL path in an HTTP profile). AIC does not mandate the retrieval mechanism at Layer 1.1.

5. Layer 1.2 — Pragmatic Qualifiers (minimal)

AIC defines optional qualifiers that shape how a request should be handled without changing the act itself.

An actor MAY support any subset of these qualifiers, but if it claims support for a qualifier, it MUST follow the stated meaning.

5.1 Qualifier: PRIORITY

Indicates relative urgency. Values are implementation-defined but MUST be documented (e.g., low|normal|high).

5.2 Qualifier: TIME_CONSTRAINT

Indicates a time bound (deadline or maximum duration). If the actor cannot meet it, it SHOULD respond with DEFERRED (with alternative timing) or REFUSED.

5.3 Qualifier: OUTPUT_PREFERENCE

Indicates preferences for representation or structure of outputs. If unsupported, the actor SHOULD return the closest supported representation and indicate the representation used.

6. Layer 1.3 — Governance Declaration (minimal)

An actor claiming Layer 1.3 support MUST publish a governance declaration that includes, at minimum:

  • Retention posture: a coarse statement of whether and how the actor retains inputs/outputs (e.g., “no retention beyond processing”, “retained for debugging for N days”, “retained until deleted”), as declared by the operator.
  • Refusal categories: a stable set of refusal category labels the actor may return (e.g., policy, safety, legal, capability, auth, rate_limit). The specific set is implementation-defined but MUST be published.
  • Authority boundaries: a coarse description of what the actor is authorized to do (e.g., “read-only access to system X”, “may initiate outbound requests to domains Y”), expressed as declarations rather than enforcement mechanisms.
  • Human escalation (optional): whether requests may be handed to a human operator, and under what declared conditions.

The governance declaration is an interoperability artifact: it enables informed integration decisions. It MUST NOT be treated as a guarantee of enforcement.

7. Layer 1.4 — Coordination Semantics (minimal)

AIC defines minimal semantics for coordination without mandating a transport.

7.1 Correlation identifiers

An actor SHOULD support a correlation identifier that allows a sender to relate responses to requests across multi-message exchanges. If supported, the actor MUST echo the correlation identifier in responses.

7.2 Idempotency (declared)

If an actor supports idempotent handling for REQUEST acts, it MUST document how idempotency is expressed (e.g., an idempotency key) and what guarantees are provided.

AIC does not require idempotency support, but requires that any claimed behavior be documented.

8. Layer 1.5 — Continuity Artifacts (minimal)

Continuity artifacts standardize the meaning of “work in progress” without requiring a job system.

8.1 Commitment

A commitment is an actor statement that it intends to perform specified work under stated conditions.

If an actor returns ACCEPTED for a REQUEST and the work is non-trivial or deferred, it SHOULD provide a commitment.

If provided, a commitment MUST include: - a commitment identifier, - the scope of work (human-readable at minimum; machine-readable if supported), - any stated conditions or assumptions, - and (if applicable) an expected completion signal (e.g., “will return a receipt”).

8.2 Receipt

A receipt is an actor statement that work has completed (successfully or not) for a referenced commitment or request.

If an actor supports receipts, a receipt MUST include: - a receipt identifier, - a reference to the relevant request and/or commitment identifier, - the final disposition (COMPLETED or FAILED), - and any result references or error details.

8.3 Continuity references

Actors MAY return references to continuity artifacts in responses. If they do, those references MUST be stable for at least the period declared in the governance declaration (retention posture).

9. Error and refusal categorization (minimal)

When responding with REFUSED or FAILED, an actor MUST provide a category label.

  • Categories MUST be drawn from the actor’s published refusal categories (Layer 1.3).
  • Categories SHOULD be stable over time; changes SHOULD be versioned in the governance declaration.

10. Extensibility

Actors MAY extend AIC by adding: - additional acts, - additional qualifiers, - additional dispositions (as long as they map to one required disposition), - additional declaration fields.

Extensions MUST NOT change the meaning of required terms. Extensions SHOULD be namespaced or otherwise clearly distinguished to avoid collisions.

11. Security and privacy considerations

This specification intentionally avoids prescribing enforcement mechanisms. Implementers SHOULD: - treat governance declarations as disclosures, not guarantees, - avoid embedding sensitive data in correlation identifiers or continuity artifact identifiers, - and document any data retention and human escalation posture clearly.

Next: Actor Description (Capability & Governance Declarations)