Provenance and four-eyes review: why who entered what matters

Publishing a battery passport means making a statement about your product, and you need to be able to back it up. The Battery Regulation requires the information to be accurate, complete and up to date (Article 77(4)), and data authentication, reliability and integrity to be ensured (Article 78(g)). It does not literally require a four-eyes review. But a four-eyes review is the obvious way to meet these requirements day to day and to show later that you did: every value carries its provenance, a second person approves it, and nothing once published is overwritten; a new, signed version replaces it instead.

This article explains what the Regulation actually requires, which evidence authorities and customers can expect, and how provenance and approval work in BatteryPass. For the full picture, see our battery passport guide.

What does the Battery Regulation require of passport data?

Several provisions work together. None of them names a software product or a procedure; they describe what has to be true in the end.

Point (f) ties the restriction to Annex XIII and to the implementing act under Article 77(9), which at our check on 25 October 2026 existed only as a draft. Regardless of that, it makes sense to define within your own company who may enter and change which values.

You may also authorise others in writing to act on your behalf (Article 77(4)), such as a service provider or a cell manufacturer. The ultimate responsibility, however, stays with the economic operator placing the battery on the market (Commission FAQ, question 2.1). When suppliers, imports, colleagues and interfaces all contribute values, you need to be able to tell at any moment whose statement you are looking at.

Does the Regulation require a four-eyes review?

No, not literally. Neither Article 77 nor Article 78 mentions a second person, an approval step or a role. The Regulation describes outcomes: correct data, integrity, restricted rights to change it, protection against fraud. How you get there is up to you; the Commission does not prescribe any particular technology either (FAQ, question 11.3).

The four-eyes principle is still the obvious route, for three reasons:

• Errors get caught. A value in Wh instead of kWh, the wrong cell type, an outdated declaration of conformity: the person who entered a value is the least likely to spot their own mistake.
• Outside statements get checked. A supplier value is a claim with a source. Only once someone in your organisation has reviewed it does your company stand behind it.
• Nobody changes things alone. If one person can change a value and publish it straight away, manipulation can go unnoticed. That runs against the aim of Article 78(h).

The principle is familiar from quality management, for example in releasing drawings and inspection plans. In short: the four-eyes principle is not an explicit legal duty, but good practice for meeting Article 77(4) and Article 78(g) in a way you can prove.

Which evidence can authorities ask for?

The Regulation requires documentation over many years, and on request at short notice:

• Ten years of retention. Manufacturers keep the technical documentation and the EU declaration of conformity at the disposal of national authorities for 10 years after placing on the market (Article 38(4)). Importers keep the declaration of conformity for 10 years and ensure the technical documentation can be made available on request (Article 41(7)).
• Information on a reasoned request. Manufacturers and importers give a national authority all information and documentation needed to demonstrate conformity with Articles 6 to 10 and 12 to 14, in electronic form (Article 38(10), Article 41(8)). Many passport entries support exactly these requirements: substance restrictions, performance and durability, labelling, state of health.
• Formal non-compliance. If the technical documentation is missing or incomplete, the Member State requires the operator to put it right; if that does not happen, it takes appropriate measures up to withdrawal or recall (Article 83).
• Test reports in the passport. The results of the test reports proving compliance are part of the passport and accessible only to notified bodies, market surveillance authorities and the Commission (Annex XIII point 3).
• Due diligence. Operators subject to it keep their documentation for 10 years after the last battery made under the relevant policy has been placed on the market (Article 48(3)).
• Fines in Germany. Anyone who, intentionally or negligently, fails to ensure that passport information is accurate, complete and up to date commits an administrative offence, with a fine of up to EUR 10,000 (Section 60(2) no. 29 and (3) BattDG).

The EU registry for digital product passports thinks in versions too: the proof of registration contains a hash of the passport version it was generated for (Article 9(2)(e) of Implementing Regulation (EU) 2026/1778). Submission from BatteryPass to the registry is planned planned.

What does provenance per value mean?

Data provenance means that for every single value, not just for the file or the passport as a whole, you can say where it came from, who entered it, who reviewed it and what it rests on. BatteryPass records this for every value in testing:

Values are never overwritten. A change inserts a new revision and marks the previous one as superseded. The application’s database role cannot change stored values at all; it can only set that link to the successor. Review decisions are revisions too: an approval adds a revision with the same value, the reviewer, the time, the note and the supporting documents, and the reviewed revision stays in the history.

The same applies to evidence. A new edition of a document gets a new revision; an old one is withdrawn with a reason, not deleted. If a value rests on a withdrawn document, an automatic check flags it.

How does a four-eyes review work?

In BatteryPass every declared value takes the same route in testing:

1. Capture. A member with the editor role or above enters a value and attaches evidence. Values can also come from a committed import or a supplier answer.
2. Automatic checks. Format, range, unit, plausibility across fields and contradictions between documents. If a check fails, the value stays “captured” and a task is created.
3. Approve or reject. A member with the reviewer, admin or owner role approves the value. A rejection needs a reason and sends a task back to the responsible person.

A value cannot be approved if an automatic check fails, if the evidence the field registry requires for that field is missing (for example for composition, hazardous substances, dismantling documents, the declaration of conformity and test reports), or if the reviewer recorded the value themselves while the four-eyes principle is on. That applies to imports as well: whoever committed a spreadsheet cannot then approve its values. Supplier values are always approved by a person in your organisation.

The four-eyes principle is an organisation setting and on by default. Only admins and owners can change it, and the change is recorded in the audit log.

Three further rules make sure there is no back door:

• Interfaces declare nothing. An API key can stage an import and report condition data, but it cannot write declared values, approve anything or publish.
• Readings are not declarations. Condition data reported by a BMS, a monitoring system or a service company is accepted as a measurement without a second person, with the reporter, the measurement time and any documents. A reviewer could not judge a reading better than the device that took it.
• The assistant only proposes. Changes prepared by the AI assistant run only after the member approves them, and with that member’s role; the four-eyes principle applies unchanged.

Why are published passports never overwritten?

Because a published passport is a statement at a point in time. Anyone asking later what the passport said on a given day needs exactly that version, not today’s. BatteryPass therefore treats every publication as a new version in testing:

• Approved values only. A passport version contains approved values only. Members with the reviewer role or above can publish, and only when no mandatory information is missing. New condition data is published by the system under your organisation’s rule.
• Immutable. Each version stores all values with their provenance details and document references, plus the reason, the time and who published it. After that, nothing about it changes.
• Signed. Each version is signed with Ed25519, once in full and once in its public view. The public keys are at /.well-known/batterypass/keys.json, and the signature can be checked with the public JSON without BatteryPass.
• Traceable. For any point in time you can retrieve the version that was valid then, and a comparison shows field by field what changed between two versions.

The example passport shows what a published, signed passport looks like.

How is this different from a spreadsheet with a ‘last changed’ column?

A spreadsheet with “changed by” and “changed on” columns looks similar at first glance. The difference shows as soon as someone asks questions:

Spreadsheets are fine for collecting data. The trouble starts when they become the only record. How to keep using spreadsheets without losing provenance is described in From Excel and ERP exports to a reviewed battery passport: imported values keep the reference to their file.

Which record answers which question?

The table lists typical questions from a market surveillance authority, a customer or an auditor, and the record in BatteryPass that answers each one.

Which data sits in which access tier, and who may see it, is explained on the access tiers page.

What do you show in an inspection or audit?

Prepare a sample before anyone asks for it:

1. Pick one battery and show the passport version that was valid on a given day, with its signature.
2. Trace three values: source, evidence with checksum, the person who entered and the person who approved, and earlier revisions.
3. Show one change: the version comparison and the reason given for the new version.
4. Document roles and settings: who may capture, who may approve and who may publish, and whether the four-eyes principle is on.
5. Have the audit log ready for the period; admins and owners can view it.
6. Prepare the export: the full organisation export is a ZIP with checksums, every revision of every value, every signed passport version, the evidence files and the audit log in testing.

Software records; deciding which statement is correct remains your company’s call.

Where do you start?

1. Define roles: who captures values, who reviews them and who publishes.
2. Keep the four-eyes principle on and justify every exception in writing.
3. Know the fields that need evidence: never approve composition, hazardous substances, declaration of conformity, test reports or dismantling documents without a document.
4. Keep sources apart: do not mix your own entries, imports and supplier answers; request supplier data instead of retyping it.
5. Correct with a new revision: never overwrite, always with a note or reason.
6. Make publication a deliberate decision: check the preview for each access tier and give a reason.
7. Plan retention: take exports regularly and keep them at least as long as your technical documentation.
8. Run a mock audit: answer the questions in the table above once, internally.

How to obtain supplier data without suppliers needing accounts is covered in Supplier data for the battery passport without supplier accounts. What else BatteryPass does is on the product page; how we protect the data itself is on the security page.