Trust
What runs where, and what never leaves.
One page for your security reviewer: what the system is, where the boundary is, who holds the keys, and whether our claims are checkable. Nothing here is a certification claim.
Tier 1 · Verifiable today, no badge required
Six statements your team can check
Zero egress.
No DNS resolver, no default route, no NTP peer outside the room. On the VM shape, time comes from your own network; a site with no time source degrades to a local monotonic clock and is flagged rather than silent. Before go-live the egress probe enumerates 225 endpoints a cloud-native system would call and must report 0 of 225 reachable. That is a gate, not a report.
No subprocessors.
None. Nothing of ours runs in your environment, so there is no third party to attest.
Customer-held keys.
Signing keys live in your TPM 2.0, HSM or dual-control smartcards. SG Systems never holds a key that can sign a decision.
Residency is trivially satisfied.
There is no shared infrastructure to partition. Your data is on your hardware in your data centre.
Reproducible, including the rationale.
Given a workflow and an input, every artifact re-derives bit for bit: the scores, the margin, the kept set, and the explanation paragraph a reviewer signed. Re-deriving needs the exact runtime, which is a fork: upstream llama.cpp at b11053 plus one recorded patch. The upstream tag alone will not reproduce a record; the patch and its hash are stated below.
Append-only audit trail.
The ledger is hash-chained and never rewritten. Corrections are appends. The chain head is anchored daily to write-once media.
Tier 2 · Inspectable, because we publish the means
We can’t afford to buy trust, so we made it inspectable.
Five artifacts that let your own security team verify our claims rather than trust a purchased certificate.
- 1
The open-source verifier.
Apache-2.0. The code that walks the hash chain and checks each signature against the key history, and re-derives the margin and the kept set from the score vector stored on the Seal — arithmetic on recorded numbers, so ‘verified’ is a statement anyone can check with a static binary and no trust in us. Re-deriving the scores themselves is a different artifact: it needs the pinned runtime, the weights and the cartridge, and is the re-derivation kit, not the verifier. Without the verifier, an auditor would have to take our word for the chain; with it, the chain is checkable and the limit of what is checkable is stated rather than blurred.
- 2
SBOM and signed build provenance per release.
Every component and version in the image, generated at build and never handwritten, plus a signed statement from the build enclave: image hash, source commit, build host, signing key. What is in it, whether it is what we built, and whether a decision can be re-derived years later.
- 3
The published threat model.
The trust boundaries, what the proof record does and does not prove, and our own limitations list, restated as a threat model rather than as marketing caveats.
- 4
The egress probe methodology.
Not just the 0 of 225 requirement: the target list and the procedure, so your network team can re-run it. A negative test proves only what was enumerated, and we say so.
- 5
The inference runtime is a fork, and we say so.
The pinned runtime is upstream llama.cpp at b11053 (commit 1af554f8) with one patch, remit-0001, which forces every embedding task to run cold: the upstream server reuses the cache of the previous request, so the same input could yield a different vector depending on what ran before it. Re-deriving a record requires the patch, not the upstream tag. Patch sha256 137846f2ba2e34cdcfaf4bc9cfac4abf688a4361ebe358419a8ffaeaed51d581; it ships in every cartridge’s audit pack at audit-pack/patches/ and is mirrored in the public verifier repository at github.com/sg-systems-co/remit-verifier/tree/main/runtime, with the pin record beside it, and the manifest carries the derivation in machine-readable form: “upstream 1af554f8fc78ba029665a47b839484d9763e2a75 + audit-pack/patches/* (recorded, hashed); re-deriving from upstream alone does not reproduce”. The build is CPU-only and static, without native tuning, so there is one accumulation order and one binary; a GPU or BLAS build is a different pin, and so is another operating system. The pin record names every build flag explicitly, including the defaults — the development build links Apple’s Accelerate framework (GGML_ACCELERATE=ON) with no BLAS backend, no Metal, no OpenSSL and no subprocess capability — and records the compiler and the CPU features it targeted, so the build a bank reproduces is the build that was run. The appliance pin is a Linux build that does not yet exist: it is declared in the same record, explicitly unbuilt, and is a pre-pilot gate built where the enclave will build it. Determinism has been measured on the development pin only.
The threat model and the probe methodology are published on this site, with the reviewed target list (225 endpoints) as a document. The verifier is published: github.com/sg-systems-co/remit-verifier, Apache-2.0, tag v0.1.0 naming the build it verifies, with the release build command in its README so the binary is reproducible. The probe itself, and per-release SBOM and provenance, are to be published with the first release; until then they are described here and linked nowhere.
Read the threat model
Deployment boundary
Three shapes, three enforcement levels
Where the gap is enforced depends on the shape you choose. In every shape the runtime has no route to the internet.
Single appliance at a site
One server runs all four products, connectors, the audit store and the consoles. No default route, sealed network configuration; files arrive by internal SFTP or approved media.
Core plus branch edge
Branches run intake, decision and gate locally and keep deciding within their licence if the core is unreachable. Edge to core crosses a one-way, allow-listed link; the core is never internet-facing.
On your own VMs
REMIT runs as VMs or containers on your hypervisor under your network policy. It makes zero external calls; the egress probe is continuous evidence rather than a network claim.
Keys, records, retention
How the proof stays provable
Signing keys never leave the hardware.
Proof records are signed by a key generated inside the appliance’s TPM or your HSM. The private key is never replicated and never crosses the boundary; public keys and their history are archived so a seven-year-old record still verifies.
Rotation is itself a record.
A key rotation is a ledger entry signed by both the old and the new key, so the key history is a chain, not a list.
An append-only, anchored ledger.
Every action is a hash-chained entry. The chain head is anchored daily to write-once media and included in the compliance report, so truncation is detectable, not merely forbidden.
Seven years by default, on write-once media.
Records and the audit trail are retained for seven years and archived to WORM media in sealed ranges that remain verifiable from the media alone.
Erasure without rewriting history.
Each case’s personal data is encrypted under its own key. An erasure order that survives legal review destroys that key and appends a tombstone entry; the decision stays provable and the data becomes unreadable. Whether this satisfies a given regulator’s definition of erasure is confirmed per market before the control is exposed.
Masked by default, unmasked by a person.
Consoles and the API show personal data masked by role. Unmasking is a human, permissioned, audited act, never an API grant.
Identity and access
No REMIT accounts
- People sign in through your identity provider: LDAP, SAML or OIDC. Directory groups map to roles in signed configuration.
- Machines authenticate with client certificates from your own CA, carry scopes rather than roles, and each has a named human owner resolved through your IdP.
- A machine principal can never hold an administrative role. Integration cannot become administration.
- Detail such as model scores is gated by role, never by a click. Reviewers never see a probability.
Tier 3 · Certifications
What we hold, and what is yours
Held today
None. We do not display what we have not earned, and we do not list targets we have not funded.
Your frameworks, which we support
MAS TRM, MAS 626 and SR 11-7 model-risk management, PDPA, GDPR, the EU AI Act and DORA are your obligations. The proof record, the measured standard and the model-risk file exist to help you satisfy them. We do not present them as our certifications.
A SOC 2 or ISO certificate would attest to SG Systems’ corporate controls. It cannot attest to the appliance in your data centre, because nothing of ours runs there. That is why we publish the means to check us instead, and why we will pursue a certification when your procurement requires one, not to decorate the site.
Our own data protection
SG Systems operates under Singapore’s PDPA
With a named Data Protection Officer and a published policy. This is about the little personal data SG Systems itself holds: site visits, enquiries, and the people we work with. It is separate from REMIT helping a customer meet its own obligations, which is a product capability. We hold no data protection certification and do not claim one.
Data Protection Officer: Sebastian Grebe, sebastian@sg-systems.co
Read the privacy policyReporting a vulnerability
Report security issues to sebastian@sg-systems.co. We acknowledge within two business days, keep you informed, and take no action against good-faith research. The policy is at /disclosure; the machine-readable contact is at /.well-known/security.txt.
Send this page to your security team.
If they have a question it does not answer, we would rather hear it now than in procurement.