Partner certification / regression evidence
Turn EDI partner testing into a versioned release gate
Prove both what should pass and what must fail against the exact partner-pack version entering production.
Direct answer
Direct answer
EDI partner testing should preserve representative accepted and intentionally rejected documents, their expected outcomes, content hashes, finding codes and the exact partner-pack version tested. Shipment Sentry encrypts fixture content, reruns the current deterministic preflight and blocks AS2 or Peppol pack activation until both outcomes pass for that version. This is product-side regression evidence, not a substitute for the partner or network certification programme.
Why a parser is not enough
A single happy-path file proves only that one sample passed once. Requiring a negative fixture catches relaxed validation and binds the evidence to the configuration release, so editing or promoting a different pack cannot inherit a stale certification label.
What the control should check
- 01Record the exact fixture bytes and SHA-256 hash.
- 02Name the expected accepted or rejected outcome.
- 03Bind the case to one partner route and pack version.
- 04Store status, counts, stable finding codes and rule-pack identity.
- 05Require both outcomes for AS2 and Peppol activation.
- 06Re-run fixtures after a rule, mapping, identifier or delivery-policy change.
Working example
PARTNER PACK 7
accepted / RETAILER-approved-856.edi / passed
rejected / missing-sscc-856.edi / passed
activation gate / ready“Ready” means the internal regression contract passed. The trading partner’s own sign-off remains separately required when applicable.
Failure modes worth catching
- A new pack reuses the previous version’s test badge.
- Only accepted examples exist, so validation can weaken undetected.
- A changed fixture keeps its older content hash.
- Internal regression evidence is marketed as partner-issued certification.
Put it into the dispatch workflow
- 1Create or draft the partner-pack version.
- 2Upload one known accepted fixture.
- 3Upload one deliberately rejected fixture.
- 4Run both through the deterministic validator.
- 5Resolve unexpected outcomes and rerun.
- 6Promote only the exact version whose suite is ready.
Questions
Implementation answers
Why require a rejected fixture?
It proves the gate still blocks a known defect instead of accepting everything.
Are fixtures retained?
Yes, inside the authenticated tenant boundary, encrypted at rest and tied to the route version.
Does this replace retailer certification?
No. It creates durable regression evidence for the product release; external partner certification remains external.
Sources and limits
Reviewed 2026-07-20. Public references cannot establish every partner-specific rule. Current implementation guides and agreements remain controlling.
Keep investigating