# Semantic Layer × AI

CURRENT_STATUS: UNKNOWN
OBSERVATION: SPEC_ONLY
FRESHNESS: UNKNOWN
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-068-semantic-layer-ai
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-068-URL-D34C8A1E96F5, EVD-EA-068-URL-0D9A9D0851F4, EVD-EA-068-URL-AB71C485E37C, EVD-EA-068-URL-3667935FF461, EVD-EA-068-URL-4827824FD91B, EVD-EA-068-URL-ADADB672F620, EVD-EA-068-URL-1913780EA4D1, EVD-EA-068-URL-94A1C139819B, EVD-EA-068-URL-405387DEAAB7, EA-068-R11-RESEARCH, EA-068-R11-WEB-READBACK
UNKNOWN_IDS: EA-068-UNKNOWN-01, EA-068-UNKNOWN-CURRENTNESS
OPS_IDS: none

## Summary
「Enterprise AIの分析では、LLMを生のデータベースschemaへ直接接続するより、組織が定義したmetrics・dimensions・relationships・access rulesを持つsemantic layerを介在させると、AIが推測しなければならない業務意味を減らし、定義をversion管理・監査・評価しやすくできる。これは回答正確性の保証ではない。semantic model自体の誤り・不足・陳腐化、権限設定、raw SQL等のbypass経路、LLMの質問解釈・query生成誤りは別途評価する必要がある。」

## Current judgment
F1 VERIFIED_SPEC/OSS_PRACTICE: semantic layer can encode business concepts above physical schema: metrics, dimensions, entities/relationships/join paths and, depending on implementation, access policy. Current Snowflake and Cube implementations expose these semantics directly to AI/NL analytics.
F2 INFERENCE: the architectural value is not “LLM becomes correct” but “business meaning becomes an explicit, versionable, reviewable dependency rather than an implicit LLM inference.” This is the safe Core abstraction.
F3 VERIFIED_SPEC: Snowflake semantic views are native schema-level governed objects; generated SQL still executes under database privileges. Semantic guidance and authorization are separate controls.
F4 SOURCE_REPORT/OSS_PRACTICE: Cube demonstrates a semantic runtime where AI queries are validated and access policy is applied before warehouse execution; however Cube also documents raw Source SQL paths that bypass the layer. Therefore enforcement must be architectural, not assumed from product presence.
F5 RESEARCH: Spider 2.0 establishes that enterprise text-to-SQL over complex raw data remains difficult. dbt Labs' semantic-layer benchmark provides direct comparative evidence but is small/domain-specific and also documents expressiveness failures (“too many hops”).
F6 SOURCE_REPORT: OSI shows active movement toward vendor-neutral semantic interchange, but interoperability is not yet evidence that metric semantics, security, dialect behavior or execution results are identical across implementations.

## Scope
Enterprise AI Core / Data / governance / implementation / interoperability / benchmark / provider mapping。EA-066 Identity-aware ACL-aware RAGとはaccess enforcement、EA-067 Knowledge Freshness Engineeringとはsemantic definition freshness、EA-015監査証跡とはgenerated query・semantic version・actorのprovenanceで接続する。

## Confirmed
- F1 VERIFIED_SPEC/OSS_PRACTICE: semantic layer can encode business concepts above physical schema: metrics, dimensions, entities/relationships/join paths and, depending on implementation, access policy. Current Snowflake and Cube implementations expose these semantics directly to AI/NL analytics.
F2 INFERENCE: the architectural value is not “LLM becomes correct” but “business meaning becomes an explicit, versionable, reviewable dependency rather than an implicit LLM inference.” This is the safe Core abstraction.
F3 VERIFIED_SPEC: Snowflake semantic views are native schema-level governed objects; generated SQL still executes under database privileges. Semantic guidance and authorization are separate controls.
F4 SOURCE_REPORT/OSS_PRACTICE: Cube demonstrates a semantic runtime where AI queries are validated and access policy is applied before warehouse execution; however Cube also documents raw Source SQL paths that bypass the layer. Therefore enforcement must be architectural, not assumed from product presence.
F5 RESEARCH: Spider 2.0 establishes that enterprise text-to-SQL over complex raw data remains difficult. dbt Labs' semantic-layer benchmark provides direct comparative evidence but is small/domain-specific and also documents expressiveness failures (“too many hops”).
F6 SOURCE_REPORT: OSI shows active movement toward vendor-neutral semantic interchange, but interoperability is not yet evidence that metric semantics, security, dialect behavior or execution results are identical across implementations.

## UNKNOWN
- EA-068-UNKNOWN-01: provider横断で同一metric definitionが同一結果を保証するconformance水準。OSIのpublication時点spec/version/converter coverage。semantic-layer変更からAI回答へのpropagation latency。semantic metadataへのprompt injection/poisoning耐性。複雑なnon-additive/semi-additive metric、temporal semantics、multi-hop relationshipの各製品限界。
- EA-068-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。

## Evidence
- EVD-EA-068-URL-D34C8A1E96F5 (RESEARCH): org: Snowflake — https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst
- EVD-EA-068-URL-0D9A9D0851F4 (RESEARCH): org: Snowflake — https://docs.snowflake.com/en/user-guide/views-semantic/overview
- EVD-EA-068-URL-AB71C485E37C (RESEARCH): org: Snowflake — https://docs.snowflake.com/en/en/user-guide/snowflake-cortex/cortex-analyst/cortex-analyst-routing-mode
- EVD-EA-068-URL-3667935FF461 (RESEARCH): org: Cube — https://docs.cube.dev/docs/introduction
- EVD-EA-068-URL-4827824FD91B (RESEARCH): org: Cube — https://docs.cube.dev/docs/explore-analyze/workbooks/index
- EVD-EA-068-URL-ADADB672F620 (RESEARCH): canonical URL: https://docs.cube.dev/docs/explore-analyze/workbooks/index ; — https://docs.cube.dev/docs/explore-analyze/workbooks/source-sql-tabs
- EVD-EA-068-URL-1913780EA4D1 (RESEARCH): org: Open Semantic Interchange community — https://open-semantic-interchange.org/
- EVD-EA-068-URL-94A1C139819B (RESEARCH): org/authors: Fangyu Lei et al. — https://arxiv.org/abs/2411.07763
- EVD-EA-068-URL-405387DEAAB7 (RESEARCH): org: dbt Labs — https://dbt-labs.github.io/dbt-llm-sl-bench/
- EA-068-R11-RESEARCH (RESEARCH): EA-068 監査済みresearch / canonical revision binding
- EA-068-R11-WEB-READBACK (IMPL): EA-068 Web body identity / canonical readback

## Failure / limits
Semantic layer can encode a wrong metric, stale business rule, incorrect relationship, unsafe access rule, or incomplete domain. It can make an error consistently repeatable rather than correct it.
## Failure / limits
Coverage gap: if a required measure/join/domain is absent, the agent may fail, refuse, or seek a bypass. dbt benchmark explicitly documents unexpressible “too many hops” cases before extra modeling.
## Failure / limits
Bypass gap: raw SQL, direct warehouse credentials, alternate tools/MCP servers, notebooks, exports, cached extracts or shadow semantic models can evade the governed layer.
## Failure / limits
Authorization gap: semantic definitions and database privileges are distinct. A semantically valid query can still be unauthorized; conversely a technically authorized raw-table query may violate intended business abstraction.
## Failure / limits
Freshness gap: warehouse data freshness and semantic-definition freshness are separate. Metric definition changes require version/provenance and regression testing.
## Failure / limits
LLM gap: correct semantic metadata does not guarantee correct question interpretation, filter choice, time window, query generation, execution or narrative explanation.
## Failure / limits
Interoperability gap: OSI portability is an active specification effort; do not claim universal vendor-neutral equivalence without versioned converter/conformance evidence.
## Failure / limits
EA-068の更新準備として、(a) current implementationが複数系統で存在、(b) raw-schema text-to-SQLの限界、(c) semantic-layer自身のcoverage/bypass/freshness/authorization failure envelope、(d) interoperabilityの現状、(e)後続paired TEST_PROFILEが揃ったため本RUNをbounded completeとする。UNKNOWNは推測で閉じず後続Workへ渡す。

---
## Practice
Snowflake: account/region/model availability, required CORTEX roles, semantic-view privileges and underlying table SELECT; preview features must be rechecked as-of publication update. Cube: Cube/Core/Cloud feature split, deployment configuration, API/MCP availability, JWT/security context and access-policy setup. dbt benchmark/MetricFlow: product/version and model coverage must be pinned before product claims. OSI: specification version and participating implementations/converters must be revalidated.
## Practice
MATURE PATTERN / PRODUCT-SPECIFIC IMPLEMENTATIONS EXIST. Snowflake has native Semantic Views integrated with Cortex Analyst/Agents and SQL; Cube has an open-source semantic-layer foundation and AI-facing query surfaces. Cross-vendor portable semantic interchange is EMERGING rather than closed. A universal Enterprise AI semantic contract remains PROPOSAL.
## Practice
Use three distinct evaluation layers:
A) semantic correctness: metric formula, grain, join path, dimension/filter/time semantics;
B) execution correctness: generated query result equals golden result under authorized principal;
C) answer correctness: final narrative/number/citation faithfully represents result.
Required paired fixture: same 30-100 business questions against (1) raw schema path and (2) semantic path, same model/version/temperature where possible. Include ambiguous synonyms, metric-definition conflicts, multi-hop joins, row-level security, unsupported questions, stale metric version, and attempted bypass. Track execution accuracy, metric-selection accuracy, unauthorized-result rate, abstention quality, latency/cost, semantic-model coverage and regression after semantic changes. Spider 2.0 is external context, not a product guarantee. dbt LLM Semantic Layer Benchmark is useful comparative evidence but too small to generalize alone.
## Practice
enforce warehouse least privilege plus semantic-layer policy; prohibit or separately authorize raw-SQL bypass. Semantic metadata itself can reveal sensitive table/metric names and business logic.
AUDIT: record principal, question, model/version, semantic-model/view ID+version/hash, generated query, executed query, referenced metrics/dimensions, policy decision, result/error and final answer provenance.
## Practice
Coreへ「Semantic Contract」を追加候補: metric/dimension/entity/relationship/grain/filter/time semantics/access policy/owner/version/effective_at/deprecated_at/source lineage。
## Practice
provider mappingはSnowflake Semantic Views+Cortex、Cube Semantic Layer/AI、dbt Semantic Layer/MetricFlowをversioned comparisonし、Microsoft Fabric/Power BI semantic model、Looker/LookML等は追加採集候補として別bounded unitで照合する。
## Practice
OSIはinteroperability節へ置き、publication時のspec version、converter実装、conformance/test statusを再採集する。
## Practice
paired benchmarkをTEST_PROFILEとして実施し、raw schema vs semantic pathを同一fixtureで比較する。
## Practice
raw SQL / alternate tool / notebook / exportのbypass inventoryを必須化し、「semantic layer adopted」と「semantic layer enforced」を分離する。
## WHY_THIS_MATTERS_TO_UPDATE
Enterprise AIで自然言語→SQLを許す場合、物理schemaだけでは「売上」「アクティブ顧客」「粗利」等の業務定義、正しいjoin path、粒度、集計式、アクセス制御を十分に表せない。semantic layerはLLMの能力を上げる機構ではなく、AIが推測すべき業務意味を減らし、metrics/dimensions/relationships/access policyをgoverned interfaceとして提供する実装層になり得る。EA-068では「semantic layerを通せば正しい」という製品保証ではなく、raw schema直結より統制可能な分析面を作る設計原則として扱う。

## SCOPE_ROUTING
Enterprise AI Core / Data / governance / implementation / interoperability / benchmark / provider mapping。EA-066 Identity-aware ACL-aware RAGとはaccess enforcement、EA-067 Knowledge Freshness Engineeringとはsemantic definition freshness、EA-015監査証跡とはgenerated query・semantic version・actorのprovenanceで接続する。

## CLAIM_OR_RESEARCH_QUESTION
Q1. AI分析をraw DB/schemaへ直接接続する代わりにsemantic layerを介在させると、business metric・join・dimension・access ruleを明示的に統制できるか。
Q2. current productsはsemantic model/viewをAI agent / natural-language analyticsの実行面として実装しているか。
Q3. semantic layerはtext-to-SQLの正確性を保証するか。それともerror surfaceを縮小するだけか。
Q4. semantic modelのversion、権限、freshness、bypass経路をどう監査すべきか。

## EVIDENCE TABLE
1) source class: official product documentation
exact title: Cortex Analyst | Snowflake Documentation
org: Snowflake
canonical URL: https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst
publication/update: current documentation; access 2026-09-15
version/release: current as-of access; Semantic Views recommended, legacy staged YAML supported for backward compatibility
supporting locator: Understanding Semantic Views / Why use Semantic Views / Access control requirements / Security and governance
label: VERIFIED_SPEC + PRODUCT_VOLATILE
relation: support + limit
finding: Semantic Views define logical tables, dimensions, facts, metrics and relationships; Cortex Analyst uses them for NL→SQL. Generated SQL executes in Snowflake and underlying table SELECT privileges/RBAC apply. Semantic view/model metadata aids SQL generation; semantic views are recommended for new implementations.


2) source class: official product documentation
exact title: Overview of semantic views
org: Snowflake
canonical URL: https://docs.snowflake.com/en/user-guide/views-semantic/overview
publication/update: current documentation; access 2026-09-15
version/release: current as-of access
supporting locator: Interfaces for working with Semantic Views / getting started
label: VERIFIED_SPEC + PRODUCT_VOLATILE
relation: support + implementation
finding: Semantic Views are schema-level objects containing business metrics, entities and relationships; usable by Cortex Agents, Cortex Analyst REST API and direct SQL SELECT, and shareable through Snowflake mechanisms.


3) source class: official product documentation
exact title: Routing Mode for Cortex Analyst
org: Snowflake
canonical URL: https://docs.snowflake.com/en/en/user-guide/snowflake-cortex/cortex-analyst/cortex-analyst-routing-mode
publication/update: current documentation; access 2026-09-15
version/release: Preview Feature — Open; PRODUCT_VOLATILE
supporting locator: Routing Mode overview / permissions note
label: VERIFIED_SPEC + PRODUCT_VOLATILE
relation: support + limit
finding: routing mode uses semantic views so metrics, joins and filters follow governed definitions; documentation explicitly states routing mode does not change permissions, which remain standard Snowflake privileges.


4) source class: author-maintained product/OSS documentation
exact title: Introduction - Cube Documentation
org: Cube
canonical URL: https://docs.cube.dev/docs/introduction
publication/update: current documentation; access 2026-09-15
version/release: current docs; Cube Core open-source semantic layer
supporting locator: Semantic SQL / semantic layer architecture / access control / APIs
label: OSS_PRACTICE + SOURCE_REPORT + PRODUCT_VOLATILE
relation: support + implementation
finding: AI agents query Cube semantic layer through Semantic SQL rather than warehouse directly; runtime validates against data model and applies access policies before warehouse execution. Metrics, joins, access rules and caching are centralized; APIs include SQL/REST/GraphQL/MCP-related paths.


5) source class: author-maintained product documentation
exact title: Workbooks - Cube Documentation / Source SQL Tabs
org: Cube
canonical URL: https://docs.cube.dev/docs/explore-analyze/workbooks/index ; https://docs.cube.dev/docs/explore-analyze/workbooks/source-sql-tabs
publication/update: current documentation; access 2026-09-15
version/release: current as-of access
supporting locator: Semantic Query vs Source SQL Query
label: SOURCE_REPORT + PRODUCT_VOLATILE
relation: counter + limit
finding: Cube itself exposes both semantic-query paths and Source SQL Query paths that bypass the semantic layer. Therefore product adoption alone does not prove semantic enforcement; bypass surface must be separately governed.


6) source class: open specification / industry working group
exact title: Open Semantic Interchange (OSI)
org: Open Semantic Interchange community
canonical URL: https://open-semantic-interchange.org/
publication/update: specification effort current; site update includes 2026-06-04 activity; access 2026-09-15
version/release: current specification site; Apache 2.0; YAML; exact spec version must be rechecked at update time
supporting locator: Core Classes / AI Ready Semantic Context / Working Groups
label: SOURCE_REPORT + PRODUCT_VOLATILE
relation: interoperability + context
finding: OSI is an active vendor-neutral effort to exchange semantic metadata across analytics/AI/BI, with semantic model, datasets, fields, metrics, dimensions and relationships. It supports the direction of portable semantics but does not yet establish universal cross-vendor semantic equivalence.


7) source class: primary research / benchmark
exact title: Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows
org/authors: Fangyu Lei et al.
canonical URL: https://arxiv.org/abs/2411.07763
publication: 2024-11-12; access 2026-09-15
version: arXiv 2411.07763; benchmark 632 enterprise workflow problems
supporting locator: abstract / benchmark description / reported baseline
label: RESEARCH
relation: counter + context
finding: real enterprise text-to-SQL involves large schemas, dialect docs, metadata and project code; reported agent success is far below simpler Spider/BIRD settings. This is evidence against treating raw-schema text-to-SQL as solved, but it does not directly prove semantic-layer superiority.


8) source class: author-maintained reproducible benchmark
exact title: LLM Semantic Layer Benchmark
org: dbt Labs
canonical URL: https://dbt-labs.github.io/dbt-llm-sl-bench/
publication/update: current benchmark site; access 2026-09-15
version: current site; 11 insurance-domain questions; repeated/model comparison runs available
supporting locator: benchmark description / note on modeling
label: RESEARCH + SOURCE_REPORT
relation: support + counter + limit
finding: benchmark explicitly compares Semantic Layer (MetricFlow) with raw SQL. Importantly, 3/11 questions are documented as “too many hops” when the semantic model cannot express required joins; adding models can make them answerable. This supports semantic modeling as a controllable interface while demonstrating that model coverage is itself a failure boundary.

## FINDINGS
F1 VERIFIED_SPEC/OSS_PRACTICE: semantic layer can encode business concepts above physical schema: metrics, dimensions, entities/relationships/join paths and, depending on implementation, access policy. Current Snowflake and Cube implementations expose these semantics directly to AI/NL analytics.
F2 INFERENCE: the architectural value is not “LLM becomes correct” but “business meaning becomes an explicit, versionable, reviewable dependency rather than an implicit LLM inference.” This is the safe Core abstraction.
F3 VERIFIED_SPEC: Snowflake semantic views are native schema-level governed objects; generated SQL still executes under database privileges. Semantic guidance and authorization are separate controls.
F4 SOURCE_REPORT/OSS_PRACTICE: Cube demonstrates a semantic runtime where AI queries are validated and access policy is applied before warehouse execution; however Cube also documents raw Source SQL paths that bypass the layer. Therefore enforcement must be architectural, not assumed from product presence.
F5 RESEARCH: Spider 2.0 establishes that enterprise text-to-SQL over complex raw data remains difficult. dbt Labs' semantic-layer benchmark provides direct comparative evidence but is small/domain-specific and also documents expressiveness failures (“too many hops”).
F6 SOURCE_REPORT: OSI shows active movement toward vendor-neutral semantic interchange, but interoperability is not yet evidence that metric semantics, security, dialect behavior or execution results are identical across implementations.

## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
- Semantic layer can encode a wrong metric, stale business rule, incorrect relationship, unsafe access rule, or incomplete domain. It can make an error consistently repeatable rather than correct it.
- Coverage gap: if a required measure/join/domain is absent, the agent may fail, refuse, or seek a bypass. dbt benchmark explicitly documents unexpressible “too many hops” cases before extra modeling.
- Bypass gap: raw SQL, direct warehouse credentials, alternate tools/MCP servers, notebooks, exports, cached extracts or shadow semantic models can evade the governed layer.
- Authorization gap: semantic definitions and database privileges are distinct. A semantically valid query can still be unauthorized; conversely a technically authorized raw-table query may violate intended business abstraction.
- Freshness gap: warehouse data freshness and semantic-definition freshness are separate. Metric definition changes require version/provenance and regression testing.
- LLM gap: correct semantic metadata does not guarantee correct question interpretation, filter choice, time window, query generation, execution or narrative explanation.
- Interoperability gap: OSI portability is an active specification effort; do not claim universal vendor-neutral equivalence without versioned converter/conformance evidence.

## AVAILABILITY_GATES
Snowflake: account/region/model availability, required CORTEX roles, semantic-view privileges and underlying table SELECT; preview features must be rechecked as-of publication update. Cube: Cube/Core/Cloud feature split, deployment configuration, API/MCP availability, JWT/security context and access-policy setup. dbt benchmark/MetricFlow: product/version and model coverage must be pinned before product claims. OSI: specification version and participating implementations/converters must be revalidated.

## IMPLEMENTATION_STATE
MATURE PATTERN / PRODUCT-SPECIFIC IMPLEMENTATIONS EXIST. Snowflake has native Semantic Views integrated with Cortex Analyst/Agents and SQL; Cube has an open-source semantic-layer foundation and AI-facing query surfaces. Cross-vendor portable semantic interchange is EMERGING rather than closed. A universal Enterprise AI semantic contract remains PROPOSAL.

## BENCHMARK_OR_EVAL
Use three distinct evaluation layers:
A) semantic correctness: metric formula, grain, join path, dimension/filter/time semantics;
B) execution correctness: generated query result equals golden result under authorized principal;
C) answer correctness: final narrative/number/citation faithfully represents result.
Required paired fixture: same 30-100 business questions against (1) raw schema path and (2) semantic path, same model/version/temperature where possible. Include ambiguous synonyms, metric-definition conflicts, multi-hop joins, row-level security, unsupported questions, stale metric version, and attempted bypass. Track execution accuracy, metric-selection accuracy, unauthorized-result rate, abstention quality, latency/cost, semantic-model coverage and regression after semantic changes. Spider 2.0 is external context, not a product guarantee. dbt LLM Semantic Layer Benchmark is useful comparative evidence but too small to generalize alone.

## SECURITY
enforce warehouse least privilege plus semantic-layer policy; prohibit or separately authorize raw-SQL bypass. Semantic metadata itself can reveal sensitive table/metric names and business logic.
AUDIT: record principal, question, model/version, semantic-model/view ID+version/hash, generated query, executed query, referenced metrics/dimensions, policy decision, result/error and final answer provenance.

## COST
semantic modeling adds authoring/review/CI maintenance but may reduce repeated prompt/schema context and wrong-query rework; product-specific caching/preaggregation can change warehouse cost. No generic ROI claim established.

## OPERABILITY
treat semantic definitions as code/config with owner, version control, review, tests, deployment environment, deprecation and rollback. Couple EA-067 freshness SLO to semantic definition rollout, not only source data refresh.

## SAFE_WORDING_FOR_FUTURE_BOOK
「Enterprise AIの分析では、LLMを生のデータベースschemaへ直接接続するより、組織が定義したmetrics・dimensions・relationships・access rulesを持つsemantic layerを介在させると、AIが推測しなければならない業務意味を減らし、定義をversion管理・監査・評価しやすくできる。これは回答正確性の保証ではない。semantic model自体の誤り・不足・陳腐化、権限設定、raw SQL等のbypass経路、LLMの質問解釈・query生成誤りは別途評価する必要がある。」

## UPDATE_WORK_HANDOFF
1. Coreへ「Semantic Contract」を追加候補: metric/dimension/entity/relationship/grain/filter/time semantics/access policy/owner/version/effective_at/deprecated_at/source lineage。
2. provider mappingはSnowflake Semantic Views+Cortex、Cube Semantic Layer/AI、dbt Semantic Layer/MetricFlowをversioned comparisonし、Microsoft Fabric/Power BI semantic model、Looker/LookML等は追加採集候補として別bounded unitで照合する。
3. OSIはinteroperability節へ置き、publication時のspec version、converter実装、conformance/test statusを再採集する。
4. paired benchmarkをTEST_PROFILEとして実施し、raw schema vs semantic pathを同一fixtureで比較する。
5. raw SQL / alternate tool / notebook / exportのbypass inventoryを必須化し、「semantic layer adopted」と「semantic layer enforced」を分離する。

## UNKNOWN
provider横断で同一metric definitionが同一結果を保証するconformance水準。OSIのpublication時点spec/version/converter coverage。semantic-layer変更からAI回答へのpropagation latency。semantic metadataへのprompt injection/poisoning耐性。複雑なnon-additive/semi-additive metric、temporal semantics、multi-hop relationshipの各製品限界。

## STOP_CONDITION
EA-068の更新準備として、(a) current implementationが複数系統で存在、(b) raw-schema text-to-SQLの限界、(c) semantic-layer自身のcoverage/bypass/freshness/authorization failure envelope、(d) interoperabilityの現状、(e)後続paired TEST_PROFILEが揃ったため本RUNをbounded completeとする。UNKNOWNは推測で閉じず後続Workへ渡す。

---

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.