Skip to content

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

Open

Description

@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. Optional LLM proposal work 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 authority — 2026-09-10

Client parent #5 is 6873ec0c0a701b2c59f3e0785d48d8739f019d5b; Source Observation PR #6 is exact 77c143d4ef8a6d8d23196682d6e3b0fd954cd115, OPEN Draft/mergeable. Ordinary non-force reconciliation at b614fddc3331365da84733f660a429ed71b83182 preserved pre-restack Source Observation 331f8edcd7cebb1719e5cea3187f3848ce7b9e71 and current Client; successors from 9fbedde... through eafc587... to 77c143d... are active-gap documentation updates only. Production/test/contract/dependency source is unchanged, but predecessor execution does not transfer to the current head.

The port/aggregate contract includes owner-computed deterministic source-content identity, exact source-key + immutable connection-policy binding, exact-schema/resource-envelope authorization, a single non-resetting operation budget across authorization and adapter work, awaitable Send execution, typed cancellation/resource/invalid-capture failures, stale-binding rejection, exact-schema snapshot containment, binding-preserving immutable receipt provenance, and single-use AuthorizedObservationRequest consumption. DSNs, credentials, provider runtime objects, foreign business truth and wall-clock provenance remain outside the provider-independent domain seam.

The UNIQUE null-semantics lineage is repaired: optional PostgreSQL uniqueness semantics distinguish unknown, observed distinct and observed not-distinct in current snapshot/receipt identity; historical receipt versions are not silently rewritten.

Exact verification boundary

Pre-restack #6 head 331f8ed... locally executed Rust 1.98 evidence: 132 tests across 42 suites including two doctests, fmt, strict all-target/all-feature Clippy, warnings-denied rustdoc, release build, Product CI contract/schema/fixture/lockfile checks, and normalized owned-production coverage of 228/228 functions, 2,026/2,026 regions and 194/194 branches. Raw LLVM was 1,807/1,825 lines, 2,192/2,206 regions and 188/194 branches and remains diagnostic.

That evidence does not transfer to current exact 77c143d..., even though the later successors are docs-only. Current-head Rust/coverage, independent review and hosted Product/security/dependency evidence must be regenerated. Product bootstrap #35 remains blocked by the central .github CodeQL owner path; leaf no-op/manual reruns are not acceptance evidence.

PostgreSQL 18 representation prerequisite

The current immutable observation aggregate represents tables, columns and table constraints, but the concrete adapter acceptance below also requires metadata that cannot be losslessly forced into those shapes. Before live adapter admission, extend the owner model and digest/receipt coordinates for observed PostgreSQL evidence rather than dropping it in the adapter:

  • relation kind and table-level comments;
  • indexes as first-class evidence, including unique/null semantics, key versus included attributes, readiness/validity/liveness, expression coordinates and partial predicates; indkey expression positions must not be collapsed into a column-name vector;
  • domains and enums as schema-scoped qualified source-type evidence, not table children. Same-name types in different schemas require distinct coordinates, and a domain/enum must remain addressable even if its schema has no observed table;
  • each column must preserve display/rendered type text separately from an exact qualified source-type reference. Type identity must resolve to the immutable qualified type evidence and must not be inferred from search_path;
  • reconstructed definitions must be labeled as server-reconstructed evidence. pg_get_constraintdef, pg_get_indexdef and pg_get_expr output is not original DDL text.

Existing #6 repairs already preserve targeted SET NULL/SET DEFAULT columns and modeled validation/enforcement state; representation expansion must not regress those fields.

Digest, authorization, type identity and receipt-version invariant

Current owner framing is explicitly conceptweave.postgres_schema_snapshot.v2 and hashes table/column/constraint evidence only. Do not append new material facts under the same identity family. Preserve frozen v2 reproduction and introduce a successor digest framing (v3 or equivalent explicit version) that binds every new material PostgreSQL fact.

Authorization must expand with representation. Current construction proves schema scope by iterating observed tables. Domain/enum evidence in a schema with zero observed tables must be checked directly against the exact AuthorizedObservationRequest schema allowlist before immutable snapshot/receipt side effects.

Review 5160201671 fixes the public-coordinate prerequisite: current ObservationLocation requires schema_name + table_name, ObservationLocationKind exposes only Table/Column/Constraint, canonical_location() always enters /schemas/{schema}/tables/{table}, and receipts expose that concrete location type. Do not make table_name() nullable or invent a sentinel table merely to fit schema-scoped objects. Existing v2 table/column/constraint coordinates must retain identical meaning. Introduce a backward-compatible versioned/tagged coordinate or receipt seam for genuine schema-scoped locations such as /schemas/{schema}/domains/{name} and /schemas/{schema}/enums/{name}. Exact membership validation must resolve the type coordinate itself rather than succeeding because some unrelated table exists in the same schema.

Review 5160252371 fixes a separate identity gap: current ColumnObservation stores only data_type: String. A successor model must bind each column to exact qualified source-type identity while retaining display text separately. Same textual type rendering must not collapse sales.status and archive.status, and validation must never resolve identity by search-path inference. Catalog OIDs may join one captured transaction but are not governed semantic identity.

Executable RED precedes production representation code:

  • a frozen historical v2 fixture reproduces its v2 digest and v2 table/column/constraint coordinate meaning exactly;
  • otherwise-identical successor snapshots differing in one newly required material field have distinct v3 identities;
  • every new evidence kind has a verified receipt coordinate;
  • unauthorized domain/enum-only schema fails before immutable snapshot/receipt side effects while an authorized type-only schema succeeds;
  • same-name types in different allowed schemas remain distinct, and columns bind to the exact intended qualified type even when display text is identical;
  • enum membership/order and material domain base/default/null/collation/check semantics alter successor identity;
  • fake table-scoped type coordinates fail;
  • a schema-scoped receipt cannot be satisfied by an unrelated table in that schema;
  • input-order permutations of the same complete evidence remain digest-identical.

Adapter transaction and resource boundary

Only after the representation/version/authorization/type-binding/receipt slice is exact-head GREEN may the concrete adapter be admitted. Use one explicit REPEATABLE READ READ ONLY transaction. Server statement_timeout, transaction_timeout and lock_timeout are defense-in-depth only; the ConceptWeave non-resetting operation budget remains the outer authority across authorization, connect, transaction setup, catalog queries and cancellation cleanup.

For Rust transport, adoption must use a maintained patched PostgreSQL driver pinned by immutable lock coordinate, pass cargo-deny/SBOM review, and use a verifying TLS path when TLS is required. A mutable latest reference is not an accepted dependency coordinate.

Current central Product gate

Protected central .github/main remains 7fd571dbcdbae6acf29d8f4ee704d7ba6297e4db. The broad current producer/handler successor is .github#2040@6706c231ab06a3c91c43fdb5b989cfcd79fff593, OPEN Ready/non-Draft/mergeable. Exact CodeQL run 34251822255 is completed failure at attempt 7 on that head/base; triggering actor is github-actions[bot]. Other recorded security/runtime lanes succeeded.

The central repair must preserve base-bound trust with a bounded pre-cutover direct-evidence bridge authenticated to exact protected handler source plus repository/PR/base/head/required-run/language/job/SARIF/artifact identity, and replace one-shot Jobs API inventory with bounded rereads until every detected language has one stable terminal rerunnable identity or a fail-closed deadline. .github#2051@558693e... and #2056 69ae472... retain useful stricter identity/versioned-rollout and complete-failed-job-set/atomic-wake deltas for later non-force reconciliation; neither is protected authority today.

Active P0

  1. RED -> minimal repair -> GREEN for v2-frozen/v3 representation, direct schema authorization, qualified column-to-type binding and backward-compatible schema-scoped receipt coordinates covering relation kind, table comment, first-class index and domain/enum evidence.
  2. Regenerate exact-current feat(observation): define immutable PostgreSQL schema snapshot contract #6 Rust/coverage evidence for the repaired successor; obtain current-head independent review and hosted Product/security/dependency evidence when protected prerequisites are available.
  3. Implement the concrete read-only PostgreSQL adapter behind conceptweave-source-port with adapter-local least-privilege credential resolution for exact key+binding and one fresh authorization per attempted observation/retry.
  4. Use one explicit REPEATABLE READ READ ONLY catalog transaction. Stale binding fails before credential/source I/O; connect/transaction/catalog/cancellation consume the same admitted remaining operation budget.
  5. Capture exact-schema pg_catalog evidence under row/byte/concurrency ceilings, source-disappearance handling and complete-or-fail snapshot construction. Preserve quoted identifiers/cross-schema collisions without importing application truth.
  6. Freeze and replay an anonymized GRC-shaped conformance fixture without copying governance-risk-compliance source or querying its application tables through hidden coupling.
  7. After observation conformance is exact-head GREEN, continue deterministic semantic 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 order/provenance-only coordinates; materially different metadata cannot reuse that identity. Every candidate binds to exact source identity/digest/location evidence. Historical v2 identities and receipt coordinate semantics remain reproducible; new material evidence uses an explicit successor identity family. A raw request or merely well-formed registry key cannot reach the adapter seam. Unknown/unauthorized source, schema, resource or stale binding fails before source/snapshot side effects. One authorization crosses execution exactly once; retry requires fresh authorization 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.

Activity

  1. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    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.

  2. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    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.

  3. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    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.

  4. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    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.

  5. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    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.

  6. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    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.

  7. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    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:

  8. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    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.

  9. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    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.

  10. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    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.

  11. seonghobae commented on Sep 2, 2026

    @seonghobae
    ContributorAuthor

    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.

  12. seonghobae commented on Sep 2, 2026

    @seonghobae
    ContributorAuthor

    Fresh GRC Generation reference-source snapshot; PR-state/acceptance evidence only, so the test-only Generation head is not moved.

    • GRC canonical default/protected source is develop@85da4e1c64e5b46ca3a11ca71654a82b57366a3e. Treat that exact protected commit plus its published/canonical schema/domain documents as the current enterprise fixture coordinate until a later protected GRC head is independently refetched.
    • GRC #63 remains open and explicitly delegates ontology learning/generation to ConceptWeave; GRC supplies authoritative domain source facts, terminology, competency questions, constraints and steward decisions rather than a local ontology generator.
    • ConceptWeave Generation PR feat(observation): define immutable PostgreSQL schema snapshot contract #6 is exact bc25e6f29f16bf5afa8df220f466e688f030aa3e, stacked on Foundation feat: establish ConceptWeave foundation #1. Product run 33594432505 / rust-quality job 100134904991 remains queued on [ubuntu-24.04], runner_id=0, steps=[], no checkout. Therefore the canonical lowercase sha256: snapshot-digest RED is still not observed and production validation remains withheld.

    When that RED becomes executable, the next GRC fixture slice remains generic Source Observation: freeze canonical GRC schema/domain evidence into immutable source coordinates, preserve exact source digest/location/extractor revision, and prove no GRC application-table SQL or GRC-specific domain model leaks across the ACL. Later semantic candidates may map identities such as controls/risks/audits, but GRC remains authoritative for those records and relations.

  13. seonghobae commented on Sep 2, 2026

    @seonghobae
    ContributorAuthor

    Fresh fleet contract handoff (2026-09-02): Generation PR #6 is now 3d34255b5ecc490cf59eb6565a8637d215ecfec7, stacked on foundation bba351b77bf5f1ab5cfd55979fbb2bd158f78b81. Its exact-head Product evidence is still non-passing: run 33599940133 was cancelled before a runner started and the bounded rerun is queued. The current source-receipt slice records test-first commit e2b1742c0f7976ab9e045eebf6d6b1d898394e05 followed by production commit 3d34255..., but the PR describes the RED as a “source-level RED specification.” Fleet acceptance requires an actually executed failing production-boundary RED at the test-only commit before the behavior change; source/spec-only RED is insufficient. Please preserve or reproduce the focused failing invocation on e2b1742..., then require focused/full GREEN on exact 3d34255... before treating this slice as TDD-compliant. After that, continue the bounded read-only PostgreSQL source adapter and the same GRC golden-fixture acceptance: no direct GRC application-table coupling, provider SDK, source-truth duplication, or automatic authority promotion.

  14. seonghobae commented on Sep 2, 2026

    @seonghobae
    ContributorAuthor

    Current Generation progress, 2026-09-02, linked to canonical PR #6 rather than a new branch.

    PR #6 exact head is cb41cff0482099dbc27eae2b47c9135f78ff6fb9, still Draft/open/mergeable and stacked on foundation PR #1. This iteration completed another test-first Source Observation defect: PostgreSQL 18 foreign keys previously preserved actions/match/deferrability but could not preserve exact convalidated / conenforced catalog state. RED commit 350b7c11c801f7356e0e602513bb54f42e90d0ae requires explicit false values to round-trip as Some(false) and unobserved state to remain None; production commit 4df2fd7b5acbbfd9406015daf977ea13f7c0b866 implements immutable optional validation/enforcement evidence, with PRD/ARCHITECTURE/CHANGELOG/product-gap reconciliation carried through the current head.

    Exact-head Product run 33606019009, job 100170059162, is still queued before execution and is not treated as GREEN. No no-op rerun is requested while this sole current-head lane remains live. The next bounded Generation implementation remains the real read-only PostgreSQL adapter behind an explicit Source Observation port, with caller cancellation, timeout/statement/row/byte/concurrency bounds, source-disappearance behavior, immutable extractor receipts, and a frozen anonymized GRC fixture. It must populate the existing PK/unique/FK/CHECK/reference-behavior/validation-enforcement contracts rather than duplicate source semantics.

  15. 103 remaining items

  16. seonghobae commented on Sep 12, 2026

    @seonghobae
    ContributorAuthor

    Source Observation checkpoint: active #46 is exact 7386ffb46ac72fb5257ac2ffd50ef8baab672f5e, OPEN/Draft/mergeable. Follow-up review 5188419794 found that identity mode (pg_attribute.attidentity='a'/'d') could coexist with nullable bounded-column evidence even though PostgreSQL identity columns are implicitly NOT NULL. Behavioral regression bd6da911262a70a0a6d27ba439848831062813fb covers both identity modes plus nullable explicit-not-identity control; production 00b166bfb47473b567bef3c5ab2f800327afda34 repairs the shared canonicalizer; doctoring 0bba879daec988b15cff63918224d70ff71c7cf6 and Gap baseline 7386ffb46ac72fb5257ac2ffd50ef8baab672f5e are current.

    Exact-head acceptance remains pending: zero PR-triggered workflow runs and only CodeRabbit success; the available host has no Rust 1.98 toolchain. Keep #45/#6 source unchanged until #46 unchanged-head native/hosted GREEN, then adopt complete delta ordinary/non-force into #45, obtain fresh parent GREEN, and propagate to #6.

  17. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    Source Observation checkpoint: #46 is now exact 2e2e5abb229c23bf6b7105b20f1fe2bc5ccdf4b9, OPEN/Draft, with a new PostgreSQL 18 column-generation declaration P1. pg_attribute.attgenerated was absent from governed evidence; review 5188836578 established the source gap, RED be3adfd0fa49fe3e27d9794c3773993a48235289 requires ordinary/stored/virtual distinction, complete/canonical bounded coverage, duplicate rejection, and generated↔identity contradiction handling; doctoring 4708708c3b9e33a3ec6ef5b49defadfbd5339300 and baseline 2e2e5abb... currentize the contract. Status is COLUMN_GENERATION_RED_ACTIVE, production repair pending. Parent #45/#6 remain unchanged; no propagation before #46 repair and unchanged-head Rust 1.98 + hosted acceptance.

  18. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    Final Source Observation coordinate for this run: #46 exact 292e996fb45275f120f097c819431b8aaf3ca3c0, OPEN/Draft. Active P1 remains pg_attribute.attgenerated evidence: 5188836578 -> be3adfd0fa49fe3e27d9794c3773993a48235289 -> 493e56bc6e985495511ef981e2d765c7d0583b51, doctoring 4708708c3b9e33a3ec6ef5b49defadfbd5339300, baseline 292e996f.... 493e56bc... removes the pre-existing identity/nullability failure from the generated↔identity fixture so that RED isolates the intended new invariant. Status remains COLUMN_GENERATION_RED_ACTIVE; production family, native/hosted GREEN, parent adoption, transport, publication, and release are pending.

  19. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    2026-09-13 Source Observation checkpoint: active child #46 is exact 1a8ff08e4751b0cf83831fc6159d878a4945e7c6, OPEN Draft/mergeable and still COLUMN_GENERATION_RED_ACTIVE; parent #45 remains 6b2a8f555725dc79f60432afbc492d6005290a4a, #6 remains 287165d399c5f54d6c4b4aa3c15497b47de8244b. PostgreSQL 18 attgenerated production family must land and receive one unchanged-head Rust 1.98/native + hosted GREEN set before complete ordinary/non-force parent adoption. Independent Product owner progress: .github#2079@6ca329896a846110ade7182ed6fa0fa7b0fbba7d now carries executable Noema finding↔confirmed-probe relation RED with exact-current review 5188972300; central evidence does not transfer to ConceptWeave acceptance.

  20. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    2026-09-13 Source Observation checkpoint: active child #46 is now exact fb6b0226fb6c4364f9e241bf01b684e110433386, OPEN Draft/mergeable on #45 6b2a8f555725dc79f60432afbc492d6005290a4a. The PostgreSQL 18 pg_attribute.attgenerated gap is ordinary-forward source repaired: 325556329e16a48b20560d0634ffd9ba07bfa34d adds the complete/domain-separated ColumnGenerationObservation family, f4e8295bf86731a4de9c8810ebcec7fdce2ea5f8 integrates canonical collation→generation→identity ordering and generated/identity contradiction rejection, and 8b0c64479ad93bacd7df2c548731eb1c1f14e59f proves identity-first attachment cannot bypass the invariant. Doctoring is current through d67433cc0caebfc427719f04ed61f5d701b9c51e; product/technical baseline is current at fb6b0226.... State is SOURCE_REPAIRED / ACCEPTANCE_PENDING, not GREEN: exact head has zero pull-request workflow runs and only CodeRabbit success; repository-pinned Rust 1.98 native verification plus hosted Product/security/dependency/review acceptance remain outstanding. Keep #45/#6 source unchanged until one unchanged #46 exact head is terminal GREEN, then adopt the complete delta ordinary/non-force through #45 with fresh parent acceptance before #6 propagation. Central Noema .github#2079@6ca329896a846110ade7182ed6fa0fa7b0fbba7d remains a separate owner RED and its evidence does not transfer.

  21. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    Source Observation checkpoint — 2026-09-13. Active child #46 advanced ordinary-forward to ac590894bfd93297aed1b83859d4745bb5235d40. New PostgreSQL 18 P1 finding 5189444945: column generation mode did not bind the actual pg_attrdef default/generation expression, so materially different defaults or generated computations could collapse under governed identity. RED afc9509f021681e6f6a2d0e6d0c386cce46fad12 adds column_expression_contract.rs; doctoring 3a76c46bc4d12fac2b8c3407a1d6a09005ddd7ea; code-current product/technical baseline ac590894.... Current state is COLUMN_EXPRESSION_RED_ACTIVE, not source-repaired/GREEN. Parent #45 6b2a8f... and #6 287165d... stay unchanged until #46 receives minimal causal production repair and one unchanged-head Rust 1.98 + hosted acceptance set.

  22. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    Source Observation checkpoint — 2026-09-13: active child #46 is now exact bd63564fd721072269a50bf5c8dbecc09a30807f, stacked on unchanged #45 6b2a8f555725dc79f60432afbc492d6005290a4a. The active pg_attrdef column-expression RED afc9509f... has advanced one production step: bd63564... adds the isolated ColumnExpressionObservation family with explicit no/default/generation states, exact server-rendered expression preservation, bounded completeness/duplicate/canonical-order validation, generation-kind consistency, and domain-separated digest framing.

    This is not source-repaired or GREEN. PostgresSchemaSnapshotV3 root integration is still absent, so the contract remains aggregate RED. Next delta is public/root state + constructor/consuming method/accessor + canonical order/digest integration after generation and before identity/timing/PERIOD, followed by unchanged-head Rust 1.98 and hosted acceptance. #45/#6 remain source-frozen until that complete child is terminal GREEN.

  23. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    Source Observation checkpoint — #46 advanced ordinary-forward to exact a41ea7efca0fc19f9fd80e2a9dbf00630d0a1cc1. Column default/generated-expression P1 now has aggregate source repair (8da6fa3193f9d2191a260372559078bb31f3118a) plus explicit generation-precondition/reverse-order regressions (3b2b6fda8ccab43ce57488ad5fbb76458502af95); docs/product-technical-gap-baseline.md is current at a41ea7ef.... State is COLUMN_EXPRESSION_SOURCE_REPAIRED / ACCEPTANCE_PENDING, not GREEN: fresh exact-head query has zero pull-request-triggered workflow runs and only CodeRabbit status, and pinned Rust 1.98 native acceptance has not executed. Parent #45/#6 remain source-unchanged; complete child adoption stays blocked until one unchanged #46 head reaches terminal native/hosted GREEN. Central Noema owner is separately .github#2079@35d1b39ad268e5cf7157716296c926df2bded3e6, still intentional RED.

  24. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    2026-09-13 Source Observation checkpoint: active child #46 advanced ordinary-forward to exact 675a923d7f8f572fabbd06080f074e902ba3aaaf, OPEN/Draft/mergeable on unchanged #45 6b2a8f555725dc79f60432afbc492d6005290a4a. New P1 finding 5189886354: PostgreSQL 18 stores explicit column NOT NULL specifications as first-class pg_constraint.contype='n' rows, while frozen ColumnObservationV3 retains only the attnotnull/nullable summary. RED 8ce7fd7c..., doctoring 5c0706da..., staged family 8912039b..., partition-parent RED e58dd0c5..., duplicate-name RED 5ac4cf33..., staged-family repair 91086655..., and baseline 675a923d... define the current slice. State is NOT_NULL_CONSTRAINT_MODULE_STAGED / AGGREGATE_RED_ACTIVE: crate-root/aggregate admission and exact-head Rust/hosted acceptance are still pending. Do not propagate partial deltas to #45/#6. Fresh central Noema owner is .github#2079@20972a57ce768751dbb4b29e7dbed76271bfed14, still owner-local RED and non-transferable.

  25. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    Source Observation checkpoint — current child #46 is exact e36fe671875e24516e8c1666300e735f5607025b, OPEN/Draft/mergeable on #45 6b2a8f555725dc79f60432afbc492d6005290a4a. The PostgreSQL 18 NOT NULL family remains MODULE_STAGED / AGGREGATE_RED_ACTIVE; aggregate admission is still the next causal change. New owner lineage: review 5190108906 found that resolved nonzero conparentid accepted impossible non-partitioned parent relation kinds -> behavioral RED 4c1c0640fc5460bb47ec074c068936e34af22543 -> minimal production fix 2f8a4f9743f653cfbac092c28376cde7881bd6af requiring RelationKind::PartitionedTable -> primary-source doctoring e1c62c07bd43f6cbfa0bafc7dba708dce32bb886 -> code-current baseline e36fe671875e24516e8c1666300e735f5607025b -> exact-current review 5190115359. #45/#6 source stay unchanged; no partial adoption before #46 aggregate repair and unchanged-head native/hosted GREEN.

  26. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    Source Observation checkpoint 2026-09-13: #46 exact 987c83333b36807f895a491e6e2ebe1611ec3704 is NOT_NULL_CONSTRAINT_SOURCE_REPAIRED / ACCEPTANCE_PENDING. Aggregate repair c5ac66ffa623f6b99ba0c08f73eea4e22f06937b admits first-class PostgreSQL 18 pg_constraint.contype='n' evidence into PostgresSchemaSnapshotV3; edge contract e60cfec34fd99df4f7623ec821384064771951c0 locks one-time admission and canonical optional-family ordering. Baseline is current at 987c833.... No native Rust 1.98 or hosted acceptance is claimed; #45/#6 source remains unchanged until one exact #46 head is terminal GREEN.

  27. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    Source Observation checkpoint — #46 is now exact cc6c4af9342384e60004430649725a3d220461a4, OPEN/Draft/mergeable, stacked on unchanged #45 6b2a8f555725dc79f60432afbc492d6005290a4a. Review 5190362750 found that PostgreSQL 18 pg_constraint.coninhcount is signed int2 while the source model admitted full u16; RED 2891675822b13282ab57d968cda985d0628920ac, repair 385bf43794849836ef6871c2abad64c124ddd723, doctoring 1b16ce65d674836e88073ba2ea857aa27fb1b2a5, and baseline cc6c4af... now reject impossible counts above 32767 before governed hashing. State remains SOURCE_REPAIRED / ACCEPTANCE_PENDING: exact cc6c4af... has no PR-triggered workflow runs and only CodeRabbit commit status; this host has no Rust toolchain, so no native GREEN is claimed. Keep #45/#6 unchanged until unchanged-head #46 native+hosted acceptance.

  28. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    Source Observation checkpoint — 2026-09-13 (corrected)

    #46 exact db2d1c8f90a4d6626d1b0e2ce3d83a6dc22f4666 remains OPEN / Draft / mechanically mergeable on #45.

    An intermediate review 5190456512 used an April 2024 development-state catalog model and incorrectly concluded that a PRIMARY KEY could remain the sole backing for attnotnull without a first-class pg_constraint.contype='n' row in PostgreSQL 18. Fresh review 5190470810 corrected that chronology: later upstream work explicitly changed PRIMARY KEY handling to create/queue NOT NULL constraints for each key column, and PostgreSQL 18 pg_attribute.attnotnull documents that the column has a possibly invalid not-null constraint.

    The mistaken ordinary-forward commits remain in history rather than being rewritten. Corrective chain: RED d4df54d99bfb50329d9a42c8ce0da61bf77dc536 -> production repair 0cdd4fd3b37642373482cfa9874fe99268ed04d9 -> primary-source doctoring 6c37275c49a1dc267d2d7f7ecaca5de6e74886df -> code-current baseline db2d1c8f90a4d6626d1b0e2ce3d83a6dc22f4666. The production NOT NULL canonicalizer again requires the bounded attnotnull=true column set to match the captured first-class NOT NULL row set. The corrected regression specifically pins the PRIMARY KEY case.

    State remains NOT_NULL_CONSTRAINT_SOURCE_REPAIRED / ACCEPTANCE_PENDING. #45 source remains 6b2a8f555725dc79f60432afbc492d6005290a4a; #6 remains 287165d399c5f54d6c4b4aa3c15497b47de8244b. Central .github#2079@20972a57ce768751dbb4b29e7dbed76271bfed14 remains a separate owner RED for finding/probe binding. Next causal gate is unchanged-head Rust 1.98 plus hosted Product/security/dependency/review acceptance; no Ready/merge/publication/release claim before that.

  29. seonghobae commented on Sep 13, 2026

    @seonghobae
    ContributorAuthor

    2026-09-13 fresh Source Observation checkpoint: leaf source authority is unchanged — #46 db2d1c8f90a4d6626d1b0e2ce3d83a6dc22f4666 remains NOT_NULL_CONSTRAINT_SOURCE_REPAIRED / ACCEPTANCE_PENDING, stacked on #45 6b2a8f555725dc79f60432afbc492d6005290a4a → #6 287165d399c5f54d6c4b4aa3c15497b47de8244b. Central Noema owner advanced ordinary-forward to .github#2079@9dccfaa0776950498e557390a2fa8d6c34e0baf4: required nullable finding_index is now in structured-output schema, prompt and deterministic validator, so the finding↔confirmed-probe owner RED is source-repaired. Its exact-head Security Scan, Semgrep and Python Security are GREEN; CodeQL is still in authenticated dispatch settlement and is not terminal GREEN yet. No central execution evidence transfers to ConceptWeave. Keep the causal order #2079 owner acceptance → #46 native/Product acceptance → complete non-force #45 adoption → #6 propagation; no leaf churn or manual/no-op evidence manufacturing.

  30. seonghobae commented on Sep 23, 2026

    @seonghobae
    ContributorAuthor

    2026-09-23 authority correction

    The issue body’s 2026-09-10 branch and central-gate coordinates are historical, not current execution authority. Current Source Observation chain is #6 8c5db75b555cd40ceb7b52616dd069b660e13ef9 → #45 c7caf6cf518aee6f28ec6441e4e3cf53f59a5e34 → active single writer #46 e35de25355cb4aa4bc75d5900a6e09803d80ff41. #46 already carries the PostgreSQL 18 representation/source-integrity repairs for first-class relreplident, relreplident × indisreplident, PRIMARY/UNIQUE reciprocity including PRIMARY NULLS NOT DISTINCT, clustered/temporal/NOT NULL evidence, index access methods and receipt recovery. Those deltas remain child-owned until one unchanged reconciled head obtains native Product/Rust/PostgreSQL execution; the four execution-gated review threads remain unresolved.

    Canonical Product producer is #35 d7b7e30b278ec2f27096b4d313c7d5eaf5387ddc, still Draft. Its current trusted-control-plane contract runs CI/Rust/coverage/semantic-controller helpers from separately verified ${{ github.workflow_sha }} Product source and treats the PR checkout as workload only. Protected main@f4f440dd58c77d7cd90dff8a1eb2eeb9a9940425 still lacks Product, and #35 current central CodeQL/Security/SAST evidence is nonterminal.

    Protected Product enforcement is now .github#2348/#2350 owner work, not the obsolete .github#2040 path described below. #2350 exact 28246b1e77ac387273aad63a8bb6746c331d633b has an intentional immutable-workflow-coordinate RED: the dedicated ConceptWeave organization branch/workflows ruleset may not bootstrap or activate until an ordinary-reviewed product_workflow_blob_sha has been adopted from protected ConceptWeave main after #35 lands. Current #2350 owner/central runs are queued before execution; no predecessor result transfers.

    The P0 domain acceptance in this issue remains valid: finish lossless PostgreSQL observation evidence and its exact receipt/identity invariants before admitting the concrete least-privilege read-only adapter, then use one bounded REPEATABLE READ READ ONLY snapshot transaction and immutable provenance. Do not start adapter/source-I/O work by bypassing the current Product/governance gate or by partially copying #46 into #6. Required sequence is #2350 source acceptance → #35 protected landing → reviewed Product blob adoption/evaluate ruleset/canary/active proof → Foundation/#5/#6/#45/#46 ordinary propagation → exact #46 native execution/thread settlement → adapter slice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions