Originally published at Cyberpath

---

When’s the last time your compliance officer asked to see your database and didn’t panic?

Most teams can’t because traditional databases hide everything in binary blobs, proprietary formats, and "trust us" black boxes. When an auditor demands forensic proof that data hasn’t been tampered with, your options are basically: panic, export something mysterious, or hire consultants to decode your own database.

Sentinel 2.1.1 just changed that game.

We built a document database in Rust where every record is a human-readable JSON file on disk. Your entire database is Git-versionable. Integrity? Cryptographically verified on every document. GDPR compliance? It’s literally rm file.json. No smoke and mirrors. No "we can generate a report." Just transparent, auditable, forensic-friendly data.

If you’ve ever sweated through a compliance audit, felt your stomach drop when someone said "show us the data" or wondered why databases make transparency feel like pulling teeth, this is for you.

The Compliance Problem That Nobody Talks About

Here’s what happens in most organizations when audit season arrives:

You export data from your database. The auditors look at the format. Someone asks "is this encrypted?" and you’re not entirely sure. Someone else asks "has this been tampered with?" and suddenly you’re running integrity checks that took six hours to set up. A third person wants to see the exact change history for a specific record, and your DBM needs to write custom queries because the database wasn’t designed for that level of forensic transparency.

By the end of it, you’ve proven the data probably hasn’t been tampered with. The auditors are probably satisfied. Everyone leaves feeling vaguely uncomfortable.

Traditional databases weren’t built for this. They were optimized for performance and query complexity. Compliance is an afterthought, a bolt-on feature, not architectural DNA.

Sentinel starts from a different question: What if your database was designed specifically for auditors?

How Sentinel Actually Works

Every document in Sentinel is stored as a pretty-printed JSON file on your filesystem. Not in a proprietary format. Not in a database file. An actual JSON file that you can open with cat, search with grep, and version with Git.

Each file includes:

• Your actual data
• A BLAKE3 cryptographic hash of the content
• An optional Ed25519 digital signature
• Metadata (version, timestamps, who touched it, when)

All in one readable JSON file.

Here’s what this means in practice:

{
"id": "user-auth-2026-01-27",
"version": 3,
"created_at": "2026-01-15T09:00:00Z",
"updated_at": "2026-01-27T14:32:00Z",
"hash": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6",
"signature": "abc123...",
"data": {
"user_id": "u-9876",
"access_level": "admin",
"last_login": "2026-01-27T12:00:00Z",
"mfa_enabled": true
}
}

Now show this to your auditor. They can:

• Verify integrity: Run the hash themselves. If it matches, nothing’s been tampered with.
• Check the signature: Cryptographically verify that a specific person or system signed this data.
• See the full history: git log shows exactly when this record was created, modified, and by whom.
• Spot unusual changes: git diff reveals what changed between versions, with timestamps.

No black box. No proprietary tools. No "trust us, the database is secure."

Features That Make It Different

1) Every Record is Cryptographically Verified Automatic BLAKE3 hashing on every document, with optional Ed25519 signatures. When someone asks "are you sure this data hasn’t been modified?" you can prove it mathematically.

2) Full Git-Based Version Control Your entire database can be a Git repository. Every change is a commit. Every commit is timestamped, attributed, and reversible. Auditors love this because it’s the same tool they use for code, familiar, transparent, verifiable.

3) Encryption Without the Compromise Support for AES-256-GCM, XChaCha20-Poly1305, and Ascon-128. Your data stays encrypted at rest, but remains human-readable JSON. No performance penalty from trying to search encrypted binary blobs.

4) GDPR, SOC 2, HIPAA, PCI-DSS Built Into the Architecture Not bolted on. Built in.

• GDPR right-to-delete? It’s rm file.json. Literally.
• SOC 2 audit trails? Git history. Immutable, timestamped, verifiable.
• HIPAA integrity requirements? BLAKE3 on every record.
• PCI-DSS access controls? Standard OS-level file permissions and ACLs.

5) Zero Vendor Lock-In Your data is JSON files in directories. If Sentinel stops meeting your needs tomorrow, you migrate anywhere using standard tools. rsync, tar, git, nothing proprietary. This isn’t marketing speak. It’s architectural.

6) Replication Without the Chaos Primary-secondary setups use Git for synchronization. No distributed consensus protocols. No quorum requirements. One node pushes changes to a Git remote, another node pulls. Simple, reliable, boring in the best way.

7) Works Anywhere No server required. Runs on any filesystem that supports Rust. Cloud servers, edge devices, airgapped networks, your laptop. Perfect for environments where traditional databases introduce unacceptable complexity or connectivity requirements.

Perfect For (Real Use Cases)

Audit Logging Systems Every action is an immutable, timestamped, cryptographically-signed file. Your log shows exactly who did what, when, and with proof that nothing’s changed since.

Certificate & Key Management Every certificate is a readable file with full version history. Access controls are OS-level permissions that your infrastructure team already understands. Compliance reporting is "here’s the directory, inspect it yourself."

Regulatory Reporting Finance, healthcare, government contractors, anyone dealing with regulatory data benefits from a database that’s literally designed for auditors. GDPR Article 32. SOC 2 Trust Service Criteria. HIPAA Security Rule. They all become simpler because your data architecture was built for them.

Edge Deployments IoT devices, retail point-of-sale systems, remote equipment. Sentinel works offline. Synchronizes when connectivity returns. Git handles conflict resolution using proven mechanics that have worked for decades.

Compliance-First Organizations Organizations where "show me the data" matters more than query performance. Banks, healthcare systems, government agencies, enterprises handling sensitive data. Places where transparency isn’t optional, it’s mandatory.

The Trade-Off (Being Honest)

Sentinel is not a traditional SQL or NoSQL database. It doesn’t compete with PostgreSQL on query performance or MongoDB on horizontal scalability.

Here’s what you’re not getting:

• Complex SQL queries across relationships
• Real-time search across millions of documents
• Horizontal scaling to petabytes of data
• One-liner aggregations and joins

Here’s what you’re getting instead:

• Every piece of data is immediately forensic-friendly
• You understand your data store intuitively
• Your compliance team stops asking scary questions
• Migration to another system is straightforward
• Your auditors actually enjoy examining your database

The question isn’t whether Sentinel is "better" than PostgreSQL. The question is: does your use case prioritize transparency and auditability, or does it prioritize query complexity and massive scale?

If you’re building an audit log system, compliance dashboard, or regulatory reporting tool, then Sentinel wins. If you’re building a real-time analytics engine or massive recommendation system, stick with Postgres or Elasticsearch.

Getting Started: Three Ways

Option 1: Try the Demo (5 Minutes)

# Install Sentinel
cargo install cyberpath-sentinel

# Create a store
sentinel store init ./my-database --encryption

# Add a document
sentinel add ./my-database/users user-123 \
'{"name":"Alice","email":"alice@example.com","role":"admin"}'

# View it
cat ./my-database/users/user-123.json

# See the full history
cd ./my-database && git log --oneline

Option 2: Read the Docs Full API reference, deployment guides, security practices, and real-world examples at https://sentinel.cyberpath-hq.com

Join the Project

Sentinel is open source under Apache 2.0. Built by CyberPath. Maintained by developers who care about compliance automation.

• GitHub: https://github.com/cyberpath-HQ/sentinel
• Docs: https://sentinel.cyberpath-hq.com
• Issues & Discussions: Let’s talk about your compliance challenges

If you’re dealing with audit logs, compliance documentation, regulatory data, or any system where auditors need to see inside your database then we’d love to hear about it.