Skip to main content
Developers

Status

A status page that only reports uptime is answering the easy question.

One transaction boundaryThree stacked elements — a record, a rule and a ledger posting — enclosed by a single boundary, indicating that all three commit together or not at all.ONE TRANSACTION BOUNDARYRecordwhat is trueRulewhat is permittedPostingwhat it did to the bookscommit together

What it changes

  1. This deploymentA development-tier environment on managed Postgres over TLS with certificate verification, behind a reverse proxy with a per-request content security policy.
  2. Verified controlsRow-level security isolating, cross-tenant writes refused, append-only ledger and audit enforced, and the deferred balance constraint refusing an unbalanced transaction at COMMIT.
  3. Not yet exercisedNo asset, investor, payment or unit exists in this database, so the business flows have not been run end to end here.
Ask, agree, then actThree steps. One person requests, a different person approves, and only then does the state change. The approval binds to what was requested, so editing it afterwards invalidates the sign-off.Requestone personApprovea different oneActnow it movesThe approval binds to what was asked.Edit it afterwards and the sign-off is void.
Every irreversible act on this platform takes this shape, whatever the subject of the page: one person asks, a different one agrees, and only then does anything move.

What it includes

UptimeA public status endpoint is not yet published.
Incident historyNot applicable: this environment holds no client assets.

See it against something real.

Bring an instrument you are actually considering. Structuring it is the only way to judge whether the model fits.

Your instrument, against this modelAn unspecified asset on the left feeds four stages: structure, compliance policy, the offering book and the register. The asset is drawn as an outline because it is the reader's, not the platform's.Your assetwhatever it isStructurePolicyBookRegister