SUPP-ONBOARD
ZAYAZ Supplier Onboarding and Data Acquisition
1. Purpose
Supplier onboarding in ZAYAZ is not a questionnaire workflow.
It is a governed process for:
- discovering suppliers from existing commercial systems;
- resolving whether the supplier already exists in the ZAYAZ ecosystem;
- enriching the supplier profile without asking the supplier for information unnecessarily;
- determining which regulatory and reporting requirements are relevant;
- selecting the correct pre-built FOGE form;
- contextualising that form where justified;
- pre-filling everything ZAYAZ can resolve from governed sources;
- asking the supplier only for the unresolved remainder;
- validating and reusing accepted supplier data;
- creating the buyer-supplier relationship in the ZAYAZ organizational graph; and
- maintaining a separate educational engagement through EcoWorld Academy.
The governing principle is:
No Ask Before Reuse.
A supplier should never be asked to recreate information that ZAYAZ can already obtain, resolve, calculate, verify or reuse from an acceptable source.
The supplier-facing form is therefore not the primary form. It is a FOGE Delta Form: the unresolved remainder of a complete applicable FOGE form after all permitted resolution and prefill steps have been exhausted.
2. Core architectural principle
The supplier architecture has two distinct phases.
Phase A — Design and governance time
Pergamum Pulse interprets regulations, standards and other authoritative requirements before a supplier appears.
Pergamum Pulse sends governed requirement packages to FOGE.
FOGE uses those packages to prepare versioned baseline forms in advance.
AI and other governed contextual logic may enrich or specialise those forms where justified, for example for specific NACE sectors, but may not silently remove or weaken mandatory Pergamum requirements.
Phase B — Runtime supplier processing
When a supplier is discovered, ZAYAZ builds a supplier profile.
A resolver uses that profile to select the correct already-prepared FOGE form and determine whether permitted contextual alterations apply.
ZAYAZ instantiates the complete form, resolves and pre-fills all fields it can, and only then asks FOGE to generate the supplier-facing Delta Form.
This distinction is fundamental.
DESIGN / GOVERNANCE TIME
──────────────────────────────────────────────────────────
Law / Regulation / Standard / Authoritative Requirement
│
▼
PERGAMUM PULSE
│
│ governed requirement package
▼
FOGE
│
│ compile baseline forms
▼
FOGE FORM RELEASES
│
└── contextual extension rules
may be added under governance
RUNTIME
──────────────────────────────────────────────────────────
Accounting / ERP / Procurement
│
▼
Supplier Candidate
│
▼
Identity Resolution + Enrichment
│
▼
Supplier Profile
│
▼
FORM RESOLVER
│
selects FOGE release
+ permitted extensions
│
▼
FOGE FORM INSTANCE
│
▼
RESOLUTION / PREFILL
│
▼
ITEM STATES
│
▼
FOGE DELTA FORM
│
▼
Supplier
│
▼
Supplier Contributions
│
▼
Validation / Trust / Reuse
3. Responsibility boundaries
| Capability | Primary responsibility |
|---|---|
| Interpret authoritative regulatory requirements | Pergamum Pulse |
| Determine regulatory applicability semantics | Pergamum Pulse |
| Maintain versioned baseline form definitions | FOGE |
| Compile Pergamum requirements into form items and rules | FOGE |
| Maintain SSSR signal semantics and canonical signal references | SSSR |
| Discover suppliers from accounting, ERP and procurement systems | ACF / Input Hub |
| Maintain buyer-scoped pre-onboarding supplier candidates | ECO |
| Resolve supplier identity to existing E-C-O identity | ECO resolution / identity services |
| Enrich supplier profile from external data providers | Input Hub / enrichment services |
| Select the applicable FOGE form for a supplier profile | Form Resolver |
| Apply governed contextual form alterations | Form Resolver + FOGE |
| Resolve and prefill form items from existing data | Resolution / Prefill orchestration |
| Calculate derivable values where permitted | MICE |
| Evaluate source authority, evidence and trust | TrustGate / DaVE / DICE as applicable |
| Persist unresolved supplier-facing requests | ECO supplier request tables |
| Persist supplier-provided data/evidence | ECO supplier contribution tables |
| Represent buyer-supplier relationship | UOM relationship graph |
| Manage course access and learning progress | EcoWorld Academy |
| Explain decisions and lineage to users | ZARA |
No subsystem should silently take over another subsystem's responsibility.
In particular:
FOGE does not become a regulatory authority. Pergamum Pulse does not become a runtime form renderer. The supplier request tables do not decide what the supplier should be asked.
Part I — Design and Governance Time
4. Pergamum Pulse prepares requirements in advance
Pergamum Pulse is the regulatory source of truth.
Its responsibility is to transform authoritative source material into governed, versioned regulatory knowledge that downstream systems can execute without re-reading laws, guidance or standards independently.
The package sent from Pergamum Pulse toward FOGE should be capable of expressing, as applicable:
- framework or legal source;
- exact source version;
- jurisdiction;
- effective period;
- applicability conditions;
- thresholds;
- entity characteristics;
- employee thresholds;
- turnover thresholds;
- sector or NACE conditions;
- group or subsidiary conditions;
- value-chain conditions;
- reporting scope;
- mandatory requirements;
- conditional requirements;
- permitted alternatives;
- evidence expectations;
- disclosure/data requirements;
- applicable voluntary caps or request limits;
- source citations and provenance;
- supersession relationships; and
- requirement identifiers stable enough for replay and audit.
Pergamum Pulse should produce these rules before runtime supplier processing.
A supplier profile therefore does not normally trigger fresh interpretation of legislation.
Instead, it is evaluated against already-governed rules.
5. Pergamum-to-FOGE requirement package
A conceptual package may look like:
requirement_package_id: PP-PKG-EXAMPLE-001
framework_ref: PP:FRAMEWORK:EXAMPLE
framework_version: 2026.1
jurisdiction: EU
effective_from: 2026-07-01
applicability:
conditions:
- employee_count
- turnover
- jurisdiction
- nace
- value_chain_role
requirements:
- requirement_ref: PP:REQ:001
requirement_type: quantitative
mandatory: true
signal_refs:
- sssr:example.metric
evidence_expectation:
type: source_record
- requirement_ref: PP:REQ:002
requirement_type: attestation
mandatory: true
signal_refs:
- sssr:example.attestation
The exact physical contract is governed separately. The important architectural point is that FOGE receives a governed requirement package, not free-form regulatory prose.
6. FOGE prepares baseline forms
FOGE converts Pergamum requirement packages into versioned form definitions.
A FOGE baseline release may include:
FOGE FORM RELEASE
├── release_id
├── framework / package references
├── content digest
├── effective version
├── sections
├── items
├── item types
├── signal bindings
├── required_when rules
├── evidence expectations
├── validation rules
├── calculation dependencies
├── presentation metadata
└── Pergamum lineage
The baseline form represents the complete governed requirement contract, not what a specific supplier will ultimately see.
FOGE releases should be immutable.
A legal or technical change produces a new release rather than modifying history.
7. Governed AI and contextual form specialisation
FOGE baseline forms may need sector, geography, business-model or other contextual specialisation.
Examples include:
- NACE-specific data needs;
- process-emissions detail for relevant industrial sectors;
- product-specific evidence;
- region-specific units or validation;
- energy-market detail;
- sector-specific certificates;
- higher-resolution data needed for a permitted calculation; or
- additional voluntary information that creates value for the supplier or buyer.
AI may assist in identifying and composing these extensions.
However, the following invariant applies:
AI may specialise or extend a Pergamum-derived form, but it may not silently remove, weaken or reinterpret a mandatory Pergamum requirement.
Any form alteration should preserve:
base_foge_release
alteration_id
alteration_type
reason
applicability_context
rule / AI component
version
provenance
approval state
Material AI-generated alterations should remain reviewable and replayable.
Part II — Runtime Supplier Processing
8. Supplier discovery
The normal supplier-onboarding flow begins in the client's existing commercial systems.
Typical sources include:
- accounting systems;
- ERP systems;
- procurement platforms;
- purchase ledgers;
- vendor masters;
- contract systems;
- sourcing systems; and
- other ACF-connected systems.
ZAYAZ should not require the client to manually re-enter the supplier list.
A source supplier record is first represented as a buyer-scoped supplier candidate.
Current ECO persistence:
eco.supplier_candidates
The candidate preserves:
- buyer entity;
- source system;
- source connection where available;
- source record identity;
- source record version;
- supplier name;
- email;
- registration number;
- VAT number;
- country;
- address;
- phone;
- website domain;
- source payload;
- resolution state; and
- resolved supplier entity where identified.
The source-system identity remains important even after resolution because it supports idempotent synchronization and reconciliation.
9. Supplier candidate is not yet a canonical supplier identity
A supplier candidate is a discovery record.
It is not automatically:
- a new
eco.entitiesrow; - a new E-C-O Number;
- a new UOM graph node; or
- evidence that the supplier must complete an onboarding process.
The first priority is resolution.
ERP Supplier Record
│
▼
Supplier Candidate
│
▼
Identity Resolver
│
├── existing E-C-O supplier
├── probable existing supplier
├── ambiguous match
└── genuinely new supplier
Human intervention should be reserved for genuinely ambiguous identity cases.
10. External enrichment
Before asking the supplier for information, ZAYAZ may enrich the candidate from external sources.
Examples may include:
- official company registries;
- AIRA or equivalent business-information services;
- public regulatory datasets;
- industry datasets;
- connected corporate databases;
- public company information;
- credit/business-information providers; and
- other governed external sources.
Current ECO persistence:
eco.supplier_candidate_enrichments
Enrichment snapshots may contain normalized facts such as:
legal_name
registration_number
country_code
registered_address
website_domain
annual_turnover_amount
annual_turnover_currency
turnover_period
employee_count
employee_count_as_of
nace_codes[]
confidence
provider
provider_reference
raw_payload
retrieved_at
effective_period
Enrichments should be versioned snapshots rather than destructively overwritten current values.
This allows ZAYAZ to reconstruct what was known at a given time.
11. Existing E-C-O identity resolution
If the supplier candidate resolves with sufficient confidence to an existing ECO entity and active E-C-O identity, ZAYAZ must reuse that identity.
It must not:
- create a duplicate ECO entity;
- issue a duplicate E-C-O Number;
- require a generic onboarding form;
- ask the supplier to recreate already-governed information; or
- treat the supplier as if ZAYAZ has never seen it before.
Instead:
Supplier Candidate
↓
Existing E-C-O identity found
↓
Link candidate → canonical supplier entity
↓
Establish buyer ↔ supplier relationship in UOM
↓
Reuse governed supplier data
↓
Continue with runtime form resolution
An existing E-C-O identity does not mean the supplier can never be asked for new information.
It means:
The supplier is not re-onboarded, and existing information is not re-requested. Only genuinely unresolved requirements may generate supplier action.
12. Buyer-supplier relationship belongs in UOM
The relationship:
Client XYZ ── SUPPLIES / supplied_by ── Supplier ABC
is not an E-C-O Number property and should not be embedded in the supplier invitation record.
It belongs in the governed UOM relationship graph.
The relationship should be:
- typed;
- effective-dated;
- provenance-bearing;
- historically reconstructable; and
- independent of whether any supplier form is required.
A supplier may therefore be connected to a client even when:
supplier_data_requests = 0
That is an important distinction.
Supplier relationship and supplier data acquisition are separate concepts.
13. Build the Supplier Profile
After source ingestion, identity resolution and enrichment, ZAYAZ builds the supplier profile used by the Form Resolver.
The profile may contain:
identity
├── resolved ECO entity
├── E-C-O Number(s)
├── registration number
└── jurisdictional identifiers
company characteristics
├── country / jurisdictions
├── turnover
├── employee count
├── NACE / sector
├── legal form
├── group status
└── other governed classification facts
relationship context
├── buyer
├── supplier relationship
├── sourcing context
└── value-chain role
available-data context
├── known ZAYAZ signals
├── existing evidence
├── prior contributions
├── connected systems
└── external enrichments
This profile is input to the Form Resolver.
It does not itself define regulatory obligations.
Part III — Form Resolution
14. The Form Resolver
The Form Resolver decides which prepared FOGE form release applies to the supplier profile.
Its job is:
Given this supplier profile and the governed FOGE catalogue, select the correct baseline form and the permitted contextual extensions.
The resolver should consider facts such as:
- jurisdiction;
- employee count;
- turnover;
- NACE;
- legal form;
- group membership;
- value-chain role;
- buyer context;
- reporting purpose;
- reporting period;
- known Pergamum applicability context; and
- effective dates.
A conceptual output may be:
resolution_id: FR-001
supplier_candidate_id: ...
supplier_entity_id: ...
base_form_release:
release_id: FOGE-EXAMPLE-2026.2
extensions:
- FOGE-NACE-C24
- FOGE-NORDIC-ENERGY
resolution_basis:
country: SE
employee_count: 412
nace: C24.10
buyer_role: supplier
resolved_at: ...
The Form Resolver does not independently reinterpret the law.
The legal/regulatory requirement has already been governed through Pergamum Pulse and compiled into FOGE.
15. The complete FOGE Form Instance
The selected form release and approved contextual alterations produce a complete supplier-specific FOGE Form Instance.
This is the authoritative runtime requirement set.
FOGE FORM INSTANCE
├── base release
├── applied extensions
├── supplier context
├── reporting / request purpose
├── effective date
├── complete applicable item set
└── item runtime states
It is critical that ZAYAZ first materializes the complete applicable form, even though the supplier may ultimately see only a few questions.
Why?
Because ZAYAZ must be able to explain:
- everything that was applicable;
- which items were already satisfied;
- which values were prefilled;
- where each value came from;
- which items were not applicable;
- which items required confirmation;
- what remained missing; and
- why the supplier was asked each final question.
The Delta Form is therefore derived from the complete form instance.
It is not the canonical requirement record.
Part IV — Resolution and Prefill
16. Resolution order
Before exposing an item to the supplier, ZAYAZ should attempt to satisfy it from governed sources.
The exact priority may depend on source authority and requirement semantics, but the candidate source classes include:
- existing accepted ZAYAZ data;
- existing E-C-O identity/entity data;
- previous accepted supplier contributions;
- authoritative connected supplier sources;
- accounting / ERP / ACF data;
- external business-information providers such as AIRA;
- official registries and public authoritative data;
- buyer-held evidence;
- valid estimates where the governing requirement permits estimates;
- MICE-derived values where calculation is permitted; and
- supplier confirmation or supplier-provided data.
This is not merely a convenience lookup.
Each candidate value must retain sufficient provenance and authority context for the applicable requirement.
17. Source authority matters
A known value is not automatically an acceptable value.
Example:
employee_count = 412
may exist in:
- the buyer's vendor master;
- an external provider;
- the supplier's own prior submission; and
- an official registry.
FOGE may require different authority depending on the item.
Therefore resolution should evaluate:
value
source
source authority
freshness
effective period
confidence
evidence
required evidence class
requirement
validation state
A field can be technically known but still require supplier confirmation.
18. FOGE item runtime states
Each FOGE Form Instance item should resolve to an explicit runtime state.
Recommended core states:
| State | Meaning |
|---|---|
SATISFIED | Requirement is fulfilled from an acceptable governed source; no supplier action required |
PREFILLED | A value has been populated and may be displayed to the supplier; no re-entry is required |
NEEDS_CONFIRMATION | ZAYAZ has a candidate value, but the requirement needs supplier confirmation/attestation |
MISSING | Required information could not be resolved from acceptable sources |
NOT_APPLICABLE | Contextual evaluation determines the item does not apply |
WAIVED | A governed decision explicitly waives the item |
BLOCKED | Resolution cannot proceed because required context or authority is unresolved |
Additional implementation states may be added where justified.
The key supplier-experience rule is:
SATISFIED → do not ask
NOT_APPLICABLE → do not ask
WAIVED → do not ask
PREFILLED → show only if useful / required
NEEDS_CONFIRMATION → ask for confirmation, not re-entry
MISSING → ask only for the missing datum/evidence
BLOCKED → resolve internally where possible before supplier contact
19. Prefill example
Assume the applicable FOGE form contains 87 items.
Complete FOGE Form Instance
────────────────────────────────────────
51 SATISFIED from existing ZAYAZ data
12 SATISFIED / PREFILLED from accounting
9 SATISFIED / PREFILLED from external sources
5 SATISFIED from governed calculations
4 NOT_APPLICABLE
3 NEEDS_CONFIRMATION
3 MISSING
────────────────────────────────────────
87 applicable runtime items
The supplier should not receive 87 questions.
FOGE generates:
FOGE DELTA FORM
────────────────────────
3 confirmation items
3 missing items
────────────────────────
6 supplier-facing items
This is the practical meaning of No Ask Before Reuse.
Part V — FOGE Delta Form
20. Delta Form generation
The Delta Form is produced only after:
- identity resolution;
- supplier enrichment;
- form resolution;
- complete FOGE Form Instance creation;
- data reuse;
- external resolution;
- calculation where permitted;
- source-authority evaluation; and
- item-state determination.
The Delta Form should contain only:
- missing required values;
- required confirmations;
- required attestations;
- missing evidence;
- unresolved conditional questions needed to determine applicability; and
- optional items only where the supplier has explicitly chosen a voluntary pathway.
The supplier-facing experience should make clear:
- what ZAYAZ already knows;
- what has been prefilled;
- what the supplier is being asked to confirm;
- what is genuinely missing;
- why the missing information is needed;
- which evidence is expected; and
- how the information will be reused.
21. ECO request persistence
Current ECO persistence created for unresolved supplier action:
eco.supplier_data_requests
eco.supplier_data_request_items
These tables are downstream execution persistence.
They do not define the canonical FOGE form.
A future FOGE runtime bridge should make the lineage explicit:
FOGE form instance
↓
FOGE form instance item
↓
supplier_data_request
↓
supplier_data_request_item
Recommended future bindings include concepts such as:
supplier_data_requests
├── foge_form_instance_id
└── delta_form_ref
supplier_data_request_items
└── foge_form_item_instance_id
Exact names and physical FKs should be established only after the FOGE runtime persistence model is confirmed.
Existing fields such as:
information_profile_ref
signal_ref
requirement_ref
profile_field_ref
remain valuable lineage.
However, they should not be mistaken for the immediate runtime parentage of the Delta Form.
Part VI — Supplier Contribution
22. Supplier responses are contributions, not survey responses
ZAYAZ does not treat the supplier's answer as a monolithic completed questionnaire.
Supplier input is stored as governed contributions.
Current ECO persistence:
eco.supplier_contributions
eco.supplier_contribution_items
A contribution may represent:
- a missing metric;
- a confirmation;
- an attestation;
- a certificate;
- a policy;
- an evidence document;
- a structured data payload;
- an API-delivered value; or
- another permitted supplier-provided datum.
Each contribution item is independently traceable to:
- supplier;
- request;
- request item;
- signal;
- value;
- evidence;
- submission channel;
- validation state; and
- acceptance/rejection state.
23. Validation and acceptance
Supplier-provided information must not automatically become authoritative simply because it was submitted.
Depending on the signal and requirement, the contribution may pass through:
- schema validation;
- DaVE input validation;
- DICE completeness/integrity checks;
- TrustGate evidence/authority evaluation;
- MICE calculation or consistency checks;
- manual verification;
- assurance workflows; and
- other governed validation services.
Once accepted, the contribution can satisfy the corresponding FOGE item and become reusable ZAYAZ data.
24. Reuse creates the supplier network effect
Accepted data should reduce future supplier burden.
Example:
Supplier ABC
│
│ provides accepted energy data once
▼
Canonical governed ZAYAZ data
│
├── reused for Client X where permitted
├── reused for Client Y where permitted
└── reused for future FOGE instances where valid
The next buyer that links the same supplier should not automatically cause the supplier to repeat the same work.
That is one of the core benefits of a reusable E-C-O identity.
Part VII — Existing Supplier Path
25. Existing supplier with sufficient data
Supplier discovered in Client XYZ accounting system
↓
Supplier Candidate created/synchronized
↓
Identity Resolver finds existing E-C-O supplier
↓
Candidate linked to canonical ECO entity
↓
Buyer ↔ Supplier UOM relationship established
↓
Supplier Profile built
↓
Form Resolver selects applicable FOGE form
↓
Complete FOGE Form Instance
↓
Resolution / Prefill
↓
All items satisfied
↓
NO DELTA FORM
NO DATA REQUEST
NO ONBOARDING QUESTIONNAIRE
The supplier should still receive a useful relationship notification.
For example:
Client XYZ has connected your company as a supplier through ZAYAZ. Your existing ZAYAZ information has been reused, so no additional sustainability information is currently required from you.
The exact communications design belongs to the notification/UX layer.
26. Existing supplier with one unresolved item
Existing E-C-O supplier
↓
FOGE form = 54 applicable items
↓
53 satisfied from existing governed data
↓
1 required certificate missing
↓
FOGE Delta Form
↓
1 evidence request
The supplier sees one task, not a 54-item questionnaire.
Part VIII — New Supplier Path
27. New supplier discovered from accounting
Accounting system
↓
Supplier Candidate
↓
No existing E-C-O identity found
↓
External enrichment
↓
Identity / company facts established
↓
Supplier Profile
↓
Form Resolver
↓
FOGE form instance
↓
Resolution / Prefill
↓
Delta Form
↓
Supplier contribution
↓
Identity/onboarding completion as required
Even a genuinely new supplier should not be asked for data ZAYAZ already obtained from acceptable sources.
Onboarding is therefore progressive rather than duplicative.
Part IX — Supplier Communication and EcoWorld Academy
28. Supplier relationship notification
Data requests and relationship notifications are separate workflows.
An existing E-C-O supplier may have no unresolved FOGE items but should still be notified that a new client relationship has been established.
This communication demonstrates the network value of ZAYAZ.
The message should generally communicate:
- which client has linked the supplier;
- that the relationship is now recognized in ZAYAZ;
- whether any action is required;
- that existing information has been reused where possible;
- where the supplier can review its ZAYAZ profile; and
- how the relationship may reduce repeated information requests.
No-data-required is a successful outcome, not a missing workflow.
29. EcoWorld Academy is an independent engagement lane
Academy engagement should occur regardless of whether the supplier has a Delta Form.
The supplier-learning workflow is not conditional on a compliance-data request.
The Academy owns:
- learner identity;
- entitlements;
- enrollment/access;
- course/module progress;
- completion;
- certificates;
- reinforcement; and
- learning telemetry.
Supplier engagement can therefore behave as:
Supplier linked to client
↓
Check Academy state
│
├── no entitlement / no learner
│ → invite to appropriate supplier course
│
├── entitled, not started
│ → friendly start reminder
│
├── in progress
│ → progress update + continue link
│
└── completed
→ completion acknowledgement
+ next/refresher course where appropriate
A supplier that has nothing to fill out can still receive value from ZAYAZ through Academy access.
Supplier training can be co-branded with the client relationship where appropriate.
Part X — Data Model
30. Current ECO supplier persistence
The current supplier-oriented ECO persistence is:
eco.supplier_candidates
eco.supplier_candidate_enrichments
eco.supplier_invitations
eco.supplier_data_requests
eco.supplier_data_request_items
eco.supplier_contributions
eco.supplier_contribution_items
eco.supplier_candidates
Buyer-scoped pre-onboarding supplier discovery record.
eco.supplier_candidate_enrichments
Versioned external enrichment snapshots.
eco.supplier_invitations
Historical onboarding/invitation delivery workflow where an invitation is actually needed.
Existing resolved suppliers do not need a generic onboarding invitation merely because a new buyer relationship is discovered.
eco.supplier_data_requests
Envelope for genuinely unresolved supplier-data requirements.
eco.supplier_data_request_items
Exact unresolved supplier-facing data/evidence requirements.
eco.supplier_contributions
Supplier submission envelope.
eco.supplier_contribution_items
Per-signal submitted value/evidence.
31. Persistence still required
The supplier model also requires a FOGE runtime layer.
Conceptually:
FOGE release
↓
FOGE form instance
↓
FOGE form instance items
↓
prefill / resolution observations
↓
item state
↓
Delta Form projection
Potential persistence concepts include:
foge_form_instances
foge_form_instance_items
foge_item_resolution_observations
foge_delta_forms
These names are illustrative, not yet canonical physical table names.
The physical model must be reconciled with the existing FOGE runtime projection before implementation.
Part XI — Runtime Events
32. Representative events
The architecture should support explicit events rather than hidden state transitions.
Supplier discovery and identity:
SUPPLIER_SOURCE_RECORD_DISCOVERED
SUPPLIER_CANDIDATE_CREATED
SUPPLIER_CANDIDATE_UPDATED
SUPPLIER_ENRICHMENT_COMPLETED
SUPPLIER_IDENTITY_RESOLVED
SUPPLIER_IDENTITY_AMBIGUOUS
BUYER_SUPPLIER_RELATIONSHIP_ESTABLISHED
FOGE runtime:
FOGE_FORM_RESOLVED
FOGE_FORM_INSTANCE_CREATED
FOGE_CONTEXT_EXTENSION_APPLIED
FOGE_PREFILL_STARTED
FOGE_ITEM_RESOLVED
FOGE_ITEM_CONFIRMATION_REQUIRED
FOGE_ITEM_MISSING
FOGE_DELTA_FORM_CREATED
Supplier action:
SUPPLIER_DATA_REQUEST_OPENED
SUPPLIER_CONTRIBUTION_SUBMITTED
SUPPLIER_CONTRIBUTION_VALIDATING
SUPPLIER_CONTRIBUTION_ACCEPTED
SUPPLIER_CONTRIBUTION_REJECTED
SUPPLIER_DATA_REQUEST_SATISFIED
Engagement:
SUPPLIER_CONNECTION_NOTICE_SENT
SUPPLIER_ACADEMY_INVITATION_SENT
SUPPLIER_ACADEMY_PROGRESS_REMINDER_SENT
Exact event naming should align with CMCB conventions before implementation.
Part XII — AI Governance
33. AI is allowed to help, but not redefine authority
AI can add significant value in supplier onboarding.
Appropriate uses include:
- entity matching;
- extracting registration identifiers;
- interpreting messy source-system supplier records;
- suggesting NACE mappings;
- identifying likely external enrichment sources;
- recommending FOGE contextual extensions;
- prefill candidate matching;
- evidence classification;
- supplier-facing explanation;
- identifying duplicate requests;
- identifying likely already-satisfied fields; and
- producing concise Delta Form language.
AI must not:
- invent regulatory obligations;
- override authoritative Pergamum requirements without governed review;
- silently remove mandatory form items;
- promote an unverified value to authoritative merely because it is plausible;
- create duplicate supplier identities when existing identity resolution is available; or
- ask the supplier for information merely because resolution is inconvenient.
Part XIII — Legal and Regulatory Alignment
34. Request minimisation
The ZAYAZ supplier architecture is designed around necessity and proportionality.
This is good system design independently of any one regulation, but it is also increasingly aligned with EU value-chain reporting rules.
Directive (EU) 2026/470 introduces a value-chain cap for certain CSRD information requests to undertakings that do not exceed 1,000 employees. It also states that reporting undertakings should request value-chain information only insofar as necessary and should request less than the voluntary standard where they do not need all information in that standard.1
The European Commission has likewise explained that CSRD reporting companies are not expected to request every data point permitted by the value-chain cap.2
ZAYAZ therefore implements a useful compliance-by-design pattern:
Determine the requirement
↓
Select the governed form
↓
Reuse and resolve available data
↓
Request only the necessary unresolved delta
↓
Preserve why each request was made
The legislation does not require the use of a particular enrichment provider or technical prefill mechanism. Those are ZAYAZ implementation choices.
The important architectural property is that ZAYAZ can demonstrate why information was requested and what efforts were made to avoid unnecessary supplier burden.
Part XIV — Auditability and Explainability
35. Every supplier question should be explainable
For every item on a Delta Form, ZAYAZ should be able to answer:
Why are we asking this?
↓
FOGE form item
↓
FOGE release
↓
Pergamum requirement
↓
authoritative source / version
↓
applicability context
It should also be able to answer:
Why did we not ask this?
↓
already satisfied
or prefilled
or not applicable
or waived
or resolved from an acceptable external source
This supports:
- regulatory audit;
- assurance;
- supplier trust;
- client governance;
- dispute resolution;
- model evaluation;
- form optimisation; and
- legal defensibility.
Part XV — Security and Privacy
36. Supplier identity and source data
Supplier candidate data can contain:
- personal contact information;
- commercially sensitive vendor data;
- financial characteristics;
- source-system identifiers;
- enrichment-provider payloads; and
- potentially confidential evidence.
Access should therefore be tenant-scoped and purpose-bound.
Raw source and enrichment payloads should not automatically become broadly visible.
37. Invitation security
Supplier invitation links should use random bearer tokens.
Only a one-way hash of the token should be stored in the database.
Current ECO invitation persistence uses:
invitation_token_hash
token_hash_algorithm
The raw bearer token should not be persisted in the invitation table.
Part XVI — Non-Negotiable Invariants
38. Supplier onboarding invariants
- No Ask Before Reuse.
- Pergamum Pulse governs regulatory requirements before runtime supplier processing.
- FOGE prepares baseline form releases from governed Pergamum requirement packages.
- The Form Resolver selects among governed FOGE releases; it does not independently reinterpret legislation.
- AI may extend or specialise forms under governance but may not silently weaken mandatory Pergamum requirements.
- A complete FOGE Form Instance exists before a Delta Form is derived.
- Every applicable item must have an explicit runtime state.
- ZAYAZ attempts resolution and prefill before supplier action is generated.
- Existing E-C-O suppliers are reused, not re-onboarded.
- Existing accepted data is not requested again unless freshness, authority or requirement semantics justify it.
NEEDS_CONFIRMATIONresults in confirmation, not re-entry.- Supplier-facing requests contain only the unresolved delta.
- Buyer-supplier relationships belong in UOM, not in invitation records.
- Relationship notification is independent of whether a data request exists.
- Academy engagement is independent of whether a data request exists.
- Supplier submissions are contributions, not monolithic survey responses.
- Accepted contributions become reusable governed data where policy permits.
- Every supplier-facing item must preserve lineage to the FOGE item and authoritative requirement.
- Historical form, request and contribution states must remain reconstructable.
- No subsystem may silently manufacture regulatory authority that belongs to Pergamum Pulse.
Part XVII — Worked Scenarios
39. Scenario A — Existing E-C-O supplier, nothing missing
Input
Client: XYZ
Supplier discovered: ABC AS
Registration number: known
E-C-O identity: found
Flow
candidate created
→ existing identity resolved
→ buyer/supplier UOM relationship established
→ supplier profile built
→ FOGE form selected
→ all FOGE items resolved from existing data
→ zero Delta Form items
Supplier experience
- receives connection notice;
- receives no sustainability questionnaire;
- sees that ZAYAZ reused existing data;
- receives or continues relevant Academy engagement.
40. Scenario B — Existing supplier, confirmation only
FOGE requires employee count.
ZAYAZ resolves:
employee_count = 187
source = acceptable external company-data source
The requirement needs supplier confirmation.
FOGE item state:
NEEDS_CONFIRMATION
Delta Form:
Employees: 187
[ Confirm ] [ Correct ]
The supplier is not asked to type 187 again.
41. Scenario C — New supplier, partial external resolution
Supplier is new to ZAYAZ.
Accounting provides:
name
email
registration number
address
External enrichment provides:
country
turnover
employee count
NACE
FOGE form contains 42 applicable items.
Resolution satisfies 36.
The supplier receives a six-item Delta Form.
Accepted data becomes reusable for future buyer relationships and future FOGE form instances.
42. Scenario D — Regulation changes
Pergamum Pulse records a material regulatory change.
new authoritative requirement version
↓
new Pergamum requirement package
↓
FOGE compiles new form release
↓
old FOGE release remains immutable
At runtime, the resolver selects the release applicable to the relevant effective date/reporting context.
Historical supplier requests remain replayable against the release under which they were created.
43. Scenario E — Sector-specific extension
The baseline form applies to multiple industries.
Supplier profile contains:
NACE = C24.10
The resolver determines that an approved metallurgy extension applies.
baseline FOGE release
+
approved NACE C24 extension
↓
supplier-specific FOGE Form Instance
The extension adds justified fields without changing mandatory baseline requirements.
Part XVIII — Implementation Sequence
44. Recommended implementation order
The supplier persistence foundation now exists in ECO.
The next implementation work should follow this order:
1. Confirm Pergamum → FOGE requirement-package contract
2. Confirm existing FOGE runtime projection
3. Implement Form Resolver contract
4. Implement FOGE Form Instance persistence
5. Implement FOGE item runtime-state persistence
6. Implement source-resolution / prefill orchestration
7. Implement source-authority decision model
8. Generate Delta Form from unresolved FOGE item states
9. Bind ECO supplier_data_requests to FOGE form instances
10. Bind ECO request items to FOGE item instances
11. Implement supplier contribution validation flow
12. Implement UOM buyer-supplier relationship creation
13. Implement supplier connection notifications
14. Integrate Academy entitlement/progress messaging
15. Add portfolio-level monitoring and telemetry
Part XIX — Canonical End-to-End Model
45. Final operating model
AUTHORITATIVE SOURCES
│
▼
PERGAMUM PULSE
│
governed requirements
│
▼
FOGE
│
baseline form releases
│
governed extensions
│
▼
───────────── RUNTIME BOUNDARY ─────────────
Accounting / ERP / Procurement / ACF
│
▼
eco.supplier_candidates
│
├── external enrichment
│
▼
Identity Resolution
│
existing E-C-O identity?
│
▼
Supplier Profile
│
▼
FORM RESOLVER
│
▼
FOGE FORM INSTANCE
│
▼
Resolution / Prefill Layer
│
┌───────────────┼────────────────┐
│ │ │
ZAYAZ External MICE
data sources derived
│ │ │
└───────────────┼────────────────┘
│
▼
FOGE ITEM STATES
│
▼
FOGE DELTA FORM
│
▼
eco.supplier_data_requests
│
▼
Supplier
│
▼
eco.supplier_contributions
│
▼
DaVE / DICE / TrustGate / verification
│
▼
Accepted governed data
│
└──────► reusable next time
PARALLEL RELATIONSHIP LANE
──────────────────────────────────────────────────────────
Supplier resolved
→ UOM buyer/supplier relationship
→ connection notification
PARALLEL EDUCATION LANE
──────────────────────────────────────────────────────────
Supplier linked
→ Academy entitlement/progress lookup
→ invite / start reminder / progress update / completion
46. Summary
ZAYAZ supplier onboarding is designed to make supplier data collection progressively disappear as the network becomes richer.
Pergamum Pulse establishes regulatory truth.
FOGE prepares the forms required by that truth.
The runtime Form Resolver selects and contextualises the correct form for the supplier.
ZAYAZ then exhausts available internal, connected and external sources before generating supplier work.
FOGE presents only the unresolved Delta Form.
Accepted contributions become reusable data.
Existing E-C-O suppliers are linked rather than re-onboarded.
The UOM graph records the commercial relationship.
EcoWorld Academy maintains an independent, value-creating supplier engagement even when no data request exists.
The desired end state is therefore not:
A better supplier questionnaire.
It is:
A system in which suppliers are asked only for information that genuinely cannot be obtained or reused elsewhere — and every remaining question can be explained, governed, traced and reused.
Related internal documentation
content/computation-hub-calcs/form-engine.mdx— FOGE source/release/runtime separation.content/eco-product-unit/epu-supplier-product-data-onboarding.mdx— supplier product-data onboarding and reuse.content/eco-product-unit/epu-supplier-contributions.mdx— No Ask Before Reuse and supplier contribution principles.content/eco-product-unit/epu-anticipatory-sustainability-acquisition.mdx— requirement resolution and anticipatory acquisition.content/eco-product-unit/epu-commercial-acquisition-service-extension.mdx— gap analysis, authority resolution and acquisition planning.content/academy/ecoworld-learning-platform/log-in-flow.mdx— Academy identity, entitlements and learning-runtime separation.content/standards/pergamum-pulse/— Pergamum Pulse regulatory knowledge and applicability specifications.