CD · Audit Event
An append-only ledger for who approved what, and when
- audit_event
- audit_json
- audit_hash
In a real production, "who approved this take" is not a trivia question - it's the difference between a release and a re-render. CDAuditEvent is the node that records those decisions in an append-only style log: what happened, who did it, when, and (optionally) chained to the event before it, so the order of approvals is provable rather than remembered. It's the audit trail for everyone who has ever had to explain their edit history.
It's from Continuity Director, a 20-node pack for repeatable AI video production, and it's the first of the "collaboration" nodes - the part of the pack aimed at teams and reviewers, not just solo tinkerers.
What you set
- event_type - what happened. The default is
generation-approved; you'll invent your own vocabulary:take-rejected,review-passed,export-approved. The node normalizes it, so keep it readable. - actor - who did it. Default
local-user; in a team you'd put an actual name or id. - payload_json - the evidence. Paste the take_id, the ranking_json, the manifest hash, whatever makes the event meaningful. The default
{}is fine for quick logs. - previous_hash - this is the interesting one. Paste the hash of the previous event and the events get linked into a chain, so tampering with or reordering any earlier event breaks the link. Leave it blank and each event stands alone.
What comes out
- audit_event - a
CD_AUDIT_EVENTwire for the collaboration/export nodes. - audit_json - the full record: schema, UTC timestamp, event type, actor, payload, previous hash, and the event's own hash.
- audit_hash - the fingerprint of this event, which is also what you'd paste into the next event's
previous_hash.
The timestamp is UTC with second precision and the hash is SHA-256 over the whole record, so an event can't be edited in place - change anything and the hash no longer matches the record.
Installing it
Continuity Director is the rare pack that installs with zero friction: no models, no API keys, and requirements.txt is a comment declaring no mandatory Python dependencies. It's pure standard library, so no dependency conflicts. Search "Continuity Director" in ComfyUI Manager and restart, or:
cd ComfyUI/custom_nodes
git clone https://github.com/xinjian0101/continuity-director.git ComfyUI-ContinuityDirector
Restart ComfyUI - nodes appear as CD · ..., with a Continuity Director sidebar offering an "Add starter chain" scaffold. Update with git pull.
The honest take
Let's be clear about what the hash chain is and isn't. It detects tampering and reordering - change an earlier event and the chain stops verifying. It does not provide authorization or prove identity; the README says it plainly: integrity hashes detect changes, they don't authenticate anyone. And there's no storage here - this node produces records, it doesn't persist a database for you. If you want the audit log to survive, you need to save the audit_json outputs somewhere (or fold them into CDExportPackage's package). For a solo project it's arguably overkill; for anything with a reviewer in the loop, it's the difference between "trust me" and "here's the chain."
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| event_type | STRING | generation-approved | — |
| actor | STRING | local-user | — |
| payload_json | STRING | {} | — |
| previous_hash | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| audit_event | CD_AUDIT_EVENT | — |
| audit_json | STRING | — |
| audit_hash | STRING | — |