Security & sovereignty, written to paste into an RFP.

Every claim below is an architectural commitment, not a brochure adjective. Ask us to substantiate any line in a technical session — that's what the briefing is for.

Request a Government BriefingLaunch the Full Demo

History you can prove — not history you have to trust.

The difference between a system that asks for your confidence and one that hands you the evidence to check it yourself.

Opaque systems

History lives in a database an administrator can quietly edit; you take its integrity on faith.

On ASTRAEA

An append-only, hash-chained audit spine: any alteration of history breaks every subsequent hash.

Opaque systems

Existence and timing of a record depend on the vendor's word and the vendor's continued existence.

On ASTRAEA

Daily checkpoints anchored to the Bitcoin blockchain via OpenTimestamps — existence proofs verifiable by anyone, forever, with no dependence on any vendor.

Opaque systems

Data location is a marketing promise with no residency boundary you can point to in a contract.

On ASTRAEA

Primary data, backups, and logs stay within an agreed residency boundary; cross-border replication only by explicit configuration.

Opaque systems

You are told the system is secure and asked to believe it.

On ASTRAEA

Architecture, logs, and processes are structured so you can audit us — we assume you will.

A history that breaks visibly if anyone touches it.

An append-only event log runs across all branches, with per-entity chains and daily checkpoints. The integrity of the record does not rest on trust in an operator — it rests on math.

  • Hash-chained audit spine: any alteration of history breaks every subsequent hash.
  • OpenTimestamps anchoring (optional): daily checkpoints anchored to the Bitcoin blockchain — existence proofs verifiable by anyone, forever.
  • Litigation-ready exports: chain-verification reports and per-record integrity proofs in formats a court can consume.

Sovereignty is where the data lives, and who holds the keys.

Run ASTRAEA the way your assurance posture demands — from a managed sovereign cloud in your jurisdiction to a fully air-gapped enclave — with the residency boundary written into the contract.

Managed sovereign cloud
Operated within your chosen jurisdiction and residency boundary, with contractually defined data-location guarantees.
On-premise
Your data centers, your operations staff, our platform and update channel.
Air-gapped
Fully disconnected deployments for classified or high-assurance environments; updates by signed media; anchoring via periodic export.
Data residency
All primary data, backups, and logs remain within the agreed residency boundary. Cross-border replication only by explicit configuration.

Encryption you specify, keys you can hold, identity that binds.

Modern encryption in transit and at rest, official PKI for the people who sign on behalf of the state, and access control scoped to role, agency, and branch — with a second factor mandatory for every official action.

Encryption
TLS 1.3 in transit; AES-256 at rest; envelope encryption with keys in your KMS/HSM where provided. Key custody options include full government custody.
Official PKI
E-signatures for judges, executives, and registrars issued under the deployment's certificate authority; signature binds signer, capacity, and document hash.
RBAC + mandatory 2FA
Role-, agency-, and branch-scoped permissions; second factor mandatory for all official actions; delegation with expiring authority windows.

Your statutes, enforced by the platform — not by policy memo.

Sealed classes are excluded from public products by construction, and each Government Pack maps your data-protection statute directly to platform behavior: retention, subject rights, redaction, and breach-notification hooks.

Sealed-record architecture
Sealed classes (protection orders, juvenile, adoption, and any class your pack defines) are enforced at the query layer — excluded from public products by construction, with access logged for authorized processes.
Privacy-law alignment
Each Government Pack maps the deployment's data-protection statute to platform behavior: retention, subject rights, redaction rules, breach-notification hooks.
Retention & legal hold
Pack-driven retention schedules with archives transfer; legal holds suspend disposition with the hold itself on the audit spine.

Built to survive failure — and built to be audited.

Documented recovery targets with drills that prove them, a secure development lifecycle with gates in CI, and an architecture deliberately structured to make third-party and supreme-audit-institution review straightforward.

Backup & disaster recovery
Documented RPO/RTO per service tier; periodic restore drills with attested results; WORM-postured object storage for documents.
Secure development
OWASP ASVS L2+ verification target; dependency audit gates in CI; signed releases.
Independent audit readiness
Architecture, logs, and processes structured for third-party security audits and supreme-audit-institution review. We assume you will audit us; the system is built to make that easy.

The answers your security officers will ask for.

Every line above is an architectural commitment. Here are the ones we get asked to substantiate most often.

How do we know history hasn't been altered?

The audit spine is append-only and hash-chained across all branches, with per-entity chains and daily checkpoints. Any alteration of history breaks every subsequent hash, so tampering is not just prohibited — it is visible.

Can integrity be verified without trusting Segal Industries?

Yes. Daily checkpoints can be anchored to the Bitcoin blockchain via the open OpenTimestamps protocol. The resulting existence proofs are verifiable by anyone, forever, with no dependence on Segal Industries or any vendor.

Where does our data physically live?

Within the residency boundary you agree to. All primary data, backups, and logs remain inside that boundary, with contractually defined data-location guarantees; cross-border replication happens only by explicit configuration.

Can we run this fully disconnected?

Yes. Air-gapped deployments are supported for classified or high-assurance environments: updates arrive by signed media, and integrity anchoring is handled via periodic export.

Who holds the encryption keys?

You can. Data is protected with TLS 1.3 in transit and AES-256 at rest, using envelope encryption with keys in your KMS/HSM where provided. Key custody options include full government custody.

How are sealed and private records protected?

Sealed classes — protection orders, juvenile, adoption, and any class your pack defines — are enforced at the query layer and excluded from public products by construction, with access logged for authorized processes. Each Government Pack maps your data-protection statute to platform behavior.

Is the system ready for an independent audit?

Yes — that is a design goal. Architecture, logs, and processes are structured for third-party security audits and supreme-audit-institution review. We assume you will audit us, and the system is built to make that easy.

Bring your security officers to the briefing.

We would rather answer the hard questions before the contract than after it.

Request a government briefingView the product walkthrough