Trust Is a Feature

Most software markets trust as a vibe.

In financial tooling, trust is concrete. It shows up in the small decisions:

How errors are surfaced.
Whether you can export the inputs and outputs.
Whether the system can explain itself six months later.
Whether integrations are intentional or accidental.

Trust is an architecture problem

When services call each other directly in ad-hoc ways, you get invisible dependencies. The first time a schema changes, something breaks somewhere else, and nobody knows why until an incident forces the issue.

We’re avoiding that pattern with two commitments:

OpenAPI as the contract. Services publish their schema. Clients are generated or validated against it.
MCP as the discovery layer. Tools and agents ask MCP where services live, what version they’re running, and what they can do.

This gives us a single place to answer questions like:

What endpoints exist in dev vs prod?
What changed in the schema since yesterday?
Which clients need to be regenerated?

Trust is a UX problem too

Good UX is not “less information.” It’s the right information, at the right moment, in a form you can act on.

For financial workflows, we bias toward:

Clear descriptions and examples
“Why” alongside “what”
Checklists and completion states
Exportable workpapers

If you can’t explain a result, you can’t defend it. The UI should make the reasoning visible.

What this means for v1 releases

Early versions don’t need to be perfect. They do need to be honest.

If something isn’t implemented yet, we’ll say so. If a route is a stub, it will be minimal and explicit. If a feature is planned, we won’t pretend it exists.

That’s part of trust: no surprises.