Modality integration contract

This guide defines the stable responsibility boundary for teams building voice, visual, Braille, sign, tactile, switch, AAC, haptic, BCI, or future modality adapters. Component repositories own versioned wire schemas and implementation details. This contract owns the behavior that every adapter preserves.

The integration boundary

A modality adapter connects to Unison at two points:

The adapter translates. Identity, consent, policy, incident state, capability authority, and physical actuation remain with their owning platform services.

Intent input contract

An input contribution identifies or references:

Raw media and biological signals follow explicit retention and disclosure policy. Derived representations carry provenance back to their authorized source. The proposed interpretation remains evidence of intent until platform identity, policy, and confirmation establish authority.

Semantic outcome contract

A renderer receives the parts of meaning needed for its authorized expression:

The semantic outcome defines required meaning. The adapter chooses native organization, pacing, vocabulary, spatial arrangement, tactile structure, prosody, signing, haptics, or other modality-specific expression.

Capability declaration

Every adapter publishes a signed, versioned declaration covering:

The orchestrator and experience composer use this declaration when selecting an eligible route. Eligibility also requires applicable identity, policy, compatibility, support, and evidence.

Confirmation and recovery

A person must be able to understand the interpreted intent, material consequences, recipients, disclosures, cost, reversibility, and recovery before a sensitive action proceeds. The adapter provides native controls for confirm, revise, cancel, pause, and request assistance when those operations are present in the semantic outcome.

Loss of a device or modality preserves the pending semantic state. Another authorized modality can continue the experience at the appropriate assurance level. Expired confirmation returns to a reviewable state.

Equivalent understanding

A conforming adapter preserves:

Native experiences can differ in sequence, density, pacing, and representation. Conformance evaluates whether the person can reach equivalent understanding and exercise equivalent control.

Test and evidence requirements

Each adapter provides:

  1. schema and compatibility tests;
  2. semantic golden journeys for input and output;
  3. identity, assurance, consent, and policy-boundary tests;
  4. replay, spoofing, prompt-injection, and malformed-input tests;
  5. privacy minimization, retention, and disclosure tests;
  6. confirmation, cancellation, interruption, and recovery tests;
  7. offline, latency, failure, and modality-transition tests;
  8. representative-device measurements;
  9. forced-colors, reduced-motion, reflow, and keyboard checks where applicable;
  10. participatory evaluation with people who use the modality; and
  11. incident, maintenance, rollback, and revocation procedures.

Evidence is labeled unit, simulation, hosted CI, physical hardware, or participatory. A supported claim requires the evidence classes defined by the owning compatibility and release policy.

Contributor workflow

  1. Read the semantic experience and intent contracts in the owning component.
  2. Declare the adapter capabilities, data path, authority limits, and evidence target.
  3. Implement the narrow input or expression translation.
  4. Add semantic golden journeys and adversarial boundary tests.
  5. Validate transitions to at least one other modality.
  6. Record device, environment, checks, limitations, and evidence.
  7. Publish the component commit before updating any workspace gitlink.
  8. Submit compatibility and support claims through the project evidence process.

Find component repositories and review testing guidance.