The embedded surface, in technical terms

The API is the lowest level. A partner posts an opportunity, an entity, a document set or a position, and receives structured output: an assessment against the tenant mandate, findings with source attribution, workflow state, or reporting figures with the records behind them. The partner owns every pixel.

Embedded components are prepared surfaces for the parts most partners would rather not build: a screening result view, an evidence pack, an investor portal, a reporting pack. They render inside the partner interface and inherit the partner's own identity session.

The white-label surface is the whole application under the partner brand and domain. It is the fastest route to a working product and the right choice when the partner's brand, not its interface, is the reason users trust the platform.

An assessment carries the mandate it was judged against, the criteria that applied, the inputs that produced each element, and the reasoning, retained rather than discarded once shown. Two tenants can post the same opportunity and receive different output, because the mandate differs.

A diligence response carries findings, and each claim carries its source and how that source was established: self-reported, verified or triangulated. That tiering is the difference between something a committee can use and a readable summary.

Workflow calls return state rather than prose: eligibility status, subscription and allocation state, capital event records, transfer state. Reporting calls return figures with the records that produced them, so a number in a pack can be traced without a reconciliation exercise.

Status changes, decision events and workflow transitions are delivered as webhooks so the partner system reacts rather than polls. Where a partner prefers to pull, the same state is readable through the API.

Users authenticate through the partner's identity provider. Permissions are scoped per tenant, and the tenant boundary is the same boundary that governs data isolation, so an access decision and a data decision cannot drift apart.

Where the partner runs its own assistants or agents, the tool interface exposes scoped operations with explicit permissions, and every agent action is recorded in the same provenance chain as a human action.

This is the question worth settling first. If the partner already has a system of record, it stays authoritative: the layer reads from it and writes back, so the partner is adding capability rather than migrating a business. If the partner would rather the layer hold the record, it can, and export keeps that reversible.

Reuben AI does not hold client money and does not settle transactions. Where a settlement, registry or administration step belongs to the partner or a licensed third party, the layer records and coordinates it rather than performing it.