Skip to content

v2.0 / v3.0 Candidate Capability Matrix (Draft)

This is review material, not a frozen compatibility commitment. The table does not change the existing v2.0 public semantics.

Capability areav2.0 frozen positionCurrent Java Runtime evidencev3.0 status
TM/QM semantic corePublished semantic layer, query DSL, and model referencesbridge engine/catalog/model SPIRetain; version mapping required
Single-model queryGoverned structured querydataset.query_model, Runtime query routesCandidate stable
Compose/cross-modelv2 capability as documenteddataset.compose_script, Compose APICandidate; boundary to freeze
DSL_CTE / Pivot / timeWindowLayered capabilities in v2 documentsExposed by schema/capabilities per versionMust not be claimed universally
Model discoveryLegacy metadata entry pointdataset.list_models preferred; get_metadata legacyRecommended upgrade
ExplainNot defined as a historical execution tracedataset.explain_query and Runtime explainEvidence semantics to freeze
NamespaceExisting implementation/integration boundaryX-NS, binding, catalog isolationCandidate public contract
Authoring workspaceNot a v2 core commitmentworkspace, candidate, publish/recoverCandidate; production scope required
Release/promotion/rollbackNot a uniform v2 core contractrelease package and promotion routesCandidate; recovery semantics required
AuthorizationModel/host boundarymanagement code, opaque Authorization, QM/TM policiesPublic security closure required
AI ProviderImplementation/deployment dependentstructured tools without Provider, NL conditionalCandidate tiering
ChartsHistorical tool name in older docsXChart/ECharts splitNames and dependency docs must change
Remote datasources/addonsNot automatically corespecific addon evidence onlyKeep conditional

Freeze evidence fields

Before freeze, each row needs an implementation version, minimum validation command, failure semantics, audit fields, compatibility strategy, Chinese/English owner, and publication date. Rows without that evidence remain candidates.