Jira progress: loading…

W-LAB

White Labelling

1. Strategic Positioning: ZAYAZ as the ESG Engine

Core Idea ZAYAZ is the computational fabric of ESG — the engine that measures, validates, and generates sustainability intelligence for any organization, framework, or system.

ZAYAZ = the data engine, formula brain, and interoperability layer.
EcoWorld =the curated branded experience with engagement, guidance, and education. EcoWorld Academy, e-c-o.com blog, E-C-O^™ Number and Score lookup,
White-label partners = “OEM reskinners” — consulting, assurance, or tech partners that deliver the ZAYAZ core inside their client ecosystems, with their own UI/UX, but the same ZAYAZ intelligence beneath.

The key message is that ZAYAZ is the universal computation and compliance logic — the hidden but trusted core everyone builds on.

1.1. Layered Brand & Platform Hierarchy

Layer	Role	Example Entities	Brand Identity on Output	Revenue / Licensing Model
Tier 1 — ZAYAZ Core	Engine for data logic, computation, and verification	DaVE, VTE, FOGE, RIF, NETZERO, COSE, etc.	Invisible or embedded signature (“Computed by ZAYAZ™”)	Engine licensing, per-API transaction
Tier 2 — White-Label Partners	Consulting, accounting, and verifier firms reskinning ZAYAZ	PwC ESG+, DNV-Sustain, ERM GreenLedger	“XYZ ESG Suite — Powered by ZAYAZ™”	White-label licensing + verifier transaction revenue
Tier 3 — Embedded / Developer Integrations (future)	Developers embedding one or more modules	IoT providers, ERPs, analytics vendors	Their brand, “ZAYAZ Verified Integration” tag	API revenue per call / seat

This keeps ZAYAZ authoritative but discreet, visible only as a trust mark or verification engine, never competing with partners.

1.2. Brand Architecture & Signature Logic

This is expressed through a unified Brand Signature Framework rather than a tagline.

Each brand level carries its own signature:

Context	Brand Signature	Purpose
Platform dashboards, APIs	“Runs on the ZAYAZ ESG Engine™”	Signals reliability of the underlying logic
Reports, outputs, or assurance files	“Verified through ZAYAZ Trust Fabric™”	Indicates integrity and audit traceability
White-label partner portals	“Powered by ZAYAZ Intelligence™”	Partner-neutral, reassuring end-users
Developer integrations	“ZAYAZ Verified Module™”	Certifies third-party module compliance

1.3. Experience Model

The product needs both universality and embeddedness.

Key architectural enablers:

Pillar	ZAYAZ Capability	Outcome
Universal Data Model	USO / SSSR → unified signal registry and ontology	Any ESG dataset becomes ZAYAZ-readable
Formula Engine	Computation Hub (NETZERO, FIRM, COSE)	Complex logic computed instantly, like Excel formulas
Interoperability Layer	DSAIL + APIs + NACE/IPCC mappings	Connects to IoT, ERP, accounting, and verification systems
Trust Layer	DaVE + VTE + ALTD blockchain audit	Every calculation has provenance
Interface Flexibility	SEEL + SDK / white-label skins	Partners can re-brand without altering logic
Scalability	Containerized micro-engine structure (MICE)	Modular deployments, on-prem or cloud

1.4. Implementation Blueprint for White-Labelling

Phase	Action	Technical / Brand Deliverable
1	Define ZAYAZ White-Label SDK	Secure containerized bundle of SEEL + Input Hub UI modules
2	Build Partner Console	Admin interface for managing partner branding, clients, and E-C-O numbers
3	Establish Signature Injection Framework	Automated embedding of “Verified through ZAYAZ” metadata in all reports
4	Create ZAYAZ Trust Registry	Public lookup showing which partner systems are validated on ZAYAZ
5	Develop Co-Brand Templates	White-label UI themes, report header/footers, and API branding fields

1.5. Governance & Commercial Rules

Data Sovereignty: All partner data processed through ZAYAZ core must retain blockchain hash for traceability.
Partner Autonomy: Partners control UI/UX but not computation logic — ensures consistency in ESG results.
Transparency Layer: Every white-label report embeds a ZAYAZ Verification Header (machine-readable JSON) for authenticity.
Revenue Model:
- Engine license (core access)
- Transactional fee per verified report
- 3 tier annual subscription model. Split handled by Stripe or customised.
- Premium AI features (ZARA, FIRM) as modular add-ons

1.6. Visual Identity Strategy

A minimalist symbol for the core — not flashy, but technical and precise.

Think: a geometric “Z Core Mark” or circular verification seal that partners can overlay unobtrusively.

Each seal could correspond to a Trust Level:

Seal Tier	Meaning
Z-Base	Using ZAYAZ computational engines
Z-Verified	Includes blockchain traceability and verification workflow
Z-Autonomous	Fully autonomous ESG computation, no human intervention

1.7. Future Scalability

This layered model easily expands to:

API marketplaces for module-level integrations
Developer ecosystems where others can extend ZAYAZ modules
Embedded verification in IoT and ERP systems via Z-Edge + MAS

In short, we’ll become the ESG OS — the Operating System for Sustainability Data.

2. ZAYAZ White-Label Governance & Partner Framework

A foundational specification for brand licensing, technical integration, and trust assurance

2.1. Purpose & Strategic Principles

Objective Define rules, standards, technical requirements, and trust protocols that enable partners to white-label ZAYAZ while ensuring:

Identical computational outcomes
Data integrity
Brand protection
Transparent trust signalling
Seamless integration with the ZAYAZ ecosystem

Core Principles

ZAYAZ is the ESG computation and verification engine.

Partners may customize experience, but never alter logic, calculations, or validation processes.

White-labelling enhances reach without diluting integrity.

ZAYAZ’s presence is subtle and authoritative—visible as a verification layer, not a consumer-facing brand.

Partners control UX; ZAYAZ controls truth.
Every output must carry a ZAYAZ Trust Signature.

(machine-readable for audit, optional visual seal for clients)

Developer extensibility is future-proofed.

Module-level APIs will allow external developers to embed ZAYAZ engines into third-party ESG tools.

2.2. Partner Types & Permission Levels

Partner Type	Branding Rights	Feature Rights	Trust Level	Examples
White-Label SaaS Partners (WL-1)	Full re-skin	Full access to ZAYAZ platform modules	Z-Base or Z-Verified	Big-4 ESG divisions, regional ESG platforms
Verification & Assurance Partners (WL-2)	Co-brand only	Verification workflows + DaVE/VTE	Z-Verified	Auditors, certification bodies
Implementation & IoT Partners (WL-3)	“Integration Partner” mark	API access + telemetry ingestions	Z-Base	Nordic Semiconductor, ERP/IoT vendors
Developer Ecosystem (WL-4, future)	No branding rights	Module-level API licensing	Z-Base	Independent devs embedding specific modules

Each partner type receives a Partner Passport describing their rights, branding assets, and technical allowances.

2.3. Brand Governance: Signatures, Seals & Usage Rules

ZAYAZ must appear consistently across all outputs—but subtly.

Mandatory ZAYAZ Trust Signature on All Outputs

Every report, API response, dashboard export, or data packet must embed: ZAYAZ Verification Header (ZVH)

A machine-readable JSON block containing:

Engine version (FOGE, DaVE, VTE, NETZERO, RIF)
Calculation hash
Verification status
Data provenance flags
Timestamp
PartnerID

Example:

verification-header.jsonGitHub ↗
{
  "computed_by": "ZAYAZ Engine v7.4",
  "trust_level": "Z-Verified",
  "verification_hash": "0x821ab3…",
  "partner_id": "WLP-2025-183",
  "daVe_score": 92,
  "vte_provenance": "autonomous",
  "timestamp": "2025-11-15T09:12:44Z"
}

This guarantees the integrity of ZAYAZ logic even under a full white-label façade.

Optional Visual Signatures (Partner controls placement)

Choose from three Trust Seals:

Seal	Meaning	Usage
Z-Base™	Calculations performed using ZAYAZ engine	All WL partners, default
Z-Verified™	Includes DaVE+VTE checks + blockchain audit	Assurance partners, regulated markets
Z-Autonomous™	Fully autonomous ESG computation, no human override	High-trust outputs

Partners may place these seals:

On report footers
In dashboard “Data Integrity” modal
In APIs as metadata tags

But NOT:

As the main brand
In UI headers
In login screens

The seal must always remain secondary to the partner’s brand.

2.4. UI/UX Governance

What Partners May Change

Logos
Colors
Typography
Navigation layout
Landing pages
Content text
Localized field names
Report templates (design only)

What Partners May Not Change

Core logic (calculations, validation rules)
Input modules and their underlying structure
SEEL materiality logic
FOGE field behavior
DaVE/VTE scoring logic
Carbon Passport computation
E-C-O Number rules
API structure
Blockchain audit requirements

This ensures all white-label products are technically identical to ZAYAZ.

2.5. Technical Architecture Rules

Partners receive the ZAYAZ White-Label SDK which includes:

Core Components

SEEL + Input Hub (UI modules)
FOGE form generator engine
DaVE validator + VTE trust engine
Computation Hub (RIF, NETZERO, FIRM)
API gateway for partner routing
Branding injection module
Telemetry ingestion router (for IoT/Matter partners)
Verification event logger
Blockchain sync client (ALTD)

Deployment Models

Cloud multi-tenant (default)
Cloud single-tenant (enterprise)
Hybrid with local Z-Edge nodes
On-prem enterprise (rare) — Only with ZAYAZ technical oversight

Data Flow Rules

All calculations MUST run through ZAYAZ engines
All trust events MUST be logged to ZVS (ZAYAZ Verification Store)
All sensitive logic MUST be validated via signature check

2.6. Partner Compliance Requirements

Each partner must pass:

Brand Compliance Certification

Correct ZAYAZ seal usage
Correct placement of ZAYAZ metadata
Fully compliant white-label UI theme

Technical Compliance Certification

Daily trust event logging
Verification header integrity
Valid DaVE/VTE integration
No attempted override of logic
Proven accurate E-C-O Number routing

Governance Review

Annual review:

Data integrity audit
Security controls
Algorithm integrity
System usage compliance

2.7. API & Module Licensing Rules

White-Label Partners (WL-1)

Full API suite
Unlimited branded UI instances
Tiered pricing based on client volume
Access to module add-ons (FIRM, PEF-ME, NETZERO Forecasting)

Developer Ecosystem (WL-4, future)

Pricing per:

API call
Data volume
Engine transaction
Validation event
Like AWS Lambda but for ESG intelligence.

2.8. Commercial Rules

Revenue Streams (depending on agreement)

White-label license fees
SaaS annual revenues sharing - Stripe or customised. solutions
Usage-based computation fees
DaVE/VTE verification fees
Carbon Passport fees
E-C-O Number issuance
Setup fees
API call revenue
IoT telemetry routing

Partner Incentives

Bulk discounts
Co-marketing
Preferred partner ranking (e.g., Platinum Integration Partner)
Access to advanced modules early

2.9. Future Extensions

Developer Marketplace for ZAYAZ micro-engines
Global ZAYAZ Trusted Integration Registry
Machine-readable partner scorecard
AI co-pilot for partner developer tools
Federation model for national ESG hubs
“ZAYAZ Embedded” program for Matter/IoT vendors

3. ZAYAZ White-Label SDK Architecture Overview

3.1. Purpose

The ZAYAZ White-Label SDK lets partners:

Embed ZAYAZ as their ESG engine while using their own branding.
Use a consistent API surface for forms, metrics, validation, trust, and reporting.
Integrate with IoT / telemetry, verification workflows, and the Computation Hub.
Guarantee that all outputs are “ZAYAZ-true”.

SDK = a set of frontend, backend, and infra components:

Frontend Web SDK (React/Vue components, theming hooks)
Backend API Client SDKs (TypeScript/Node, Python; others later)
Infrastructure & DevOps artifacts (OpenAPI spec, Postman collection, webhook patterns)

3.2. High-Level Architecture

Think of the SDK as three concentric layers:

Core Engine Layer (inside ZAYAZ, not exposed as code)

FOGE, SEEL, DaVE, VTE, Computation Hub (NETZERO, FIRM, etc.)
Runs entirely in ZAYAZ-controlled environments.

Integration / API Layer

REST/GraphQL APIs and Webhooks.
Tenant isolation, auth, rate limiting, versioning.

SDK & UI Layer

White-label UI components.
API clients & helpers.
Branding & config.

[ Partner UI / Apps ]
    ▲   ▲
    |   |
[ SDK & UI Layer ]  --> React/Vue components, TS/Python SDK
        ▲
        |
[ Integration Layer ] --> REST/GraphQL, Webhooks, OAuth2/JWT
        ▲
        |
[ Core Engine Layer ] --> FOGE, DaVE, VTE, NETZERO, FIRM, PEF-ME, etc.

3.3. Modules in the SDK

Core Client Libraries

zayaz-core-js (TypeScript/Node)
zayaz-core-py (Python)
Later: zayaz-core-php, zayaz-core-dotnet if needed

Features:

HTTP client with built-in retry & backoff.
Auth handling (API keys, OAuth2 client credentials, or JWT).
Strong models for:
Tenants / Clients
Forms / Form Templates
Submissions
Validation Results
Metrics / KPIs / ESRS datapoints
Trust Objects (DaVE/VTE outputs)
Carbon Passport / E-C-O Number lookups.

Frontend / UI SDK

zayaz-ui-react (first-class)
Later optional: zayaz-ui-vue

Components:

Form Components
- <ZayazForm /> – renders FOGE-driven form by form_id.
- <ZayazField /> – field-level component, supports FOGE metadata (required, unit, AI hint, etc.).
- <ZayazSection />, <ZayazGroup /> – chunking forms into modules (Waste, Energy, etc.).
Trust & Verification Widgets
- <ZayazTrustBadge trustLevel="Z-Verified" />
- <ZayazDataIntegrityPanel submissionId="..." />
Metrics & Dashboard Widgets
- <ZayazMetricCard metricCode="E1-1" />
- <ZayazKpiTable naceCode="..." />
Theming / Branding
- Config object:

ui-provider.tsxGitHub ↗
// ui-provider.ts

export const exampleZayazTheme = {
  primaryColor: "#partner",
  logoUrl: "/partner-logo.svg",
  fontFamily: "partner-font",
  showZayazBranding: false, // white-label mode
  showZayazTrustSeal: "minimal", // none | minimal | full
};

Configuration & Tenant Module

Tenant bootstrap & mapping:
- tenant_id = partner sub-instance.
- client_id = end-customer within partner.
Controls:
- Enabled modules (e.g. FIRM, NETZERO, Carbon Passport).
- Regional rules (ESRS / EU taxonomy toggles, local rules).
- Trust thresholds (minimum DaVE score, VTE level required).

Validation & Trust Integration The SDK wraps DaVE / VTE endpoints:

validateSubmission(submissionId) → validation score + issues.
getTrustSummary(submissionId) → DaVE score, provenance flags, etc.
Helper to embed ZAYAZ Verification Header into partner outputs.

Telemetry / IoT & Z-Edge Integration (for partners like Nordic)

Optional zayaz-iot-client:
Register device → obtain device token.
Submit telemetry events (energy, flow, sensor metrics).
Link device to:
- Facility
- E-C-O Number
- Product / CPI

Webhook & Event Subscriptions

SDK helpers to register & manage:
- on_form_submitted
- on_validation_completed
- on_metrics_updated
- on_trust_score_changed
- on_cpi_verified

3.4. Packaging & Distribution

OpenAPI spec → auto-generate clients, Postman, etc.
NPM packages for JS/TS.
PyPI package for Python.
Example repos:
- zayaz-sdk-examples-js
- zayaz-sdk-examples-react
- zayaz-sdk-examples-python

3.5. Security & Multi-Tenancy

JWT / OAuth2 for partner apps.
Per-tenant rate limits and quotas.
Enforced mapping: each request goes through:
partner_id
tenant_id
client_id
Audit log for:
Access to trust results
Engine versions used
Changes to thresholds/config

4. Developer API Documentation Outline

4.1. Intro Section

What is the ZAYAZ API?

High-level: ESG computation, validation, trust, and reporting.

Key Concepts

Tenant, Client, User
Form Template vs Submission
Metrics & KPIs
Trust (DaVE, VTE, Verification Headers)

Use Cases

Fully white-labelled ESG portal.
Integrating ZAYAZ into existing ERP/ESG tools.
IoT telemetry → metrics.
Verifier workflow integration.

4.2. Getting Started

Environments

sandbox.api.zayaz.io
api.zayaz.io

Authentication

API keys (for server-side integrations).
OAuth2 / Client Credentials (for larger partners).
JWT for user-level auth.

Versioning

URI-based or header-based (e.g. v1, v2).

Error Handling

Error envelope structure:

error-envelope-structure.jsonGitHub ↗
{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "…",
    "details": {  },
    "trace_id": "..."
  }
}

Rate Limits

General guidance + response headers.

4.3. Core Resources & Endpoints

Tenants & Clients

POST /v1/tenants
GET /v1/tenants/{tenant_id}
POST /v1/tenants/{tenant_id}/clients
GET /v1/tenants/{tenant_id}/clients/{client_id}

Docs content:

Object schema: IDs, names, region, industry/NACE, size.
Permission notes (who can create/manage these).

Forms & Form Templates (FOGE)

GET /v1/forms/templates — list templates (e.g. “ESRS E1”, “Supply Chain Scope 3”).
GET /v1/forms/templates/{template_id} — schema & metadata
POST /v1/forms — instantiate a form for a client (FOGE-driven).
GET /v1/forms/{form_id} — structure + status

Docs content:

Relationship between template, instance, and submission.
Fields: types, units, AI guidance, NACE relevance.

Submissions & Data Input

POST /v1/forms/{form_id}/submissions
GET /v1/submissions/{submission_id}
PATCH /v1/submissions/{submission_id} (partial updates)
File upload endpoints if needed (/attachments).

Docs content:

How to send structured data.
How to handle multi-period submissions.
Idempotency keys.

Validation & Trust (DaVE / VTE)

POST /v1/submissions/{submission_id}/validate
GET /v1/submissions/{submission_id}/validation
GET /v1/submissions/{submission_id}/trust-summary

Docs content:

DaVE score, completeness, consistency metrics.
VTE: provenance, source types, evidence.
Trust thresholds and how to configure them (e.g. in /trust-policies).

Metrics & KPIs

GET /v1/clients/{client_id}/metrics
- Filters: period, framework segment, NACE, topic (E/S/G).
GET /v1/clients/{client_id}/metrics/{metric_code}
GET /v1/kpis/{kpi_code}

Docs content:

Metric identifiers (ESRS codes, internal codes).
Units, scopes (Scope 1/2/3), formula references.
How recalculation works when new data arrives.

Carbon Passport & E-C-O Number

GET /v1/eco-numbers/{eco_number}
GET /v1/carbon-passports/{cpi_id}
POST /v1/carbon-passports/verify (for customs/border systems).

Docs content:

Structure of eco_number and cpi_id.
What tiers (1/2/3) mean.
How CPI verification and expiry works.

Telemetry & IoT Integration (Z-Edge / Matter) POST /v1/devices/register GET /v1/devices/{device_id} POST /v1/devices/{device_id}/telemetry e.g. energy, flows, other signals. GET /v1/devices/{device_id}/metrics

Docs content:

Linking devices to facilities and E-C-O Numbers.
Recommended payload schema.
Security & token model for devices.

Verifier & Workflow APIs

POST /v1/verifiers — register a verifier profile.
GET /v1/verifiers/{verifier_id}
POST /v1/verification-requests — supplier → verifier.
GET /v1/verification-requests/{request_id}
POST /v1/verification-requests/{request_id}/decision

Docs content:

Linking outputs to Z-Verified trust level.
Attaching verification results to submissions / metrics

4.4. Events & Webhooks

Event types:
- form.submitted
- submission.validated
- metrics.updated
- trust.score.changed
- cpi.verified
Endpoints:
- POST /v1/webhooks
- GET /v1/webhooks
- Signature & security scheme for webhooks.

Docs content:

Example webhook payloads.
Signature verification snippet in Node/Python.

4.5. ZAYAZ Trust & Verification Header (ZVH)

Definition of the header / object:

definition-of-header.jsonGitHub ↗
{
  "computed_by": "ZAYAZ Engine v7.4",
  "trust_level": "Z-Verified",
  "verification_hash": "0x...",
  "engine_components": ["FOGE", "DaVE", "VTE", "NETZERO"],
  "timestamp": "2025-11-19T10:12:33Z",
  "tenant_id": "TEN-123",
  "client_id": "CLI-456"
}

How to embed it:
- In PDFs (as metadata or JSON block).
- In XLSX (hidden sheet).
- In JSON API responses.

4.6. SDK Usage Examples

Separate section:

JavaScript / TypeScript
- Initializing client.
- Fetching templates.
- Creating a form & submitting data.
- Running validation & fetching trust.
React
- Embedding <ZayazForm />.
- Showing a trust badge & panel.
Python
- Back-office data sync script example.

4.7. Security, Compliance & Logging

Data protection guidelines.
Audit log access:
- GET /v1/audit/logs
How ZAYAZ logs:
- Engine versions.
- Trust decisions.
- API calls per tenant.

4.8. Advanced Topics (Later Docs)

Custom modules (e.g. FIRM scenarios, ZACC curves).
Multi-framework mapping (ESRS, GRI, ISSB).
National deployments (CPI routing by country code).

4.9. Changelog & Deprecation Policy

GET /v1/meta/changelog
How long deprecated endpoints are supported.
Version migration guidance.

5. The Two Types of White-Label Partners

We have two categories:

Skin-Only White-Label Partners These are the consulting firms, accounting firms, assurance partners, etc. They want:

Their brand on the platform
Their colors, fonts, logo
Their tone and report templates
Possibly small UI changes
But NO backend integrations
NO custom modules
NO API usage

Examples:

PwC GreenSuite powered by ZAYAZ
Deloitte ESG Portal powered by ZAYAZ

They just need a skin, not an engineering integration.

Full-Integration Partners These are tech-savvy partners:

IoT vendors
ERP companies
Software integrators
Developer ecosystem partners

They need deeper access to:

APIs
Telemetry ingestion
Computation Hub modules
Workflow endpoints
SDK clients in JS/Python

5.1. The SDK Serves BOTH — but in different layers

The SDK has three layers:

SDK Layer	Skin Partners Use It?	Deep Integrators Use It?
UI/Theming SDK	✔️ YES	✔️ YES
Configuration Layer (Partner + Tenant settings)	✔️ YES	✔️ YES
API/Backend SDK	❌ NO (usually)	✔️ YES
Telemetry & Device SDK	❌ NO	✔️ YES
Webhook Layer	❌ NO	✔️ YES

Skin partners only need:

zayaz-ui-react or zayaz-ui-vue
Theming tokens (colors, typography, spacing)
Branding injection config
Report template customizer
Portal logo override
Hide/show ZAYAZ seals toggle (minimally visible trust layer)

5.2. What “Skin Partners” Actually Do With the SDK

They get:

A theming skeleton

  <ZayazUIProvider
    theme={{
      brandPrimary: "#003B7A",
      brandSecondary: "#00A6D6",
      logo: "/pwc-logo.svg",
      font: "Inter",
      headerStyle: "hidden",
      trustSealDisplay: "minimal"  // always present but subtle
    }}
  >
    <App />
  </ZayazUIProvider>

A set of overridable UI components Examples:

<PartnerHeader />
<PartnerSidebar />
<PartnerReportCover />

White-label specific config

Domain mapping (portal.pwc-esg.com)
Footer text override
Color tokens
Typography tokens
Ability to hide ZAYAZ references
Ability to embed partner content inside ZAYAZ pages (through extension zones)

Nothing else They don’t need to think about:

APIs
Validations
Submissions
Trust engines
Devices
Workflows
Computation

ZAYAZ should handle all of it.

5.3. The SDK Has a “Skin Mode” Profile

This is important. When a partner is onboarded as a Skin-Only White Label, the SDK activates a lightweight mode.

Skin Mode Includes:

UI SDK
Partner Theme Config
Report Template Customizer
ZAYAZ Seal Placement Rules
Tenant/Client creation UI components (not APIs)
Form rendering UI components

Skin Mode Excludes:

All backend client libraries
Device/telemetry modules
Direct API calls
Custom workflow hooks
External system integrations
Webhooks

The partner sees only the “presentation surface” of ZAYAZ.

5.4. Skin Partners Still Need the SDK

The SDK handles: ✔️ Theming (The main value to them as a white-label offering.)

✔️ Embedding their brand correctly ZAYAZ must remain invisible except trust seals — the SDK enforces this.

✔️ Preventing brand conflicts No partner accidentally deletes required ZAYAZ metadata.

✔️ Customizing reports

They will want to brand:

Sustainability statements
Dashboards
PDF exports
Recommendation outputs

ZAYAZ outputs are always the same; only the wrappers change.

✔️ Consistent Partner L10N / Regionalization

Skin partners often:

Want language
Tone style
Terminology overrides.

The SDK centralizes this.

5.5. The Real Benefit: Skin Partners Can Onboard in 1 Day

We promise to them:

“You can launch your own ESG platform in 24 hours using your colors, your logo, your reports — with all the power of ZAYAZ underneath.”

To enable that, the SDK must provide:

A zero-code configuration mode
UI blocks
Branding tokens
Report templates
Language packs
Partner Portal Builder

GitHub Repo Request for Change (RFC)

1. Strategic Positioning: ZAYAZ as the ESG Engine​

1.1. Layered Brand & Platform Hierarchy​

1.2. Brand Architecture & Signature Logic​

1.3. Experience Model​

1.4. Implementation Blueprint for White-Labelling​

1.5. Governance & Commercial Rules​

1.6. Visual Identity Strategy​

1.7. Future Scalability​

2. ZAYAZ White-Label Governance & Partner Framework​

2.1. Purpose & Strategic Principles​

2.2. Partner Types & Permission Levels​

2.3. Brand Governance: Signatures, Seals & Usage Rules​

2.4. UI/UX Governance​

2.5. Technical Architecture Rules​

2.6. Partner Compliance Requirements​

2.7. API & Module Licensing Rules​

2.8. Commercial Rules​

2.9. Future Extensions​

3. ZAYAZ White-Label SDK Architecture Overview​

3.1. Purpose​

3.2. High-Level Architecture​

3.3. Modules in the SDK​

3.4. Packaging & Distribution​

3.5. Security & Multi-Tenancy​

4. Developer API Documentation Outline​

4.1. Intro Section​

4.2. Getting Started​

4.3. Core Resources & Endpoints​

4.4. Events & Webhooks​

4.5. ZAYAZ Trust & Verification Header (ZVH)​

4.6. SDK Usage Examples​

4.7. Security, Compliance & Logging​

4.8. Advanced Topics (Later Docs)​

4.9. Changelog & Deprecation Policy​

5. The Two Types of White-Label Partners​

5.1. The SDK Serves BOTH — but in different layers​

5.2. What “Skin Partners” Actually Do With the SDK​

5.3. The SDK Has a “Skin Mode” Profile​

5.4. Skin Partners Still Need the SDK​

5.5. The Real Benefit: Skin Partners Can Onboard in 1 Day​

1. Strategic Positioning: ZAYAZ as the ESG Engine

1.1. Layered Brand & Platform Hierarchy

1.2. Brand Architecture & Signature Logic

1.3. Experience Model

1.4. Implementation Blueprint for White-Labelling

1.5. Governance & Commercial Rules

1.6. Visual Identity Strategy

1.7. Future Scalability

2. ZAYAZ White-Label Governance & Partner Framework

2.1. Purpose & Strategic Principles

2.2. Partner Types & Permission Levels

2.3. Brand Governance: Signatures, Seals & Usage Rules

2.4. UI/UX Governance

2.5. Technical Architecture Rules

2.6. Partner Compliance Requirements

2.7. API & Module Licensing Rules

2.8. Commercial Rules

2.9. Future Extensions

3. ZAYAZ White-Label SDK Architecture Overview

3.1. Purpose

3.2. High-Level Architecture

3.3. Modules in the SDK

3.4. Packaging & Distribution

3.5. Security & Multi-Tenancy

4. Developer API Documentation Outline

4.1. Intro Section

4.2. Getting Started

4.3. Core Resources & Endpoints

4.4. Events & Webhooks

4.5. ZAYAZ Trust & Verification Header (ZVH)

4.6. SDK Usage Examples

4.7. Security, Compliance & Logging

4.8. Advanced Topics (Later Docs)

4.9. Changelog & Deprecation Policy

5. The Two Types of White-Label Partners

5.1. The SDK Serves BOTH — but in different layers

5.2. What “Skin Partners” Actually Do With the SDK

5.3. The SDK Has a “Skin Mode” Profile

5.4. Skin Partners Still Need the SDK

5.5. The Real Benefit: Skin Partners Can Onboard in 1 Day