Standard
A consensus document issued through a defined standards process.
Open standards and specifications index
Define the contract.
Verify the implementation.
A researched field guide to 36 dependable standards, protocols, specifications and governance frameworks shaping interoperable AI, cloud, browser graphics and spatial systems.
36RESEARCHED ENTRIES
04SYSTEM DOMAINS
Official primary sources
Revision and status disclosed
Last researched 01 Aug 2026
Shared language, explicit boundary
Interoperability begins
before integration.
A useful standard makes a boundary repeatable. It defines what producers and consumers may exchange, how implementations behave, and where conformance can be tested. It does not remove engineering judgement, operational ownership, security review or the need to govern revisions.
Six connected ideas
Know what the
document promises.
The directory distinguishes formal standards from specifications, protocols and implementation frameworks so a familiar name is never mistaken for complete assurance.
Specification
A normative contract for interfaces, formats, behavior or terminology.
Protocol
Rules governing communication, message order, state and failure.
Framework
A structured method for managing decisions, controls and evidence.
Implementation
Software that applies a contract, with its own support and limits.
Conformance
Observable evidence that an implementation meets stated requirements.
Specification lifecycle
From shared need to
tested contract.
A published revision is one moment in a continuing system. Good adoption accounts for maturity, errata, implementation evidence and the cost of change.
- 01
Frame
Define the boundary, actors and interoperability problem.
- 02
Specify
Write normative behavior, formats and extension points.
- 03
Review
Resolve implementer feedback, security and ambiguity.
- 04
Conform
Test observable requirements against shared fixtures.
- 05
Adopt
Deploy compatible implementations and operating policy.
- 06
Revise
Publish corrections and govern compatibility over time.
Standards system map
Every boundary needs
a shared language.
Four domains connect policy, interfaces, runtime behavior and portable artifacts. Most production systems need a composition from more than one domain.
AI and governance
Management systems, risk, terminology, lifecycle and impact.
10 entriesCloud, APIs and trust
Interfaces, events, telemetry, containers, identity and evidence.
10 entriesBrowser graphics and media
GPU access, shaders, immersive sessions, media and accessibility.
08 entriesSpatial and 3D systems
Scenes, assets, textures, materials, geospatial data and runtimes.
08 entriesStandards directory
Choose the contract
you can operate.
Filter by domain, publication state, document type and implementation surface. Each profile explains the current revision, the boundary it defines, what remains outside scope and where official conformance evidence exists.
No matching entries
Try another domain, publication state, document type, implementation surface or search term.
Boundary comparison
Compare contracts that
govern the same pressure.
Choose up to three compatible entries. The first selection establishes a shared decision boundary so unrelated governance, runtime and content specifications are not presented as substitutes.
0 of 3 selected
Standards composition
Standards work
as a stack.
A production boundary may depend on transport, schema, identity, telemetry, artifact and provenance contracts at once. Composition is strongest when each layer keeps a clear role.
- 01 / INTERFACE
- Describe the operation, message and expected behavior.
- 02 / SCHEMA
- Constrain the structure and meaning of exchanged data.
- 03 / TRUST
- Bind actors, permissions, software and evidence to policy.
- 04 / OBSERVABILITY
- Expose signals that prove the composed system behaves as intended.
Research method
A familiar name is not
implementation evidence.
Every entry is checked against a steward-maintained primary source. Publication state and revision are disclosed because living specifications, formal standards and operational frameworks carry different change and conformance models.
Use primary sources
Link to the official steward, normative document, registry or publication record.
Check the revision
Record the current published version and distinguish it from drafts or proposals.
State the boundary
Explain what the document defines and what remains an implementation decision.
Find conformance
Identify test suites, implementation reports, certification or documented self-assessment.
Expose dependencies
Show related contracts that complete the implementation and security model.
Date the evidence
Recheck status and guidance as stewards publish revisions, errata and extensions.
Research note: inclusion indicates practical relevance, not certification, legal advice or a claim that one document fully governs a production system.
Before adoption
Six questions before
the architecture record.
What boundary does it govern?
Name the producer, consumer, asset, interface or organizational process in scope.
Which revision is current?
Pin the implemented revision and record how errata and extensions are handled.
Is conformance testable?
Find shared tests, schemas, implementation reports or other observable evidence.
What remains outside scope?
Separate normative requirements from product behavior, policy and operating controls.
What else does it require?
Map transport, identity, schema, security and lifecycle dependencies.
How will revisions be governed?
Assign compatibility testing, upgrade windows, exceptions and retirement ownership.
Engineering the complete system
Choose the contract.
Build the evidence.
ADOR.IS designs software, AI, graphics and spatial systems around explicit interfaces, portable data, measurable conformance and operational ownership.
[email protected] ↗