DPA
Standard data-processing addendum available at contract stage. Sub-processor list disclosed.
Keystone is a data-infrastructure product with a licensed-partner model for every regulated function. This page covers the technical posture and the regulatory posture side by side — because both matter to the buyers we serve. The per-asset hash + hash-chained lifecycle log is the source of a defensible audit trail for lenders, rating agencies, and regulators who need to reconstruct the provenance of any single record in the pool without re-inspecting the underlying asset — and the same log serves as a verified disbursement audit trail for government programs that inspectors general, HUD program offices, and state HFA compliance staff can query in place of reconstructing evidence after the money moves.
Some are shipped. Some are in progress at pre-customer stage. Every one is available on request.
Standard data-processing addendum available at contract stage. Sub-processor list disclosed.
Completed against your standard template (VSA, CAIQ, or your custom form).
Type I readiness assessment scheduled at first design-partner engagement; Type II follows the 6-month observation period.
Every workspace in Keystone is scoped by
workspace_id. Modules, pools, programs,
disbursements, insurance policies, and the activity timeline
all carry a workspace_id and are gated by row-level security
policies at the Postgres layer using security-definer helpers
(is_member(workspace_id)). The policies are the
enforcement layer; misconfiguration or bypass would surface in
the audit trail, which is why every access decision is logged.
As of the June 2026 audit, the RLS surface has been re-verified
against critical findings (see the Audit closure section
below); see audit history
for details.
Every module gets an auto-generated hash at insert. The hash covers provenance, QA, resilience, and value attributes. Lifecycle events (state changes, inspections, transports) are append-only in the audit table; the application layer does not expose edit or delete for prior events, and any exception would appear as an audit-schema anomaly.
Every disbursement attempt — released, denied for milestone, denied for over-budget — is captured. The audit record carries the source module, the requested milestone, the amount, the rail fee, the timestamp, and the decision. Inspector general and program funder access is granted by workspace permission.
Email + password via Supabase Auth. (Auto-confirm in concept mode; real email confirmation will be enabled before production wide-release.) Invite allowlist controls who joins which workspace; invited emails auto-join the named workspace, and any other email gets its own isolated personal workspace.
Hosted on Supabase, us-east-1 region. Postgres 17. Encryption at rest (Supabase default). TLS in transit. Edge Functions run isolated per request.
Industry-aggregated data flows into the Modular Index only de-identified — no manufacturer attribution, no project attribution. Individual workspace data is never exposed to other workspaces or to the Index without explicit consent.
Workspace owners can audit every action taken in their workspace from the activity timeline. Disbursement programs can grant inspector general access scoped to their program. API tokens scoped per workspace. Coming soon: SAML SSO for enterprise workspaces.
The verified-asset rail is only as trustworthy as its weakest tenant boundary. We treat that boundary as the product's foundation.
A security audit conducted 2026-06-12 identified two critical
findings (overly-broad anon-role grants across
public tables; overly-permissive RLS policies on the
prospects table) and additional findings at HIGH
and MEDIUM severity. All critical findings have remediation
instructions applied and the current status is tracked in the
audit document, kept in the source repository. Any counterparty
performing security review can request the audit + closure
record directly.
Request the audit and closure record →
An AI audit trail is an append-only, hash-chained log of every AI decision an operating system made — the input, the model version, the prompt or spec, the retrieval context, and the output — so an auditor can reconstruct any single AI decision without re-running the system. Callisto Bridge's Applied AI engagements extend the same posture into every AI system we build and operate inside a partner: model inventory, prompt-injection audit, hash-chained AI audit trail (a data-access audit, not a model-behavior audit), and human-in-the-loop AI compliance on every regulated action. Same discipline as Keystone, applied to a different surface.
Every model used in a partner's AI system is inventoried with provider, version, deployment target, and authorization scope. When a new model becomes available, it enters the inventory only after passing the partner's evaluation set. Rolled-back model versions stay in the inventory as available fallback targets. This is AI model inventory compliance in the sense EU AI Act, NAIC AI bulletin, and SR 11-7-style reviews expect: which models are in scope, at what version, scoped to which authority, evaluated against which set.
Every prompt template is versioned in the partner's repository and reviewed like code. Retrieved context is tagged with provenance at ingestion and treated as untrusted at inference time. Adversarial evaluations probe injection surfaces before shipping and on a scheduled cadence in production — a prompt injection audit that runs continuously rather than as a one-time pre-launch check.
Every AI output is written to an append-only log with a cryptographic hash that includes the previous log entry's hash — the same hash-chained-audit primitive Keystone applies to verified-asset records. Auditors get an immutable record of every AI decision the partner's product made, along with the prompt, model version, and retrieval context that produced it. This is the AI data-access audit layer (what the AI touched, when, and how), rendered as an AI audit trail for regulatory review — a different but complementary artifact to model-behavior audits.
AI inference calls and training data honor the same data residency rules the rest of the partner's stack respects. Region-pinned inference where required. Federated evaluation where cross-region data movement isn't allowed. Contracts and BAAs with model providers negotiated per partner engagement, not per-user default terms.
Human-in-the-loop AI compliance: when an AI output would trigger a regulated action — a rate filing, a credit decision, a benefits determination, a medical recommendation — a licensed counterparty performs the regulated action. The AI supplies the analysis; the licensed party makes the regulated decision. Same licensed-partner posture that keeps Keystone out of NRSRO, MGA, broker-dealer, and money-transmitter registration; extended to AI systems.
One parent company. Two offers. Ask about either.