# Testing Jev on Database Change and Access Workflows

> Our proposed database review workflow: static SQL rules enforce policy, Jev assesses contextual risk, an LLM explains the findings, and a human approves.

Tianzhou | 2026-09-21 | Source: https://www.bytebase.com/blog/jev-database-change-and-access-workflows/

---

TypeSafe released [Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) last week. You give it context and a list of typed questions. It returns choices, scores, or yes/no probabilities, each with a confidence number. No text generation. We wanted to see how useful that would be for database reviews.

We have used this picture for years to explain the DBA's job:

![The database operations trolley problem: a DBA at the lever, developers on one track, security engineers on the other](/content/blog/_shared/trolley-problem.webp)

Every database request is a trolley. Hold it, and the developers waiting on it get run over. Pull the lever, and the security engineers do. Jev predicted the DBA would regret the decision in 30 of our 32 cases. Sounds about right.

We tested whether Jev could help assess risk and route requests for approval. This is an experiment, with no Bytebase feature attached yet. It led us to a workflow we think makes sense:

> Database change and access workflows should combine static SQL review rules, Jev, an LLM, and human review. Static rules enforce explicit SQL policies and block violations. Jev assesses risk from the request context to determine where additional approval is needed. An LLM explains the findings and suggests fixes. A human reviews the request and makes the final call.

## The setup

We wrote eight requests a DBA might get in a week. Four are database changes:

1. A Friday 5pm hotfix: `ALTER TABLE orders ADD COLUMN ... NOT NULL DEFAULT` on a 400M-row PostgreSQL table.
1. An `UPDATE` with no `WHERE` clause, ten minutes before the billing job.
1. `CREATE INDEX` on a 2-billion-row MySQL table at peak traffic.
1. Dropping a column that "nobody uses, probably."

Four are requests for access:

1. A developer asking for read access to production `users` and `payment_methods` to debug a customer bug.
1. A full export of the `customers` table to a shared drive for a churn model.
1. `GRANT ALL PRIVILEGES` to a service account to unblock a launch.
1. An AI coding agent asking for credentials to apply its own migration to production.

We also wrote four short DBA profiles to include in the prompts:

1. **Outage veteran:** was on call for a bad outage.
1. **Ex-developer:** remembers waiting for database approvals.
1. **Compliance-first:** is three months from a SOC 2 audit.
1. **Burned-out DBA:** is the only DBA for 120 engineers.

We asked Jev about all 32 combinations of request and DBA profile. Two questions matter here:

- How bad is it for security if this runs now? Jev picks one of four levels, from negligible to a reportable event. We show them as low, moderate, and high. No request came back negligible.
- What does this DBA do in the next five minutes: pull the lever and run it now, or hold it? Jev returns a probability.

The same data drives an [interactive version of the picture](/trolley/). Choose a DBA persona and an operation, then send the trolley. Each run samples Jev’s precomputed probabilities, so the same setup can produce different outcomes. Open “Behind the decision” to see the persona profile and model scores.

## Who picks up the ticket matters

| Type   | Request                    | Risk if it runs now | Chance the DBA runs it now, lowest to highest persona |
| ------ | -------------------------- | ------------------- | ----------------------------------------------------- |
| Change | Friday hotfix migration    | Moderate            | 6% to 93%                                             |
| Change | `UPDATE` with no `WHERE`   | High                | 1% to 41%                                             |
| Change | Index on a 2B-row table    | Low                 | 8% to 96%                                             |
| Change | Drop a column              | High                | 1% to 69%                                             |
| Access | Production read access     | Moderate            | 7% to 91%                                             |
| Access | Full customer table export | High                | 1% to 52%                                             |
| Access | `GRANT ALL` to a service   | High                | 1% to 62%                                             |
| Access | AI agent wants credentials | High                | 0% to 40%                                             |

Jev gave each request the same risk level across all four DBA profiles. Its prediction of what the DBA would do varied considerably: a 6% chance of running the Friday hotfix for the DBA burned by an outage, versus 93% for the former developer.

The DBA with the outage history was the least likely to proceed in every case. The former developer or the overloaded DBA was always the most likely. That follows the profiles we wrote: one remembers an outage, another knows the frustration of waiting for approval, and the third has 120 engineers to keep moving.

These are fictional DBAs and model predictions. Still, anyone who has worked a request queue will recognize the pattern. We want a review process that holds up regardless of who picks up the ticket. The consistent risk ratings were the result that interested us.

## Where each one fits

Here is how we would divide the review:

|                    | Bytebase SQL review               | Jev                                               | LLM                 |
| ------------------ | --------------------------------- | ------------------------------------------------- | ------------------- |
| Reads              | The SQL statement                 | The whole request: SQL, ticket, requester, timing | The whole request   |
| Returns            | Pass or fail, with the rule named | A level or a probability                          | Text                |
| Can block a change | Yes                               | No. It can add an approver                        | No                  |
| Job                | Enforce explicit SQL rules        | Assess contextual risk                            | Explain and rewrite |

**Bytebase SQL review.** The four change requests are all things [Bytebase built-in SQL review](/sql-review/) catches with a fixed rule:

- The hotfix: the _Disallow add column with default_ rule on PostgreSQL.
- The `UPDATE` with no `WHERE`: the _Require WHERE_ rule.
- The index on a 2-billion-row MySQL table: the _Limit DDL operations on tables with large data volumes_ rule.
- The dropped column: the _Backward incompatible schema change_ rule.

We would keep these checks in SQL review. The rules already catch the problem, name it, and can block the change. Asking a model adds little here.

**Jev.** The access requests need more context:

- Is `users` plus `payment_methods` a proportionate scope for debugging one customer's bug?
- Should a full customer table land in a shared drive because a board deck is due?
- Does a service that fails on one permission error need `ALL PRIVILEGES`?
- Should an agent hold production write credentials because its squad has a demo tomorrow?

To judge these requests, a reviewer needs the ticket, the requester, the timing, and what the tables contain. Jev can take that context and return a risk level for the approval workflow to use.

**LLM.** The developer whose hotfix is held needs to know why and how to split it into an add, a backfill, and a constraint. The approver wants a three-line summary of a 300-line migration. This is where we would use an LLM.

**Human approver.** The approver gets the rule violations, the risk rating, and the explanation, then decides whether the request can proceed.

## Why try Jev for risk ratings?

Teams already ask LLMs for risk ratings in JSON. Jev is worth trying for that job for a few reasons:

1. **Typed output.** Jev returns the requested value directly, without asking a text model to follow a JSON format.
2. **Consistent ratings in this test.** Changing the DBA profile left each request's risk level unchanged. We would need broader testing before relying on that in an approval policy.
3. **A confidence number.** This could help route uncertain cases for closer review, provided the confidence is well calibrated. TypeSafe says LLMs tend to be overconfident when asked to rate their own answers; we did not test that comparison.
4. **Low cost.** Our 32 calls cost less than a cent. TypeSafe claims 70 to 500ms per call, which would be practical for a review workflow.

## How it would fit the workflow

Bytebase routes approvals by condition: environment, project, engine, SQL type, affected rows, and a risk level of high, moderate, or low. Requests for a role and for just-in-time access go through the same approval flows as schema changes.

We mapped Jev's ratings to those three levels so they could feed into the existing routing. A high rating could add an approver to a change that passes SQL review, or flag an access request for closer review.

We would let the rating add scrutiny, with every policy-required approval still in place. If production access needs a DBA's sign-off, a low score from Jev should leave that requirement alone.

## What we did not test

- **Intent.** We did not plant a mismatch between the SQL and the ticket in any of the eight requests, so we learned nothing about whether Jev could catch one.
- **Calibration.** We had no ground-truth labels to check the ratings or confidence numbers against. The agreement across DBA profiles tells us little about accuracy.

## References

- [Introducing System One Models & Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev)
- [SQL review rules](https://docs.bytebase.com/sql-review/review-rules)

## Related reading

- [SQL Review: From Linting to Governance](https://www.bytebase.com/blog/sql-review-tool-for-devs/)
- [When the Agent Writes the Migration, Who Approves It?](https://www.bytebase.com/blog/governing-agent-authored-database-changes/)
- [How to Prevent an AI Agent From Dropping Your Production Database](https://www.bytebase.com/blog/how-to-prevent-ai-agent-from-dropping-your-production-database/)