Security & trust

Security is the substrate.
Not a layer we added later.

Velenza was built by a security architect, from the foundation up, for a system that would hold a company's most sensitive operational data. The controls below are not features on a roadmap — they are how the platform works.

Scroll
Our commitment

Built secure at the core.

Most platforms retrofit security once a review demands it — an audit log bolted onto a system that was never designed to produce one, encryption added at the perimeter of a store that mingles everyone's records. Velenza reversed the order.

Designed first
Every action Checked against policy before it runs. Every customer Isolated from every other, by design. Every transaction A way to undo it, confirmed before it starts. Every claim Graded against what actually happened.
Pursuing SOC 2

We are pursuing SOC 2 and are building toward it deliberately rather than scrambling for it — the control map an auditor works through is largely a description of choices already made in the architecture.

Acting on systems you do not own

You cannot own another company's transaction.

A call to raise an invoice times out halfway through. Did it post, or didn't it? Fire it again and you may have billed a customer twice. Do nothing and you're silently short a real invoice nobody ever flagged. Most platforms guess. Velenza doesn't have to — because it never lets that question stay open.

Completed Finished in full, verified — never left half-done.
Reversed The undo path was confirmed before the action ever ran.
Parked for a person Never a guess, never rounded to success.

Always exactly one of these three. Never a fourth, silent state.

These three states describe what Velenza can verify on its own side — never a claim about your vendor's system. We won't call a record there "tamper-proof" or "immutable"; we don't own that system, and no platform honestly can. A security review will find that out in the first ten minutes.
The gate

Nothing runs without a decision.

A decision on every effect, without exception

Every action that can cause an effect is checked against the gate, automatically, not because someone remembered to add a check. There is no way for an action to skip it.

You are always the backstop

Some actions proceed on their own once policy clearly allows them. Anything policy doesn't clearly allow waits for a person — through the same gate as everything else, never a side door.

Always current

A permission you changed five minutes ago is the permission that applies. There is no stale copy to catch up.

Computed, not declared

The decision is derived from the facts of the action together with the policy and the identity asking. There is no severity field for an integration to set wrongly, and no priority for anyone to inherit and forget.

Cognition never touches state

The reasoning half proposes. A separate deterministic layer owns every effect and every byte of stored state. A model cannot make itself the authority that causes something to happen. The separation, in detail →

Nothing starts with write access

Every deployment begins read-only. Write capability is enabled deliberately, once you have watched what the system proposes for long enough to decide.

Your data

Where it lives and what happens to it.

Isolated Never pooled or commingled with another customer's. Built in, not filtered.
Never trains a model Not ours, not a provider's — excluded by the inference terms.
Exportable, then deletable Take it out in full. On termination, it's deleted, not retained.
Encrypted, in transit and at rest Business fields encrypted again at the column level.
Your identity provider No separate Velenza password to manage, or for us to lose.

The service dependencies underneath are shared under review rather than published: who processes what, in which region, under which agreement. A public list of everything a platform runs on is a map for anyone probing it, so that one goes to your security team directly and not to the open web.

Being wrong

Models are wrong sometimes. Velenza is built for that.

A language model reasons over your operational record, and it is wrong sometimes — confidently, like every model. Any vendor implying otherwise is selling you a problem for later. Velenza is architected on that assumption, and four properties follow from it.

Reasoning cannot cause an effect. The worst outcome of a wrong conclusion is a wrong proposal, held at a gate, reviewed by a person against the actual record. It is not a wrong payment.

The evidence stays attached. A conclusion arrives with the records it was drawn from, so it can be checked against them rather than accepted on its own.

Predictions are written down before the outcome exists, then graded when it does. The trailing accuracy is published in the product, including the calls it got wrong. A system with a perfect published record is a system whose checks are too weak to fail.

Every finding shows its sources. You can always get from a conclusion back to the records it was built from, which is the only durable defense against a plausible-sounding wrong answer.

Accuracy figures belong to your deployment, measured on your data, and that is where we will report them — against calls written down before their outcomes existed. An industry-average number lifted into a marketing page tells you nothing about how a system performs on your operation.

SECURITY REVIEW

Send us your questionnaire.

If you are assessing Velenza for someone else, send the standard questionnaire and we will work through it with you — control by control, against the architecture rather than around it.

Send us your vendor questionnaire