[P0] Build relational-schema to governed semantic-model proposal vertical

[seonghobae]

Buyer outcome

A data architect can provide immutable relational source evidence and receive a reviewable governed semantic-model proposal that explains what was observed, which exact source coordinates support each candidate, how it was validated, and what a released client may safely consume.

DDD boundary

Source Observation owns bounded source-access contracts, registry authorization capability binding, immutable observed facts, evidence coordinates and extractor receipts; it does not own source-system business truth or semantic inference. Semantic Discovery owns candidates, never authoritative source truth. LLM proposal work, if used, routes only through a released contextual-orchestrator contract and remains proposed/inferred. Model Alignment and Model Validation own matching/refinement and deterministic validation. Governance & Publication owns steward decisions and immutable semantic releases. External source/provider DTOs and credentials remain behind adapter ACLs.

Current Source Observation lane — 2026-09-06

Client parent #5 is fcf36c8a99f015b963c9f812787df127ac2e2f9e; Source Observation PR #6 is exact e3c415600300b6c2d5b852c457ea6ab2e5222e08, Draft/open. Predecessor evidence does not transfer to this exact head.

The retained contract now includes owner-computed deterministic source-content identity, bounded authorization metadata, exact source-key + immutable connection-policy binding resolution, explicit exact-schema and complete resource-envelope policy, one non-resetting monotonic operation budget across local authorization and adapter execution, awaitable provider-independent Send execution, stale-binding rejection, snapshot-side exact-schema containment, and binding-preserving immutable receipt provenance. DSNs, credentials, provider runtime objects, foreign domain truth and wall-clock timestamps remain outside the port.

Single-use authorization repair

Review 5124482059 identified that predecessor db209b9b11039ed77cbae246f65b3a83d7589d23 still treated AuthorizedObservationRequest as replayable: it implemented Clone and SourceObservationPort::observe borrowed it. One successful registry authorization could therefore start multiple observations and multiply one operation's admitted row, byte, concurrency, deadline and source-access budget.

2a03a56a5982f9d56e880689a139597aea3ef47d committed the compile-contract specification first: the port consumes the authorization by value and cancellation/success controls obtain independent authorizations. 340ded102f18c1c4abebbcf0590e5941b61f6cba is the minimum production repair: AuthorizedObservationRequest is non-Clone and SourceObservationPort::observe consumes it. Successor fixtures preserve authorization zero-side-effect, cancellation, stale-binding, remaining-budget and resource-envelope behavior on that single-use seam.

Architecture, TRD, Security, Test Strategy, Operability, CHANGELOG and docs/product-technical-gap-baseline.md are aligned. Proposed ADR 0006 refines Proposed ADR 0004 with the single-use operation-capability decision. docs/doctoring/source-observation-authorization-replay-governance.md traces the finding and repair to OWASP API4:2023 and MITRE CWE-770 resource-governance guidance while explicitly distinguishing that general guidance from the Rust ownership mechanism chosen here.

Verification state

Do not treat the current head as GREEN until fresh exact-head evidence proves it. The current tool environment has no Rust toolchain, so the compile-contract specification was not observed with cargo here. Required evidence remains Rust 1.98 tests, strict fmt/Clippy, warnings-denied rustdoc, release build, owned 100% coverage and applicable security/dependency workflows on one unchanged exact head. ADR 0004 and ADR 0006 remain Proposed. No predecessor Product/coverage/rustdoc evidence transfers.

Active P0

1. Execute unchanged feat(observation): define immutable PostgreSQL schema snapshot contract #6 head under Product/Rust/coverage/rustdoc/security/dependency gates once the protected-base Product path is available; repair only observed failures.
2. Implement the concrete read-only PostgreSQL adapter behind conceptweave-source-port with a maintained patched Rust PostgreSQL driver, adapter-local least-privilege credential resolution for the exact key+binding, one fresh authorization per attempted observation/retry, one explicit REPEATABLE READ READ ONLY catalog transaction, exact-schema pg_catalog evidence, and one remaining operation budget across connect/transaction/statement/cancellation work.
3. Enforce cancellation plus row/byte/concurrency limits, stale-binding rejection before I/O, complete-or-fail snapshot construction and source-disappearance handling.
4. Freeze and replay an anonymized GRC-shaped conformance fixture without copying governance-risk-compliance source or querying its application tables through hidden coupling.
5. After observation conformance is GREEN, continue discovery/proposal/alignment/validation/governance/release work from verified source receipts rather than relational structure alone.

Acceptance

Same immutable observed metadata produces the same owner-computed source-content identity regardless of input table order or provenance-only coordinates; materially different observed metadata cannot reuse that identity; every candidate binds to exact source identity/digest/location evidence; a raw request or merely well-formed key cannot reach the canonical adapter seam; unknown/unauthorized source, schema, resource or stale binding fails before source/snapshot side effects; one authorization can cross the canonical observation execution seam only once; retry re-authorizes against current policy; authorization, connection and catalog work share one operation deadline; access remains read-only, least-privilege, cancellation-aware and credential-free at domain boundaries; partial/ambiguous capture is never promoted to immutable success; raw LLM SQL is never executed against source systems; publication and Client consumption use governed immutable releases only.

Refs #6, Issue #4, ContextualWisdomLab/governance-risk-compliance#63.

[seonghobae]

GRC generation reference source

ContextualWisdomLab/governance-risk-compliance#63 is the first concrete domain-source program for this Generation vertical. Use GRC as a realistic, independently owned reference domain rather than inventing a ConceptWeave-only toy schema.

The reference flow is:

GRC canonical schema + public contracts + PRD/ADR/ubiquitous language + reviewed framework/control terminology
→ immutable ConceptWeave source snapshot/observations
→ deterministic schema facts
→ LLM-assisted term typing / concept / taxonomy / non-taxonomic relation / physical mapping / semantic definition proposals through contextual-orchestrator
→ deterministic graph/schema/constraint/evidence validation
→ GRC semantic-steward/domain-owner review
→ versioned ConceptWeave semantic release
→ ConceptWeave #3 Client contract
→ GRC Analytics consumer (#64).

Generation acceptance for the GRC reference case must prove:

• GRC remains the source of truth; ConceptWeave observes contracts/schema/docs rather than writing GRC application tables.
• external_requirement, compliance_obligation, policy, internal_control, control_implementation, evidence, control_test, risk, audit_finding, remediation and related terms are not collapsed merely because physical names look similar.
• evidence presence is never automatically inferred as control effectiveness/compliance.
• physical schema relations, documentation terminology, official-standard mappings, and lineage evidence remain distinguishable evidence channels.
• LLM proposals preserve exact source evidence and remain inferred/proposed until deterministic validation + authorized GRC review.
• unsupported dimensions/measures or ambiguous relationships abstain rather than becoming heuristic truth.
• the same immutable GRC snapshot and deterministic extractor revision reproduce the same observed facts, while LLM/model/prompt variation is recorded and evaluated separately.
• no GRC credential, tenant evidence payload, unnecessary PII, or secret is sent to model providers.

Do not hard-code GRC concepts into the generic engine. GRC is a golden domain fixture/consumer used to expose missing generic capabilities; any reusable fix belongs in ConceptWeave's generic generation/release contract.

[seonghobae]

Research/GRC reference update — 2026-09-01

The Generation lane now has a code-current research mapping in PR #1 at docs/doctoring/RESEARCH_CAPABILITY_TRACEABILITY.md. The register maps current Consensus results to term typing, taxonomy discovery, non-taxonomic relations, dataset-to-ontology staging, end-to-end taxonomy benchmarks, competency-question-driven generation, cross-domain evaluation, and explicit complex-model abstention. It also records which research remains research_only rather than silently becoming a product rule.

GRC remains the first enterprise Generation reference source, but not a GRC-specific algorithm. Current external contract is still governance-risk-compliance#63: ConceptWeave should consume immutable published schema/API/docs/glossary/standards snapshots with exact digest/location provenance and must not query GRC application tables directly. The golden flow remains GRC source snapshot -> observed facts -> LLM-assisted proposed semantic artifacts through contextual-orchestrator -> deterministic validation -> GRC steward/domain review -> governed release.

No Generation implementation is being fanned out ahead of the foundation invariant repair. PR #1 currently carries a test-first publication-evidence regression and is intentionally non-merge-ready until exact-head RED is observed and repaired.

[seonghobae]

Consensus research delta — 2026-09-01

The fresh accepted search set contains two relevant studies not yet present in docs/doctoring/RESEARCH_CAPABILITY_TRACEABILITY.md. They must be incorporated in the next code-current documentation commit rather than left as bibliography-only references.

1. Kommineni, König-Ries, & Samuel (2024), From human experts to machines: An LLM supported approach to ontology and knowledge graph construction — current Consensus metadata: arXiv abs/2403.08345, 115 citations. Classification: generation / cross_cutting; decision: adapt. Capability implication: competency questions -> TBox -> KG construction is a useful Generation evaluation pipeline, but their judge-LLM evaluation cannot become ConceptWeave ground truth. Adopt competency-question coverage and human-in-the-loop/steward evaluation; explicitly reject LLM-judge-only publication evidence.
2. Mateiu & Groza (2023), Ontology engineering with Large Language Models, SYNASC 2023, pp. 226–229, 59 citations. Classification: generation; decision: adapt. Capability implication: NL -> Description Logic / OWL-functional-syntax proposal is a useful publication-adapter/LLM-Proposal fixture for class subsumption, domain/range, object-property, disjointness/complement/cardinality axioms. Preserve human supervision and deterministic syntax/semantic validation; generated axioms remain proposed.

No runtime dependency is implied by either paper. Both should map to executable benchmark/fixture families and limitations in the research register after the current foundation RED/GREEN repair, with the current Consensus metadata treated as source of record for this snapshot.

[seonghobae]

GRC protected-source golden fixture coordinate — 2026-09-01

Use the protected GRC develop source, not unmerged Analytics/client branches, as the first Generation reference snapshot. Fresh coordinate: ContextualWisdomLab/governance-risk-compliance@85da4e1c64e5b46ca3a11ca71654a82b57366a3e.

The first bounded relational fixture should cover the currently protected 3NF model in cwl_grc/models.py: control_framework, control_item, authorization_purpose, evidence_record, control_evidence_binding, audit_event, policy_document, policy_version, and policy_control_mapping, including PKs, FK graph, unique constraints, check constraints, nullability, data types and comments/docstrings. PostgreSQL integrity semantics in cwl_grc/migrations.py are additional source observations/constraints, not inferred ontology truth.

Expected semantic proposals for this fixture are generic, evidence-bound candidates such as catalog/control concepts, policy document/version concepts, evidence/control binding relationships, authorization-purpose context and append-only/immutability constraints. Do not infer control effectiveness, compliance, risk acceptance, or other GRC authority merely from a binding or FK. Ciphertext payload contents are out of scope for schema observation and must never be sent to an LLM.

The fixture receipt must bind the exact GRC source commit plus content digests/locations for each observed element. When the GRC protected branch later integrates newer risk/audit/remediation models, treat that as a new source snapshot/version and produce an explicit semantic diff rather than rewriting this fixture in place.

[seonghobae]

Consensus accepted-search delta — 2026-09-01

The current Generation research register on PR #1 is already broad, but the fresh accepted search set adds one Generation study not yet represented and confirms one pending study:

• Aggarwal, Salatino, Osborne, & Motta (2024), Large Language Models for Scholarly Ontology Generation: An Extensive Analysis in the Engineering Field, Information Processing & Management, 63, 104262 (current Consensus record; 24 citations). Class: generation / cross_cutting; decision: adapt. Product implication: relation typing should include explicit broader/narrower/same-as/other-style gold labels and model/prompt-size ablations rather than judging a generated taxonomy only as one whole artifact. Add a relationship-classification benchmark family and complexity/domain-stratified errors; do not generalize scholarly-topic performance to enterprise GRC.
• Mateiu & Groza (2023), Ontology engineering with Large Language Models remains a valid generation delta already recorded here. Preserve its NL→DL/OWL-functional-syntax proposal fixture under human supervision and deterministic syntax/semantic validation.

Lippolis et al. (2025) is already mapped in docs/doctoring/RESEARCH_CAPABILITY_TRACEABILITY.md to competency-question/user-story-driven generation, so no duplicate row is required.

Do not move PR #1 merely to record this documentation delta while its exact-head publication-invariant RED run is still queued. Incorporate the new Aggarwal row together with the pending Mateiu/Kommineni rows in the first code-current documentation commit after the current RED is observed and the causal authority-boundary repair is made.

[seonghobae]

GRC golden Generation source snapshot — protected authority

Prepared the first immutable enterprise reference-source coordinate without reading foreign application tables or treating an active GRC PR as source truth.

Snapshot identity

• Source repository: ContextualWisdomLab/governance-risk-compliance
• Authoritative branch for this fixture: protected/default develop
• Exact source commit: 85da4e1c64e5b46ca3a11ca71654a82b57366a3e
• Commit tree: 5dd769b83e2bd6266e545a93e0790518b054deeb

Selected protected artifacts for the first fixture are individually content-addressed:

• ARCHITECTURE.md — architecture/domain ownership input; fetch by the exact commit, not a moving branch.
• cwl_grc/migrations.py — blob e730a4ac7a116042980ddd588f55ae13510bd6c8; schema-lifecycle fixture input.
• cwl_grc/catalog.py — blob 64b47d39f3a41772c2ab7e1eca4bb377af66398f; official control/catalog terminology input.
• cwl_grc/policy.py — blob dcd3310bfef01a750379316e683f007f191da438; policy/version/mapping behavior terminology input.
• cwl_grc/evidence.py — blob 39cb3087ff2c50b7faa033f59b5fdcdae37f9b90; evidence/binding terminology input.
• cwl_grc/audit.py — blob 15b3c4df882c62ee83a4a4a480bdefd30296d31c; audit terminology input.
• docs/product-technical-gap-baseline.md — blob d03b70b89ac30a579c31d66dd1a2dc4b9e697e34; planning/context evidence only, not domain authority.

Source-authority rule

These files are a reproducible golden fixture input, not permission to couple ConceptWeave to GRC Python modules. The production relational adapter still observes an immutable PostgreSQL schema snapshot through the Source Observation port. migrations.py may synthesize a test database or expected fixture, but ConceptWeave must not import cwl_grc, query GRC application tables directly, or infer unobserved database facts from documentation.

The first GRC fixture should preserve exact source_id + source_digest + location for each observation and distinguish:

• relational observations from the actual introspected fixture database;
• documentation/glossary observations from exact blobs;
• LLM-assisted semantic proposals from both;
• steward-approved/published semantic truth from every proposal.

Expected domain candidates — proposals, not gold truth

The fixture should be capable of proposing and later steward-reviewing concepts such as policy document/version, control framework/item, evidence record, control-evidence binding and audit event, plus relationships visible in the exact source. Candidate dimensions/measures require deterministic source/calculation contracts before publication; names inferred from docs alone are insufficient.

First executable Generation acceptance after runner admission

1. Materialize a realistic PostgreSQL fixture from this immutable GRC coordinate without importing GRC runtime code into ConceptWeave production.
2. RED: prove Source Observation does not yet produce the required immutable observation receipt for the fixture.
3. GREEN: observe tables/columns/PK/unique/FK/nullability/types/comments and exact evidence coordinates deterministically.
4. Pass the observations to LLM Proposal only through contextual-orchestrator; capture model/prompt/source receipts and keep all outputs proposed/inferred.
5. Deterministically validate graph/mapping/evidence invariants before steward review.
6. Produce the same semantic-release contract consumed by Issue [P0] Build semantic-model client consumption, alignment, and query contract #3/GRC reference-client fixtures; do not introduce a GRC-specific release format.

Current ConceptWeave runner-admission blocker remains #4. Do not churn PR #1 or claim RED/GREEN execution until a hosted runner actually executes the test boundary.

[seonghobae]

Fresh Consensus Generation/data-model delta — 2026-09-01

The accepted Generation search set now contains four relevant studies not yet present in docs/doctoring/RESEARCH_CAPABILITY_TRACEABILITY.md. The foundation exact head is intentionally frozen while current Product/SAST/Security/required jobs remain unassigned, so record these as the next code-current research delta rather than moving PR #1 merely for documentation churn.

• Avignone, Tierno, Fiori, & Chiusano (2025), Exploring Large Language Models' Ability to Describe Entity-Relationship Schema-Based Conceptual Data Models (Information, 16, 368; current Consensus citation count 7). Class: generation; decision: adapt. Capability implication: enriched ER/schema context can improve LLM-generated conceptual descriptions. Add a GRC relational-schema fixture that compares plain physical labels with bounded structural hints and evaluates semantic-description correctness/coverage. Generated descriptions remain proposed evidence and cannot create ontology authority.
• Zhang, He, Pintscher, Meroño-Peñuela, & Simperl (2025), Schema Generation for Large Knowledge Graphs Using Large Language Models (pp. 12561–12580; current Consensus citation count 8). Class: generation / cross_cutting; decision: adapt. Capability implication: structured schema generation over local + global graph context is a useful publication-adapter benchmark. Add syntax/shape-validity and structural-quality fixtures for rich formalisms; do not make ShEx or any generated schema the internal canonical model solely because a model emitted it.
• Fernandez, Elmore, Franklin, Krishnan, & Tan (2023), How Large Language Models Will Disrupt Data Management (Proceedings of the VLDB Endowment, 16, 3302–3309; current Consensus citation count 138). Class: cross_cutting; decision: research_only. Capability implication: schema matching, entity resolution, data discovery, and query synthesis are semantic grounding problems, which supports ConceptWeave's product boundary. This is architecture/motivation evidence rather than benchmark accuracy or permission to merge matching/query execution into one LLM component.
• Wu, Dwivedi, & Leskovec (2025), Large Language Models are Good Relational Learners (arXiv abs/2506.05725; current Consensus citation count 21). Class: generation / research_only; decision: research_only. Capability implication: flattening relational structures into text can lose local graph/temporal structure and create redundancy. Preserve PK/FK/neighborhood evidence as typed structure in LLM Proposal inputs and benchmark structured-context vs flat serialization. Do not introduce a GNN/Rel-LLM runtime dependency without a separate ADR and measured product need.

Already-registered studies returned by the same search (OLLM, Shimizu/Hitzler, LLMs4OL, Lippolis, Li et al. SLR, Du review) require no duplicate rows. These four new rows should be added to the research register and bibliography in the first code-current docs commit after runner admission can execute the exact resulting head. Each row must retain the decision, owner, executable fixture/evaluation family, and limitation above.

Consensus records used for this delta:

• https://consensus.app/papers/exploring-large-language-models-ability-to-describe-avignone-tierno/1a33b962ea8a5a6a973b8ddb753e7014/?utm_source=chatgpt
• https://consensus.app/papers/schema-generation-for-large-knowledge-graphs-using-large-zhang-he/997fd97bd7155d8fb02a1b1b7a57b443/?utm_source=chatgpt
• https://consensus.app/papers/how-large-language-models-will-disrupt-data-management-fernandez-elmore/3a1e577d60465b8ca8d20f55c3abd624/?utm_source=chatgpt
• https://consensus.app/papers/large-language-models-are-good-relational-learners-wu-dwivedi/1a14ab8c9f2d566b8b09b2ee8c1408a3/?utm_source=chatgpt

[seonghobae]

Fresh GRC Generation golden-source coordinate for the next Source Observation RED: protected/default ContextualWisdomLab/governance-risk-compliance remains develop@85da4e1c64e5b46ca3a11ca71654a82b57366a3e. The protected source model at cwl_grc/models.py is a concrete immutable fixture candidate and currently defines the 3NF graph control_framework -> control_item, authorization_purpose -> evidence_record, control_item <-> evidence_record through control_evidence_binding, plus policy_document -> policy_version -> policy_control_mapping -> control_item and append-only audit_event semantics. Exact source blob is f52619362ce23c884039b183da02ac8f4f5b9455.

The Generation vertical should observe this as SOURCE METADATA, not import the Python ORM or query GRC application tables. The first executable adapter fixture should preserve table/column identity, PKs, unique pairs, FKs, nullability, SQL type, comments/docstrings only when supplied as an explicit source, and exact source revision/blob digest. Useful structural cases are already present here: single-column PKs, composite uniqueness, multiple FKs from one binding table, one-to-many relationships, a many-to-many bridge, optimistic revision fields, immutable/finalization semantics expressed outside mere FK topology, binary evidence payload, and temporal columns. Semantic outputs such as control, evidence, policy edition, or mappings remain proposed until validation/steward publication.

This protected snapshot can therefore serve as the SAME enterprise fixture later consumed by the Client/GRC round trip. If the implementation needs GRC-specific ORM imports or hard-coded table names, that is a failed abstraction: improve the general PostgreSQL Source Observation port/fixture contract instead.

[seonghobae]

Fresh GRC golden-source fixture coordinate for the Generation root while Client RED CI is queued:

• authoritative reference branch: ContextualWisdomLab/governance-risk-compliance protected/default develop@85da4e1c64e5b46ca3a11ca71654a82b57366a3e;
• ORM schema evidence: cwl_grc/models.py blob f52619362ce23c884039b183da02ac8f4f5b9455;
• migration/integrity evidence: cwl_grc/migrations.py blob e730a4ac7a116042980ddd588f55ae13510bd6c8.

The first enterprise fixture should preserve the actual relational structure rather than flattening labels: control_framework -> control_item, authorization_purpose -> evidence_record, control_item + evidence_record -> control_evidence_binding, policy_document -> policy_version -> policy_control_mapping -> control_item, plus append-only audit_event. Include PKs, unique pairs, FKs, nullability, string/text/binary/time/boolean types, policy_document.current_version_number >= 0, positive policy version numbers, finalized-policy immutability and append-only audit/mapping constraints as observed physical evidence.

Generation acceptance for this fixture: the Source Observation adapter must derive these facts from an immutable PostgreSQL snapshot/system-catalog read through the generic read-only port; it must NOT import cwl_grc.models or migrations at runtime and must not query GRC application rows. The source blobs above are fixture/provenance coordinates only. Semantic Discovery may propose concepts such as control/evidence/policy and relationships from the observed graph, but the source table/constraint identities remain GRC facts and every proposal must retain exact source digest+location evidence.

Use this exact fixture for the planned plain-label vs structured PK/FK/neighborhood evaluation, including the many-to-many binding and policy-version chain. A Generation implementation that only infers from table/column names without preserving structural evidence does not satisfy #2.

[seonghobae]

Fresh Generation provenance acceptance, 2026-09-02.

Issue #2 requires every candidate/source observation to retain a verifiable source identity/digest/location. Current PR #6 source review found PostgresSchemaSnapshot::new accepted arbitrary nonblank snapshot_digest strings such as digest, which cannot support immutable GRC golden-source evidence or later round-trip provenance.

Current test-only PR #6 head 7657222d8004191f4a5dffd23cfa6f51d5d6adb5 now specifies canonical sha256: + exactly 64 lowercase hex for snapshot_digest and rejects plain labels, short hashes, uppercase hex and another algorithm prefix. Product run 33563608323 / job 100041625887 remains queued before checkout, so the intended validation RED has not yet been observed and production validation is intentionally unchanged.

GRC reference-client/source evidence remains consistent with this direction: GRC #63 requires immutable source observations and GRC #64 deliberately expects a lowercase SHA-256 content coordinate at its consumer boundary while refusing to guess the supplier's later wire schema. After actual RED observation, the minimal Generation repair is digest-coordinate validation at Source Observation, not GRC-specific semantic inference or direct GRC table access. The same frozen GRC fixture should then carry exact source digest + evidence location into candidate/proposal receipts.

[seonghobae]

Consensus research-register reconciliation — accepted search set 2026-09-02.

Accepted query: large language models ontology engineering systematic review ontology learning ontology matching, year filter 2023–2026. The returned set contained 10 relevant papers; all 10 are assigned below. Current Consensus metadata wins over remembered scheduler metadata. This staging intentionally advances research traceability without moving the queued Generation/Client source heads; the next material source/documentation commit must transfer these entries into docs/doctoring/REFERENCES.md plus the machine-readable/tabular research→capability artifact and bind accepted implications to executable benchmark/contract tests.

Paper	Primary class	Capability implication / decision	Owner + benchmark/test family	Limitation / status
Li, Garijo, & Poveda-Villalón (2026), Large Language Models for Ontology Engineering: A Systematic Literature Review	cross_cutting	ACCEPT: explicit task definitions, heterogeneous-input disclosure, standardized evaluation, reproducibility artifacts, human-expert/steward workflow; REJECT single-prompt-as-algorithm	Research register + Generation/Client evaluation; reproducibility/benchmark-disclosure fitness contracts	Current Consensus: Semantic Web, vol. 17; 36 papers / 49 task-level studies; keep as governance/evaluation evidence, not algorithmic ground truth
Taboada et al. (2025), Ontology Matching with Large Language Models and Prioritized Depth-First Search (MILA)	client	ACCEPT retrieve→identify→prompt, programmed graph search before LLM, LLM only for borderline cases	Model Alignment / Client; OAEI-style P/R/F1, candidate recall, LLM-call reduction/abstention	Current Consensus metadata is ArXiv abs/2501.11441; do not represent as final peer-reviewed publication; research_only until venue status changes
Hertling & Paulheim (2023), OLaLa: Ontology Matching with Large Language Models	client	ACCEPT prompt/representation/candidate-generation as explicit experimental variables; few/zero-shot matching only after bounded candidate generation	Model Alignment / Client; OAEI matching P/R/F1 and prompt/representation sensitivity	K-CAP 2023 proceedings; no automatic authority promotion
Giglou, D’Souza, Engel, & Auer (2024), LLMs4OM: Matching Ontologies with Large Language Models	client	ACCEPT separate retrieval + matching modules and concept / parent / children representations	Model Alignment / Client; retrieval recall, matching P/R/F1, neighborhood-representation ablations	Current Consensus metadata is ArXiv abs/2404.10317; research_only as publication-status evidence, while the architecture pattern remains benchmarkable
Du, An, Wang, & Liu (2024), A Short Review for Ontology Learning: Stride to Large Language Models Trend	cross_cutting	ACCEPT only as historical/task-taxonomy context; REJECT treating a narrative trend review as a production algorithm	Research register; contradiction/task-taxonomy review	Current Consensus provides no journal venue metadata; research_only, no product gate derived solely from it
He, Chen, Dong, & Horrocks (2023), Exploring Large Language Models for Ontology Alignment	client	ACCEPT labels + structural context as an alignment representation/ablation candidate	Model Alignment / Client; OAEI Bio-ML equivalence subsets, structural-context ablation	Current Consensus: ArXiv abs/2309.07172, explicitly preliminary; research_only, no authority claim
Shimizu & Hitzler (2024), Accelerating Knowledge Graph and Ontology Engineering with Large Language Models	generation	ACCEPT modular ontology-engineering stages rather than one monolithic prompt; map modeling/extension/population/alignment to bounded contexts	Semantic Discovery + LLM Proposal + Model Alignment; task-specific generation metrics and modular reproducibility	Current Consensus metadata is ArXiv abs/2411.09601; conceptual/research architecture evidence, not sole production validation
Sousa, Lima, & Trojahn (2025), Complex Ontology Matching with Large Language Model Embeddings	client	ACCEPT structural/subgraph surroundings for expressive-correspondence candidate evidence; keep embedding/model spaces explicitly identified	Model Alignment / Client; complex-correspondence accuracy, subgraph/entity/label ablations	Current Consensus metadata is ArXiv abs/2502.13619; reported 45% F-measure improvement must be reproduced/benchmarked before product claims; research_only
Lippolis et al. (2025), Ontology Generation using Large Language Models	generation	ACCEPT competency questions/user stories as explicit ontology-generation inputs, multidimensional structural criteria plus expert review; REJECT direct draft→publication	LLM Proposal + Model Validation + Governance; CQ/user-story golden fixtures, structural validity + steward qualitative/edit-distance evaluation	Current Consensus metadata is ArXiv abs/2503.05388; reported variability/common mistakes require abstention/steward gates; research_only
Song, Chen, & Schmidt (2025), GenOM: ontology matching with description generation and large language models	client	ACCEPT semantic-description enrichment → embedding candidate retrieval → exact lexical evidence as an ablatable matching pipeline; generated descriptions remain proposed evidence	Model Alignment / Client; OAEI Bio-ML, candidate-retrieval recall, matching P/R/F1, lexical/retrieval/description ablations, generated-definition quality criteria	Current Consensus: World Wide Web, vol. 29; published metadata. Domain-heavy biomedical results must not be generalized without ConceptWeave/GRC and public benchmark replication

Executable feature deltas from this search set:

• Generation golden fixtures must add competency-question/user-story input alongside schema observation, then measure structural criteria plus steward edit distance; LLM ontology drafts remain proposed until deterministic validation and review.
• Client matching fixtures must add semantic-description enrichment as an optional candidate-evidence source, but preserve deterministic lexical/structural evidence and retrieval-before-prompt. A GenOM-style description must never become truth merely because it improves ranking.
• OAEI-style evaluation must report representation/context ablations (label-only vs parent/children/neighborhood/subgraph/description enrichment), candidate-retrieval recall and LLM-call count in addition to final P/R/F1.
• Metadata/publication status is part of traceability: current ArXiv-only records above are explicitly research_only evidence until source metadata changes; they can motivate tests without being misrepresented as stable standards or peer-reviewed production authority.

This search set introduces no GRC-specific special case. GRC remains the first enterprise golden fixture/client used to test the GENERAL Generation↔Client contract.