Spec — Forest × Rulebase Integration: QA Ground-Truthing (v0)

For: Nicolas Devillard, Gautier Delache (Forest Admin) From: Chidi Williams, Gideon (Rulebase) Date: 2026-05-01 Scope: Use case 1 of the three agreed in the 2026-04-23 sync. Use case 2 (proactive workflows) and use case 3 (EU two-brain dispute rule) will follow as separate specs.

1. The integration in one paragraph

Rulebase evaluates customer-service interactions for QA. Today our score is blind to whatever the agent did in Forest, so when a reply turns on a back-office field (account state, KYB status, transaction state, compliance flag) we either approximate or skip it. We want Rulebase to read live state from a Forest customer’s MCP server at evaluation time and use that state to ground the score. Read-only, real-time, scoped per customer.

2. Integration shape

• Rulebase acts as an MCP client; the Forest MCP server stays self-hosted on the Forest customer’s side per your two-server model.
• OAuth 2.1 + PKCE per the MCP authorization spec, with Dynamic Client Registration (RFC 7591) preferred and manual client_id/client_secret accepted as a fallback.
• Tool discovery via tools/list at runtime — Rulebase does not bake in per-customer tool catalogs. The QA evaluator picks from whatever tools the customer’s instance exposes.
• Per-customer scoping. Each Rulebase customer (= one Forest customer) gets their own data-source row, OAuth token, and MCP endpoint.
• Reads happen on demand at evaluation time; we cache briefly within an evaluation only, never long-term.

3. The reads we need (categorical, v0)

Two shapes of read are sufficient for v0; specific field names vary per customer.

1. Per-customer record state — flags, enums, and timestamps on the primary customer / account / org record: things like “is this customer in periodic review?”, “what’s the account state?”, “what’s the onboarding / KYB state?”, “are any compliance flags set?”. One lookup keyed on the Forest customer/org ID.
2. Per-transaction state — state of a specific transaction or hold (e.g., pre-authorization state). Keyed on the Forest payment/transaction ID.

Two tool calls per evaluation is fine; more granular shapes are fine if the customer’s collection model favours smaller reads.

4. Out of scope for v0

• No write actions — no triggers, no smart actions, no document uploads. Use case 2 will spec these.
• No dispute records — use case 3 (EU two-brain rule) will spec the dispute read surface separately.
• No historical / time-rewound state. You flagged in the sync that replay is hard; Rulebase QA runs in real time, so we don’t need it.
• No agent attribution or activity-log reads.

5. Open questions for Forest (not answered by your public docs)

1. OAuth surface on self-hosted MCP servers. Your public docs cover Forest Admin SSO and the MCP server feature, but don’t spell out the OAuth surface a third-party MCP client connects to. Does a typical customer instance ship with an OAuth 2.1 authorization server, and does it support Dynamic Client Registration (RFC 7591)? If not, what’s the minimum config we need to surface to a customer admin (redirect URI, scopes, anything else) for a manual registration path?
2. Scope-naming convention. Forest’s permission model is granular (per-table, per-action, with the four-eyes / approval primitives you showed). Does the MCP server expose those as named OAuth scopes? Is there a recommended convention for read-only vs. action scopes that we should adopt rather than invent?
3. Real-time freshness. Is the MCP read path always live-from-DB, or are there cases where it returns cached / lagged state? We want to know whether we can trust “current” or need to mark a finding as stale.
4. Rate limits. Two reads per evaluation × evaluations-per-second is the load shape. Is there a per-tool or per-token rate-limit shape we should design around?
5. Tool discovery. Does the customer instance support tools/list for runtime discovery, or do you publish a static tool catalog separately? Either is fine; we’d just want to know which to expect.
6. Workflow skeletons (your offer). Per Nicolas’s offer in the sync, when we move to use case 2 (Rulebase triggers pre-filled Forest actions on risk indicators), would Forest pre-build matching workflow tools per customer against a spec from us? If yes, what’s the right hand-off format on our side?
7. EU two-brain (use case 3). Where does the dispute object typically live in a Forest customer’s schema, and is filed_at (or equivalent) reliably set? Answer to this shapes whether use case 3 is a separate dispute read surface or just another collection on the existing reads.

6. What we’d like from you next

A short reply against §5 — happy with email, the shared Slack channel, or a 30-min sync. Once that’s clear we can scope a v0 ship plan against a specific Forest customer instance and come back with a concrete OAuth + tool list.