What the twin does
The twin evaluates an institution’s balance-sheet specification with deterministic, versioned methods: a cash survival surface across horizons and stress scenarios, an exit path graph with time-to-cash and shared dependencies, signed distance to every mandate constraint, and a ranked list of evidence gaps. Decisions built on that evidence live in a versioned repository with flip conditions and hash-chained events.
Run the embedded demo to inspect the complete output, or use the guided one-USTB builder below. Advanced users can still edit the exact twin-spec-v1 JSON.
Build a one-USTB treasury twin
This guided builder creates the exact client-held specification for a bounded pilot: opening USD cash, one USTB holding, one hard obligation and a 7-day liquidity mandate. USD inputs must be exact cent amounts no greater than $9,000,000,000,000 each. The service applies its labelled default exit routes. Nothing is sent until you choose Evaluate.
Review and evaluate
Review the generated twin-spec-v1 document or paste an advanced specification. Your original JSON is sent unchanged after a local syntax check, so the service can enforce exact-cent money lexemes before decoding numbers. It is processed in memory and is not stored unless you explicitly select persistence. Every response carries the canonical specification hash for replay.
Load a stored evaluation
Enter an evaluation ID returned by a persisted run. The service verifies the stored hashes before returning its specification and evidence.
Recent evaluations in this session
Evaluation
Cash survival surface
Each cell shows the share of simulated paths on which every hard obligation is met, the coverage ratio, and, where shortfalls occur, the median first-shortfall day. A cell marked insufficient inputs is suppressed rather than estimated.
Exit paths and time to cash
Common-mode dependencies
Single points of failure
Mandate headroom
Liquidity bucket coverage
Nearest breach
Headroom is the signed distance to each constraint. A negative figure is a breach and is stated as such, never clipped. Where a ratio is undefined because the stated need is zero, it is suppressed rather than shown as infinite.
Blind spots
Evidence gaps that could most change the answer, ranked by the share of value they expose: positions on assumed default routes, stale or suppressed inputs, and flip conditions sitting within their margin.
Decision repository
Decisions are versioned artefacts: each version pins its inputs and method versions, carries machine-checkable flip conditions, and expires on the tightest freshness budget of its evidence. Every state change is an event on a hash-chained ledger. Open a decision to see its versions, compare any two, and download the packet for an approved version.
Required only to create a decision, append a version or change status. It is kept only for this browser session and sent only as the X-Governance-Token header on those write requests. It is never used as subscriber access.
Diff two versions
Status action
Status changes follow the governed lifecycle (draft, proposed, approved, superseded, expired, review required). Every action is bound to the explicitly displayed main-branch version. A required rationale is recorded with the event; disallowed or stale transitions are refused and the review context is refreshed. The audit actor is the verified governance key ID, not a caller-entered name.
Events ledger
Record a decision
New decisions start as version 1 on the main branch, in draft. If an evaluation has been run on this page, its identifiers are pinned to the record automatically. Flip conditions state what observation would change the answer; evidence rows set the record’s freshness budget through their cadence. The durable audit actor is the verified governance key ID.
Flip conditions
Evidence
YieldGuard Ltd is a technology provider, registered in England and Wales, company number 16914415. YieldGuard does not custody client assets, hold private keys, provide investment advice, act as broker or dealer, or exercise discretionary investment management. Twin evaluations and decision records are evidence for committee review, produced by deterministic, versioned methods; nothing on this page routes, allocates or executes, and nothing is a recommendation to transact. See the methodology changelog for corrections.
