A Trace is a named, ordered grouping of anchored events under a single identifier, representing a complete business process from start to seal. It is not a workflow engine. It does not enforce steps, approvals, or sequencing. It groups independently verifiable events into one auditable unit and produces a single exportable proof artifact when sealed.

A trace answers one question: "Here is everything that happened during this process, in order, cryptographically proven, and independently verifiable as a complete sequence."

Every event within a trace retains its own independent hash, signature, and verification URL. The trace adds a layer on top — a composite hash computed over the ordered sequence of all event hashes. This composite hash is the cryptographic commitment to the entire process. If any event is missing, reordered, or altered, the composite hash changes and verification fails.

Traces are a grouping mechanism built on top of the existing Event Ledger. Each event anchored to a trace is processed identically to a standalone event — same SHA-256 content hash, same Ed25519 signature, same append-only persistence. The trace_id is simply a reference that links them together.

Individual event proofs are necessary but insufficient when the complete sequence matters. A vendor onboarding involves application receipt, document collection, compliance checks, approvals, and payment authorization. Proving each step happened is different from proving the entire process completed correctly and in order.

In dispute resolution, a vendor might claim the onboarding process was incomplete or steps were skipped. Without a trace, you manually reconstruct the timeline from scattered logs across multiple systems. With a trace, you export the sealed proof bundle — every step hashed, signed, and ordered, with a composite hash proving the complete sequence.

In regulatory audits, a regulator might ask you to prove your loan origination process followed required procedures. Without a trace, you spend weeks assembling evidence from multiple sources, and admissibility is questioned because records are editable. With a trace, you hand over one proof bundle per loan — sealed and verifiable, each step independently signed, the sequence cryptographically proven.

The same pattern applies to insurance claims processing, contract execution, incident response, and audit preparation. Any multi-step process where the complete sequence matters — not just individual events — benefits from a trace.

The trace lifecycle has four steps. No branching, no conditions, no approvals. Your application decides what events to anchor, in what order, and when to seal. Invoance groups, hashes, signs, and exports.

Step one: create. Your application calls POST /v1/traces with a label and optional metadata. Invoance generates and returns a trace_id. This ID is server-generated — your application stores it and references it in subsequent event calls.

Step two: anchor events. Your application calls POST /v1/events with the trace_id from step one. Invoance validates that the trace exists, belongs to the same tenant, and is still open. Each event is independently hashed with SHA-256, signed with Ed25519, timestamped, and persisted with its full payload. The trace_id is a foreign key reference — it does not affect hash computation.

Step three: seal. Your application calls POST /v1/traces/{trace_id}/seal. Invoance immediately transitions the trace status to "sealing" (which blocks new events) and returns a 202 Accepted response. A background worker then fetches all events with this trace_id ordered by creation timestamp, concatenates their content hashes, computes SHA-256 over the concatenation to produce the composite hash, creates a seal event (type: trace.sealed) containing the composite hash and event count, signs the seal event with Ed25519, and updates the trace status from sealing to sealed in a single database transaction.

Step four: export. Your application or any third party exports the sealed proof bundle — JSON for machines, PDF for humans. The bundle contains everything needed to independently verify the entire trace without contacting Invoance.

The composite hash is the cryptographic anchor of the entire trace. It is computed as SHA-256 over the ordered concatenation of all individual event content hashes: SHA-256(h1 || h2 || h3 || ... || hn). Any missing, added, reordered, or altered event invalidates the composite hash.

The seal event is itself a standard event — hashed with SHA-256, signed with Ed25519, and appended to the ledger. It contains the composite hash, the event count, the trace metadata, and the seal timestamp. The seal event is the cryptographic commitment that says: "This is the complete sequence. Nothing comes after this."

Once sealed, a trace cannot be reopened, modified, or deleted. The seal transition from open to sealed is the only mutation in the traces table. Everything else is append-only. This is enforced at the database level with a WHERE status = 'open' guard on the update — if two seal requests arrive concurrently, only one succeeds.

The trace_id is not included in any event's content hash. The content hash is computed from the event payload only — the data the tenant sent. This means the same payload anchored to two different traces produces the same content hash. The trace association is metadata managed by Invoance, not part of the cryptographic content.

A sealed trace produces a proof bundle — a self-contained artifact that reads top to bottom like a chronological record. The bundle has four sections: header, events, seal, and footer.

The trace header contains the label, tenant domain, domain verification status, trace ID, creation and seal timestamps, total event count, and the composite hash.

Each event section contains the event number in sequence, timestamp, event type, the full readable payload exactly as the client sent it, the SHA-256 content hash, the Ed25519 signature, the public key, and the verification status. Readable content is front and center. Cryptographic proof sits underneath in monospace. An auditor reads top to bottom and understands the full process. An engineer can independently verify every hash and signature.

The seal section contains the seal timestamp, composite hash, seal signature, event count confirmation, and verification results — specifically whether the composite hash was recomputed and matched, and whether all individual signatures are valid.

The footer contains the public verification URL and a QR code linking to it. No authentication required to verify.

Invoance persists the full event payload alongside the content hash. The proof bundle includes the exact data the client sent — not just hashes. This means the bundle is independently verifiable without requesting the original data from anyone.

JSON bundles are machine-readable — feed them into automated compliance pipelines or verify programmatically. PDF bundles are for auditors, lawyers, and executives — readable payloads front and center, cryptographic proof in monospace underneath, horizontal dividers between events, QR code to verification URL. Black and white. Certificate of authenticity, not a report.

Verification requires no authentication, no access to internal systems, and no trust in Invoance. A third party independently verifies a sealed trace in six steps.

First, receive the proof bundle — JSON or PDF, or access the public verification URL.

Second, recompute hashes. For each event, independently compute the SHA-256 content hash from the payload data included in the bundle and compare it against the stated content hash.

Third, verify signatures. Validate each Ed25519 signature against the event hash and the public key included in the bundle.

Fourth, recompute the composite hash. Concatenate all event content hashes in order and compute SHA-256. Compare against the stated composite hash in the seal.

Fifth, verify the seal event. Confirm the seal event's Ed25519 signature is valid, the composite hash matches, and the event count matches.

Sixth, confirmed. All hashes match. All signatures valid. Composite hash confirmed. The trace is cryptographically proven as a complete, unaltered sequence.

The proof bundle is entirely self-contained. All cryptographic material needed for verification — public keys, signatures, hashes, payloads — is included. No call back to Invoance. No network request. No trust assumption.

Trace is a proof layer, not a workflow engine. This distinction is architectural, not a limitation.

Invoance does not define what steps a process must contain. There are no step definitions or templates. Your application decides what to anchor.

Events are ordered by timestamp, but Invoance does not reject based on sequence or missing steps. There is no ordering enforcement beyond chronological ingestion.

There is no approval workflow. No conditional logic, no gates, no role assignments. The trace records — it does not orchestrate.

There is no status beyond open and sealed. No "in progress," no "pending review," no "approved." A trace is open or sealed. That is it.

Sealed traces cannot be reopened under any circumstance. This is a structural guarantee, not a policy.

There is no branching or forking. One trace, one linear sequence, one seal. If your process branches, use multiple traces.

There is no expiration or auto-seal. Open traces stay open indefinitely. Invoance never forces a seal. Your application decides when the process is complete.

Once an event is anchored to a trace, it cannot be removed, replaced, or reordered. The sequence is permanent from the moment of ingestion.

The tenant's application decides what events to anchor, in what order, and when to seal. Invoance groups, anchors, hashes, signs, and exports. That is the entire scope.

These are structural properties of how traces work — not policy commitments. They hold regardless of plan, tenant, or circumstance.

Composite integrity: the composite hash is SHA-256 over the ordered concatenation of all event hashes. Any missing, added, reordered, or altered event invalidates it.

Seal immutability: the seal event is itself hashed, signed with Ed25519, and appended to the ledger. It cannot be forged, backdated, or reversed.

Individual event proof: every event in a trace retains its own independent hash, signature, and verification URL. Trace membership does not weaken individual proof.

Append-only guarantee: no UPDATE or DELETE on traces or events. The seal transition from open to sealed is the only mutation, and it is irreversible.

Offline verification: the proof bundle contains everything needed to verify the entire trace — public keys, signatures, hashes, payloads — without contacting Invoance.

No vendor lock-in: export the proof bundle. Verify it yourself. The cryptography is standard Ed25519 and SHA-256. No proprietary formats.

Traces themselves are free to create. They are a grouping mechanism. Each event anchored to a trace counts against the tenant's existing event quota — already billed. There are no new pricing tiers, no add-on fees, and no per-trace charges. All plans include traces.

Traces are designed for Event Ledger events in the current version. Support for Document Anchoring and AI Attestation within traces may be considered based on customer demand, but is not part of the initial release.