[P0] Build semantic-model client consumption, alignment, and query contract

Buyer outcome

A consuming product or data platform can load a governed ConceptWeave semantic release and use it safely without knowing generator internals: validate integrity/provenance, resolve concepts, align local vocabularies, inspect mappings, plan semantic queries, and surface conflicts instead of silently coercing meaning.

Client Consumption boundary

Client Consumption owns the provider-independent public semantic_release contract and deterministic admission/integrity/compatibility/diff/resolution/supersession behavior. It does not own consuming-product tenant/purpose authorization, business truth, physical query execution, catalog UX, or LLM/provider routing.

The generator publishes immutable/versioned artifacts; clients consume only released contracts. No client may depend on generator-private classes, prompts, provider payloads, internal persistence tables, orchestration state, mutable PR heads, or cross-service SQL. semantic-data-portal remains catalog/governance/consumption, context-graph-contracts interop, enterprise-architecture-core EA, and contextual-orchestrator production model/provider routing.

A public release seam must preserve release/version identity, ontology/schema versions, concept/relation identifiers, truth/publication status, evidence/provenance references, physical mappings, dimensions/measures/calculation metadata, constraints, compatibility/deprecation metadata, and cryptographic integrity evidence where the contract defines it.

Current dependency-first Client lane — 2026-09-10

Foundation #1 is exact 60f14a6e85a83d56c2eea43b34d52b3366bb1735, OPEN Draft/mergeable. Client PR #5 is exact 6873ec0c0a701b2c59f3e0785d48d8739f019d5b, OPEN Draft/mergeable, after an ordinary two-parent non-force reconciliation that preserves the prior Client semantic tree and adopts current Foundation. Predecessor/local/hosted evidence does not transfer to this successor.

The current source already contains a versioned public semantic-release schema, offline published/authoritative admission, digest/provenance validation, compatibility checks, deterministic resolution/diff behavior, immutable-content collision rejection, and explicit predecessor/successor supersession validation. These are the current implemented baseline, not future placeholders.

Repository-owned Product CI still cannot become protected authority until bootstrap #35 is normally integrated. #35 is exact 22709ec9b4d969bf67ec74db402813e74d11f7ca, OPEN non-Draft/mergeable. Its Security/Semgrep lanes succeeded while CodeQL is terminal failure in the central owner path; no Client source change or blind leaf rerun repairs that owner contract.

The broad current central producer/handler successor is .github#2040@6706c231ab06a3c91c43fdb5b989cfcd79fff593, OPEN Ready/non-Draft/mergeable on protected .github/main@7fd571dbcdbae6acf29d8f4ee704d7ba6297e4db. Exact CodeQL run 34251822255 is terminal failure at attempt 7: both language verdict readers fail and the coordinator fails because one one-shot Jobs API snapshot cannot bind every pending language to a stable exact failed job. The same successor also needs bounded pre-cutover direct-evidence admission for the currently protected handler without restoring creator-only legacy status trust. .github#2051@558693e... and stacked #2056 69ae472... retain useful stricter base identity/versioned-rollout and complete-failed-job-set/atomic-wake deltas, but neither is protected authority today. Reconcile those deltas non-force only after the #2040 seam is causally repaired.

Keep #5 stable while that owner path proceeds through RED → minimal repair → exact central GREEN and qualifying independent review → normal protected integration → fresh #35 exact-head CodeQL/review → normal #35 integration → fresh Client acceptance. No no-op push, manual rerun loop, synthetic status, stale predecessor GREEN, or gate weakening is acceptance evidence.

Next Client gaps after exact-head verification

Complete generic explain, match, resolve, validate, diff, compatibility, and query-plan client operations with reproducible receipts rather than product-specific forks.
Add ontology/concept alignment APIs that return typed candidate correspondences with lexical/structural/provenance evidence and explicit ambiguity/abstention; they must not mutate either ontology or promote candidates to authority.
Use retrieve/filter/match and graph-neighborhood pruning before any optional LLM assistance. Production LLM calls route only through released contextual-orchestrator; deterministic validation, authorization, publication-state checks, and final acceptance remain non-LLM.
Keep semantic query planning separate from physical execution. Consuming products retain their own authorized data-access boundary and domain calculations.
Add a frozen GRC-shaped conformance fixture only as a consumer of the generic released contract. governance-risk-compliance remains authoritative for its own business truth; no GRC tuple becomes part of ConceptWeave's canonical public model.
Verify older-supported, superseded, malformed, unknown-version, partial, conflicting, unpublished and digest-invalid releases fail or resolve exactly according to the public compatibility policy.
Publish language-neutral contract/package artifacts only from a release-ready protected head with immutable version/tag/SBOM/provenance/reproducibility/rollback evidence.

Research/evaluation basis

Client matching and alignment work remains traceable to the repository's doctoring register, including Hertling & Paulheim (2023) OLaLa, Giglou et al. (2024) LLMs4OM, Sousa et al. (2025) complex ontology matching, Taboada et al. (2025) prioritized graph search, Barcelos et al. (2025) KROMA, Xiao et al. (2025) LLM4VKG, and Li et al. (2026) systematic review. Every cited work must map to an implemented capability, evaluation family, ADR, or explicit rejection reason; bibliography history is evidence, not a mutable runtime dependency.

Evaluation must cover applicable OAEI-style precision/recall/F1, candidate-retrieval recall, ranking quality, complex correspondences, abstention/ambiguity handling, version compatibility, release-diff correctness, stale/superseded handling, provenance completeness, deterministic digest validation, query-plan correctness, unauthorized-access non-occurrence, reproducibility, and LLM-call reduction versus naive full-ontology prompting where an LLM lane exists.

Acceptance

a consumer validates and inspects an immutable released contract offline without contacting an LLM provider;
generated artifacts are usable through stable public contracts without generator internals;
LLM-assisted client behavior is optional, proposed/inferred, and routed only through contextual-orchestrator;
alignment outputs retain evidence/truth status and never become authoritative automatically;
current/older-supported/superseded/malformed/unknown-version/conflicting cases are covered by deterministic conformance fixtures;
physical mappings and governed dimensions/measures can be resolved while downstream products retain authorization and execution authority;
owned production doc/test/edge coverage meets the repository's 100% contract and one unchanged exact head reaches terminal protected evidence before integration.

Out of scope

becoming an enterprise catalog UI;
owning consuming-product authorization or business-domain truth;
direct client writes to foreign product databases;
auto-accepting LLM mappings as authoritative;
duplicating semantic-data-portal search/catalog responsibilities.

Refs #5, #1, #35.

GRC reference-client binding

ContextualWisdomLab/governance-risk-compliance#63 is now the first concrete reference-client program for this Client/release contract. GRC stacked PR ContextualWisdomLab/governance-risk-compliance#64 has already established a test-first provider-neutral SemanticModelClientPort boundary on top of the GRC Analytics root PR.

ConceptWeave #3 must therefore treat GRC as a mandatory golden consumer, not a prose example. Release/client acceptance must include at least:

offline release validation without an LLM provider;
exact release/schema/semantic-layer version and SHA-256 content identity;
publication/truth-status preservation and rejection of proposed/superseded artifacts for authoritative use;
concept/relation resolution and physical↔semantic mappings usable without generator-private imports;
governed dimensions/measures with deterministic calculation metadata;
release diff/compatibility reporting that identifies affected client query assumptions;
provider-neutral validate, resolve, match, align, diff, compatibility, explain, and query-plan semantics;
tenant/purpose scope remaining owned by the client and never widened by semantic metadata;
optional LLM matching/query interpretation only through contextual-orchestrator;
no direct access from ConceptWeave to GRC application tables;
golden cross-repo contract fixtures exercised by both ConceptWeave and GRC.

Do not invent a GRC-specific wire protocol inside ConceptWeave. Publish one general versioned Client contract and make the GRC adapter prove that it is sufficient. If the GRC reference case exposes a missing generic capability, fix the generic ConceptWeave contract and re-run both sides.

Client/reference update — 2026-09-01

The Client lane now has an expanded research-to-capability register in PR #1. Current accepted Client implications include retrieval-before-prompt, concept/parent/children and neighborhood evidence, deterministic lexical signals, candidate pruning, complex correspondences, LLM-specific hallucination benchmarks, explicit ontology/release versioning, and human validation quality. Agent-OM and GenOM were added as concrete evidence for separated retrieval/matching responsibilities and definition-enriched matching; OM4OV is now explicitly mapped to release-diff/version-compatibility requirements rather than treating versioning as ordinary ontology matching.

The first enterprise reference client remains GRC. Live external state was re-read: governance-risk-compliance#63 is open and GRC PR #64 remains an open Draft stacked on its Analytics root, with a provider-neutral SemanticModelClientPort and exact-head Product evidence recorded on the GRC side. ConceptWeave must satisfy that consumer through a general published semantic_release/Client contract; do not add a GRC-only endpoint or import GRC internals.

Required cross-repo acceptance remains: published release validates offline; proposed/superseded/unknown/malformed/digest-invalid releases fail closed; mappings and governed dimensions/measures preserve provenance/calculation metadata; release diff identifies affected GRC queries; tenant/purpose authorization remains GRC-owned; LLM-assisted matching/query interpretation routes only through contextual-orchestrator.

Foundation PR #1 currently carries a test-first publication-evidence regression and is intentionally not merge-ready until the exact-head RED is observed and repaired.

Fresh GRC reference-client evidence — 2026-09-01

Do not use the scheduler's remembered GRC parent SHA. ContextualWisdomLab/governance-risk-compliance#64 is still open/draft/mergeable with child head eea4f054fbfe8901eb1fd4562094e552f93df1e6, but its base branch feat/grc-analytics-query-contract-20260831 has advanced: parent PR #62 is now at 72e0120085430a269a73c0503bcab307fd2e645c (open, non-Draft, mergeable). Therefore #64's prior Product GREEN is useful predecessor evidence only; it is not current integrated GRC reference-client evidence.

ConceptWeave Client acceptance must remain independent of those internal GRC SHAs and use a versioned language-neutral fixture. Before declaring the GRC golden client current, require the GRC owner path to integrate the fresh #62 parent into #64 without destructive history, then re-run its exact-head Product/security/review gates. ConceptWeave's side must prove the same published semantic-release fixture validates offline and that proposed/superseded/unknown-version/digest-invalid variants fail closed.

This is intentionally a cross-repository acceptance coordinate, not permission for ConceptWeave to modify GRC source or PR state.

Consensus accepted-search delta — 2026-09-01

The fresh Client/alignment search set adds two relevant studies not yet represented in docs/doctoring/RESEARCH_CAPABILITY_TRACEABILITY.md:

He, Chen, Dong, & Horrocks (2023), Exploring Large Language Models for Ontology Alignment (current Consensus record: arXiv abs/2309.07172; 64 citations). Class: client; decision: adapt. Product implication: equivalence matching must test concept labels together with bounded structural context, including OAEI Bio-ML-style hard subsets. Add a structural-context ablation beside concept-only matching; zero-shot LLM output remains a correspondence candidate and never authoritative alignment.
Amini, Saki Norouzi, Hitzler, & Amini (2024), Towards Complex Ontology Alignment using Large Language Models (current Consensus record; pp. 17–31; 35 citations). Class: client; decision: adapt. Product implication: complex-correspondence evaluation should permit bounded ontology modules/rich local context rather than only 1:1 label matching. Add module-size/context-bound receipts and complex-alignment fixtures; rich prompts must not bypass retrieval bounds, evidence provenance, or release truth state.

GenOM (Song, Chen, & Schmidt, 2025) is already mapped in the current register to definition-enriched retrieval/matching and deterministic lexical evidence, and MILA/OLaLa are already mapped to retrieve-before-prompt and OAEI evaluation, so no duplicate rows are needed.

As with the Generation delta, do not move foundation PR #1 solely for this documentation update while its publication-invariant RED head is waiting for a runner. Add these two rows in the first code-current documentation commit after the current RED/GREEN authority-boundary repair.

GRC reference-client contract — fresh consumer evidence

Revalidated the first real consumer before defining ConceptWeave's public release contract.

Current GRC integration lane:

ContextualWisdomLab/governance-risk-compliance#63 remains the cross-repo acceptance issue.
GRC PR #64 is currently Draft/mergeable at exact head ddee8c9f254a95a8e205a8bb7b6a54f74351395f, stacked on its Analytics root. Its current exact-head Product evidence is recorded by that owning repository; ConceptWeave does not transfer or reinterpret it as ConceptWeave CI evidence.
GRC's provider-neutral SemanticModelClientPort intentionally defers the concrete adapter until ConceptWeave publishes a versioned contract.

The current GRC consumer boundary requires only a minimal immutable reference today:

release_id
schema_version
content_digest_sha256 (exact lowercase 64-hex)
publication_state

For authoritative GRC use, the release must be published; proposed/superseded releases fail closed. The GRC port also requires validate_release and resolve_term and explicitly does not carry endpoint/provider credentials/raw source/generator-private state.

ConceptWeave must generalize, not mirror GRC's local DTO

The public semantic_release contract should include the GRC minimum while remaining language-neutral and sufficient for other clients. Its first version must define at least:

release identity and semantic-release schema version;
immutable content digest/canonicalization rules;
publication state and release-level truth/governance semantics;
ontology/semantic-model version coordinates;
concepts/relations with stable identifiers and truth status;
evidence/provenance references;
physical↔semantic mappings;
dimensions/measures including deterministic source/formula/null/time metadata where present;
constraints;
compatibility/deprecation/supersession coordinates.

The Client side must be able to validate those deterministic fields offline, without contacting contextual-orchestrator or any model provider. Matching/alignment/query interpretation may optionally use LLM assistance later, but only after deterministic release validation and only through contextual-orchestrator.

Next executable RED after runner admission

Before implementing release production code, add a failing contract test proving the current repository cannot yet:

accept a canonical published release with the GRC-required coordinates;
reject proposed/superseded, malformed/unknown-version, non-canonical digest and provenance-invalid releases;
resolve a stable concept/mapping from a published fixture without provider access;
diff a previous and current release and identify affected semantic identifiers;
preserve generated/private implementation independence from the Client package.

Then implement the minimal general Release Contract + Rust-first Client boundary and re-run the same fixture against the GRC reference client. Do not add a network endpoint or GRC-specific adapter merely to satisfy this fixture.

ConceptWeave #4 currently blocks executable RED/GREEN because Product/Security/SAST jobs on PR #1 have not acquired runners. Keep PR #1 exact head stable until that admission boundary moves; queued evidence is not a test result.

Fresh Consensus interoperability delta — 2026-09-01

The accepted Client/alignment search set adds two domain-specific but product-relevant studies not yet represented in docs/doctoring/RESEARCH_CAPABILITY_TRACEABILITY.md. They are retained as bounded evidence, not generalized accuracy claims.

Pournik et al. (2026), Large Language Models for Health Knowledge Modelling in Data Interoperability: A Scoping Review of Methods, Standards, and Applications (Studies in Health Technology and Informatics, 336, 1287–1291; current Consensus citation count 0). Class: client / cross_cutting; decision: research_only. Capability implication: terminology mapping, schema integration, ontology alignment, and KG construction repeatedly use retrieval/embedding/LLM methods, while trustworthy use still needs standardized benchmarks and explainability. Keep this as secondary evidence for benchmark disclosure/explainability requirements; healthcare-specific standards/results do not become ConceptWeave defaults.
Ozonze, Okonor, Dike, & Adedeji (2026), Enabling interoperability across disparate health data sources using Large Language Models (PLOS Digital Health, 5; current Consensus citation count 0). Class: client; decision: adapt. Capability implication: cross-schema mapping errors should be stratified by semantic confusion, structural misalignment, ambiguous terminology, and terminology variance rather than reported only as aggregate F1. Add these error families to GRC/public cross-repo matching diagnostics and require human/steward validation for authoritative adoption. The healthcare CDM→FHIR setting and web-chat execution are not production architecture for ConceptWeave.

The same fresh search re-returned MILA, KROMA, GenOM, Agent-OM, LLMs4OM, OLaLa, and He et al.; these are already registered or already queued as research deltas, so no duplicate rows should be added. The two rows above belong in the first code-current research-register/bibliography commit after runner admission can execute the resulting ConceptWeave head.

Consensus records used for this delta:

Live GRC reference-client coordinate was also re-read: governance-risk-compliance#64 remains open/Draft/mergeable at child head 317524f44544cc94506199c5bd8327dd1a083dd7, stacked on Analytics parent head 72e0120085430a269a73c0503bcab307fd2e645c. Its current contract still deliberately defers the concrete adapter until ConceptWeave publishes the general Client/release contract. Do not encode these GRC branch SHAs into the language-neutral wire format or compatibility semantics.

GRC reference-client parity exposed a concrete Client-contract mismatch on the current PR #5 stack: GRC's SemanticReleaseRef requires a lowercase SHA-256 content coordinate, while ConceptWeave ReleaseDigest and contracts/semantic-release.schema.json currently accept uppercase A-F as well. This is a canonicalization/interoperability defect, not cryptographic-byte verification yet.

TDD RED head is now 41629bd0f24c4cbe21b3d14dcec645f980e921b7: it adds a Rust regression that requires sha256: + 64 uppercase hex characters to be rejected, plus a JSON fixture semantic-release.invalid-uppercase-digest.json wired into the Product contract suite. No production digest/parser/schema fix has been applied before observing RED. Product run 33528732254, job 99926129453, is currently queued on requested ubuntu-24.04 with runner_id=0/no steps, so the RED remains pending execution and is simultaneously tracked through central .github#712 runner-acquisition RCA. Once the same test-only head actually executes and fails at the intended Rust/schema boundary, the narrow GREEN is to require canonical lowercase [0-9a-f] in both Rust and JSON Schema and then re-run exact-head parity.

This keeps the GRC-specific observation as evidence while repairing the GENERAL ConceptWeave public release contract rather than adding a GRC-only exception.

Fresh GRC reference-client evidence, 2026-09-02.

ContextualWisdomLab/governance-risk-compliance#64 is still open/Draft/mergeable at exact head ecfa729a29dfba6cd3c78046cda2d9d2518fe06e, stacked on Analytics parent dbe7f5d42db0bb1b24d8a0b51eae5032d098d7f5. Its exact-head Product push/pull-request runs are GREEN, but supplier Security/SAST/release evidence is intentionally absent and the child remains Draft. GRC currently validates only consumer-owned pre-wire coordinates: Published state, bounded nonblank release/schema identities, and a lowercase SHA-256 content coordinate. It explicitly refuses to invent ConceptWeave schema-version support, provenance/signature representation, mappings, dimensions/measures, or diff wire format before this generic Client contract is published.

That makes the current PR #5 integrity correction a generic contract requirement rather than a GRC special case. The release manifest itself contains artifact_digest; therefore the old wording that the digest covers the entire serialized release manifest is self-referential unless a canonical exclusion rule exists. Current test-only PR #5 head ed22957471f7c62b644f68e4f37bdb86327d8668 instead specifies detached immutable semantic-artifact bytes as the digest scope. Product run 33562998629 / job 100039652518 remains queued before checkout, so this is not yet an observed RED and production/schema/ADR changes remain deliberately withheld.

Cross-repo acceptance after the RED/GREEN sequence: GRC must be able to receive the manifest coordinate, independently hash the detached artifact bytes offline, reject digest mismatch before semantic use, and do so without importing generator internals or acquiring a provider connection. The contract must stay language-neutral so later bindings reproduce the same bytes/digest semantics.

Client-track research acceptance delta from the 2026-09-02 Consensus reconciliation staged on Issue #2.

Two relevant Client papers not present in the remembered baseline are now explicit acceptance evidence:

Song, Chen, & Schmidt (2025), GenOM: ontology matching with description generation and large language models — primary class client; current Consensus metadata: World Wide Web, vol. 29. Add an optional description-enrichment stage before embedding candidate retrieval, preserve exact lexical/structural evidence as independent signals, and evaluate description/retrieval/lexical ablations. Generated definitions remain proposed evidence and never authorize a correspondence.
He, Chen, Dong, & Horrocks (2023), Exploring Large Language Models for Ontology Alignment — primary class client; current Consensus metadata: ArXiv abs/2309.07172. Use only as research_only support for label + structural-context representations and an OAEI Bio-ML benchmark/ablation adapter; its preliminary status must remain visible.

The accepted set also revalidated OLaLa, LLMs4OM, MILA/PDFS and Complex Matching. Client evaluation therefore needs to expose candidate-retrieval recall, final P/R/F1, complex-correspondence accuracy, representation/context ablations, LLM-call count/reduction and abstention—not only aggregate F1. GRC remains the mandatory enterprise fixture in addition to public OAEI-style fixtures.

No Client source head is moved for this research update while exact 398d8d6878706251397267d8fd8a660d4c2ecc7e Product evidence remains queued before runner assignment.

Fresh GRC reference-client conformance snapshot for the Client P0 lane; this is PR-state/acceptance evidence only and does not move the test-only Client head.

GRC canonical default/protected source remains develop@85da4e1c64e5b46ca3a11ca71654a82b57366a3e.
governance-risk-compliance#63 is an open P0 issue, not a PR; it continues to require a provider-neutral SemanticModelClientPort, offline published-release validation, mapping/dimension/measure/diff/query-plan consumption, fail-closed degraded mode, tenant/purpose isolation, and no cross-service SQL.
GRC stacked reference-client PR #64 is currently open/Draft/mergeable at exact child head ecfa729a29dfba6cd3c78046cda2d9d2518fe06e, base feat/grc-analytics-query-contract-20260831@dbe7f5d42db0bb1b24d8a0b51eae5032d098d7f5. It deliberately defers the concrete ConceptWeave adapter until the generic supplier contract is published.
ConceptWeave Client PR feat(client): add offline semantic release admission contract #5 remains test-only at exact 398d8d6878706251397267d8fd8a660d4c2ecc7e; Product run 33584293306 / rust-quality job 100105057506 is still queued on explicit Ubuntu 24.04 with runner_id=0, no steps/checkout. Therefore the intended missing verify_detached_artifact RED is not yet observable and production release-integrity code remains withheld.

Cross-repo acceptance remains general rather than GRC-specific: the eventual published semantic_release must let #64 replace its placeholder consumer coordinates with the stable ConceptWeave contract while preserving GRC authority and working offline for deterministic admission. Do not wire #64 to ConceptWeave branch internals or moving source.

Current Client Consumption progress, 2026-09-02, linked to canonical PR #5 rather than a new branch.

PR #5 exact head is 9df087a5d8f6e46c7e2e91e9c447ee504d00c677, still Draft/open/mergeable and stacked on foundation PR #1. This iteration preserved and completed the concurrent writer's test-first legacy-compatibility lane. RED commit 091c36b24330671952de378d3596afcde5f62351 specified Current, SupportedLegacy, and Unsupported classification plus fail-closed invalid policy. Production commit 2a4596e88d016e01a3bffded7a8436b14d55ec18 adds an explicit current contract version and explicit supported-legacy set; it never infers compatibility from version ordering, and supported legacy releases still require the same Published + Authoritative admission gate. PRD/ARCHITECTURE/CHANGELOG/product-gap reconciliation is carried through the current head.

Exact-head Product run 33606488054, job 100171557081, is still queued before execution and is not treated as GREEN. Existing deterministic client slices remain offline admission, exact concept resolution, release diff, and exact detached-artifact SHA-256 verification. The next Client gaps remain explicit deprecation/supersession semantics, relation/physical-mapping/dimension/measure inspection, stable signature/provenance verification when publication defines the signing contract, research-backed optional match/align/explain through contextual-orchestrator, and a versioned semantic query-plan DTO while consumers retain physical authorization/execution.

2026-09-02 exact-head client evidence update: PR #5 is still Draft/open and now at 9688dde08368a9324d64abe25122036719dcc1fd; Product run 33610145373 exists for that exact head and is queued before execution, so no GREEN is claimed. The bounded supersession slice is now implemented test-first: RED 67132eda0e25d23a4185d4b98f0c6dc3b11e17a4 required exact predecessor/successor release id+digest references, nonblank rationale, self-supersession rejection, exact-reference mismatch failure, and ordinary authoritative-use admission; production 2c4a7954ad3a4fb0dd0a5482a6870fcc0d2996a3 implements SemanticReleaseReference, ReleaseSupersession, and validate_supersession; edge test e04c7bdd5934f175d9e5cd9b3e2ab26802a64e41 binds mismatch to digest identity and covers both predecessor/successor admission; later error/docs/PRD/architecture/gap reconciliation reaches the exact current head. ADR 0004 was repaired from premature Accepted to Proposed because this stacked PR is not integrated and exact-head checks/governance are incomplete. Issue #3 remains open: next bounded Client gaps are the language-neutral supersession/publication-receipt contract, then typed relation/mapping/dimension/measure resolution, signature/provenance verification, match/align/explain, semantic query-plan, and the anonymized GRC reference-client fixture. Predecessor/queued evidence is non-passing; do not ready/merge this child until PR #1 integrates and the child is restacked/revalidated.

2026-09-02 fresh Client/GRC acceptance coordinate. This supersedes earlier ConceptWeave Client-head coordinates in this issue thread without changing the contract boundary.

ConceptWeave Client PR feat(client): add offline semantic release admission contract #5 is currently Draft/open/mergeable at exact 143506eb66b6904b770a628ac793af2253559df2, stacked on foundation bba351b77bf5f1ab5cfd55979fbb2bd158f78b81.
Its Product run 33610537831, rust-quality job 100184362749, still has runner_id=0, steps=[], label ubuntu-24.04; therefore the language-neutral supersession/publication JSON-contract RED is not yet observed and no production schema/fixture implementation is authorized from queued evidence.
GRC acceptance issue governance-risk-compliance#63 remains open. Its reference-client PR #64 is currently open/Draft/mergeable at exact ecfa729a29dfba6cd3c78046cda2d9d2518fe06e, stacked on Analytics parent dbe7f5d42db0bb1b24d8a0b51eae5032d098d7f5. Exact-head GRC Product evidence is GREEN, but #64 deliberately defers a concrete ConceptWeave adapter until this generic supplier contract is published.
#64's PR body still contains historical ConceptWeave supplier-head coordinates. Treat those supplier coordinates as stale external prose; ConceptWeave live state above is authoritative for this owner lane. Do not mutate GRC from here and do not encode either repository's branch SHA into the language-neutral wire contract.

Cross-repo GREEN remains: one published generic semantic_release/Client fixture validates offline in ConceptWeave and through GRC's SemanticModelClientPort; proposed/superseded/unknown/malformed/digest-invalid variants fail closed; mappings/dimensions/measures/diff/query-plan semantics preserve GRC tenant/purpose and deterministic-data authority. Generator internals, provider state and moving branches remain outside the client contract.

Client-track research refresh is staged in Issue #2 comment 5513924952 from the same accepted 2026-09-02 Consensus search set; every relevant returned paper was assigned a primary generation / client / bridge / cross_cutting category rather than left as bibliography-only evidence.

Client-specific additions beyond the existing baseline are now explicit acceptance input:

Song, Chen, & Schmidt (2025), GenOM: generated-definition enrichment may contribute proposed alignment evidence alongside exact lexical matching and embedding retrieval; add definition-quality and component-ablation metrics, but never overwrite source definitions.
Lushnei et al. (2025), Large Language Models as Oracles for Ontology Alignment: add a typed uncertainty/borderline seam so optional contextual-orchestrator calls validate/rank only uncertain correspondences; benchmark oracle-call reduction, abstention and false-accept cost. LLM output is not ground truth.
Mavridis et al. (2025) is classified bridge: adapt its preprocessing/retrieval/mapping decomposition for Generation↔semantic-consumption evaluation, while rejecting its medical/tool-specific BioBERT/ChromaDB choices as generic ConceptWeave defaults.
Ding et al. (2026) and Li et al. (2026) strengthen the client-side requirement that alignment evaluation be reproducible, stage/operation-specific and steward-visible rather than an aggregate model score.

When PR #5's current test-only head obtains its real RED and a source-changing Client commit becomes causally justified, fold this research delta into docs/doctoring/REFERENCES.md plus the research→capability artifact and bind it to the matching/alignment API tests. Do not move #5 merely for a research-doc commit while its sole exact-head Product evidence is still queued.

Fresh owner traceability, 2026-09-03 KST. Client root remains stacked through PR #5. Current exact head is 9c278598001c502a733100d11e901538c3dc2677; Product run 33730262561, job 100568327581, still requests explicit ubuntu-24.04 and is queued before any executed step/checkout with runner_id: 0.

The immediately preceding exact RED is already real evidence, not a planned test: head 0c32a7b55d3c687ab76cee789962866573496ba1 acquired an Ubuntu 24.04 runner, proved exact checkout and fmt, then Clippy failed E0599 because the test contract required SemanticReleaseClient::verify_detached_artifact and production did not expose it. Current head 9c278598... contains only the causal production/rustdoc repair for detached immutable artifact bytes. Do not transfer predecessor GREEN and do not move on to the next schema merely because this source change is mechanically mergeable.

The next Client RED remains intentionally unimplemented: Product's contract stage requires contracts/semantic-release-supersession.schema.json plus valid/invalid supersession fixtures. It should be implemented only after this unchanged head executes through the repaired API and exposes that missing contract boundary. This preserves a real RED→minimal fix→GREEN lineage rather than pre-solving the next test.

Fresh authoritative read of GRC protected develop now resolves to 83e13a1fe80cbf63fb089c337d4da749c4a7956c; earlier coordinates observed during this loop are stale. This mutable coordinate is reference/client-conformance evidence only, not a ConceptWeave dependency. GRC must continue consuming only a published/versioned semantic_release through its ACL/Client port. Central intermittent runner admission remains owned by ContextualWisdomLab/.github#712; no ConceptWeave no-op push, duplicate rerun, or runner-selector churn is warranted while this exact head remains queued.

2026-09-03 Client Consumption owner update after fresh live-state repair:

PR feat(client): add offline semantic release admission contract #5 exact head advanced non-force to 1e543bbcc343adad04b748109cdd2a22b0d49f1e.
Hosted predecessor 0c32a7b55d3c687ab76cee789962866573496ba1 already supplied the real detached-artifact RED: Product 33664177838 / job 100361706615 reached Clippy and failed E0599 because verify_detached_artifact was absent. Production 9c278598001c502a733100d11e901538c3dc2677 repaired only that API/rustdoc boundary.
Fresh current-source review then found PRD/TRD/UML/ADR 0004/TEST_STRATEGY/SECURITY/CHANGELOG/gap-baseline drift still naming the retired serialized-artifact API or a future verifier. Test commit 5bdb873f97aa663e413c12f572df2b92143344a3 pins the public documentation contract; repair commit 1e543bb... aligns all public docs to verify_detached_artifact and detached immutable semantic-artifact digest scope without changing production digest behavior.
Current Product run 33741224641, job 100603361888, is queued before execution; queued evidence is non-passing. Do not churn/rerun without a causal condition change.
Fresh GRC reference coordinate is protected/default develop@83e13a1fe80cbf63fb089c337d4da749c4a7956c. It remains mutable reference evidence only, never a ConceptWeave dependency.
The next accepted Client RED remains the missing language-neutral semantic-release-supersession.schema.json/fixture contract, and must be observed only after the exact current head reaches that Product stage.

No generator-private dependency, GRC special-case model, provider call, cross-service SQL, self-approval or gate weakening was introduced.

Client Consumption exact-head update (2026-09-04): Product 33741224641 / job 100603361888 finally acquired Ubuntu 24.04 runner 1001651738 for 1e543bbcc343adad04b748109cdd2a22b0d49f1e, verified exact checkout, and passed CI-contract validation, Rust 1.98.0, fmt and Clippy. cargo test --workspace then failed exactly at retired_serialized_artifact_api_is_absent_from_public_docs: docs/product-technical-gap-baseline.md still literally reproduced the retired serialized-artifact method identifier while describing the guard test. This is a real documentation/API parity RED, not a runtime/API behavior defect.

Minimal causal repair is now fa0e31272097d154427ac53bfb7cc60dc96e72c8: only the baseline wording changed so it still records the retired API concept without reproducing the prohibited identifier. Production Rust, digest semantics, publication authority and public schema behavior are unchanged. New Product run 33814440715 / job 100843333180 has materialized for the exact repair head and is currently queued pre-runner on explicit ubuntu-24.04; predecessor GREEN does not transfer.

Next gate remains unchanged: exact repair head must pass the documentation contract and reach the public JSON-contract boundary before the missing language-neutral supersession/publication schema + fixtures are treated as an observed RED and implemented.

2026-09-04 successor correction: Client PR #5 is stacked on Foundation e1b0eaa544c92f3526d91c33d50e11d17115a5cf at exact head 30fdde3746f023a2fab010bcb0b46e670ded0b6e. c588ba4... established the non-force merge ancestry and forward commit 30fdde3... adopted the Foundation doctoring test file; no Client contract delta was discarded. Current Product 33836434482, job 100909811550, is queued on explicit ubuntu-24.04 before runner assignment. The next Client RED remains the absent language-neutral supersession/publication JSON Schema plus valid/invalid fixtures; those artifacts remain intentionally absent until this exact head first clears the inherited Foundation doctoring lane and then reaches that public-contract boundary.

2026-09-04 successor correction: Foundation is now 707e687bb510d3f1fd5d1bdc94e590b30ffbb641, with the doctoring RED contract strengthened so each authoritative APA record binds the authoritative URL and version-of-record year in the same entry; the Amini KGSWC 2024 chapter therefore requires Springer (2025).. Client adopted that one-file Foundation delta through a two-parent non-force merge and is now 0f878fc796feb93406dedbbad85351282d3ed7bc; old-child→new-child comparison changes only research_reference_traceability.rs, so the existing supersession/publication schema RED lineage is preserved. Current Product 33850422999 / job 100951717500 is still pre-runner queued with zero steps. Do not add the missing Client schema/fixtures before this exact head passes the Foundation doctoring lane and reaches the Client RED.

2026-09-04 successor correction: Foundation live-state baseline drift was a separate valid docs-to-code finding and has been repaired on Foundation b69f6e797834cb74cb70d093c71efa1d5a86bbb5. Client was non-force restacked by two-parent merge to 57259ec7667adf85344245a266507fee8de848d2; the Client semantic/contract delta is preserved and the only adopted Foundation delta is docs/product-technical-gap-baseline.md. New Product run 33860241181, job 100982777252, is queued on ubuntu-24.04 with no runner/steps yet. The legal order remains Foundation bibliography RED -> minimal APA repair -> GREEN, then missing language-neutral supersession/publication schema+fixtures RED -> minimal repair -> GREEN. Predecessor Product evidence does not transfer.

2026-09-04 successor correction: Foundation is now a8b95a3ab336986fd8e3da6b5a9f267cbf08a253. Exact repository-state inspection showed the adopted He/Amini traceability entries had no matching authoritative bibliography records; hosted runner RED was not observed, so the evidence is static/deterministic rather than a claimed hosted RED. Minimal 17d604150a7ab334412b41136d8313c1d898e9d5 added only the two records, followed by documentation-only baseline refresh a8b95a3.... Client #5 was non-force restacked twice and is now 67c104987e54b39e4c9a9ecae803306f9a6ab645; comparisons show only the Foundation bibliography and baseline documents changed, preserving every Client semantic/contract delta. Current Product 33865125357 / job 100998123088 is queued/non-terminal. The missing language-neutral supersession/publication schema and fixtures remain the next Client RED only after inherited Foundation quality reaches terminal evidence.

2026-09-04 successor correction: PR #5 is now based on Foundation a379c7230253c3aaa0c6fc8486cc39be421eca35 at exact child head c0dadd96ff19b3ebec5e7b1e1efb50ae5a0d627e. Old-child 67c104... -> current comparison changes only the inherited Foundation truth-state mismatch fixture/schema, five Product JSON-contract check lines, and refreshed gap baseline; the Client release/supersession delta remains intact. Current Product 33871532542 / job 101018424248 is pre-runner queued on ubuntu-24.04 with runner_id=0, steps=[]. The missing language-neutral supersession/publication schema and fixtures remain the next Client RED only after Foundation terminal evidence; no schema/fixture repair has been preemptively added.

2026-09-04 Client successor correction

PR #5 remains Draft/open/mergeable on Foundation a379c7230253c3aaa0c6fc8486cc39be421eca35, but its exact head has advanced from the stale body value c0dadd96... to 61776fbf5969ec4f8897f48b7bd410052f83ea9d. The one intervening commit is an integration-gate repair, not a replacement of Client semantics: Source Observation retains ADR 0004, Client moves to ADR 0005, detached-artifact documentation/tests are restored, source-coordinate coverage accounting is repaired, and the compatibility/digest API remains deterministic.

Current Product 33872841480, job 101022689003, is queued before runner assignment (ubuntu-24.04, runner_id=0, steps=[]). No submitted reviews or inline review threads are currently returned for #5. The next accepted Client RED remains the missing language-neutral semantic-release-supersession.schema.json plus valid/invalid fixtures, and it must not be implemented before Foundation terminal evidence and the exact child actually reaches that contract failure.

2026-09-04 successor correction: Client PR #5 is now a379c723... -> 0087f6c8bdafcc9fb08eb14f962597b07560272d, Draft/open/mergeable. Predecessor 61776fb... reached hosted Product 33872841480/101022689003: CI-contract/toolchain/fmt/Clippy/tests/rustdoc/100% owned coverage passed, then public-contract validation failed because contracts/semantic-release-supersession.schema.json was missing. Concurrent successor 0087f6c... landed the same minimal four-file repair while this writer was preparing it, so it was adopted rather than overwritten: Draft 2020-12 supersession schema plus valid, invalid-digest, and invalid-rationale fixtures. The schema mirrors exact release-reference IDs/digests and nonblank rationale; Rust remains the semantic gate for self-supersession/exact admitted-release matching. Current Product 33883553217 is queued, so no exact-head GREEN is claimed.

2026-09-05 successor correction — the body’s old e1b0eaa... -> 30fdde... Client lane is no longer current authority.

Current prerequisite is Foundation PR #1 8e8783286eac7567803568d9a91010daaf028074; current Client PR #5 is 475000ed50aaedf77ad6cc5c1e5664fb7d4c5dc8, Draft/open/mergeable and non-force descended from that Foundation head. The initially missing public supersession schema already recorded a real hosted RED on predecessor 61776fb... and was repaired in 0087f6c....

A later current-line review found five additional fail-closed defects. Test-only 6cf136b... encodes them. The branch now has causal repairs for all five: v1 schema contract-version binding (af1d123c...), LLVM expansion/total-region coverage (1ac0758d...), machine-readable cross-field self-supersession validation plus negative fixture (e54a0b30...), immutable release-id conflict + governed Superseded predecessor handling (663e52d6...), and the corresponding edge/error coverage (d6690051...). e0ef02ee... non-force adopted Foundation #14 without dropping the Client contract gate, and 475000ed... reconciles ADR 0005 plus the product/technical gap baseline.

Acceptance has not advanced to GREEN: the latest exact-head read for 475000ed... returned no pull-request workflow run, so the five review threads intentionally remain unresolved and #5 remains Draft. Predecessor checks, local source inspection and focused semantic-validator execution do not transfer to this head. The next legal Client action is exact-head Product/security/review evidence; any concrete GRC consumer remains downstream of a released/versioned generic ConceptWeave contract, never this mutable branch.

2026-09-05 current-head correction: Client #5 is now cbb9cda0c93d8b762195423834f1d6a27dbfa613, Draft/open/mergeable, stacked on Foundation #1 5cdd319b9425989e632149b243a3308dd630c0ae. The older exact-head/run coordinates in this issue body are historical evidence only.

A fresh repository bootstrap finding changes the immediate TDD order: protected main@f4f440dd58c77d7cd90dff8a1eb2eeb9a9940425 has no .github/workflows/product.yml, so Product pull_request CI cannot materialize for #1/#5 from their current base. PR #35 daa543ce2cc2b2eb6d35a7265abcf2a7466e7381 is the minimal normal-merge prerequisite that installs only the pull-request Product workflow on main; after it is ordinarily integrated, Foundation #1 must obtain Product evidence on one unchanged exact head before Client's next public-contract RED is promoted.

The next Client RED remains the missing language-neutral supersession/publication JSON contract and valid/invalid fixtures after inherited Foundation gates are actually satisfied. Do not convert predecessor/local checks or descendant evidence into current-head Client GREEN, and do not add a GRC-special contract ahead of the generic released Client seam.

Correction to my immediately preceding current-head note: the sentence naming a missing supersession/publication public contract was stale and is superseded by this comment. Direct inspection of current Client #5 cbb9cda0c93d8b762195423834f1d6a27dbfa613 confirms contracts/semantic-release.schema.json exists as Draft 2020-12 with contract_version: const "1.0.0", canonical artifact digest/provenance/publication/truth fields, and the current PR body records machine-readable supersession validation plus deterministic semantic checks and all five prior inline findings as source-repaired.

The current Client blocker is therefore not “add the missing schema.” It is prerequisite/exact-head acceptance: bootstrap #35 must first put the repository-owned Product pull-request workflow on protected main, then Foundation #1 5cdd319... must run and integrate through ordinary protection; only afterward should #5 be non-force restacked as needed and obtain its own unchanged exact-head Product/security/SAST/dependency/review GREEN. Its next semantic/buyer gap must be chosen from fresh code-current review after those gates, not from the historical issue text.

2026-09-23 authority correction

The issue body’s 2026-09-10 Foundation/Client/Product and central .github#2040 coordinates are historical. Current Foundation is #1 84e56256a794b11568c271818c55c899ecfcbb60; Client Consumption is #5 5a3afdc4b6b4440b241291953c55dcd0765457f8, Draft/mergeable on that exact parent. The public Client boundary remains unchanged: consume only governed immutable semantic_release contracts; no generator-private adapters/prompts/tables/orchestration state, mutable sibling heads or cross-service SQL.

Canonical Product producer is #35 d7b7e30b278ec2f27096b4d313c7d5eaf5387ddc, still Draft with nonterminal current central evidence. Its Product control-plane helpers execute from separately verified ${{ github.workflow_sha }} source rather than candidate-owned scripts. Protected ConceptWeave main@f4f440dd58c77d7cd90dff8a1eb2eeb9a9940425 still lacks Product.

Product protected-policy work is .github#2348/#2350-owned. #2350 exact 28246b1e77ac387273aad63a8bb6746c331d633b intentionally requires an immutable protected Product blob coordinate before evaluate bootstrap/activation; current owner/central runs are queued. Generic solo-maintainer approval/bypass remains .github#772/#1351/#1644-owned. Do not duplicate either repair in Client.

Required Client sequence is: central runtime/generic governance convergence → #2350 immutable-coordinate source acceptance with no live mutation → #35 normal producer landing → ordinary-reviewed protected Product blob adoption → dedicated ConceptWeave Product organization ruleset in evaluate → Foundation Product/Rust reconciliation + real required-workflow canary + guarded active proof → Foundation normal merge → #5 ordinary parent adoption and fresh exact-head Client evidence. Only then continue the next Client buyer gaps listed in this issue (explain/match/resolve/validate/diff/compatibility/query-plan, evidence-bearing alignment/abstention and immutable release conformance).

Navigation Menu

Repository navigation

[P0] Build semantic-model client consumption, alignment, and query contract #3

Buyer outcome

Client Consumption boundary

Current dependency-first Client lane — 2026-09-10

Next Client gaps after exact-head verification

Research/evaluation basis

Acceptance

Out of scope

GRC reference-client binding

GRC reference-client contract — fresh consumer evidence

ConceptWeave must generalize, not mirror GRC's local DTO

Next executable RED after runner admission

Fresh Consensus interoperability delta — 2026-09-01

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[P0] Build semantic-model client consumption, alignment, and query contract #3

Description

Buyer outcome

Client Consumption boundary

Current dependency-first Client lane — 2026-09-10

Next Client gaps after exact-head verification

Research/evaluation basis

Acceptance

Out of scope

Activity

seonghobae commented on Sep 1, 2026

GRC reference-client binding

seonghobae commented on Sep 1, 2026

seonghobae commented on Sep 1, 2026

seonghobae commented on Sep 1, 2026

seonghobae commented on Sep 1, 2026

GRC reference-client contract — fresh consumer evidence

ConceptWeave must generalize, not mirror GRC's local DTO

Next executable RED after runner admission

seonghobae commented on Sep 1, 2026

Fresh Consensus interoperability delta — 2026-09-01

seonghobae commented on Sep 1, 2026

seonghobae commented on Sep 1, 2026

seonghobae commented on Sep 2, 2026

seonghobae commented on Sep 2, 2026

seonghobae commented on Sep 2, 2026

seonghobae commented on Sep 2, 2026

seonghobae commented on Sep 2, 2026

seonghobae commented on Sep 2, 2026

3 remaining items

seonghobae commented on Sep 3, 2026

seonghobae commented on Sep 3, 2026

seonghobae commented on Sep 3, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 4, 2026

seonghobae commented on Sep 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions