Solon · AI decision governance

How Solon turns overrides into policy

One decision function, four steps, and a human merge. Policy is code, and Git is the review trail.

Step 1: capture every decision

Solon wraps one decision function in your app. Each decision and the override that follows is stored append-only, with PII redacted per your policy. The evidence is audit-ready from day one.

Step 2: cluster the repeats

Similar overrides surface in a rolling window. One override is noise; a cluster is a missing rule. Three similar cases is enough signal to draft one.

Step 3: propose the rule as a pull request

Solon drafts the rule, with the evidence that motivated it, and opens a pull request against your policy repository. Policy is code, so the change is a diff, and the diff is reviewable.

Step 4: a human merges

Your team reviews the rule and merges it, or rejects it. Solon never merges its own proposals. A merged rule applies to every future decision, and the loop keeps compounding.

What the team provides

  • One integration point: the decision function Solon wraps.
  • A Git repository for policies. Private is fine.
  • Two to four reviewers, typically support managers.
  • About 30 minutes a week of feedback during the pilot.

Where the numbers come from

In a four-week synthetic pilot, 800 seeded decisions produced weekly escalations that fell from 28 to 0 while the traffic stayed constant. The evidence pack is available on request.

Run a 30-day pilot

We deploy Solon against your refund or exception workflow. You bring reviewers; we bring the loop and the metrics.

Start a 30-day pilot

Free during the pilot · exit anytime · merging stays a human action

Keep reading