Jev in Snowflake, DuckDB and Neo4j

Semantic SQL in Snowflake and DuckDB

Jevflake is a community Snowflake integration with dbt and Terraform setup paths. Its README documents jev_noul, jev_choice, jev_score and jev_ask. It requires configured external access, a stored API secret and appropriate roles. Those setup requirements matter before any model-generated judgment appears in a query.

For DuckDB, recodelabs/duckdb-jev describes semantic filtering, ranking and classification functions. Its README distinguishes the proposed community installation path from loading available builds. Check the current installation status and DuckDB version instead of assuming every command in an introductory snippet is available through a package registry.

Different DuckDB projects expose different functions, batching and backend choices. Choose the exact repository before writing SQL against its interface.

Filter ordinary facts before model calls

Use deterministic predicates for known dates, identifiers, permissions and exact values. Apply the semantic decision only to the candidates that still require interpretation. For support records, that might mean selecting new, authorized rows first, then judging whether their text requests a refund.

authorized source rows
    -> exact SQL filters
    -> typed semantic judgments
    -> persisted result + model/question version
    -> reporting, routing or review

This is an architectural example, not syntax for a particular extension. Persisting a result makes its provenance visible and avoids accidentally recomputing an expensive judgment every time a dashboard runs.

Cache with the question and model identity

A record's answer depends on more than its row ID. A practical cache identity includes the relevant content, question definitions, model version and preprocessing version. Changing the rubric should invalidate the earlier judgment even if the original document stayed the same.

Keep error states separate from negative answers. A failed API request is not a low probability, an empty category or evidence that the row did not match. Store retry and review state so the pipeline can recover without hiding missing work.

Graph traversal is different from graph construction

Neo4Jev presents neighboring graph relationships as Choice options and asks whether a traversal goal has been reached. The graph supplies legal moves; Jev judges among the supplied candidates. Code controls branching, stopping conditions and the search budget.

JevGraph instead describes a document-to-graph pipeline with local parsing, candidate blocking, typed relation decisions and deterministic schema checks. A proposed edge remains a claim supported by source evidence; being structurally valid does not make it factually true.

The official entity-alignment cookbook addresses another related job: deciding whether candidate records describe the same entity. Matching identities, navigating edges and proposing relationships should have separate tests.

Check the operational contract

• Which columns leave the database, and under whose permissions?
• Where is the API key stored and which roles can use it?
• How many calls can a query trigger, including retries?
• Can a rerun reuse valid results without hiding failures?
• Can a reviewer trace each result to the source and rubric?

Start with a bounded table and an output-only view. Compare judgments with labels, inspect failures, and only then connect them to downstream operations. Ordinary constraints and access controls remain the authoritative checks.