Building Calm Financial Systems

Financial products often ask people to compensate for system weakness. They ask a trader to stay alert through volatility, a borrower to reveal more than is necessary, or an operator to remember the boundary that software failed to enforce.

Kiyan starts from a different question: what would it take for the system itself to carry more of that discipline?

Calm is an implementation property

“Calm” is easy to misunderstand as a visual preference. In Kiyan's current product work, it means that a consequential action has fewer places to become ambiguous. The implementation should carry the checks a person would otherwise need to remember under pressure: which state is current, whether a route is eligible, whether an approval still matches the request, whether a payment has actually settled, and whether a capability is live at all.

Mowazi and Naseeg solve different problems, but both are built around that reduction in ambiguity. Mowazi keeps model output, deterministic policy, owner signing, restricted venue credentials, and execution services in distinct layers. Naseeg keeps a reusable project, a Fund's round-specific curation decision, a paid contribution, and optional encrypted signals in different records and systems.

01 / mowazi

Execution boundary

Evidence, policy, owner approval, and venue work remain separated.

02 / naseeg

Round boundary

Reusable projects, Fund decisions, and paid contributions remain distinct.

03 / shared

Status boundary

Closed Beta and Coming Soon are product facts, not visual details.

Mowazi: do not turn a useful model into an owner

In the current Mowazi stack, Convex owns authenticated product state and current snapshots; Temporal owns durable workflow coordination; Timescale holds detailed evidence and history; Redis holds short-lived coordination; and an isolated gateway/sidecar handles the narrow execution boundary. The model worker can produce evidence and proposals, but it does not receive a wallet key, venue credential, signing adapter, or broadcast tool.

That can be expressed as a deliberately boring rule:

type Proposal = { market: string; venue: string; sizeUsd: number };

function modelMayCreateProposal(input: Proposal) {
  return validateStructuredProposal(input);
}

function modelMayExecute() {
  return false;
}

The real implementation is more detailed, but the architecture should be this legible. A proposal enters an admission and preflight path that binds an idempotency key, policy, current observations, and an exact market/venue scope. A fresh quote and deterministic checks decide whether dispatch is even possible. A later reconciliation path handles uncertain outcomes. A polished agent interface does not change that sequence.

Naseeg: do not let a local decision become a global label

Naseeg's active funding model treats a project as reusable content and a Fund submission as a decision inside a specific round. Support eligibility requires an open round, a published project, and a curated submission in that round. The decision does not rewrite the project's identity or prevent it from participating in another Fund.

const canSupport = isProjectSupportEligible({
  roundStatus: round.status,
  projectStatus: project.status,
  submissionStatuses: roundSubmissions.map((item) => item.status),
});

if (!canSupport) throw new Error("Project is not eligible in this round");

At settlement, Stripe Checkout handles the card payment and Convex records the contribution state and allocation inputs. Optional Sepolia fhEVM interactions can carry encrypted support signals or scores, but do not custody the fiat payment or become the source of truth for public totals.

Status language carries product responsibility

The same discipline applies to public copy. Mowazi is in Closed Beta: public quotes, shadow paths, or a working interface should not be described as universal live execution. Naseeg is Coming Soon: its current implementation and domain model can be explained without pretending that it is publicly open for funding.

This is not conservative wording pasted on after the system is built. It is part of how a serious product stays understandable. A status must tell a user what they can rely on today, not what a roadmap may eventually permit.

The practical test

A calm financial system answers a small set of questions without forcing the user to infer the rest:

1. What is this system allowed to decide?
2. Which system owns the current state?
3. What must happen before money or authority moves?
4. What has been paid, simulated, proposed, blocked, or merely researched?
5. Which capability is available now?

When the code cannot answer those questions, the design should not cover the gap with confidence. Kiyan's implementation direction is to make the missing boundary visible, reduce authority, and add the next control only when it can be inspected.

That does not mean removing people from consequential decisions. It means making policy explicit before automation moves, defining where private information may travel, and presenting a status that is honest about what is available now. Calm is the result of that work. It is not a beige interface placed over an unpredictable system.

Two products, one standard

Mowazi is built around autonomous trading, where evidence and analysis can be useful but must never silently become execution authority. Naseeg is being built around public-good funding, where creators, Fund Accounts, and supporters need a shared model without collapsing projects into one global approval decision.

The products are different. The standard is the same:

• define the responsibility boundary;
• make the source of truth clear;
• preserve meaningful owner or operator control;
• expose the system's status without inflating it.

The work is in the boundary

A promise is easy to write. A boundary needs architecture, product language, tests, and an interface that makes the boundary legible. That is why Kiyan publishes engineering and research notes alongside product pages. The writing is part of the product: it tells collaborators which claims are implementation facts, which are research conclusions, and which capabilities still require a deliberate activation decision.

We think financial systems should feel composed because the underlying system is composed. That is the work Kiyan is here to do.