Treat consent history as a sequence of decisions your application can verify

Consent often changes over time. Someone may allow analytics and decline marketing, then later withdraw one choice or make a new set of selections.

Consent Record Kit, from Brownsmith Dynamics, helps an application construct, serialize, hash, authenticate, and validate technical records of those choices. It is a TypeScript library for the record-handling layer. It does not collect consent through a user interface, establish identity, or determine whether a choice was informed, freely given, or legally sufficient.

Record choices in a defined structure

Suppose an account settings page offers separate analytics and marketing controls. A receipt can identify an application-defined subject reference, the version of the notice shown, and a list of purpose IDs with explicit granted values. A denial is represented directly, rather than disappearing from the record. The schema is intentionally fixed and rejects unknown fields, so policy text and interface evidence should be retained by the integrating system alongside the version they refer to.

Use opaque subject references where possible, but remember that a linkable identifier may still be personal data. The kit does not resolve or verify the identity behind a subject value. Your application remains responsible for the collection experience, access controls, encryption, retention, exports, and related data handling.

Make records stable and checkable

Canonical serialization gives a receipt a deterministic JSON spelling for fixed values. The library can parse that canonical form, calculate a SHA-256 digest, and compare a record with a trusted digest. It can also authenticate a receipt with HMAC-SHA-256 using a caller-provided secret key. These operations help detect changes and check that a record was produced by a holder of the shared key.

A digest by itself is not authentication: anyone able to edit a record can calculate a new digest. HMAC also does not identify a particular signer, because every holder of the shared secret can create valid records. Keep keys in a protected server-side secret manager, use a trusted allowlisted mapping from key IDs to secrets, and authenticate records separately.

Represent withdrawal as an event

If a person withdraws analytics permission while leaving marketing unchanged, a withdrawal record can refer to the prior receipt and mark the selected purpose as no longer granted. A supersession instead records a complete replacement set of decisions, such as choices made after a notice update. Both create linked records, but constructors check only the supplied link, not the full history or authoritative current state.

That distinction matters in the application’s storage workflow. Your system must serialize updates, verify the authoritative prior record and its authentication, reject stale versions, and apply the withdrawal’s effects to the relevant product behavior. Creating a withdrawal record does not stop processing, revoke a permission elsewhere, or delete old records. Define idempotency, replay, and conflict rules in the system that stores and acts on these events.

Fit the kit into the larger process

Use the library to give records a consistent shape and validation path, then connect that path to your application’s UI, durable storage, key management, and policy review. The package has no network calls, telemetry, database, or automatic persistence.

Read more on the npm package page and in the source repository.