Sovereign deployments, scoped as an engagement.
Some institutions cannot put their deal record on anyone's cloud. For them, Exedra Gate is delivered onto the client's own infrastructure: the signing engine, the data rooms, the hash-chained audit trail and the evidence packs run inside the client's perimeter, under the client's keys, and the client's security team approves every update before it lands. Each capability that would otherwise reach an external service is a switch the client sets, and every position of every switch has its consequence for what the record can claim, stated in writing before anything runs.
The review is conducted under mutual NDA, with the client's security and technical leads in the room. It covers what exists today and what an engagement would scope; nothing is uploaded and nothing is trialled.
An engagement with the client's security team. Not a download.
A sovereign deployment is scoped, quoted and delivered as an implementation engagement: the client's infrastructure, the client's jurisdiction, the client's security controls, and a hardening and verification plan agreed with the client's own security function. There is no self-serve installer and no trial instance, because for this buyer there should not be.
The boundary is stated rather than implied. This is not marketed as air-gapped: in the connected timestamping modes described below, one thing leaves the perimeter, a SHA-256 fingerprint of the record, sent to an independent authority for timestamping, and that egress is the point, because a timestamp an operator issues to itself proves little to anyone else. A client that requires true isolation can run the deployment with the independent timestamp off, and the claim ladder is downgraded accordingly, in writing. Nothing about either posture is left to be discovered later.
Every external dependency is a switch. Every position has a stated consequence.
The platform's externally connected capabilities are built behind seams: a common interface, named adapters, a configured selection. In a sovereign deployment each one is set to off, supplied by the client, or operated by Exedra Gate, per engagement. The table records what each position means for the record's claims, because a configuration whose claims are undocumented drifts from its marketing within a quarter.
| Module | Off | Supplied by the client | Operated by Exedra Gate | Claim consequence |
|---|---|---|---|---|
| Identity verification (KYC) | The client's own verification process runs outside the platform; the platform records the outcome the client attests. | An adapter is built against the client's identity vendor, per engagement; the seam exists for exactly this. | Hosted verification through Exedra Gate's provider; identity documents transit that provider's infrastructure. | With the switch off, every verified badge reads as verified by the operator of the deployment's own process, never as verified by Exedra Gate or a named provider. The attestation still signs; the attested statement changes. |
| Sanctions and adverse-media screening | The client's trade-compliance function screens; the platform stores their resolution as a dated evidence event. | The client's screening vendor is integrated per engagement. | Exedra Gate's screening service, with the client's acceptance that directors' and owners' special-category data leaves the perimeter for it. | With the switch off or in client mode, Exedra Gate issues no screening badge; an equivalent certification, if wanted, is the client's own, on the client's letterhead. |
| In-app notification only; signing invitations and reminders reach counterparties through the portal alone. | The client's own mail infrastructure carries the messages, through the platform's SMTP transport. | Exedra Gate's delivery provider carries the messages, with delivery webhooks feeding the record. | On the client's mail system, the delivery-evidence claim is downgraded in writing: the record shows dispatch, recorded and timestamped; evidence of delivery becomes the client's mail system's own. On the operated service, delivery events are recorded by provider webhook. | |
| Independent timestamping | Four postures, decided per engagement; the section below states each one with its consequence, because this is the switch the whole claim ladder hangs on. | See the timestamping section. The connected posture is the default; a client-procured qualified authority is the premium posture. | ||
| Billing | Invoice-based enterprise billing against a signed usage record; the card-payment flows of the cloud product simply do not exist on a sovereign deployment. | Not applicable; billing runs between Exedra Gate and the deployment's operator. | Not applicable in a sovereign deployment. | None. Billing has never been part of the evidence story, and turning it off changes no claim. |
| AI assistance | Off entirely. Nothing in the compliance function depends on it: AI on this platform surfaces, and a person decides, in every configuration. | The client's own model endpoint behind the provider seam; the documentation and explainability duties travel with the model to its operator, and the engagement says so. | Optional modules reachable by API token; prompts and content leave the perimeter for those calls, module by module, at the client's choice. | None on the evidence claims. A deployment with AI off loses convenience, not compliance function. |
Stated per configuration, because it is only true per configuration: with verification, screening and mail in client mode or off, and the timestamp off or on site, no document, key or event leaves the client's perimeter in normal operation. Each module moved to an operated service adds exactly the egress named in its row, and nothing else.
The independent timestamp is the load-bearing switch. It is chosen deliberately.
Every evidence pack is signed and hash-chained in every posture. What the postures differ on is the timestamp: who issues it, what leaves the perimeter to obtain it, and what the record can honestly claim afterwards. The posture is decided in the engagement, in writing, before anything runs. The connected posture is the default, because it is the one that keeps the independent-time claim without asking the client to run a trust-service procurement of its own; a client that prefers its own qualified provider takes the second posture instead.
- DEFAULT
Connected: timestamped by an authority Exedra Gate designates. This is the default. The one egress is a SHA-256 fingerprint sent for timestamping under RFC 3161. The independent-time claim holds in full, and the deployment is described as connected but private, never as isolated. The designated authority is independent of Exedra Gate, and Exedra Gate is not itself a qualified trust service provider: where an engagement requires the European framework's qualified presumption, the stamps at the designated endpoint are procured from a qualified provider, bought rather than self-issued, and the engagement records which provider and what its status is.
- CLIENT QTSP
Timestamped by a qualified authority the client procures. The premium posture. Hashes go to the client's own trust-service provider. Under the European framework a qualified timestamp carries a legal presumption that an ordinary one does not (eIDAS, Art. 41(2)); a client with an existing qualified provider keeps that benefit inside its own contractual chain, with Exedra Gate outside it.
- ON SITE
Timestamped inside the perimeter. Nothing leaves. The claim is downgraded in writing and on the record itself: the timestamp is attested by the same operator that controls the evidence store, so the record is internally timestamped and externally verifiable in format, and it is never marketed as independently timestamped.
- OFF
No timestamp. Packs remain signed and hash-chained, and the claim ladder stops there: integrity and order, dated by the operator's own clocks. Offered because true isolation mandates exist, and stated plainly because a client who chooses it should know exactly what was given up.
In a sovereign deployment, your controls govern.
Cloud platforms answer the security question with their own certifications, because they hold your data. Here the platform runs inside your perimeter: updates ship as signed artifacts your security team reviews and approves before anything deploys, and the audit scope stays yours. In the default configuration, the only routine egress is a document fingerprint sent for independent timestamping. That is stated, not hidden.
An ordinary audit log is a table its administrator can rewrite. This one shows the rewrite.
The question a security team asks about any evidence system is what its own administrators can do to it. In most platforms the audit trail is a set of database rows, and whoever holds the database can edit them after the fact without trace. Here every action is sequenced into a hash chain: each entry incorporates the hash of the entry before it, the record is signed with Ed25519, and in the connected postures it is anchored to independently issued RFC 3161 timestamps. Editing or removing an entry afterwards breaks the sequence, and the break is exposed by a verification run, whoever made the edit and whatever their privileges were.
That is a deliberately narrower promise than the industry's word for this, and a stronger one. Nothing here prevents a privileged insider from acting; no honest system can promise that. What the rail does is make retroactive alteration detectable and attributable: the record as it stood is provable, and a record that has been tampered with stops verifying. Detectable is a property that can be demonstrated on demand. Unalterable is a property that can only be asserted.
The rail itself never leaves the client's hands.
In every posture: the in-house signing engine, with no third-party e-signature vendor anywhere in the path; per-document, per-person access control with row-level tenant isolation; the hash-chained audit trail; evidence packs in standard formats, SHA-256 for fingerprints, Ed25519 for signatures, RFC 3161 tokens where the posture includes them, checkable offline with free standard tools; and an update channel in which the client's security team approves every update before it is applied.
Nine sectors whose regimes make the case concrete.
Each page states the sector's own regulatory situation with primary sources, what a sovereign deployment changes for it, the switchboard configuration it would plausibly run, and what Exedra Gate does not solve for it. That last section is on every page on purpose.
Space & satellite operators
Export-controlled technical data in diligence rooms, and network rules that now reach ground-segment operators.
MINERALSStrategic minerals & rare earths
State-screened investors, and provenance chains that must survive audit years after the offtake was signed.
DEEP SEADeep-sea & hydrocarbon exploration
A contested sector, examined hard: sponsorship, licence and baseline documentation, evidence-heavy by construction.
QUANTUMQuantum & cryptography
Dual-use screening on nearly every foreign cheque, and diligence access that counsel treats as an export question.
AI SYSTEMSAI & autonomous systems
A statutory boundary at exclusively-military use, and investors who ask where the line-of-business record is.
CIVIL NUCLEARCivil nuclear
Assistance itself is an authorised activity, and the records are expected to answer questions for decades.
BIODEFENCEBiodefence & synthetic biology
Registration, personnel assessment and oversight regimes that are documentation duties before anything else.
eID & CBDCeID & CBDC vendors
Vendors that sell sovereignty to governments, audited for it, under a rulebook that is still moving.
DEFENSIVE CYBERDefensive cyber security
Flow-down security obligations, exports that turn on knowledge, and a page that states who it is not for.
The first conversation is architectural, and it is under NDA.
An architectural review walks the client's security and technical leads through what runs today, the module switchboard and its claim consequences, and what a scoped engagement would contain. It is conducted under mutual NDA. Nothing is uploaded, nothing is trialled, and nothing on this page describes a deployment that is already productised: the engagement is where it becomes real, with the client's own security team in the room.
Exedra Gate is a technology platform, not a broker, dealer, custodian, escrow provider, or investment adviser. It never holds, routes, or settles investor funds, does not recommend offerings to investors, and charges no success-based fees. A sovereign deployment is an implementation engagement, scoped and quoted per client; it is not a downloadable product, and no configuration of it is represented as satisfying any legal or regulatory regime. Records and timestamps attest integrity and existence as of a date, not compliance with any particular regime; that judgment remains with the client and its counsel.
Regulatory references on this page are orientation, not legal advice: see Sources & verification.