Engineering Deliverables · Submission

Lovehoney / Certin Engineering Onboarding and Integration Deliverables

Prepared by: Engineering
Date: 21 September 2026
Test gate: 28 September 2026 EOD
Detection go-live target: 29 September 2026

Purpose and Scope

Engineering deliverables for the Lovehoney onboarding. Scope for this phase is Germany domestic road freight, read-only, running in shadow mode alongside Lovehoney’s existing Excel tracker, portal and email process. Two administrator seats; restricted access for all other users. Cancelled shipments are marked and retained, never deleted. Out-of-scope features are hidden by configuration or feature flag, not removed from the shared product.

Every statement below is marked by evidence status. Where the platform already implements something, it is marked Confirmed and the actual field, route or value is given. Where Lovehoney must supply something, it is marked Required from Lovehoney. Where a fact exists but has not been verified against a live system or document, it is marked To be confirmed. Nothing has been invented to fill a gap.

Evidence status legend

• Confirmed — verified in the Certin implementation or design notes
• Required from Lovehoney
• To be confirmed
• Non-blocking

Question for Lovehoney

One decision is needed to keep the 28 September test gate on track:

• Which carrier-tracking provider should this integration use — Parcel Perform, Zencargo, or both? (Parcel Perform is already built for this pilot; if Zencargo is required as well or instead, we’ll need the organisation access described in Section 4A.)

1. Technical Onboarding Checklist

Section 1

Every data, access and configuration dependency. "Required By" states the stage the item blocks. Owner is the party who must produce it, not the party who consumes it.

Data Dependencies

Integration Dependencies

Access and Credentials

Security and Compliance

Configuration

Business Rules

User and Role Setup

Testing Dependencies

Operational Dependencies

2. Data-Intake Specification

Section 2

What Certin requires from Lovehoney’s tracker. Certin field names below are the actual column names in the shipments table. Accepted header aliases are the literal strings the importer already recognises — a matching header maps with no configuration.

2.1 Shipment fields

Additional optional fields recognised without configuration: sku_code, route_code, warehouse_code, vehicle_type, product_category, distance_km. Each is stored under metadata.

2.2 SLA contract fields

Supplied via the SLA/transit-time sheet, not the shipment tracker. Delivery deadlines are derived from the contract, never from a date in the shipment file.

2.3 Canonical status values

Confirmed. Incoming statuses normalise to the set below. Anything unrecognised passes through unchanged and will not drive SLA or exception logic — which is why the full Lovehoney vocabulary is a blocking requirement.

Known follow-up on the two new statuses

return and needs_review are recorded in the design notes as not yet present in the analytics status buckets that every reporting consumer reads. Until that is updated, shipments in these two states are not counted in the delivered / failed / active / problem bucket metrics. Flagged rather than assumed resolved — it affects Automated Status Coverage reporting in Section 10.

2.4 Identifier requirements

• Unique — the shipment reference must be unique within the Lovehoney organisation. The database enforces uniqueness on (organization_id, tracking_number).
• Stable and persistent — it must not change across the shipment’s life. A changed reference is indistinguishable from a new shipment and creates a duplicate record.
• Used for matching — every update from every source matches on this value. It is the upsert key.
• Used for deduplication — repeated rows carrying the same reference collapse to one shipment.
• Used to correlate across systems — the tracker row and the carrier record must carry the same value, or they cannot be reconciled. Which carrier field carries it is Required from Lovehoney.

Known identity mismatch in the carrier feed

Parcel Perform’s own documentation states that a tracking number is not unique on its own — true identity is tracking number plus carrier. Certin’s constraint is organisation plus tracking number. The gap is handled by a guard: if an incoming tracking number already exists under a different carrier, the record is not written — it is held in a quarantine table and an alert is raised. Migrating the database key to include carrier remains open target-state work.

2.5 Handling rules

2.6 Date-field conflict — must be resolved before UAT

One date field currently carries three meanings

The importer reads a single date column for estimated_delivery, and its recognised aliases include eta, promised delivery and delivered on together. There is no field for a business commitment date.

Where a shipment is marked delivered, that same column is also taken as the actual delivery timestamp, so on-time performance compares a value against itself. Separately, where an SLA contract matches, the deadline is computed from the contract and any per-shipment date in the file is discarded — which is exactly what a fixed-appointment shipment needs preserved.

Lovehoney’s stated requirement is that carrier ETA and business commitment stay separate, with exceptions assessed against the commitment. That requires three separated fields and a change to deadline derivation. UAT-05 and UAT-06 cannot pass correctly until this is done. Section 13, item 2.

3. Draft Excel-to-Certin Field-Mapping Template

Section 3

Copy directly into Excel. Column A is filled in by Lovehoney with their actual header text; every other column is pre-filled. Rows marked Confirm need Lovehoney input before the mapping is final. Certin field names are the real column names — none invented.

Provisional until the tracker sample arrives

The anonymised tracker sample requested on the call has not yet been received. This template is built from the Certin importer’s recognised aliases, so any Lovehoney header that already matches an alias maps with no configuration. Headers that do not match need an explicit row here.

Second tab — status vocabulary mapping

4. Zencargo Integration Checklist

Section 4

No Zencargo source material exists

A search of both repositories, the engine design notes and all accessible documentation returns zero Zencargo references. There is no API documentation, no endpoint list, no authentication scheme, no rate limit and no event catalogue available to Engineering.

Per the instruction not to ask Lovehoney for what we can obtain ourselves, obtaining the Zencargo API documentation is Engineering’s own action, not a Lovehoney request. It has not yet been done and is the reason this section cannot be completed in the same detail as the Parcel Perform sub-section below. Nothing here is invented.

What already exists for Lovehoney is a built Parcel Perform connector. 4B documents it as confirmed fact so the reviewer can see what is genuinely ready. Which provider is the carrier-data source is an open decision — Section 13, item 1.

4A. Zencargo — required to complete

Authentication

API / Endpoints

No Zencargo endpoint paths are documented in any available material. Purposes below state what the integration needs; paths are pending documentation review.

Refresh Frequency

Certin’s supported intervals are Confirmed: every 15 minutes, hourly, every 6 hours, daily, or manual. An interval outside this set cannot be committed without development.

• Expected polling frequency — every 15 minutes, subject to Zencargo rate limits.
• Event-driven updates — preferred where available, with polling retained for reconciliation.
• Maximum acceptable data delay — Required from Lovehoney. Drives the Time to Know KPI target.
• Full sync — on initial load and after any watermark loss.
• Incremental sync — watermark-based, taken from fetch start with an overlap window so records created mid-fetch are not skipped.

Rate Limits

Required Events

Events relevant to the Lovehoney workflow. Availability in Zencargo is unknown until the documentation is reviewed.

4B. Parcel Perform — implemented, for comparison

Documented here because it is confirmed fact and directly relevant to the same decision. Values are taken from the connector implementation and its design notes.

5. User Access and Permissions Setup Guide

Section 5

Uses the real Certin permission model. Nine roles exist; each combines a module list with five capability flags. No roles are invented below.

Certin Users

Agreed on the call: two administrators, limited access for all remaining users. Names and emails for both groups were requested and are outstanding. Required from Lovehoney.

User Roles

The nine roles, as implemented:

Permissions

Capability flags are the platform’s real permission axes: team management, settings, analytics, automations, bulk assignment, exception resolution and forecasting. The matrix below maps them onto the requested columns.

There is no genuinely view-only role

The deployment is read-only at the integration boundary. That is not the same as read-only for users. member — the most restricted role — still reaches the dashboard, inbox, exceptions and shipments, and can send messages from within a thread. A Lovehoney "restricted" user provisioned as member would be able to act, not only observe.

Two options: add a view-only role, or feature-flag the action surfaces for this workspace and describe that arrangement plainly. This needs a decision before the permissions guide can be issued to Lovehoney — Section 13, item 3.

Environment Access

Integration Access

Carrier API credentials are held by Certin, encrypted at rest, and are not exposed to any Lovehoney user through the interface. Connector enablement is per-organisation and defaults to off. There is currently no administrative UI or API for enabling the connector or setting its credentials — both are done by direct database operation during onboarding. Confirmed.

Administrative Access

Platform-level administration sits with Certin. Access requests from new users are approved through the platform’s access-request flow; approval creates the user and sends an invitation. Approval requires a role that passes the admin check — a platform super-admin can approve across organisations.

Testing Access

UAT participants need production-equivalent roles in staging so that a permission difference does not invalidate a test result. Reserved test shipment references are listed in Section 7. Required from Lovehoney.

Customer Access

No end-customer or consumer access is in scope for this phase. Lovehoney’s own customers do not receive Certin logins.

2FA

Two-factor enforcement is an organisation setting, off by default. If enabled for Lovehoney, any user who has not enrolled is blocked from the API with an enrolment-required response. Enrol the two administrators immediately if it is switched on. Confirm whether Lovehoney requires it.

6. Technical Data-Flow and Security Summary

Section 6

Architecture

Lovehoney Excel tracker                Carrier tracking provider
  (manual export / upload)               (Parcel Perform — implemented)
          |                                (Zencargo — undecided, Section 13)
          |  file upload                        |
          |                                     |  HTTPS GET (poll, every 15 min)
          |                                     |  HTTPS POST (provider-initiated webhook)
          v                                     v
  +-------------------------------------------------------------+
  |                        C E R T I N                           |
  |                                                              |
  |  Ingestion  -->  Mapper (PII allowlist)  -->  Projection      |
  |                                                  |            |
  |                                                  v            |
  |                                          shipments table      |
  |                                          (+ quarantine on     |
  |                                           carrier collision)  |
  |                                                  |            |
  |     +--------------+--------------+--------------+            |
  |     v              v              v              v            |
  |  Exception      Dashboard      Alerts /       Reporting       |
  |  detection      + live feed    routing        + KPI capture   |
  +-------------------------------------------------------------+
          |
          |  operator-initiated only (see boundary note below)
          v
  Driver / carrier contact (WhatsApp, email)
  No arrow returns to the Lovehoney tracker or the carrier provider.

What Certin reads from

• Lovehoney’s Excel/CSV tracker, by file upload or connected spreadsheet.
• The carrier tracking provider’s read endpoints, plus provider-initiated webhooks.

What Certin receives

Operational and logistics fields only: identifiers, carrier, status and phase, timing, expected delivery window, service and packaging type, item count, dimensions, weight, linked shipments, tags, and a coarse event history with a city or hub label. A proof-of-delivery URL reference may be received; the document itself is never fetched or stored.

PII explicitly dropped and never persisted

Confirmed and test-enforced. Dropped at the mapper before anything reaches storage: notification emails and phone numbers; recipient, sender, to, from and return addresses and every sub-field including names, company and tax id; recipient identification and signature data; customer name and email on orders; line-item product detail; returns detail; customer ratings and feedback; collection-point addresses; invoice and label documents; commercial values including shipment value, shipping cost and cash-on-delivery; and fine-grained event geolocation including latitude and longitude.

The enforcement is structural, not procedural: the mapper is built field-by-field from an allowlist and never spreads or holds a reference to the raw provider payload, so nothing outside the allowlist can reach storage. Dedicated tests feed fixtures containing every dropped field and assert none survives. No name, email, phone, physical address or commercial value reaches Certin’s database.

How data enters Certin

Two paths. Scheduled polling every 15 minutes per enabled organisation, running on a retrying queue, with a watermark that advances only on complete success so an outage backfills on the next cycle. And provider-initiated webhooks, verified by HMAC-SHA256 over the raw body in constant time, deduplicated by body hash, acknowledged fast and processed asynchronously.

Where data is stored

PostgreSQL. Shipment records in the shared shipments table scoped by organisation; raw ingested records in a per-organisation schema; collision-quarantined records in a dedicated table. Retention follows the platform’s existing organisation-level retention configuration; no pilot-specific retention rule exists.

What Certin processes

Status normalisation, SLA deadline computation, exception detection and severity assessment, risk scoring, alert routing, KPI capture and reporting.

What Certin does not modify

Read-only boundary — operational statement

Certin consumes data from the source systems for monitoring, analysis and workflow purposes. Certin does not create, modify, cancel or delete source-system records.

Specifically: Certin does not write back to the carrier provider. It does not create, update or cancel shipments, bookings or appointments in Lovehoney’s systems. It does not modify Lovehoney’s Excel tracker — the tracker is read as an export and the original file is never written to. It does not send instructions to carriers on Lovehoney’s behalf.

This is enforced structurally for the implemented connector: the provider API client has no POST, PUT, PATCH or DELETE method against any provider resource path, so a write call cannot be introduced by accident. Confirmed in the implementation and its data-boundary document.

The one outbound path, stated plainly

Certin can send messages to a driver or carrier contact — WhatsApp or email — initiated deliberately by a Lovehoney operator from within an exception. It is never automatic, and it does not write to Lovehoney’s or the carrier provider’s systems; it is an outbound message to a contact.

This is disclosed here rather than omitted. A claim of an absolute boundary that a security review then contradicts costs more than stating the exception up front. If Lovehoney wants this disabled for the pilot, it can be feature-flagged off — to be confirmed.

No AI exposure for provider-sourced data

Confirmed and test-enforced. Provider-sourced data never reaches an LLM call site. The ingestion path explicitly skips the inference dual-write for this provider, a behavioural test proves it is never invoked for a real ingest, and a structural scan confirms no connector file references an inference call site.

Credentials, encryption and environment separation

7. UAT Plan

Section 7

Execution-ready. Each scenario needs a reserved shipment reference from Lovehoney before execution. Tests run against synthetic and anonymised data first, then in shadow mode. Evidence is attached to the tracker in Section 8.

UAT-05 and UAT-06 are blocked

Both assert against the business commitment date, which the platform cannot currently store separately from the carrier ETA (Section 2.6). They are written here in full so they are ready to run, but they cannot pass until the schema change in Section 13, item 2 is complete.

Core scenarios

Edge cases

8. Issue and Defect Tracker

Section 8

In use from the first UAT run, not created afterwards. Columns below are the tracker’s own; copy directly into the shared sheet.

Classification rules

Applied in order — the first that matches wins. This keeps two people from classifying the same issue differently.

Tie-breaks. Wrong data arriving correctly is Data Quality, not an Integration Issue. Correct data arriving wrongly is an Integration Issue, not a Product Bug. A Product Bug is only a Product Bug once input and configuration are both ruled out. Anything touching the read-only boundary or credentials is Security regardless of what else it looks like.

Severity definitions

Tracker

9. Lovehoney Platform Walkthrough Plan and Recording Script

Section 9

Built around a Lovehoney operator’s actual working day on German domestic road freight, not a feature tour. Target length 10–12 minutes. The recorder follows the script without improvising structure.

Walkthrough plan

Recording script

Before recording

Use anonymised Lovehoney-shaped data on German domestic road, never live customer data. Have one shipment already at-risk against its commitment date, and one delivered on time, prepared in advance. Confirm the two-date display is working — if the Section 13, item 2 work is not complete, re-cut stages 2, 7 and the SLA portion of 5, and say so rather than showing a single date as though it were the commitment.

Stage 1 · Shipment enters Certin

show: imports screen, import summary

"This is your existing tracker — the same export you produce today. Certin reads it; nothing writes back to it. When the file lands you get this summary: rows accepted, rows rejected, and the reason for each rejection. Here, four rows had no shipment reference, so they’re listed rather than silently dropped."

Understand: their process does not change, and nothing disappears without being reported.

Stage 2 · Status becomes visible

show: shipment list, then one shipment detail

"Every shipment from the tracker and the carrier feed in one list. On this shipment you can see both dates: your committed delivery date, and the carrier’s current estimate. They’re held separately, and everything Certin assesses is measured against your commitment, not the carrier’s estimate."

Understand: the distinction they specified is built in, not a reporting afterthought.

Stage 3 · Certin identifies an exception

show: live feed, then the exception appearing

"The carrier has just revised its estimate past your commitment date. Certin has raised an exception — no one had to go looking. This is the gap we measure as Time to Know: from the event happening to it being in front of you."

Understand: detection is automatic, and it is the first KPI in the framework.

Stage 4 · Operator sees the exception

show: exception queue sorted by severity

"This is the morning view. Everything needing attention, most serious first. Instead of opening the portal shipment by shipment, you start from the shipments that have a problem."

Understand: the queue replaces manual checking — the Manual-Checking Requirements KPI.

Stage 5 · Operator investigates

show: exception detail, history, SLA panel

"Opening the exception gives you the shipment’s full history, the carrier’s events, where it sits against your commitment, and the contract terms that apply. This is the information you’d currently gather from the tracker, the portal and an email thread."

Understand: one place instead of three — the Duplicate-Entry Hours KPI.

Stage 6 · Certin provides context

show: AI assistant, one question and answer

"You can ask about the shipment directly. Ask what’s driving the risk here — the answer draws on this shipment’s own data. Note the internal marker: this is a working note for your team, not a message to anyone outside it."

Understand: faster orientation, with no risk of an internal note reaching a customer.

Stage 7 · SLA risk is surfaced

show: deadline, hours remaining, exposure figure

"Certin puts a number on it: hours remaining against your commitment, and the exposure under the contract terms if it breaches. That’s what tells you whether this one is worth a phone call."

Understand: prioritisation by cost, not just by lateness.

Stage 8 · User takes action

show: assign, then escalate or contact

"From here you assign it, escalate it, or contact the carrier — without leaving the shipment. Every action is recorded against it, so the next person sees what’s already been done."

Understand: action and context stay together; nothing lives only in someone’s inbox.

Stage 9 · Outcome is recorded

show: resolution with category, then audit trail

"When it’s closed you record what actually happened and categorise it. That category matters — it’s how we measure whether Certin’s assessment was right, and it’s what builds the picture of what’s really going wrong on this lane."

Understand: the resolution step is what makes Assessment Accuracy measurable. If operators skip it, that KPI degrades silently.

Stage 10 · Reporting and KPI visibility

show: dashboard KPIs with movement

"These are the measures in your framework, moving against the previous period. During the pilot Certin runs alongside your existing process — we’re establishing the baseline, not replacing anything yet."

Understand: shadow mode is deliberate, and early numbers are a baseline rather than a verdict.

10. Lovehoney KPI Measurement Framework

Section 10 · customer-facing

Written for Lovehoney stakeholders. Where a measure depends on something Lovehoney must provide, that is stated in the row rather than assumed.

No signed agreement was available

The signed agreement was not accessible when this was prepared. Definitions below are derived from the deliverables request wording and from what the platform can actually measure. Every one must be checked line by line against the agreement before this section is sent to Lovehoney, and any target stated there replaces the placeholder here.

One target does exist in the implementation: automated coverage carries a 90% target marked "to be confirmed" in the connector’s KPI acceptance fixture. It is recorded below as found, not as agreed.

11. Day 0 Baseline Requirements

Section 11

A baseline cannot be reconstructed after the fact. Everything below must be captured on or before 29 September, and platform-side capture must be verified as running before the first live data arrives.

12. Consolidated Engineering Requirements from Lovehoney

Section 12

The single request to send. Items already requested on the call are restated as outstanding rather than re-asked. Nothing here asks for anything Engineering can obtain itself.

Required Before Configuration

Required Before Live Testing

Useful but Non-Blocking

13. Blockers and Open Dependencies

Section 13

14. Submission Readiness Check

Section 14

Two items require a decision today

Section 13, item 1 — the carrier-data provider is undecided, and the request names a provider for which no material exists. Section 13, item 2 — the business commitment date cannot currently be stored, which blocks two UAT scenarios and two stages of the end-to-end chain due 28 September.

Prepared 21 September 2026. Sections 4, 10 and 12 carry explicit dependencies on material not available at the time of writing — the Zencargo API documentation, the signed agreement, and the anonymised tracker sample. These are identified in place rather than filled with assumptions.