Structured business ontology that gives AI agents deterministic access to institutional reasoning.
AI agents using Markdown + RAG score 0% recall on "why?" questions. The same agents using Right Reasons score 100%. Tested across 48 sessions with 2 independent judges. Full experiment results →
Tested on a real business domain (48 runs, 8 task types, 2 independent LLM judges):
| Metric | Markdown + RAG | Right Reasons | Delta |
|---|---|---|---|
| Entity recall | 0.514 | 0.976 | +90% |
| "Why?" question recall | 0.000 | 1.000 | 0% → 100% |
| Reasoning quality | 1.96 / 5 | 4.33 / 5 | +121% |
| Stability (variance) | 1.457 | 0.472 | 3× more stable |
| Latency | 284.6s | 183.8s | -35% faster |
| Pairwise wins | 0 | 20 | (4 ties) |
Full methodology and results →
Right Reasons maps your business knowledge into a four-layer ontology:
LORE (beliefs, worldview)
↓ interpreted_into
VISION (goals, theses, priorities, boundaries)
↓ operationalized_into
RULES (policies, decision rules, tactical concepts)
↓ applied_to
OPERATIONS (initiatives, decisions, tasks, events)
Every connection between layers carries an assertion — an explicit explanation of why that relationship exists. This means an AI agent can trace from any operational decision back to the foundational beliefs that justify it.
- Deterministic retrieval: SQL queries, not vector search. No probabilistic hallucination.
- Reifiable relations: Every edge can carry a versioned "why?" explanation.
- Human validation: Every AI-proposed change goes through diff-based approval (Dolt = Git for data).
- OPS Contracts: Reasoning envelopes that attach institutional context to work in external systems.
- EPICAL pipeline: Extract → Ponder → Interrogate → Calibrate → Authenticate → Load.
- Docker and Docker Compose
- Python 3.11+
docker compose up -dThis initializes Dolt with the schema and example seed data (11 objects, 8 relations across all 4 layers).
cd mcp-server
python -m venv .venv
source .venv/bin/activate
pip install -e .Add to your Claude Desktop / Claude Code MCP config:
{
"mcpServers": {
"right-reasons": {
"command": "/path/to/mcp-server/.venv/bin/right-reasons-mcp",
"env": {
"RR_DOLT_HOST": "127.0.0.1",
"RR_DOLT_PORT": "3307",
"RR_DOLT_DATABASE": "right_reasons"
}
}
}
}Ask your agent:
Why did we choose Provider A over Provider B for identity?
Use the get_explanation_packet tool with object ID "ex_ops_02".
The agent will trace the reasoning chain:
- OPERATIONS: Chose Provider A (affordable, OIDC compatible)
- RULES: Start with affordable identity provider, plan migration later
- VISION: Build self-service tools for micropreneurs
- LORE: Small business owners want to handle accounting themselves
| Tool | Description |
|---|---|
list_objects |
List objects filtered by layer, type, search, validation status |
get_object |
Full details of a single object |
list_relations |
List relations with assertion explanations |
get_relation_assertion |
Full assertion history for a relation |
traverse_graph |
Navigate the ontology graph — trace "why?" chains |
get_schema_info |
All object types (14) and relation types (20) |
get_authentication_trail |
Audit trail: who proposed, confirmed, validated |
get_explanation_packet |
Complete context for an object in one call |
query_sql |
Read-only SQL for advanced queries |
| Tool | Description |
|---|---|
create_session |
Start an EPICAL intake session |
propose_object |
Stage a candidate object (requires authentication before promotion) |
propose_relation |
Stage a candidate relation |
promote_candidate |
Promote authenticated candidate to canonical |
| Tool | Description |
|---|---|
generate_ops_contract |
Auto-generate reasoning envelope from ontology for external work |
get_ops_contract |
Retrieve contract with resolved references |
list_ops_contracts |
List contracts by status or kind |
| Tool | Description |
|---|---|
dolt_status |
Working set status (like git status) |
dolt_diff |
Row-level diffs between commits (like git diff) |
dolt_commit |
Commit changes with message |
Right Reasons does not allow AI agents to write directly into the canonical ontology. All knowledge passes through the EPICAL pipeline:
Source docs ──▶ EXTRACT ──▶ PONDER ──▶ INTERROGATE ──▶ CALIBRATE ──▶ AUTHENTICATE ──▶ LOAD
│ │ │ │ │ │
raw text identify challenge adjust human promote to
intake candidate claims & confidence validates canonical
objects & assumptions scores via Dolt ontology
relations diff review
| Stage | What happens | Who |
|---|---|---|
| Extract | Source documents parsed into fragments | Agent |
| Ponder | Candidate objects and relations identified | Agent |
| Interrogate | Claims challenged, gaps surfaced | Agent |
| Calibrate | Confidence and durability scores adjusted | Agent |
| Authenticate | Human reviews Dolt diff, approves or rejects | Human |
| Load | Authenticated candidates promoted to canonical status | Agent |
The epistemic boundary is strict: promote_candidate requires status authenticated or calibrated. An agent cannot bypass human validation.
OPS Contracts solve the "last mile" problem: how does institutional reasoning reach the systems where work actually happens (Jira, CI/CD, planning tools)?
An OPS Contract is not a task manager. It is a reasoning envelope — a paperclip that attaches scoped institutional context to a work item in an external system.
External work item OPS Contract Ontology
(Jira, GitHub, etc.) (reasoning envelope) (4 layers)
┌──────────────┐ ┌─────────────────────┐ ┌──────────────────┐
│ TASK-123: │────▶│ Clauses (from RULES)│◀────│ RULES: policies, │
│ Prepare │ │ Constraints │ │ decision rules │
│ annual │ │ Success criteria │ ├──────────────────┤
│ report │ │ References (31) │ │ VISION: goals, │
│ │ │ Reasoning chain (13)│ │ boundaries │
└──────────────┘ └─────────────────────┘ ├──────────────────┤
│ LORE: beliefs, │
│ worldview │
└──────────────────┘
The agent generates it in one call:
generate_ops_contract(
external_work_ref="jira://TASK-123",
description="Prepare annual report for submission",
contract_kind="annual_reporting"
)The contract tells the executing agent why this task matters, what rules apply, and which boundaries must not be crossed — without the agent needing to query the full ontology itself.
The full schema is in schema/LOAD1st_bootstrap.sql.
Core tables:
rr_object— canonical business objects with layer, confidence, validation statusrr_relation— typed edges between objectsrr_relation_assertion— versioned "why?" explanations (reifiable relations)rr_object_type— 14 types across 4 layersrr_relation_type— 20 relation types in 5 familiesops_contract— reasoning envelopes for external work itemssrc_session,src_candidate_object,src_candidate_relation— EPICAL intake pipelinesrc_authentication_event,rr_validation_record— audit trail
| Layer | Type | Description |
|---|---|---|
| LORE | lore_item |
Foundational belief or worldview element |
| VISION | strategic_goal |
Desired longer-horizon outcome |
| VISION | strategic_thesis |
Directional belief about how success is created |
| VISION | strategic_priority |
Relative weighting among strategic directions |
| VISION | strategic_boundary |
Strategic no-go area or explicit limit |
| RULES | policy |
Operational policy derived from higher-layer strategy |
| RULES | decision_rule |
Discrete action-shaping logic |
| RULES | escalation_rule |
Trigger for upward traversal or human review |
| RULES | tactical_concept |
Reusable applied operational pattern |
| OPERATIONS | initiative |
Bounded effort or program |
| OPERATIONS | situation |
Live context requiring interpretation |
| OPERATIONS | decision |
Chosen or recommended course of action |
| OPERATIONS | task |
Concrete action unit |
| OPERATIONS | event |
Observed outcome or signal |
Organized in 5 families. Reifiable relations (✓) can carry versioned assertion explanations.
Transition — cross-layer links that form the reasoning spine:
| Code | Description | Reifiable |
|---|---|---|
interpreted_into |
LORE → VISION interpretive transition | ✓ |
operationalized_into |
VISION → RULES operationalization | ✓ |
applied_to |
RULES → OPERATIONS application | ✓ |
Structural — within-layer relationships:
| Code | Description | Reifiable |
|---|---|---|
supports |
Positive contribution | |
constrains |
Limiting relation | |
conflicts_with |
Tension or conflict | |
depends_on |
Dependency | |
affects |
Material effect | |
relevant_to |
Contextual relevance |
Reasoning — justification and prioritization:
| Code | Description | Reifiable |
|---|---|---|
justified_by |
Explicit reasoning support | ✓ |
validated_against |
Validation against another object | ✓ |
prioritized_over |
Relative ranking | ✓ |
escalates_to |
Escalation target | ✓ |
Governance — ownership and authority:
| Code | Description | Reifiable |
|---|---|---|
owned_by |
Ownership | |
reviewed_by |
Review relation | |
authorized_by |
Authorization | |
overridden_by |
Override (with explanation) | ✓ |
Feedback — observations and outcomes:
| Code | Description | Reifiable |
|---|---|---|
observed_in |
Observation in context | |
resulted_in |
Causal result | ✓ |
evaluated_by |
Evaluation | ✓ |
┌─────────────┐ ┌──────────────┐ ┌──────────┐
│ AI Agent │────▶│ MCP Server │────▶│ Dolt │
│ (Claude, │ │ (Python / │ │ (Git │
│ GPT, etc.) │◀────│ FastMCP) │◀────│ for │
│ │ │ 18 tools │ │ data) │
└─────────────┘ └──────────────┘ └──────────┘
│
stdio / SSE / HTTP
- Dolt provides Git semantics for data: branch, commit, diff, merge, PR-style validation
- MCP is the de facto standard for agent-tool communication (97M+ SDK downloads)
- Python / FastMCP keeps the server simple (~700 lines across 7 files)
generate_ops_contract(
external_work_ref="jira://TASK-123",
description="Prepare annual report for submission",
contract_kind="annual_reporting"
)Returns a reasoning envelope with:
- Clauses derived from RULES-layer objects
- Constraints from policies
- Success criteria from decision rules and tactical concepts
- References to all relevant objects across all 4 layers
- Reasoning chain showing the full LORE → VISION → RULES → OPS trace
Business Source License 1.1 — see LICENSE.
Right Reasons is in early development. If you're interested in contributing or using it for your business, open an issue or reach out.