Genace

image content hash cache: identify immutable media from collected bytes

An image content hash cache identifies the bytes you actually collected. A prompt hash identifies a request specification, which is a different thing. Reusing a prompt does not establish that another generation will return identical pixels, and an upstream URL may change without describing your application’s archived object.

Genace returns output locations and job information. Content-addressed storage, cache policy, authorization, and derivative identity belong to your own application. Keep those concerns separate from model request deduplication.

Hash the stored candidate

Collect the successful output into a staging file, verify that it is the intended image, then compute its digest. This Node.js example hashes a local file with a stream so it does not need to load the entire asset into one buffer.

import { createHash } from 'node:crypto';
import { createReadStream } from 'node:fs';

const hash = createHash('sha256');
for await (const chunk of createReadStream('approved-image.png')) {
  hash.update(chunk);
}
console.log(hash.digest('hex'));

The implementation uses the hashing API documented by Node.js. Store the digest with the verified file, not with an unverified partial download.

Separate identity from permission

RecordIdentifiesDoes not establish
Request hashCanonical generation inputsIdentical output pixels
Content hashExact collected bytesWho may access them
Derivative identifierA specific transformationApproval of every placement
Publication referenceA destination usagePermanent source availability

Two users can reference identical bytes while having different access rights. A content hash should not become a public authorization token. Enforce access through your application’s normal ownership and publication rules.

Make immutable objects actually immutable

If an object path includes a content digest, never overwrite that path with different bytes. A change in crop, metadata, or encoding creates a new digest and derivative record. Human-readable aliases can point to the current approved object without pretending that its contents never changed.

MDN’s Cache-Control reference explains cache directives. Choose public caching only for assets intentionally published publicly; private source material needs an appropriate authorization and caching policy.

Do not attach long-lived immutable caching to a mutable latest-image path unless your invalidation behavior is deliberate. Versioned object identity and current-publication routing solve different operational problems.

Handle duplicate collection safely

Use a uniqueness rule for content identity in your storage manifest where appropriate, then attach multiple source or usage records to that object. Preserve every job relationship even when the bytes happen to match, because the generation history and accounting remain distinct.

A failed upload should be retried from the verified staging file. Comparing the uploaded object’s digest with the staging digest verifies transfer identity without generating another candidate.

Acceptance checklist

Hash complete verified bytes, test an edited derivative, enforce ownership independently, and verify cache headers in the actual response. Confirm that a changed file receives a new identity and that identical bytes do not erase separate approval or source records.

Keep encoding information beside the digest. The hash identifies the stored bytes, while the recorded media type and dimensions help the delivery layer serve and validate the right object.

Continue with asset lineage, metadata stripping, and archive policy.

Continue with media delivery

Where these facts come from