Find what this change actually broke.
Compare base and head in equivalent environments. Separate a new violation from a pre-existing defect, a resolved issue, an unchanged outcome or an incomparable run.
Explore the mechanismBusiness-rule verification
Critical behavior.
From every angle.
Seven verification areas. One evidence contract. A controlled path from finding a violation to reviewing a repair.
01Sequence & state
Only valid transitions may change a record.
- Execute
- Refund a payment before it is captured.
- Observe
- Reject the transition; preserve the original state.
02Concurrency & races
Competing requests must preserve the same invariant.
- Execute
- Two requests reserve the last available unit together.
- Observe
- One reservation succeeds; stock never becomes negative.
03Retries & duplicate effects
Repeating a request must not repeat its business effect.
- Execute
- Deliver the same payment event twice.
- Observe
- One ledger entry, one effect, one stable response.
04Authorization & tenancy
Access must respect ownership, roles and revoked permissions.
- Execute
- A tenant requests another tenant’s record after access is revoked.
- Observe
- Deny access; leave the other tenant’s data unchanged.
05Partial failure & recovery
A failed operation must not leave an invalid partial result.
- Execute
- Interrupt a transfer after debit, before credit.
- Observe
- Roll back or complete the defined compensation; conserve the balance.
06Evaluation integrity
The change under test must not redefine its own judge.
- Execute
- A pull request edits the rule and disables its assertion.
- Observe
- Use the approved base-commit rule; detect incomplete execution.
07Reproduction & diagnosis
A finding must include enough context to reproduce it.
- Execute
- Replay a failure with the same input, schedule and fault point.
- Observe
- Reproduce the observation, or explain the mismatch without claiming a pass.
Five language tracks · two database tracks
Node / TypeScript · Python · Java / JVM · Go · C# / .NET
PostgreSQL and MySQL for each track. Defined Redis scenarios. Explicit execution profiles keep support precise.
From observation to decision
Know what changed.
Know what held.
A verdict is the beginning. The evidence tells you what failed, whether the change introduced it, and what a repair actually preserves.
Observe the effect, not just the response.
Inspect committed state, balances, stock, permissions and emitted effects. A rejected request that still writes unauthorized data is a violation.
Explore the mechanismControl the conditions that expose the bug.
Exercise admitted overlapping schedules, lost responses, duplicate deliveries, restarts and fault points. Record the schedule and the convergence window.
Explore the mechanismReplay the counterexample.
Carry the code and policy revisions, image and dependency digests, seed, initial state, schedule and fault point into a clean replay. Keep original and minimized evidence distinct.
Explore the mechanismKeep incomplete coverage visible.
Retain an observed violation even when another scenario cannot finish. Separate verdict, coverage, applicability and execution state; a successful job alone is not PASS.
Explore the mechanismRepair without weakening the check.
Protect the approved rules and evaluator. Run the original failure, held-out neighboring behavior, legitimate paths and required customer checks against the actual patched commit.
Explore the mechanismControl sharing, spending and writes.
Approve outgoing file names, snippets and tool results. Bound attempts, tokens, time and cost. Review the diff and residual risks; a changed target commit requires revalidation.
Explore the mechanismSupport is a tested combination
Broad scope. Explicit boundaries.
Each language–database profile connects execution, seven-area verification, reproducible evidence and independently reviewed Fix.
| Language track | PostgreSQL | MySQL | Redis |
|---|---|---|---|
| Node / TypeScript | Profile-based verification | Profile-based verification | Defined scenarios |
| Python | Profile-based verification | Profile-based verification | Defined scenarios |
| Java / JVM | Profile-based verification | Profile-based verification | Defined scenarios |
| Go | Profile-based verification | Profile-based verification | Defined scenarios |
| C# / .NET | Profile-based verification | Profile-based verification | Defined scenarios |
Runtime versions, frameworks, dependencies, observation points, scheduling and fault capabilities belong to each published profile. A language name alone is not a support guarantee.
Explore repository compatibilityControlled Fix
Repair the violation.
Keep the judge independent.
- Start from a reproduced FAIL with its approved rule and exact commit.
- Show the files and tool results proposed for model sharing. Send only explicitly approved content under the customer’s model key.
- Generate a bounded patch. Protect rules, evaluation code and prohibited paths.
- Run independent, held-out scenarios and the customer’s required checks. Incomplete execution is UNKNOWN.
- Present the diff, remaining risks, validation results and cost. A PASS is necessary, never sufficient.
- Require human review. No automatic merge or unapproved repository write.
Product acceptance
The whole path has to work.
Panel & evidence
One execution ID and commit connect the verdict, scenarios, evidence and Fix. Loading, empty, stale, error and permission-loss states remain distinct.
Product safeguardsIdentity & access
Repository and organization access is enforced on the server. Revocation, uninstall, logout and recovery invalidate the affected access.
Product safeguardsInstallation & updates
A new team can install a pinned release, approve a rule, read its first real result, update, roll back and uninstall.
Product safeguardsDeployment & rollback
A reproducible package installs in a clean environment and returns to the previous version after a failed update.
Product safeguardsMonitoring & recovery
Controlled outages trigger the correct alert. An encrypted offsite backup restores into a clean environment with verified data integrity.
Product safeguardsComplete user journey
Sign in → connect repository → approve rule → open PR → inspect violation → inspect evidence → review Fix → human approval.
Product safeguardsEvidence before claims
No execution. No PASS.
PASS names the behaviors actually executed. FAIL shows an observed violation. UNKNOWN states what could not be verified. NOT_APPLICABLE means the rule did not apply; it is not a verified pass.
Customer-CI results inherit the trust of the customer’s runner and workflow. Detailed evidence export and model sharing require consent. Source code is not silently uploaded.
Competitor comparisons require versioned, matched conditions and a frozen independent evaluation set. False PASS, false FAIL, UNKNOWN, completion time, reproducibility and cost are measured separately. No superiority claim is made before those measurements exist.