JEV meaning.
PostgreSQL structure.

Three capabilities, different jobs.

Independent semantic work runs concurrently within configured limits. Questions sharing context can be batched. Compatible observations can be reused when decision thresholds change, without treating skipped work as a false answer.

Implementation: natural-language queries · operator reference · native stage plans

A question you can reproduce.

“For each supplier, show the total quantity delivered, largest total first.” The project's deliveries tutorial records this generated query:

SELECT
  SUM("r0"."quantity") AS "result_1",
  "r0"."supplier" AS "result_2"
FROM "deliveries" AS "r0"
GROUP BY "r0"."supplier"
ORDER BY SUM("r0"."quantity") DESC NULLS LAST;

The tutorial data returns Birch: 36, Aster: 30, Cedar: 8. These totals come from SQL aggregation. They are an example result, not a claim that arbitrary natural-language requests are always interpreted correctly.

Run the tutorial and inspect its data · See recorded queries and results

A native PostgreSQL framework, centered on JEV.

The native development preview places Rust semantic operators inside PostgreSQL 17. Independent JEV stages can run in parallel, while dependent stages wait for their required evidence. PostgreSQL performs relational joins and aggregation; the model evaluates the semantic questions.

The framework retains compatible answer probabilities for reuse when decision thresholds change. Its explainable embeddings use named questions and answer distributions, so each coordinate has a defined meaning. The stable workspace and native preview have separate deployment paths.

Native installation · Parallel native plans · Explainable embeddings

Every coordinate has a named meaning.

The development function jev_native.embed evaluates a fixed question basis for each record. A question can have false/true answers, named categories or rubric levels. Every answer is retained, so one record becomes a question-by-answer probability matrix and a flattened vector.

The resulting vector is [0.20, 0.80, 0.70, 0.30]. These numbers illustrate the representation; they are not measured model confidence. A basis can contain 1–32 independent questions. Missing evaluations remain null with NOT_EVALUATED, rather than becoming zero probability.

jev_native.embedding_distance compares complete embeddings with the same basis, axes and evaluator identity. It uses root mean squared Hellinger distance across questions and performs no model calls. Retrieval quality depends on your question basis and provider; the project does not claim a universal advantage over dense-vector retrieval.

Embedding contract and limitations · Runnable embedding SQL

Combine several kinds of evidence.

These are illustrative application designs, not claims of deployed customer systems. Use schema relationships, domain definitions and explicit review policies for your own data.

Application integration · Text extraction and review · Dependencies and parallel stages

Before you choose jev4pg.

Related research: semantic queries and AI data systems.

These papers provide context for combining language models with relational queries. They describe separate systems; their results are not jev4pg benchmark results.

jev4pg's documented focus is typed JEV decisions, reusable evidence, and a PostgreSQL-native development path. Follow its operator reference and native plan documentation for implemented behavior.

Explore the JEV and PostgreSQL ecosystem.

These independently maintained projects offer other ways to work with typed decisions and PostgreSQL:

• TypeSafe JEV documentation explains the provider's question types and API; start here when designing a decision contract.
• pg-jev exposes semantic predicates, probabilities, choices and scores through a PostgreSQL extension.
• jevQL provides a CLI and SDKs that evaluate semantic calls outside vanilla PostgreSQL, without installing an extension.

jev4pg combines a natural-language query workspace with semantic operators, reusable evidence and a native development preview. Choose according to where you want decisions to run, your deployment requirements and the evidence you need to inspect.

Choose a deployment.

Start with a release tag for a fixed deployment. For native development, read the compatibility and provider requirements before building.