The Event Ledger is an append-only, cryptographically signed record of business events. Every event ingested through the Invoance API or dashboard is hashed with SHA-256, signed with Ed25519, timestamped at ingestion, and stored permanently. No event can be modified or deleted after ingestion — this is enforced at the database level, not by policy.

The Event Ledger answers one question: did this specific event happen, exactly as recorded, at this exact time? The answer is cryptographically provable and independently verifiable by anyone with the event ID.

Unlike traditional application logs which can be edited, rotated, or deleted, the Event Ledger is structurally immutable. The database has UPDATE and DELETE revoked on the events table. Each event's hash chains to the previous event's hash, creating a tamper-evident sequence where altering any record invalidates all subsequent records.

Events can be created via the API or directly from the dashboard. The dashboard provides a visual interface for creating events with JSON payloads, while the API supports high-throughput automated ingestion from your application's backend.

When an event is ingested, Invoance processes it through a deterministic pipeline. The JSON payload is canonicalized — all object keys are sorted lexicographically to ensure identical content always produces identical hashes regardless of input formatting.

SHA-256 is computed over the canonical payload bytes to produce the content hash. This hash is a 256-bit fingerprint that uniquely identifies the exact content. Any change to the payload, even a single character, produces a completely different hash.

The event is then signed with Ed25519 using the tenant's private key. The signature proves the event was produced by the stated organization and has not been tampered with since signing. The public key is included in the event record so anyone can independently verify the signature.

Events are published to a durable message queue (NATS JetStream) for asynchronous processing, ensuring the API responds immediately while the cryptographic operations happen reliably in the background. The writer worker picks up each event, signs it, and persists it to the append-only PostgreSQL table with retry logic and at-least-once delivery guarantees.

Every event in the ledger contains the full payload exactly as sent by the client, the SHA-256 content hash, the Ed25519 signature, the signing public key, the ingestion timestamp (server-authoritative, not client-provided), the event type classification, and retention policy metadata.

The payload is stored alongside the hash — not instead of it. This means proof bundles and verification pages can display the actual content of the event, not just cryptographic references. An auditor can read what happened. An engineer can verify the math. Both work from the same record.

Events also include an optional event_time field for the client's own timestamp, an optional idempotency key for safe retries, and a trace_id for linking events to a trace. The trace_id is not included in the content hash — it is envelope metadata managed by Invoance, not part of the cryptographic content.

Every event has a public verification page accessible without authentication. Anyone with an event ID can visit the proof page and see the organization that issued the event, the content hash, signature, public key, and timestamp.

Verification can be performed three ways. Through the web UI at invoance.com/proof/event/{event_id}, where a third party can paste a hash or raw payload to verify it matches the anchored record. Through the API at POST /v1/proof/event/{event_id}/verify, which accepts either a pre-computed SHA-256 hash or the raw JSON payload (the server canonicalizes and hashes it for comparison). Or entirely offline using the event's cryptographic data — the public key, signature, and hash are all that is needed to verify independently.

Verification proves that the content has not changed since anchoring, the record was issued by the holder of the private key, the timestamp was recorded at ingestion and is part of the signed payload, and the issuing organization owns the stated domain (verified via DNS TXT record).

Events are retained according to the tenant's plan-based retention policy. Policies range from short-term (90 days) to indefinite retention. The retention policy is recorded as part of the event record and cannot be changed after ingestion — it is set at write time based on the tenant's plan.

For regulatory frameworks like SOC 2, HIPAA, and GDPR, the Event Ledger provides the evidence infrastructure that auditors require. Each event is independently verifiable, timestamped, signed, and stored in a system where modification is structurally impossible. This is stronger than "we have controls to prevent tampering" — it is "tampering is mathematically detectable."

The Event Ledger supports traces — grouping multiple events into a single sealed proof bundle that covers an entire business process. Events within a trace are processed identically to standalone events. The trace adds a composite hash layer on top, proving the complete sequence is intact.

The Event Ledger is designed for any business event where proof of occurrence matters. Compliance events like policy changes, access grants, and configuration updates. Financial events like payment approvals, invoice submissions, and reconciliation records. Operational events like deployment records, incident responses, and SLA measurements. Legal events like contract executions, consent records, and regulatory filings.

If an event is important enough to log, it is important enough to prove. The Event Ledger makes the distinction between "we have a log" and "we have cryptographic evidence" — the difference that matters when a regulator, auditor, or opposing counsel asks for proof.