DF
DriftFence Trace-first merge gating for critical operations
Protect critical operations in AI-assisted repos

Let agents ship code. Keep critical operation behavior locked.

Passing tests can still hide critical operation behavior changes. DriftFence gives the few backend operations that matter a second gate: record a compact trace for them in integration tests, approve the expected behavior in Git, and block merges when behavior changes without explicit review.

Operating model
Humans approve intent Agents implement code Green CI is not enough No hosted service
See the proof See how it works
See the release-it experiment results See claim limits
Current public proof

release-it is an open-source release automation tool for versioning, tagging, and publishing npm packages. The current public proof comes from one release-it experiment measured on March 10, 2026.

23 / 23 measured model-written patches kept the relevant tests green
5 / 12 publish-behavior operation changes would have been blocked
4 / 5 independent review upheld 4 of 5 blocked patches
0 / 11 the two other operations in the same experiment stayed quiet

That split matters because DriftFence acted on the two publish-behavior operations shown here and stayed quiet on the two other release-it operations tested in the same experiment.

Humans approve expected behavior. Agents implement the code.

DriftFence keeps both aligned at merge time with deterministic behavior checks, Git-native approvals, and reviewer-usable failure reports.

Why DriftFence matters now.

AI-assisted delivery increased patch throughput faster than semantic review bandwidth. The real problem is not every code change. It is the handful of backend operations where green tests still do not prove the behavior you intended.

False comfort

Passing tests do not prove a critical operation stayed intact.

Side effects, ordering, and argument routing can change while relevant tests still pass. DriftFence exists for those quiet but costly operation behavior changes.

  • Behavior can move without a failing assertion.
  • Code review often sees diffs, not operation intent.
  • Silent behavior changes are worst on high-consequence flows.
Human leverage

Humans should approve operation intent, not parse diff noise.

DriftFence turns critical operation behavior into a small, reviewable behavior diff so approval happens at the level that actually matters.

  • Behavior updates move through normal Git review.
  • Reports explain the first divergence, not only the failure.
  • Intent changes become explicit instead of accidental.
Adoption shape

Start with one operation, not your whole repo.

Launch scope stays intentionally narrow: protect the one or two flows with real blast radius, then make the guardrail stricter only where the operation demands it.

  • Starter mode gets the first protection in quickly.
  • Stricter modes are there when needed.
  • No hosted approval system or product sprawl required.

What DriftFence adds beyond tests, lint, and review.

DriftFence does not replace the rest of your engineering quality stack. It adds a merge-time behavior check for the small set of operations you cannot afford to let change silently.

Surface Strong at Usually misses What DriftFence adds
Tests Explicit assertions, outputs, and obvious regressions. Allowed-but-wrong side effects, ordering changes, and argument changes that the current assertions do not model. A saved expected-behavior file checked on every PR, even when the relevant tests stay green.
Lint and static rules Code shape, policy rules, and local correctness checks. Business operation intent and whether operational semantics are still the same. Reviewer-approved operation behavior, not just code-style or API-usage rules.
Code review Judgment, product context, and broad architectural tradeoffs. Subtle operation behavior changes hidden inside large AI-authored diffs or fast implementation loops. A small semantic approval surface plus deterministic first-divergence reports for reviewers.
DriftFence Critical operation behavior, explicit approvals, and deterministic CI gating. Broad repo quality; it is intentionally narrow and should not be treated as a replacement for existing CI. A second gate for the few backend operations where silent behavioral change is too expensive to trust to green tests alone.

DriftFence is strongest when it stays narrow: one saved behavior file per protected operation, one Git-native approval surface, and one deterministic gate for the flows that matter most.

How the loop works.

DriftFence is simple by design: trace one important operation, draft the expected behavior, approve it in Git, then enforce it in CI. In DriftFence, a workflow means one specific code-driven operation your system performs. A trace is the compact behavior record written by one protected test scenario. For a subscription-cancel flow, that can include the input, the billing stop call, the database update, the emitted event, and the final subscription state.

1. Instrument

Write one trace per scenario.

Add the tiny TypeScript SDK to an integration test for a critical operation such as billing cancellation, refunds, entitlements, or provisioning. Each scenario writes one compact behavior record that DriftFence can compare later.

2. Approve

Draft and review the expected behavior.

Generate inferred proposals from traces, accept the approved version into .driftfence/contracts/, and let normal repo review own future changes.

3. Enforce

Block silent behavior changes in CI.

On every PR, tests regenerate traces and DriftFence compares them against the approved behavior. Divergence becomes a reviewable report instead of an invisible operation change.

Choose how strict the guardrail should be.

Adoption starts with simple summaries, then tightens only where exact order or post-execution guarantees matter. The checker keeps the first divergence deterministic either way.

Default for onboarding
Starter mode

Fastest path to protecting an operation.

Starter mode is the launch default because it is easy to understand and quick to adopt. It focuses on the important side effects and lets a strong engineer protect the first operation in under an hour.

Tracks Important calls, effects, and payload slices
Best for Billing cancellation, refund issuance, entitlements
Tradeoff Less strict on exact ordering than full sequence mode

Evidence first. Claims second.

The most credible current public story is still a narrow one: AI-written changes to release operation publish behavior before merge. That proof is strong enough to show value without pretending the product is already proven everywhere.

Current strongest public proof

AI-written release-it publish-behavior changes that passed tests.

The experiment page is strongest when read in four pieces: what was tested, what DriftFence would have blocked, what outside review said about those blocked patches, and where DriftFence stayed quiet.

  • What was tested: 23 separate model-written patches in release-it measured on March 10, 2026.
  • What happened: across the two publish-behavior operations, DriftFence would have blocked 5 of 12 test-passing patches before merge.
  • Why trust the positive hits: independent review judged 4 of those 5 blocked patches worth review or rejection.
  • Why the claim stays specific: on the two other release-it operations in the same experiment, DriftFence stayed quiet across 11 of 11 test-passing patches.
Claim boundary

Specific operation evidence, not broad product proof.

This evidence supports a specific pre-merge release operation use case. It does not yet show broad efficacy across all repos or all operations. DriftFence is for protecting a few critical operations with saved expected behavior and deterministic checks.

  • No repo-wide static inference engine in launch scope.
  • No claim that every release-it task shows the same signal.

Method note: on the release-it proof surface, the model prompt did not mention DriftFence or include DriftFence artifacts.

Designed for a few high-consequence operations.

The right fit is not every test in the repo. It is the handful of backend operations that become operationally dangerous when they change silently.

Good fit

Operations with real blast radius.

Billing cancellation, refunds, entitlement grant or revoke, payout state transitions, subscription renewal, order capture, and account deprovisioning all fit the product shape well.

Billing cancellation Refunds Entitlements Provisioning Payouts Renewals Deprovisioning Order capture
Not the launch story

No broad platform sprawl.

DriftFence is not trying to become a generic semantic diff platform, a whole-repo policy engine, or a replacement for your test runner. Narrow scope is a product feature here.

No browser UI No hosted backend No multi-language launch No auto-approve No repo-wide inference

Get the first operation protected quickly.

The intended adoption path is local and direct. Install the CLI and SDK, instrument one operation, draft the expected behavior, approve it, then enforce it in CI.

Quickstart

Minimal setup, explicit review.

Protect one critical integration flow first. The product gets its credibility from clarity, not from breadth. 

npm install -D @driftfence/cli @driftfence/sdk
npx driftfence init --owners @team-owning-the-operation
npx driftfence draft --precision summary
npx driftfence accept --recorded-by $USER
npx driftfence check --mode enforce
Read next

README for installation and package layout.

Experiment

Release-it experiment page for the real metrics and methodology.

Bounded proof

Release wedge demo runbook for the strongest current live proof loop.

See the actual DriftFence shape.

The product stays concrete: one test hook writes a compact behavior record (`trace`), one approved contract saves expected behavior in the repo, and one CI report shows reviewers the first behavior change that matters.

SDK example

Instrument one integration test.

The SDK wraps the operation steps you already exercise in a real test and writes one behavior-record file for the scenario.

test/cancelSubscription.test.ts 
const trace = startTrace({
  contractId: "billing.subscription.cancel",
  scenarioId: "cancel_nonpayment",
  input,
  stateBefore
});

const billingStop = trace.effect("billing.stop", async () => ({
  ok: true as const
}));
const updateSubscription = trace.effect(
  "db.subscription.update",
  async () => ({ updated: true as const })
);
const emit = trace.emit(async () => undefined);

trace.finish({ output, error: null, stateAfter });
await trace.write();
Approved contract

Keep expected behavior in Git.

The approved contract says which behavior is expected for a named scenario and how strict the check should be.

.driftfence/contracts/billing.subscription.cancel.yaml 
contractId: billing.subscription.cancel
scenarios:
  - id: cancel_nonpayment
    lifecycle:
      state: approved
    precision: sequence
    expect:
      summary:
        effects:
          - billing.stop
          - db.subscription.update
        emits:
          - SubscriptionCancelled
Review report

Show reviewers the first behavior change.

When a patch changes approved behavior, DriftFence explains the first difference directly instead of only failing the job.

.driftfence/check-report.md 
Contract: billing.subscription.cancel
Scenario: cancel_nonpayment
Classification: widening_request

Expected:
  billing.stop(customerId = input.customerId)
  db.subscription.update(patch.status = Cancelled)

Observed:
  billing.stop(customerId = input.customerId)
  queue.analytics.publish(event = "SubscriptionCancelled")