Provenance•9
Open-Source Governance Evidence Ledger
An independently verifiable ledger for governed systems
Provenance•9 is an open-source ledger system that began as a fork of Hearth•9. It adds portable, cryptographically verifiable history to existing applications and databases without replacing their operational data stores. Evidence is preserved in compressed, signed .g9p segments that can be verified without a Glare•9 subscription or hosted service.
An open-source project stewarded by Glare•9
A ledger layer for systems that already exist
Provenance•9 sits beside operational applications and databases. APIs, SDKs and connectors submit versioned governance events through an authenticated ingestion boundary. The ledger validates and canonicalises each event, assigns deterministic routing, and preserves it in a hash-linked history.
- Applications and databases remain the operational systems of record
- APIs, SDKs and connectors translate activity into stable event envelopes
- Canonical event records are deterministically encoded and hashed
- Records are routed into versioned shards and finite G9P segments
- Checkpoints and separately operated witnesses can attest ledger heads
- Readers, verifiers and rebuildable projections consume verified history
What is sealed inside a G9P evidence chain
Canonical records
A deterministic binary codec and strict event validation make the same accepted event produce the same authoritative record bytes and SHA-256 commitments.
Independent compression blocks
Canonical framed records are stored in bounded Zstandard blocks, supporting finite recovery work and access without one perpetual compression stream.
Logical and physical commitments
Merkle commitments bind logical event history, while block commitments and exact-file hashes protect the bytes that were physically stored.
Signed segment identity
Ed25519 signatures bind the segment commitments to a signing-key identity. Verification can require an externally trusted key rather than trusting only the embedded key.
Hash-linked continuity
Each final segment links to the previous segment in its shard. Mutation, signature changes, truncation and incorrect chain links are detectable.
Offline verification
The hostile-input verifier checks format, canonical meaning, commitments, compression, identity, signatures and chain structure without calling a Glare•9 endpoint.
Durable intake before final sealing
The stable version 2 ingestion contract accepts events into crash-safe, topology-neutral storage before routing them to a shard. Accepted events are retained durably, active memory is bounded, and provisional blocks can be recovered and reconciled after restart before final segment publication.
Accepted
The canonical event has durable intake custody but has not yet been assigned a final segment hash.
Provisional
The record is in a completed and synchronised active block with known routing and position, but the segment remains open.
Sealed
The record is included in a verified final G9P segment with an exact segment hash, position and signer identity.
Event identifiers make repeated delivery idempotent. Receipt polling uses both event identity and the expected record hash, and receipt state never moves backwards.
Deterministic sharding with signed topology history
Provenance•9 routes a stable subject to a shard using the versioned subject-sha256-v1 policy. Each shard is a continuous ordered stream made from finite segments. Segment byte, record and age limits control when an active segment is sealed.
- The same ledger, subject and routing policy always produce the same shard
- Routing epochs are described by signed G9P topology descriptors
- Resharding is a forward-only transition that does not move or rewrite history
- Transition barriers verify and preserve every old shard head
- Global checkpoints commit to shard heads and the previous checkpoint
- Independent witnesses can issue separately signed checkpoint receipts
Connect operational data without coupling it to the ledger format
The separately runnable MySQL connector uses a transactional outbox. An application commits its business change and event envelope in the same database transaction. The connector knows only the generic outbox table, has no access to customer business tables, and never writes G9P files directly.
- Short FOR UPDATE SKIP LOCKED leases release database locks before network delivery
- At-least-once delivery is made safe by ledger-side event idempotency
- Durable accepted receipts transfer custody without waiting for segment age or size limits
- Retry, back-pressure, dead-letter and reconciliation behaviour is explicit
- TLS is required by default and connector permissions are limited to the outbox
- The shared connector contract leaves room for other databases and event sources
Open verification with explicit trust and maturity boundaries
The format specification, ledger core, reader, verifier, checkpoint protocol, reference witness, conformance vectors and MySQL connector are open source under Apache License 2.0. The core ledger has no third-party runtime dependencies. Language-neutral vectors allow another implementation to test the exact bytes, commitments, valid results and required rejection behaviour.
Installed profiles support integrated encrypted signing custody or optional self-hosted separated custody. In separated custody, the ledger submits only domain-separated commitments over a local Unix-domain socket and verifies returned signatures before publication. Historical verification does not depend on the signer service.
Provenance•9 is Foundation-stage software. It proves what was recorded and whether sealed history remains internally consistent. It does not prove that every recorded assertion is objectively true. Production reliance still requires qualification of the selected storage, signing custody, transport, backup, recovery and operational controls.
Explore related Glare•9 services
Combine focused assessments, practical governance documentation and ongoing support as your needs develop.