The runtime directory is a structured research catalog. It records primary and secondary categories, covered layers, deployment and hardware targets, capabilities, status, sources, caveats, and a UTC verification timestamp. It is not a leaderboard.
Key takeaways
- Filter by responsibility and deployment need.
- Read caveats and version scope before treating a field as current.
- Submit corrections with authoritative sources.
Runtime directory
[ar_directory]
Data model
Each record supports name, canonical URL, maintainer, open-source/commercial status, license, primary and secondary categories, runtime layers, model formats, frameworks, hardware and deployment targets, distributed and quantization capabilities, protocols, browser/edge support, agentic capabilities, observability, governance, repository, status, version scope, UTC verification, authoritative sources, and caveats.
[ar_downloads file=”aruntime-runtime-directory-entry.schema.json”]
Verification
Fields are sourced from official documentation, specifications, repositories, or release notes where possible. “Not recorded” and caveat text are preferred to inference. Verification applies to the named documentation state and should be repeated after material releases.
Limits
A directory record does not prove performance, security, fitness, or compatibility for a specific deployment. Products can span layers, and implementations change. Use the selection guide and a workload-specific evaluation.