Picture an engineer asking their AI assistant to "add a check that trip IDs are unique". Moments later there is a plausible rule in a pull request. The reviewer approves it because it looks right. Nobody ran it against data with duplicates in it, so nobody knows whether it catches anything, and the only record of why it exists is a chat window that has since been closed.
An assistant can write a rule quickly, but unless the rule runs against data containing the failure it targets, nobody, including the assistant, knows what it does to real rows. The review step was built for people who could explain their change; an assistant's change arrives with confidence but no evidence.
The short answer: let the assistant propose, but make every proposal arrive with a test result, and keep the decision with a person. This post compares the common ways teams govern assistant-written data changes, then shows the workflow LakeLogic exposes over MCP (Model Context Protocol), and where its limits are.
Why assistant changes are hard to review
The assistant cannot see the contract or the data. It writes SQL from the prompt and whatever files are open. It does not know that trip_id is the table's key, or that a foreign key has no orphan check.
A passing test can prove nothing. If the test data contains no duplicates, a uniqueness rule passes, and that tells the reviewer nothing about whether it works.
The decision leaves no trail. Who asked, what was tested and who agreed end up spread across a chat, a commit message and a reviewer's memory.
Recent adverts for data engineers and governance leads ask for both data quality expectations and auditable change, and some now ask for secure, auditable AI pipelines specifically. Assistant-written rules sit right on that line.
The ways teams govern assistant changes today
| Approach | How it works | Good fit | Watch out for |
|---|---|---|---|
| Pull request review only | The assistant writes code; a person reviews the diff | Small teams with strong reviewers | The reviewer sees text, not the rule's effect on rows |
| CI tests on a fixture | Changes run against a checked-in sample dataset | Teams with maintained fixtures | Fixtures rarely contain the specific bad row a new rule targets |
| Run against a dev copy of production | The rule runs on a recent copy of real data | Teams with a governed dev environment | Real data in more places; personal data handling and cost |
| Assistant restricted to read-only access | MCP or API keys that can only read | Exploration and Q&A | Safe, but the assistant cannot help close a gap |
| Vendor AI features inside a quality tool | The tool suggests monitors or rules from profiling | Teams already on that tool | Uses the vendor's assistant, not your team's own |
These can all work, and CI plus review is a sensible baseline. The gap is that none of them makes "what does this rule reject?" part of the proposal itself, with the evidence attached to the decision.
How LakeLogic approaches it
LakeLogic Platform runs an MCP server, so any MCP client your team uses (Claude, Cursor, Copilot and others) can connect with an API key. The setup guide has the steps. The server exposes a small set of tools, each limited by the key's scopes and to the key's organisation:
| Tool | What it does | Scope |
|---|---|---|
get_contract | The published contract, never a draft | read |
assess_quality | Gaps in declared checks, plus governance lint findings | read |
blast_radius | What sits downstream of a dataset, with a confidence level | read |
propose_rule | Adds one rule as a draft of the contract; the live contract does not change | propose |
test_change | Runs the draft in a sandbox on generated data | test |
proposal_status, get_evidence | The proposal's state and its full record | read |
Gaps include fields with no rule, a key with no uniqueness check and foreign keys with no orphan check. Each answer carries its source and how far to trust it. assess_quality, for example, says it reflects declared checks only, not run results.
The workflow
- Assess. The assistant reads the contract's gaps.
- Propose. It adds one rule. LakeLogic stores it as a draft and refuses if the contract already has someone else's open draft.
- Test. LakeLogic runs the draft in a sandbox, on rows generated from the contract's schema with some deliberately broken for that rule, such as duplicate keys for a uniqueness rule. It never runs on your data or your platform.
- Decide. A person with editor rights approves or rejects it in LakeLogic, with the result in front of them: rows tested, passed and rejected, and example rejected rows. An API key cannot approve, a proposal without a test result cannot be approved, and a test that ran no rows is not accepted as evidence.
- Publish the usual way. Approval records the decision; it does not publish. The draft goes through the same pull request and change checks as any other change.
Every tool call is written to the audit trail with the key's name, so you can see which assistant asked for what.
What happened when we tried it
We gave Claude Code one instruction against a RideFlow contract (our fictional ride-hailing reference project): assess the dataset, find the most important missing check, propose and test it, and show the results before approval. It found four gaps and chose the one that mattered most: trip_id was the key and nothing checked it was unique, so a duplicated trip would be counted twice downstream.
It also reported that its first sandbox test proved nothing, because the generated data contained no duplicates. That was a gap in our sandbox, and we changed it to plant duplicate keys for uniqueness rules. It is the case for testing before review: the reviewer sees what a rule does, including when the test cannot show it.
When you might not need this
- Your assistant only answers questions. Read-only access, or none, is enough.
- Your rules already run in CI against fixtures that contain the failures you care about. Review plus CI covers it.
- Few rule changes. If quality rules change a few times a year, a careful human review is cheaper than a new workflow.
Limits worth knowing
- Your assistant's model sees what it reads. Contract YAML and gap reports go to whichever model provider your assistant uses, under that provider's terms. Connecting over MCP does not make inference private or keep it on your network.
- Synthetic tests are evidence for the sample, not for production. A rule that rejects the planted rows may behave differently on real data volumes and edge cases.
- One kind of change. The assistant can propose quality rules. It cannot publish, run anything on your platform, or change other parts of a contract through this workflow.
- Approval is not deployment. It is a recorded decision; the pull request and your platform still decide what runs.
- Plans differ. A read-only workspace gets the read tools; proposing and testing need a trial or paid plan.
Calls from your own assistant do not use Zeus credits. Zeus, LakeLogic's built-in assistant, remains available for teams without one.
Key takeaways
- Treat assistant-written rules as proposals, and keep the decision with a named person.
- A rule's test needs data that contains the failure it targets; a pass on clean data proves nothing.
- Attach the test result to the decision, so the record shows what the reviewer saw.
- Give assistants scoped keys: read by default, propose and test only where needed.
- Remember where prompts go: your assistant's provider sees what the assistant reads.
Connect your assistant
Follow Connect your AI assistant (MCP) to create a scoped key and point your client at LakeLogic. For how contracts generate the test rows the sandbox uses, read generate test data from a data contract.