Partners

Test provenance continuity in the workflow you actually use.

Test it in your real workflow, on selected licensed or owned images, through the transformations you actually use, against acceptance criteria you define.

Current hosted tests run on EU infrastructure. Images are the supported media type today.

~25-minute scoping · typically 2–4 hours of partner-side input for a first bounded test · no obligation to continue beyond the agreed test gate · stop after any gate.

Presented a provenance integration concept for IIIF workflows at the 2026 IIIF Online Meeting and contributed to the Digital Heritage Summit in Cyprus through its exhibition and hackathon.

Test your workflowFind your workflow

Current test path

The path a bounded test follows.

  1. 1Original image
  2. 2Imperceptible UID embedded
  3. 3Provenance record created and UID-derived commitment anchored
  4. 4Copy, resize, recompress, or redistribute
  5. 5Recover UID and verify against the record and public commitment

The UID-derived commitment is batched into a Merkle root and anchored to Bitcoin.

Why test now

Metadata is useful until it is separated from the file.

Publishing systems, messaging platforms, derivative generation, and format migration can remove or disconnect metadata and manifests. Exact file hashes also change after normal transformations.

Why test now

puit.is keeps a recoverable identifier in the media signal.

An imperceptible UID links the asset to the current INICS-operated provenance record and a separate UID-derived public commitment. The goal is continuity of origin evidence across systems, not a claim that the content itself is true.

Pilot path

Provenance Continuity Pilot

A bounded, gate-based path from a first asset test to workflow integration and, where justified by the evidence, an operational pilot.

~25-minute scoping

typically 2–4 hours of partner-side input for a first bounded test

typically 1–2 partner-side working days for workflow integration, depending on access and workflow complexity

no obligation to continue beyond the agreed test gate · stop after any gate

No commitment to production deployment or further procurement. Media remains off-chain; processing location, transferred fields, retention and deletion are agreed before testing; publication only by agreement.

  1. Recommended first test

    Pilot step 1

    Bounded Asset Test

    A first technical test on selected licensed or owned images and an agreed transformation path.

  2. Pilot step 2

    Workflow Integration Test

    Connect one agreed sandbox or test workflow and measure acceptance inside the defined processing topology.

  3. Pilot step 3

    Operational Pilot

    A jointly scoped operational window, used only where earlier evidence justifies the next step.

At every gate: scope the question → freeze the protocol → run and inspect → decide what the evidence supports.

No partner media is transferred before this agreed test step.

You bring

  • A real use case or workflow question
  • Representative assets with processing permission
  • The intended transformation or redistribution path
  • A technical or operational contact
  • Agreed success criteria
  • Data, security, or publication restrictions
  • For independent validation: a validator-owned or independently governed evaluation protocol.

You receive

A bounded test should answer a decision, not just produce a report.

  1. 1Does recovery meet the acceptance criteria on the selected assets and path?
  2. 2Where does continuity fail, and under which conditions?
  3. 3Do the status, distance, and evidence outputs fit your review or acceptance process?
  4. 4Should you stop, extend the test, or move to integration?
  • Bounded test plan
  • Versioned configuration and run context
  • Per-item results and summary metrics
  • Negative-control and failure-case observations
  • Limitations and unresolved questions
  • Integration/validation recommendation
  • Reproducibility artefacts where in scope

A test result is evidence about a defined configuration and workflow. It is not a universal claim about all media, edits, or deliberate removal attacks.

Separate evaluation path

Independent Validation

A separate, validator-led evaluation under a predefined, reproducible protocol. It can run in parallel to workflow integration.

Where this can lead: bounded test → workflow integration → independent validation → lighthouse pilot → reference deployment.

Partner request

Scope a partner test or collaboration.

Not every useful collaboration starts with a pilot.

Add technical details — optional

By submitting this form, you agree that puit.is may use the information provided to respond to your enquiry. See our Privacy Notice.

Do not submit sensitive media, credentials, or private diligence documents through this form.

Prefer email? Write to partners@puitis.com.

Need to share this internally? Download the concise Provenance Continuity Pilot brief.

Role router

Find your workflow

Start with the path where provenance can become detached, then expand the role to frame a bounded first test.

Use puit.is at the source

Keep provenance through distribution

Build and validate the infrastructure

Scoping and bounded asset testing can start now. Larger workflow integrations are currently targeted for Q1/Q2 2027, subject to financing, scope and mutual agreement.

Integration modes

Choose how you want to connect.

The test package defines what you want to validate. The integration mode defines how puit.is connects to the workflow.

Lowest-friction mode

Reproducible batch test

Run a bounded asset set and defined transformations with per-item outputs, run metadata, and evidence artefacts.

Available for scoped tests

Hosted REST API

Watermark and verification endpoints with OAuth2/Keycloak-based access for controlled sandbox integration.

Available as a scoped integration

Workflow adapter test

Map puit.is into a specific IIIF, DAM, CMS, publishing, or media-service workflow. For each test, the required adapter is scoped and built for that specific workflow. puit.is does not currently offer generic deployment connectors for third-party platforms.

Data handling

What happens to test media and provenance data?

The following describes the current hosted test mode. Before testing, the processing location, transferred fields, retention period, and deletion arrangements are agreed. In this mode, partner media can be transferred to the INICS-operated EU-hosted API for processing. No media file is written to the public ledger; only a UID-derived commitment is publicly anchored. Any different deployment or retention requirement must be agreed during scoping.

The same file in three states. The original and the processed copy look identical; the processed copy carries the embedded Media UID. Only a UID-derived commitment is published.

Media stays off-chain.

Media is uploaded to the INICS-operated EU-hosted API, processed in object storage, and returned as a watermarked copy. Verification uploads are temporary test data within the agreed workflow.

The record stores identifiers and verification data.

The current record contains a GUID, 128-bit watermark payload, PDQ-256 perceptual fingerprint, timestamps, and owner identifier. Media itself is not stored on a blockchain.

Only a UID-derived commitment is publicly anchored.

A SHA-256 commitment derived from the GUID is batched into a Merkle root and anchored to Bitcoin. The public anchor contains no media, fingerprint, or descriptive metadata.

Current system: TRL6, live EU-hosted beta, single-operator, INICS-controlled; public commitment anchoring live. Cross-provider replication and verification have been demonstrated in a two-node prototype under one operator. Validation across real independent operators is part of the TRL7 development path.

Evidence

Evidence before claims.

12,331

unique images

160,303

controlled transformations

61,655

negative controls

98.5%

UID recovery after manual WhatsApp transfer · 985/1,000

Results reflect documented benchmark versions, configurations, and test conditions. They do not imply equivalent performance across all edits or deliberate removal attacks.

See methodology, test conditions and limitations on the Evidence page.

EIC Accelerator review

puit.is passed Step 1 of the EIC Accelerator and was invited to Step 2 in July 2026. The evaluation is ongoing; puit.is is not EIC-funded.

FAQ

Frequently asked questions

Does puit.is decide whether content is true?

No. puit.is provides evidence about origin, continuity, and the relationship between media and a provenance record. It does not judge whether content or an underlying claim is true.

Do you store media on Bitcoin?

No. Media, perceptual fingerprints, and descriptive metadata remain off-chain. The public anchor contains a Merkle root over commitments derived from asset identifiers.

Does media have to leave our environment?

In the current hosted test mode, files are uploaded to the INICS-operated EU-hosted service for processing. Different deployment or retention requirements must be agreed during scoping.

Which media types are supported?

Images are supported today. Audio, video, documents, and 3D assets are research or roadmap areas, not part of the current system.

Is the current network already decentralised across independent operators?

No. Current system: TRL6, live EU-hosted beta, single-operator, INICS-controlled; public commitment anchoring live. Cross-provider replication and verification have been demonstrated in a two-node prototype under one operator.

Do published metrics apply to every transformation?

No. Results are specific to documented versions, configurations, datasets, and test conditions. Aggressive geometric edits, AI-based removal, and heavy compositing remain active work.

What does a first test normally involve?

The lowest-friction route is a bounded batch test using representative images and an agreed transformation path. Depending on the evidence and partner need, this can progress to workflow integration, independent validation, or a scoped operational pilot.

Is independent validation performed by puit.is?

No. puit.is can provide version-pinned software and configuration, benchmark tooling, technical documentation, and reproducibility artefacts, but an independent validation study should be run or methodologically controlled by the validating institution under an agreed protocol.

Is multi-operator deployment available today?

No. The current system is a single-operator, INICS-controlled, live EU-hosted beta. A two-node prototype under one operator has demonstrated cross-provider record replication and verification. Validation across real independent operators is part of the TRL7 development path.

Can results be published?

Publication scope is agreed before the test. Results may remain confidential, support an internal decision, or be converted into separately approved public wording.