以下内容可直接粘贴到报名表的 About the project：

Inspiration

AI agents are becoming capable of generating and executing database changes, but execution success is not the same as business safety.

A SQL statement can run without errors and still modify the wrong warehouse, corrupt order history, release inventory twice, or cross a tenant boundary. Traditional AI evaluations usually reward the answer with the highest quality score, while traditional database checks focus on syntax, constraints, and transaction success. Neither answers the most important question:

Did the AI change exactly what the operator authorized—and nothing else?

That question inspired SafeCommit: the commit gate for AI database agents.

Our defining demo moment is intentionally simple. Three AI-generated plans compete to solve the same logistics task. Two receive the highest scores, but one changes inventory outside the requested warehouse and another rewrites a shipped order. SafeCommit rejects both and selects the slightly lower-scoring plan that preserves every required business invariant.

The highest-scoring answer does not win when it is unsafe.

What it does

SafeCommit turns a natural-language database request into a verifiable, human-approved state transition.

An operator can request a change such as:

Merge the duplicate SKU in Los Angeles and release its cancelled allocation. Do not change other warehouses, shipped orders, lots, or serial numbers.

SafeCommit then:

Converts the request into an explicit intent contract.
Uses Fireworks AI to generate three competing structured database plans.
Executes every candidate against the same MySQL 8 snapshot in an isolated Daytona sandbox.
Captures row-level before-and-after database evidence.
Evaluates every plan in Braintrust and compares a direct AI baseline with the safety-gated result.
Applies 13 deterministic hard gates covering warehouse scope, tenant isolation, inventory conservation, protected order states, referential integrity, idempotency, rollback, and other business invariants.
Rejects every candidate that fails even one non-negotiable gate, regardless of its AI quality score.
Uses CopilotKit to pause for a human decision and bind approval to the exact request, plan, snapshot, schema, source revision, and execution evidence.

SafeCommit does not automatically write to production. A successful result means SAFE_TO_COMMIT: the plan has been proven eligible and approved, but production execution remains a separate controlled action.

How we built it

We built SafeCommit as a TypeScript and Next.js application around an OpenBoxes-derived executable MySQL 8 logistics fixture. The fixture contains the tables and relationships needed to model products, warehouses, orders, allocations, inventory, lots, serial numbers, and tenant ownership. It is deliberately labeled as an OpenBoxes-derived fixture rather than a full OpenBoxes deployment.

The workflow combines four sponsor technologies:

Fireworks AI generates multiple structured candidate plans from the same operator request.
Daytona creates isolated MySQL sandboxes so every plan runs against an identical baseline without touching production or contaminating another candidate.
Braintrust stores the evaluation dataset, traces, direct-agent baseline, and SafeCommit-gated experiment.
CopilotKit provides the human-in-the-loop approval step after deterministic validation is complete.

Our safety kernel treats safety as eligibility, not as another weighted score. A candidate that fails a hard gate cannot compensate by scoring better elsewhere, and a human approval cannot override a failed safety invariant.

For every candidate, we verify SQL plan integrity, bounded mutation scope, warehouse and tenant boundaries, inventory conservation, non-negative inventory, allocation bounds, lot and serial preservation, referential integrity, protected order states, blast radius, idempotency, and rollback.

We also generate an evidence manifest that binds provider resource IDs, database fingerprints, execution results, the selected candidate, and the source commit. The interface replays this verified evidence as a clear, judge-readable workflow instead of exposing raw hashes and internal logs.

Challenges we ran into

The first major challenge was making AI-generated SQL both flexible and safely executable. A model can generate a semantically interesting plan that violates a foreign key, uses a volatile value such as NOW(), or cannot produce the same result twice. We strengthened both the generation contract and the deterministic policy layer so invalid or non-idempotent plans fail closed.

The second challenge was distinguishing isolation from safety. Daytona ensures that an unsafe plan cannot damage production, but a sandboxed plan can still produce a dangerous business outcome. We therefore compare the complete database state before and after execution rather than treating “the SQL ran successfully” as proof of correctness.

The third challenge was trustworthy evidence across several external providers. We needed to prove that each provider resource belonged to the same run, that all sandboxes were destroyed, and that the final approval referred to the exact winning plan. We solved this with canonical evidence digests, source binding, provider ID validation, and manifest verification.

Finally, we had to make a technically complex workflow understandable within a three-minute demo. We redesigned the interface around readable business consequences: “crossed the warehouse boundary” is far more meaningful to an operator than an unexplained failed hash or internal gate name.

Accomplishments that we're proud of

We completed a real end-to-end provider run using Fireworks AI, three Daytona MySQL sandboxes, Braintrust experiments, deterministic SafeCommit gates, and a CopilotKit approval receipt.

In that run:

Three AI-generated plans competed against the same database baseline.
Every Daytona sandbox was isolated and destroyed after execution.
Two plans scored approximately 0.99 but were rejected for business-state violations.
The selected plan scored 0.96 and passed all 13 hard gates.
The direct AI baseline selected an ineligible plan.
SafeCommit prevented that unsafe selection.
The approved plan preserved other warehouses and shipped-order history.
Rollback reproduced the original database state.
The entire workflow completed with zero production writes.

We are especially proud that the system explains not only which plan failed, but why it mattered to the business.

What we learned

We learned that model evaluation and operational authorization are fundamentally different problems.

An AI score can help rank plausible solutions, but it should never grant permission to modify critical state. Sandboxes provide isolation, but deterministic invariants are still required to decide whether a result is acceptable. Human approval is also meaningful only when it is bound to exact, unchanged evidence—not when it is a generic confirmation button.

Most importantly, we learned that safety does not have to make an AI product feel slower or less usable. When the evidence is presented clearly, safety becomes the product’s most compelling moment: the user can immediately see the dangerous high-scoring answer lose.

What's next for SafeCommit

Next, we want to turn the current logistics workflow into a reusable policy platform for AI database agents.

Planned extensions include:

Configurable safety-policy packs for finance, healthcare, commerce, and enterprise operations.
Support for additional database engines and production-grade snapshot providers.
A declarative invariant language for organization-specific business rules.
Multi-operator approval policies for high-risk changes.
Deeper CI/CD and GitHub pull-request integration.
Continuous Braintrust regression evaluation for new prompts, models, and policies.
Evidence-bound production execution with rollback monitoring and complete audit trails.

Our long-term goal is straightforward: AI agents should be able to propose powerful database changes, but no change should commit until its real business-state impact has been proven safe.