Jira progress: loading…

Design — Code of Conduct (Onboarding Requirement #1) & Client Assessment Architecture

Status: Design v1.0 for decision · Companion to: ZAYAZ ESG Data Ladder proposal (Passport = requirement #2) Completes: the onboarding pair → unblocks SP-T2 m006 Scene 6.3 (CoC placeholder)

---

Part A — Code of Conduct

A1. The model: baseline + overlays

Three kinds of CoC exist in the supplier's world, and the design handles all three without ever making the supplier sign the same principles twice unnecessarily:

1. The ZAYAZ Supplier Code of Conduct (baseline) — one document, accepted once by every supplier at onboarding, before the Passport. This is the platform's floor: no supplier is on ZAYAZ without it. Anchored to international norms (below) so it is defensible to any client's procurement and legal teams.
2. Client CoC overlays — a client may attach their own CoC to the relationship. Acceptance is recorded per relationship, on top of the baseline. The platform presents it honestly: "You have accepted the ZAYAZ baseline; [CLIENT NAME] additionally asks you to accept their code."
3. The supplier's own CoC — registered as a governance document (the Snapshot's g_code_of_conduct item), and at Tier 5 it becomes the code they cascade to their suppliers.

Why a baseline at all (instead of only client CoCs): it guarantees every supplier on the platform has accepted a floor even before any client attaches anything; it gives Tier 5 suppliers a ready-made, respected code to cascade; and it lets small clients without their own CoC rely on the platform's. It is also what makes the CoC an onboarding requirement rather than a per-relationship event.

A2. Baseline CoC — content architecture (drafting outline)

Anchored explicitly to: ILO core conventions, the UN Guiding Principles on Business & Human Rights, the OECD Guidelines for Multinational Enterprises, and the UN Global Compact's ten principles. Naming the anchors in the preamble is half the respectability.

§	Section	Core commitments (summary for drafting)
0	Preamble & anchors	Purpose, who it binds, the international norms it implements; plain-language promise: "commitments actually kept beat impressive claims"
1	Legal compliance	Comply with applicable law everywhere the supplier operates; where the Code is stricter, the Code guides
2	Human & labour rights	No child labour (ILO min. age), no forced labour, no discrimination, freedom of association & collective bargaining, lawful wages & working hours, humane treatment
3	Health & safety	Safe workplace, incident recording (ties to B9/the safety-log habit taught in Tier 2), continuous improvement
4	Environment	Environmental legal compliance, pollution prevention, resource efficiency, willingness to measure & improve (ties the Code to the Data Ladder without making data a Code obligation)
5	Business integrity	Zero tolerance for corruption & bribery (ties to the Passport B11 declaration), fair competition, conflicts of interest, gifts & hospitality limits
6	Responsible sourcing (cascade)	Supplier promotes equivalent principles in its own supply chain — the seed of Tier 5, written into the floor from day one
7	Information & data	Confidentiality, data protection, honest and accurate records (ties to "defensible data")
8	Raising concerns & remediation	Reporting channel, non-retaliation, remediation-first approach — improvement over termination where the supplier engages honestly
9	Acceptance, validity & re-attestation	Versioning, annual re-attestation (aligned with the Passport cycle), consequence of non-re-attestation (account restriction, not deletion)

Tone requirement: same plain language as the courses — short sentences, translation-ready. The Code should read like it was written by the people who wrote Tier 1, because trust is one voice. Legal review before publication is mandatory; this outline and the draft to follow are for counsel to review, not a substitute for it.

A3. Mechanics

• Versioned documents: every CoC (baseline, client overlays) is a versioned entity; the accepted version is immutable in the record.
• Acceptance record: who (named actor + role), for which supplier (E-C-O Number), which document + version, when, and how (click-accept in the invitation flow). Baseline acceptance happens before Passport completion — it is the first gate of the front door.
• Public lookup publication (subscriber feature): a supplier who subscribes to ZAYAZ can publish their baseline CoC acceptance as part of their E-C-O Number lookup service — accepted version + date, publicly verifiable by anyone resolving the E-C-O Number. Acceptance itself is free and universal; public verifiability is a subscription perk, consistent with the fence (the network keeps the data; the outward-facing artifact is paid, same pattern as the VSME report export).
• Annual re-attestation: one combined yearly moment — Passport declarations + CoC re-attestation together, aligned with the reporting-period rollover and surfaced in the "data care" routine. One email, one ten-minute session, everything renewed.
• Version changes: a new baseline version triggers delta-acceptance ("what changed" shown plainly) at next login or next re-attestation, whichever comes first; grace period before restriction.
• Client overlays: attached per relationship; acceptance recorded in the same table with owner=client. The platform nudges clients toward relying on the baseline (less friction for their suppliers) but never blocks their own code — procurement autonomy stays intact.
• Languages: baseline published in the invitation-language set; acceptance always records which language version was shown.
• Non-acceptance path: a supplier who declines the baseline cannot activate the account; the inviting client sees "invitation declined at Code of Conduct" — a status, not a judgment (framing rule applies even here).

A4. Storage model

• coc_documents (id, owner_type: zayaz|client|supplier, owner_id, version, language, effective_from, body/file, changelog)
• coc_acceptances (supplier_eco_number, document_id, version, actor_name, actor_role, accepted_at, method, language_shown, reattest_due, status: active|lapsed|superseded)
• Client overlays link through the relationship (client_id ↔ supplier eco-number); supplier-own codes register as governance documents referencing the same coc_documents table with owner_type=supplier.
• Passport (requirement #2) lives beside this in the onboarding schema, as per the Data Ladder proposal — one onboarding domain, two requirement tables, one re-attestation clock.

---

Part B — Client Assessment Architecture

B1. The principle: a lens, not a questionnaire

The client assessment is not a separate questionnaire. It is a client-configured selection over the canonical field library (the Data Ladder fields, VSME-mapped), rendered per relationship, pre-filled from everything the supplier has already answered anywhere on the platform. One data model; the assessment is a lens over it.

Why this is the only design that survives contact with reality:

1. Answer once, share everywhere is structurally guaranteed — pre-filling isn't a feature bolted on; it is what the assessment is. A supplier at Level 2 opens a new client's assessment and finds most of it already green.
2. Cap compliance by construction: clients compose their assessment from a library that lives inside VSME Basic (plus the clearly-marked voluntary layer, which they may invite but not require). Custom uploaded questionnaires would reintroduce the exact legal exposure the Omnibus cap forbids — so the platform simply doesn't have that feature for required content.
3. Scoring stays coherent: every answer feeds the same field once; there is no "questionnaire answer" diverging from "reported data" for the same fact.

B2. Anatomy of an assessment

Layer	Content	Constraints
1. Data selection	Client picks fields from the canonical library (curated presets: "Starter" = Passport+L2 fields, "Basic" = full VSME Basic, or custom selection)	Required fields must be ≤ VSME Basic; voluntary-layer fields may be invited, visibly marked "optional — your choice"
2. Relationship context	What the supplier delivers to this client, which sites serve the relationship, contract/product references	Bounded template — a fixed, small set of relationship fields, not free-form question authoring
3. CoC overlay	Client's own CoC acceptance, if attached (Part A)	Baseline already accepted at onboarding

Completion status per layer is what the client dashboard shows ("assessment 80% — 2 fields awaiting data"), and unanswered required fields deep-link straight into the relevant quick-start or course module — the assessment becomes a router into the programme, which is exactly the activation loop the Supplier Programme wants.

B3. What clients give up, and what they get

Honest trade-off, stated in client-facing terms: clients give up free-form questionnaire authoring. They get pre-filled assessments (faster supplier turnaround, dramatically higher completion rates), cap compliance by design, comparable data across their whole supplier base, and suppliers who improve over time via the programme instead of resenting the form. For genuinely client-specific needs, the relationship-context layer plus their CoC overlay covers the legitimate cases; anything beyond that is bilateral business between them, outside the assessment.

B4. Consequences for existing designs

• Passport: unchanged — the assessment at onboarding is simply this architecture's first rendering (typically the client's "Starter" preset + relationship context + any CoC overlay).
• Quick-start #1 (client assessment): unchanged in purpose; its script gains the pre-fill behavior ("fields you've already answered arrive green").
• Tier courses: unchanged; deep-links from open assessment fields into modules strengthen activation.
• Platform requirements list gains: canonical field library with cap-boundary flags, assessment composer (presets + selection), pre-fill/render engine, relationship-context template, deep-linking from open fields to programme content.

---

Addendum — A5. Equivalence mapping: client CoC ↔ baseline (schema)

Purpose: when a client attaches their own CoC, spare the supplier double reading — clauses covered by the accepted baseline are shown as covered; only genuine deltas require review and acceptance.

Tables:

• coc_clauses (document_id, version, clause_ref, section_no, title, clause_text, text_hash) — clause-level decomposition of any CoC in the system, baseline and client codes alike; the hash detects silent text changes.
• coc_equivalence_maps (id, source_document_id, source_version, target_document_id, target_version, status: draft | approved | invalidated, method: manual | assisted, approved_by_actor, approved_at) — one map per (client CoC version → baseline version) pair.
• coc_clause_mappings (map_id, source_clause_ref, relation, target_clause_ref nullable, note) — with relation one of:
  • equivalent — covered; supplier sees "covered by your ZAYAZ baseline acceptance"
  • stricter — same topic, higher bar; shown as a delta (a stricter demand needs conscious acceptance)
  • additional — topic the baseline doesn't cover; delta
  • weaker — baseline already exceeds it; covered, no action
  • not_covered — reviewed, no baseline counterpart; delta

Rules that make it safe:

1. The client approves the map. ZAYAZ pre-suggests mappings (method=assisted), but "our code is equivalent here" is the client's legal position — a client actor approves before any supplier sees the reduced view. Unapproved map → supplier sees the full client CoC.
2. Delta acceptance records the map version — provable exactly which reduced view was accepted under which equivalence claims.
3. Version invalidation: a version change on either document flips the map to invalidated; full-document fallback until a new map is approved.
4. Supplier UX: "Your ZAYAZ baseline covers 14 of 17 sections of [CLIENT NAME]'s code. Review the 3 additions."

Implementation can follow launch, but acceptance records carry the map-version reference from day one — retrofitting provenance into acceptance records later is far harder than carrying an empty column now.

Decisions — RESOLVED

1. Baseline scope: lean floor, international-norms-anchored. ✔
2. Full baseline CoC text: drafted (v1.0, plain-language, for legal review — separate document). ✔
3. Assessment presets at launch: "Starter" and "Basic". ✔
4. Equivalence mapping: wanted — schema designed (A5 addendum above); implementation may follow launch, acceptance-record provenance built in from day one. ✔

---