1781product evidence platform

Know what every product can prove.

Turn your product catalogue and documentation into structured, source-backed product data. 1781 maps every document to the products it actually covers, identifies missing information and preserves the evidence behind every approved value.

Book a catalogue review Explore the Harris demo

For European manufacturers, importers and distributors with 100+ products.

GET /api/products/{productId}/export200

2 "key": "en1344.abrasionResistance",

3 "value": "A3",

4 "status": "COMPLETE",

5 "valueOrigin": "INHERITED",

6 "inheritedFrom": "PK36 — 40 mm and thicker",

7 "sourceDocument": "Harris_PK36_Datablad_extract.pdf",

8 "documentCoverage": {

9 "scope": "PRODUCT_FAMILY",

10 "status": "ACCEPTED"

11 },

12 "approvedBy": "user_demo"

13}

Abrasion resistanceConfirmed

Inherited from PK36 — 40 mm and thicker

sourceHarris_PK36_Datablad_extract.pdf

Demonstration based on publicly available, draft and unverified product information. Harris ApS is not a customer, and no product has been legally assessed.

From document folders to product evidence.

Your product information already exists. It is just not in one shape.

It is spread across supplier PDFs, spreadsheets nobody owns, ERP fields that were filled in once, email threads and a shared drive. Every new customer question means finding it again.

Supplier PDFsDeclarations, datasheets, test reports
SpreadsheetsThe real product list, maintained by hand
Email threadsThe answer somebody already gave once
ERP exportsCodes and weights, no documents attached

Structured, source-backed

PK36 — product data

Requirement	Value	Recorded at	Status
Standard reference Technical datasheet	DS/EN 1344	Product family	Inherited
Freeze / thaw resistance Technical datasheet	FP100	Product type	Inherited
Unit weight Technical datasheet	2,3 kg	This SKU	Confirmed
Declaration of Performance Required document	—	Product type	Missing

One source. Every product it actually covers.

One document. Every product it actually covers.

A datasheet does not belong to a SKU. It belongs to whatever it was written for — and that is usually a family, a type, or a supplier's whole range. Say what a document covers once, and the information it carries reaches exactly those products.

Harris_PK36_Datasheet.pdf
Confirmed · covers the PK36 family
PK36
Product family
1. 40 mm and thicker
  Product type
  - 200 × 100 × 52 mm
    Inherited
  - 200 × 100 × 65 mm
    Inherited
  - 200 × 100 × 71 mm
    Inherited
2. 20 mm indoor
  Product type
  - 200 × 100 × 20 mm
    Inherited

One confirmed datasheet. Its declared values are recorded once against the family and inherited by every SKU beneath it.

Nothing applies until a person says so

A suggested relationship is a proposal. It contributes nothing to any readiness figure, appears in no export and changes no product — until somebody confirms the document really does cover them.

EPD_MD-23026-EN.pdf
Proposed · awaiting a decision
PK36
Product family
1. 40 mm and thicker
  Product type
  - 200 × 100 × 52 mm
    Unchanged
  - 200 × 100 × 65 mm
    Unchanged
  - 200 × 100 × 71 mm
    Unchanged
2. 20 mm indoor
  Product type
  - 200 × 100 × 20 mm
    Unchanged

A suggested relationship. It contributes nothing to any readiness figure until a person confirms the document really covers these products.

When a document lapses, so does what it supported

Documents state their own validity. When that date passes, every value resting on it stops counting as settled — across every product it covers, at the same moment, without anyone having to notice.

Harris_PK36_Datasheet.pdf
Lapsed 31 May 2026
PK36
Product family
1. 40 mm and thicker
  Product type
  - 200 × 100 × 52 mm
    No longer evidenced
  - 200 × 100 × 65 mm
    No longer evidenced
  - 200 × 100 × 71 mm
    No longer evidenced
2. 20 mm indoor
  Product type
  - 200 × 100 × 20 mm
    No longer evidenced

The document states its own validity date, and that date has passed. Everything relying on it stops counting as settled — on every product it covers, at once.

Built for real catalogues.

Built for catalogues that are actually large.

A tool that works on one product and falls over at five hundred is a demonstration, not a product. These figures come from an automated scenario that runs against the real system on every build.

500: Products imported from one file, with provenance on every value
120: SKUs covered by a single confirmed document
1: Review of a shared value, applied to every product beneath it
119: Sibling SKUs left untouched when one records its own value

Tested scale scenario, not a customer outcome. 1781 has no customers to quote and does not present demonstrations as results.

Catalogue structure

Products the way your catalogue already thinks about them

Suppliers, product families, product types and SKUs. Information is recorded at the level it genuinely belongs to, which is why one datasheet can settle seven variants and why an override on one of them changes nothing about the other six.

Import creates the hierarchy from your own columns
A grouping stays marked as provisional until you confirm it
Values live at supplier, family, type or SKU level

Harris ApS · 7 SKUs

Catalogue

PK36Product family · 7 SKUs
40 mm and thickerProduct type · 6 SKUsdraft grouping
200 × 100 × 40 mmPK36-200x100x40
200 × 100 × 52 mmPK36-200x100x52
200 × 100 × 65 mmPK36-200x100x65
20 mm indoorProduct type · 1 SKUdraft grouping
200 × 100 × 20 mmPK36-200x100x20

How it works

Import, map, review, reuse, export.

Five steps, in order, each of which a person can inspect and reverse. There is no stage where the system decides something on your behalf and moves on.

01
Import
Bring the catalogue in from a spreadsheet or an export. Confirm how its columns map, see a dry run of every row, and commit only when it reads correctly.
02
Map
Attach documents to the products they cover — one SKU, a product type, a whole family or a supplier. Suggestions are proposals; a person confirms them.
03
Review
Extracted values arrive as candidates with the passage they came from. Accept, edit or reject. Nothing counts until somebody does.
04
Reuse
An approved value is recorded once, at the level it belongs to, and inherited by every product beneath it — until a more specific value overrides it.
05
Export
Take the whole record out as structured data: every value with its scope, its source document, its approver and its open questions.

See the platform in detail

Construction products · first market

Declarations, datasheets and the products they were written for

Construction documentation is scattered by nature: a declaration of performance for a product type, a datasheet for a family, safety information somewhere else entirely. 1781 maps each to the products it covers, then shows what is still missing.

Declarations, technical data, safety and environmental documentation
Documents that cover many products, confirmed once
Unanswered requirements listed as work, not hidden in a score

Construction products Explore the Harris demo

Harris_PK36_Datasheet.pdf

Technical datasheet

Covers the PK36 family · 7 SKUs

Confirmed

EPD_MD-23026-EN.pdf

Environmental declaration

Covers unverified — declared per tonne

Valid until 2028

Proposed

Declaration of Performance

Required by the requirement pack

Missing

Demonstration based on publicly available, draft and unverified product information. Harris ApS is not a customer, and no product has been legally assessed.

Many regulated markets. One evidence engine.

One evidence engine, several regulated markets.

Requirements differ by industry. The machinery underneath — coverage, inheritance, review, provenance, expiry — does not. Adding a market is a requirement pack and a profile, not a second product.

Construction products

First commercial market

Documentation readiness for manufacturers, importers and distributors of construction products, built on the text of the current rules and on real product documentation.

Declaration and marking documentation
Declared technical characteristics
Environmental declaration metadata and coverage
Readiness for the forthcoming passport regime, reported separately

Explore construction products

Batteries

Working prototype

EU Battery Passport data readiness on the same engine: the published data points, their applicability by battery category, and the same review and provenance model.

Data points from the published guidance
Applicability by battery category
Conditional requirements decided by a person, never assumed
Evidence expiry handled identically

Explore batteries

Find the gaps before your customers do.

The useful part is what it refuses to guess.

Anything can store a value. What matters in product documentation is knowing which values you cannot yet stand behind, and why.

Confirmed

Evidence behind every value

Each approved value points at the document it came from, the passage that supports it, and the person who accepted it.

Missing

Gaps named as work

Missing information is listed as a specific next action against a specific product — not folded into a percentage that hides it.

Conflict

Conflicts surfaced, never resolved

When two sources disagree, both are shown and the value stops counting as settled. The system does not pick a winner.

Expired

Expiry that propagates

A lapsed document invalidates what it supported everywhere it was used, at once, without anyone having to notice.

Inherited

Reuse with a visible trail

An inherited value shows which level it came from, so you always know whether you are looking at this product’s answer or its family’s.

Proposed

Human review as the gate

Machine suggestions are proposals. They wait, visibly, until a person accepts, edits or rejects them.

Who it is for

Three jobs, one underlying problem.

Whether you make the products, import them or resell them, the question a customer asks is the same: what can you prove about this item, and how quickly can you show me?

Manufacturers

You publish the documentation others rely on, and the same values are re-entered for every variant, every format and every customer request.

Record once at the level it belongs to, and let every SKU beneath inherit it.

Importers and distributors

Documentation arrives from many suppliers in many shapes, and it is rarely obvious which files cover which of the products you actually sell.

Map supplier files to the right products, and see exactly what is still outstanding.

Compliance and sustainability

You are asked to stand behind information you did not gather, from sources you cannot always trace, against requirements that keep moving.

Requirements mapped, evidence attached, review history kept — without a compliance verdict attached.

Product principles

A number that can go down is worth more than one that only rises.

Uploading a document that reveals a contradiction lowers readiness. That is the behaviour, not a bug in it — a figure that only ever improved would turn uncertainty into confidence you have not earned.

How we handle your data

We say what we have not read
Where a requirement comes from a standard we do not hold, it is labelled as derived from real product documentation rather than from the standard — on screen and in every export.
We do not determine your legal position
1781 records which role you hold in a supply chain and which requirements follow from it. Whether that is legally correct is a question for you and your advisers.
We never assume coverage
A document published by a supplier is not automatically a document about your product. 1781 proposes, explains its reasoning, and waits for a person.
Every value keeps its trail
Scope, source document, coverage decision, approver and timestamp travel with the value into the export.

Catalogue review

Start with one product family.

A catalogue review is a short conversation about your products and your documentation. We look at one representative family together and show you what is already there, what is missing and what could be reused. No obligation.