Most tools govern what an agent can do. Solon governs whether the decision was right.
Human overrides become AI policy: automatically, auditably, and only with your sign-off.
Open principles and architecture · policy stays in your Git repo · a human merges every change
What Solon sees
Why now
Since August 2, 2026, the EU AI Act's transparency obligations are in force, with broader high-risk obligations phasing in around the same window. The practical effect on AI products: buyers and auditors increasingly ask for decision-level evidence, not just activity logs.
Most stacks can show that an agent acted. Almost none can show what happened the last time a person disagreed with one of its decisions. That gap is what Solon closes: overrides captured, patterns learned, policy merged by a human.
Where each approach sits
Categories, not mud-slinging: every tool below is good at the question it answers. None of them answers Solon's.
| Tool | What it governs | When it acts | Learns from overrides | Produces durable policy |
|---|---|---|---|---|
| AWS Bedrock AgentCore (temporal policies) | Agent actions and tool access | Runtime, before the action | No. Approvals are required, not learned from | No. Rules are authored manually |
| Salesforce Agentforce Trust Layer | PII, prompt injection, audit logs | Runtime | No | No |
| Evaluation & observability suites | Output quality and drift | After the fact, on outputs | No. Scores outputs, not business decisions | No |
| GRC platforms | Risk registers and compliance documents | Inventory and periodic review | No | No. Documents, not executable rules |
| Legal guardrail platforms | Compliance with known regulation | Before the action, static rules | No. Rules are authored top-down by lawyers | Yes. Written from regulation, not from your decisions |
| OPA / Rego | Infrastructure access policy | Runtime, static rules | No | No. Rules are engineered by hand |
| Spreadsheets + manager judgment | The status quo | After the fact, in people's heads | Implicitly. Then it walks out the door | No. The same case returns |
| Solon | Business decisions: refunds and exceptions | On every decision, and after every override | Yes. Overrides cluster into a proposed rule | Yes. A versioned pull request a human merges |
Based on public documentation, September 2026. If something here mischaracterizes your tool, tell us. We'll fix it.
From override to policy, in four steps
Solon wraps one decision function in your app. Everything else is the loop.
Every decision, recorded
Each decision and override is stored append-only, with PII redacted per your policy. The evidence is audit-ready.
Repeats surface
Similar overrides cluster in a rolling window. Three similar cases is enough signal to propose a rule.
A rule, as a PR
Solon drafts the rule and opens a pull request against your policy repo. Policy is code; Git is the review trail.
A human decides
Your team reviews and merges. Or rejects. Merged rules apply to every future decision.
Humans stay in charge: Solon never merges its own proposals. Policy changes apply only when a person approves the pull request.
Why not just a spreadsheet?
For most teams, the real alternative isn't a vendor. It's a spreadsheet and a manager's memory.
No versioning
The policy lives in someone's head. There's no diff, no review, no history to learn from.
No audit trail
When a decision is questioned months later, the reasoning is gone.
It walks out the door
When the manager leaves, the judgment leaves with them. Nothing compounded.
Solon turns that judgment into versioned, reviewable policy. Starting from the overrides your team already makes.
Proven in a 4-week simulation
Seeded traffic, simulated reviewers, the real stack. 4 weeks × 40 decisions/day. The loop compounds: escalations fall at constant traffic.
Synthetic partner simulation, seed 7. An internal proving ground, not a customer. Identical-seed reruns vary (acceptance 50–75%); both modes validated: local merges and real PRs. Evidence pack available on request.
Every tool answers a different question
The AI governance market is crowded. With tools answering everything except the question your policy owner asks.
| Question | Who answers it |
|---|---|
| Can the agent act, and what can it reach? | Agent runtimes & access-control security |
| Is the output good, and is it drifting? | Evaluation & observability suites |
| Is the organization documented for auditors? | GRC platforms |
| Is this decision correct. And did we learn from the last override? | Solon |
Built in the open
The thinking behind Solon is public: product principles, architecture, dated decisions, and the build log. Every entry is curated, and every publication is merged by a human, the same rule the product enforces for policy. The code repository is still private; the open work is live now.
Read it on GitHubCurated in the open · every entry merged by a human · content licensed CC BY 4.0
Work with us
We are looking for a few teams running refund or exception decisions to collaborate with us as design partners. You keep your policy in your Git repo and your evidence in your stack; your feedback shapes what we build.
What you bring
- A refund or exception workflow with real volume
- A Git repo for policies (private is fine)
- 2 to 4 reviewers, typically support managers
- About 30 minutes a week of feedback
What you get
- Direct influence on what we build next
- Help getting set up
- Policy co-authoring from your current exceptions runbook
- A direct line to the team
No cost · your policy stays in your Git repo · a human merges every change