Trust Center

Direct Answer

A private equity firm verifies AI-generated deal analysis by checking three things it can inspect rather than three things it is told. First, whether every material claim resolves to a source page the reviewer can open. Second, whether the release that produced the analysis is itself verified against known-correct answers on the live system, with a failure holding the pipeline rather than being logged and forgotten. Third, whether the firm's data is separated from every other tenant by an enforced mechanism rather than a policy statement. The ReturnCatalyst Trust Center describes the mechanisms behind each, and keeps in-progress governance work marked as in progress rather than presented as an attestation.

Governed publication into the citation layer

AI output becomes citable evidence through one sanctioned publication path and no other. That path verifies the owning organization before it writes anything, refuses to reactivate a deleted or superseded record or one belonging to a different project, and takes an exclusive lease that is re-validated inside the write transaction. Extracted content is stored as a content-addressed object written with a create-only precondition, so a published version cannot be silently overwritten in place, and a superseded version is removed only after its replacement is durably referenced. The chokepoint is self-enforcing: a structural test parses every backend source file and fails the build if any code path other than the sanctioned ones publishes into the retrieval and citation layer. On the document spine itself, client applications cannot create document records at all, and client updates are restricted to an explicit allowlist of presentation fields — indexing state, extraction output, storage pointers, tenancy, and derived content are writable only by backend services, and the coordination records that fence concurrent document mutations are neither readable nor writable from a client.

Tenant isolation enforced at two layers, not asserted once

Backend callable functions run with administrative credentials that database rules cannot constrain, so every callable that touches tenant data performs its own project-access check before it reads or mutates anything. The same check governs retrieval: a question is narrowed to the caller's accessible projects before synthesis, rather than searching broadly and filtering the citations afterwards. For anything a client reads or writes directly, Firestore security rules apply the same team-membership predicate and are the final gatekeeper.

Releases gated on live production evidence, not a green build

Regression suites run in CI before a deploy. After every release to the main branch, 17 named evaluation gates run as live probes against the deployed system — real requests, real project data, real authentication — repeated across rounds, with a nine-gate subset required to complete consecutive rounds with no retries before a release counts as clean. The gate list is not a comment that can quietly shrink: a test parses the pipeline definition and fails if the count or the membership changes. Where a gate is deliberately advisory while its threshold is being ratcheted up, that state is declared in the pipeline configuration rather than hidden.

Provider failures never reach a deliverable

An external research provider once returned an API-retirement notice — marketing copy and support address included — and that raw text reached a partner-facing dossier. Provider failures are now classified into a fixed set of causes and rendered as one of a small set of neutral phrases naming the role the provider played, never its identity, its URL, its support address, or its raw message. Each surface owns exactly one status line, so a stale failure from an earlier run cannot accumulate beside a newer one. A regression test pins the exact text that leaked and asserts it can never be reproduced.

Frequently Asked Questions