https://www.sagitta.systems/newsroom Design intent and architecture reasoning from the people building the network. en Thu, 30 Jul 2026 00:00:00 GMT https://www.sagitta.systems/sagitta.png https://www.sagitta.systems/newsroom https://www.sagitta.systems/newsroom/risk-policy-is-only-real-when-it-constrains-the-decision https://www.sagitta.systems/newsroom/risk-policy-is-only-real-when-it-constrains-the-decision Thu, 30 Jul 2026 00:00:00 GMT A founder perspective on allocation governance: a risk policy that cannot refuse a decision is documentation rather than a constraint. The article opens on a situation most treasury operations will recognise. Delegates rotate. A position taken eighteen months ago comes under scrutiny, and nobody currently in the room was in the room when it was taken. Without a durable decision record, the team reconstructs the answer from spreadsheets, governance discussions, messages, and individual memory — which is to say it reconstructs an answer, not the answer, and cannot tell the difference. The usual response is that the institution has an investment policy statement, and it does. The argument here is that this is not where the failure occurs. The operational gap appears at decision time: written policy still requires interpretation, and that interpretation rarely becomes part of the allocation itself. The document says what should happen. Someone reads it, forms a view about what it means in the present circumstance, and acts. The view is what actually governed the decision, and the view is precisely what does not survive. So a policy that cannot refuse a decision is not functioning as a constraint. It is functioning as documentation of an intention — useful for explaining what the institution meant to do, useless for establishing what it did. The Autonomous Allocation Agent's answer is to convert approved policy into machine-checkable logic. Once a policy is approved, its rules define the permitted decision space, and the interpretation step disappears because there is nothing left to interpret at decision time. The allocation either falls inside the space the policy describes or it does not occur. Determinism does the supporting work. Identically declared assets allocate equally, and changing row order cannot alter the result. That second clause is smaller than it sounds and matters more: an allocator whose output depends on the order in which inputs happened to be listed has a hidden input, and a hidden input is unauditable by construction. Removing it is what makes the rest of the record trustworthy. Each allocation then produces a decision record carrying the declared beliefs, the policy version, the constraints evaluated, the allocator version, the policy effects, the turnover, and the final allocation. The reconstruction problem the article opened with is solved not by better documentation habits but by making the record a by-product of the decision rather than an activity performed afterwards by whoever remembers to. The governance shape that results is clean: treasury delegates declare the investment beliefs, governance ratifies the policy, and AAA preserves the connection between them. When the question arrives eighteen months later, it is answered from the record — not from whoever is still employed. The full article is published on LinkedIn. Article Words from the Architect Xavier D. Moore https://www.sagitta.systems/newsroom/account-to-treasury-lifecycle-behind-an-onchain-financial-product https://www.sagitta.systems/newsroom/account-to-treasury-lifecycle-behind-an-onchain-financial-product Tue, 28 Jul 2026 00:00:00 GMT A founder perspective on what a bank actually has to control to put a deposit product onchain: funding, enrolment, term, maturity, and the evidence returned at each transition. Onchain financial products are often assembled as disconnected components: custody, stablecoin rails, wallets, tokenized assets, and sources of return. Each is real, each works, and none of them individually knows whose money it is holding. That is the gap the article is about. An institutional product has to connect those components to account ownership, reconciliation, customer balances, exception handling, and treasury policy — and the requirement can be stated in four lines. Every movement needs an account state. Every settlement needs a defined purpose. Every return needs evidence. Every distribution needs a governed destination. A component stack that cannot satisfy all four is a set of capabilities, not a product a regulated institution can operate. The lifecycle the article specifies runs: operating account, settlement, documented return, treasury distribution. The operating account establishes ownership, with the institution's core ledger as the source of truth. The design point is that the institution keeps its interface, brand, and customer relationship — USDC is the movement layer, and the bank remains the customer experience. Settlement then connects that ledger to onchain execution: batches record source accounts, purpose, amount, authorization state, and destination, with screening, sanctions controls, and whitelisting applied before release, so every movement stays connected to its originating account events and control history. The third stage is the one that distinguishes this from a payment rail. On completion, a proof-of-return record is generated and linked back to the original settlement batch, carrying the batch reference, deployed capital, destination, network, transaction identifiers, completion dates, gross return, variance, approval trail, and ledger postings. Operations and finance receive a reconciliation statement rather than reconstructing what happened from a block explorer — which is the difference between an auditable product and an interesting one. Exception handling is treated as part of the lifecycle rather than as failure. Failed settlements, delayed transactions, stuck batches, depegs, and reconciliation variances enter named states, and the customer's available balance reflects the last confirmed account event while unresolved capital remains visible as pending. Financial truth is preserved through the exception instead of being suspended until someone resolves it. Treasury distribution then applies the institution's own rules: customer principal and earned return to designated accounts, institutional revenue posted separately, the same accountable path every cycle. The boundary is explicit throughout. Sagitta orchestrates the lifecycle alongside the institution's existing banking environment; the institution retains the regulated customer relationship, the custody structure, and compliance responsibility. Sagitta does not take custody or hold customer funds. Sagitta Banking is In Development. The article describes the specified control surface and the two engagement paths — an architecture and diligence engagement, and a pilot — not a delivered integration. The full article is published on LinkedIn. Article Words from the Architect Xavier D. Moore