Minting

Minting Architecture

Overview

The tieback minting system is built for enterprise scale Digital Product Passport issuance. It separates a synchronous control plane, which you interact with, from an asynchronous execution plane that generates tokens in the background. That is how very large requests complete reliably without holding anyone at a progress bar.

What happens after you submit a mint request?

Your request is validated immediately and a job is created, then generation runs in the background. You can leave the screen at any point. The platform issues the tokens, writes their resolver URLs, and prepares export packs for printing, and the dashboard reflects progress as it goes.

Submit and validate

Job queued

Tokens generated

Export packs

Submission is validated and queued, generation runs in the background, and completed tokens become resolver URLs and downloadable export packs.

Control plane and execution plane

Control plane

The control plane handles the operations you drive:

  • Submission. Preflight validation and creation of the job and batch pair, returning immediately with a job reference.
  • Reads. Paginated access to batches, units, events, batch detail and KPIs.
  • Exports. Listing of generated export artefacts.

Control plane operations require an authenticated session with the appropriate role.

Execution plane

The execution plane handles asynchronous token generation:

  • Job claiming. The background worker claims queued jobs under a lock that prevents two workers taking the same job.
  • Cycle processing. Units are generated in high throughput cycles, each inserting tokens, resolver URLs and serial numbers atomically.
  • Continuation. Jobs larger than a single processing window continue automatically in later invocations until they complete.
  • Failure isolation. An error in one cycle leaves previously generated units untouched, and a bounded retry mechanism absorbs transient failures.

Idempotency

Client provided idempotency keys make submission safe to retry. When a duplicate key arrives, the existing job is returned and no new records are created.

Concurrency model

Multiple mint jobs run concurrently:

  • Each job is claimed and processed independently.
  • A soft lock gives exclusive access during processing.
  • Duplicate tokens and serial numbers cannot be generated under concurrent load.
  • The model has been validated with multiple overlapping million unit jobs completing cleanly.

Scan resolution stays separate

Scan resolution is architecturally separate from the minting control plane:

  • Resolver URLs are written at token creation and are scannable straight away.
  • Resolution handles scan destination and telemetry capture, with activation state controlled by the brand.
  • Resolution endpoints operate independently and share no authentication with the minting control plane.
  • Bot detection keeps automated scanning out of your telemetry.

The result is that heavy minting activity has no effect on scan performance, and heavy scan traffic has no effect on minting.

Storage and exports

Export artefacts (CSV manifests) are stored privately and access controlled:

  • Only members with brand level access can generate and download exports.
  • Downloads use short lived signed URLs.
  • Large batches produce multiple sequential packs.
  • Export generation is resumable, so an interrupted export continues without regenerating completed packs.