Home Features

Features

Everything Provenance does

Grouped by the part of the job they belong to: making the identifiers, getting them onto physical things, answering when one is scanned, and keeping the record true afterwards. Nothing here sits behind a higher plan, because there is only one, and nothing here is billed yet either. What it will cost.

The register

Where the records live

Two copies, and it matters which one is which.

Your Shopify admin holds the mirror

A provenance_item metaobject definition, created in your store on install and owned by you. Readable by your theme, exportable from Shopify, and still there after you uninstall the app. If this company disappears tomorrow, your records do not.

Our database is the system of record

Because metaobjects cannot do the two things that make a register safe: enforce that an identifier is unique, and count. Uniqueness here is a database constraint rather than a code path that checks and hopes. Everything is written to our side first and mirrored to yours.

Nothing identifying a person goes into the mirror

The definition is publicly readable, which is what lets a scan resolve at all: anybody holding an identifier can read every field on it. So no owner name, no email address, no order number, no price, ever. That is a design constraint rather than a setting you could switch, and it is the reason there is no owner-registration feature.

Minting

Making the identifiers

One screen: browse products, pick variants, set quantities, mint.

Mixed runs

A single run can cover several products. Each identifier carries its own product reference, so nothing about an item depends on what it happened to be minted alongside.

Unguessable, unstructured

Generated from a cryptographic random source over an alphabet with no I, L, O or U. They encode nothing about the item, so two cards together tell a competitor nothing about your volumes.

Idempotent

Minting twice by accident, or on a flaky connection, does not double your run. The guard is a database constraint keyed on the whole run and insensitive to the order you picked products in.

Edition numbering

Give a line an edition size and each item is numbered as it is minted. Numbers continue from what that variant has already been minted, so a restock does not produce a second No. 1. A run that would exceed the size is refused.

Verified mirroring

Items are written to your register in batches, and every handle Shopify returns is compared against the one that was sent. A partial write shows as a partial write rather than as success.

Repairing a failed write

A retry button on the run and on each item. It looks every item up before writing and lets the answer choose: create what is missing, update what exists, and write nothing at all when the lookup itself did not answer.

Production

Getting codes onto physical things

The part that is usually left to you, and the part that decides whether any of this reaches a customer.

The print sheet

A standalone HTML file, one card per identifier, each with its code printed as text beneath the QR. No design skills and no software. Grouped by product when a run holds more than one, because a card in the wrong box makes a certificate that confidently describes the wrong object.

The print package

A zip of vector QR files plus a merge-ready CSV, for an InDesign data merge against your own card design. Vector rather than raster, so a code stays scannable at swing-tag size.

Marking a run printed freezes it

One-way, behind a confirmation, and blocked if any item in the run failed to reach your register. After it, identifiers in that run cannot be edited or deleted, and your storefront address is locked. Cards in the world cannot be recalled, so the register has to keep matching them.

The lookup

What happens when a card is scanned

Two surfaces, both inside your own storefront, both saying the same thing.

The app-served page

Live from the moment you install, at /apps/provenance on your own domain. Shopify renders it inside your theme, so it arrives with your header, footer and typography. Nothing to create and no block to place.

The theme block

For a brand that wants the panel on a page they have designed. An app block for any Online Store 2.0 theme, with its own settings, and a test that keeps its wording identical to the app-served page.

Your own address

If cards should read a page in your store rather than /apps/provenance, the app can create one and point at it. Choose before you print: the choice locks once anything has been.

Identity, never a verdict

Model, colourway, photograph, made-on date, edition, status. No "Authentic" headline and no green tick, because a boolean is defeated by copying one real code onto a thousand fakes.

Not-found looks like found

Same keys, same order, same timing. A response that is faster or shaped differently when a code does not exist is an oracle for working out which codes do.

No code in the URL

The identifier travels in the fragment, after the #, which browsers never send to a server. Not in logs, not in analytics, not in a referrer header.

After the sale

Keeping the record true

An item's record should be worth reading two years later, which means it has to change.

Status

In stock, sold, or lost or stolen. A lost-or-stolen report is shown prominently on the lookup and on the certificate, and clearing one requires a reason.

Event history

Every item has a page carrying its whole log, each entry stamped with who made the change, whether that is a member of your staff or a Shopify event.

Certificates

A4, one per item, rendered on demand from the register rather than stored as a file, so it cannot describe the item as it was last year. Headed "Certificate of registration", never "of authenticity".

Your certificate design

Per brand, previewed against a real render with a sample record. The lost-or-stolen state is not restylable: a certificate that can only flatter its holder is worth nothing.

Editing, while unprinted

Edition number, edition size and the made-on date, which are the three things the certificate prints. Not the identifier, and not the product it points at.

Deleting, while unprinted

A single item or a whole run. Entries are removed from your register first and our rows second, so a failure leaves something the retry button can repair rather than orphans nothing can find.

Not here

Things people ask for that this does not do

Listed because finding out on day three is worse than finding out now.

Owner registration. Recording who owns an item means holding customer data, which this app deliberately does not. It needs a separate store with no public read access and Shopify's approval for protected customer data. Wanted, not built.
Emailing certificates. The link and the download work today. Emailing needs buyer addresses, which changes what this app is from the ground up.
Automatic sold status from fulfilment. Marking items sold by hand works. Doing it automatically needs somebody to record which physical piece went into which order, at packing time, and that is a workflow question rather than a code one. It is being designed.
NFC tags. A printed QR is what this produces. An NFC chip is a different manufacturing decision and a different threat model, and pretending otherwise would be selling you a plan rather than a product.
Verifying your claims. Never, by anyone. See the home page.