"Are you EPCIS 2.0 conformant?" — how to actually answer it in an RFP or security questionnaire

The question arrives in a spreadsheet cell three columns wide. Are you EPCIS 2.0 conformant? (Y/N). Notes. And you type Yes, because you have a capture endpoint that speaks EPCIS-shaped JSON, and the deal moves on.

That "Yes" is a liability you just signed. Because the person who wrote that cell is not the person you have to satisfy. The RFP is answered by a procurement analyst; the claim is tested, six months later, by your customer's auditor — or by their other vendor's integration engineer, on an interop call, with your event hash on one side of the screen and theirs on the other. One of you is wrong, and it is discoverable in about four minutes.

This page is about answering the question so it survives all three readers: the analyst who scores the RFP, the security reviewer who wants provenance, and the auditor who shows up later. The short version: "Yes" is not an answer. Evidence is. And the evidence is a fixed set of artifacts you can name, pin, and hand over — the same set every time, whether the question comes phrased as conformance, as data integrity, or as a supply-chain security control.

Why "we support EPCIS" loses the exact deal it's supposed to win

Conformance is table stakes. That is the trap in it. It wins you no deals — your serious competitors can all say "Yes" in the same cell — and it loses you the deals where the claim gets tested and doesn't hold. So the asymmetry runs entirely against a bare "Yes": no upside, and a downside that detonates after you've already been selected, when switching cost has landed on your customer and reputational cost has landed on you.

There are three distinct readers behind that one cell, and each accepts a different kind of proof:

• The procurement analyst scoring the matrix wants a citation, not prose. Give them a version and a link they can paste into the scorecard.
• The security / vendor-risk reviewer wants provenance and integrity: what exactly did you validate against, can it be altered after capture, who is allowed to change it. This is a supply-chain-security question wearing an EPCIS costume.
• The auditor or interop engineer, later, wants to reproduce your result without you in the room. If they can't, "conformant" was a marketing word.

A single sentence — "we support EPCIS 2.0" — satisfies exactly one of these (the analyst) and actively fails the other two. The fix is to stop answering with an adjective and start answering with a manifest of artifacts.

The five artifacts that turn "Yes" into evidence

Here is the answer set. Build it once; it is the same for every RFP, every questionnaire, every audit, because it is anchored to a public standard rather than to whatever a given customer happened to ask.

1. A pinned schema manifest — PINS.json with sha256 digests. "Which version of EPCIS 2.0?" should have a byte-level answer, not a slide. A manifest that names the exact official GS1 EPCIS 2.0 schemas your validation runs against — by sha256 digest, at a stated revision (e.g. EPCIS 2.0.1) — converts a vague "we're on 2.0" into a verifiable fact. When the standard revises, the pin moves in one place, on the record, dated. A security reviewer reads this and stops worrying; they can see precisely what you conform to.

2. A CI conformance pass over the GS1 test requirements. Not "we tested it once." A suite that runs on every change, over the standard's own test requirements, with a green result you can screenshot or link. The value to the analyst is a citation; the value to you is that the claim can't silently rot between the RFP and the audit — a regression breaks the build, not the deal.

3. RFC 7807 exception behaviour. When you refuse a non-conformant capture, refuse it as an application/problem+json body carrying the standard's own exception types — not a bespoke vendor error string the customer's integration has to special-case. This is the tell a sophisticated reviewer looks for: a vendor who emits standard problem bodies has implemented the standard's failure modes, not just its happy path. Anyone can accept a valid event. Rejecting an invalid one correctly, in the standard's vocabulary, is the harder half — and the half auditors probe.

4. A §8.9 event-hash vector suite — graded against someone else's vectors. The CBV 2.0 §8.9 standardized event hash exists so two parties who never coordinated compute the same digest for the same event. That property is worthless if you only check your hash against your own implementation — of course it agrees with itself. Grade it against a public reference set you didn't author (OpenEPCIS publishes vectors), and gate it in CI. Now "we match" means "we match the digest your customer's other vendor also computes," which is the only version of the claim that survives an interop call.

5. An append-only, minimally-scoped integrity property — stated as a structural fact, not a policy. The security questionnaire's real question is "can this record be altered after the fact, and who can read what." The strong answer is architectural: no service identity holds an UPDATE or DELETE grant, and out-of-scope data is absent from a read rather than redacted from it. That is a property of the system, not a permission you promise to configure correctly — which is exactly the distinction a vendor-risk reviewer is trained to look for.

Five artifacts. One manifest of them, kept current, is your answer to the conformance cell, the data-integrity section, and the audit — all three, in one place, because they were always the same question asked by three readers.

Claim it strongly — and mark the one line you cannot claim

Here is the discipline that makes the whole answer credible: claim the artifacts you have, in full voice, and name the one thing you don't.

You can say, without hedging, that your capture validates against the pinned official schema, that your rejections are RFC 7807 problem bodies, that your event hash is graded against an independent public vector set in CI. Those are checkable facts about code. Say them plainly. A reviewer who verifies one and finds it true extends trust to the rest.

What you cannot say — and must not let an eager sales engineer imply — is that any of this is certified. A conformance attestation is issued by a body, against a specific record, at a specific time. If no such attestation exists, "certified" is the word that gets you caught, and it poisons every true claim next to it. The honest form is: "here is the evidence; verify it yourself; no third party has attested it, and we won't pretend one has." That sentence loses you zero credible deals and wins you every reviewer who was waiting to catch an overclaim.

This is why the embedded-layer approach exists at all. The point of taking the conformance surface as a pinned dependency rather than a staffed project is that the artifacts — the manifest, the CI pass, the vector suite, the problem-body behaviour — come with the layer and stay current with it, instead of being five things your team has to build, keep green, and re-prove every time the standard moves. The pillar walks the full surface: embed the standards layer, don't maintain it forever.

Proof, not adjectives. The conformance gateway described here passes its suite against GS1's normative artefacts, and it answers two ways right now: POST /translate, /validate and /hash on this origin, and npx epcis.dev on your own bench. No attestation has ever been issued, and no customer is named on this site. You cannot resell a certification that does not exist — and neither can we.

The move

Stop typing "Yes" into the conformance cell. Assemble the five artifacts once, keep the manifest current, and answer every future RFP, security questionnaire, and audit from the same evidence set — in full voice on what's real, honest on what isn't attested.

If you'd rather inherit that evidence set than build and maintain it, get a capture key for conformance evaluation. Line up the worst customer XML you have and the interop hash you need to match; that corpus is the evaluation.

→ Get a capture key — conformance evaluation

One address, one row. Keys are provisioned from this list, in order. One email when yours is ready — one, not a drip campaign. No account, no sequence, no call unless you ask for one.