> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/standardization/nexus-sovereignty/viii.-interoperability-and-integration/policy-linked-credentialing.md).

# Policy-Linked Credentialing

Verifiable Identity, Role, and Performance Architecture Aligned to Global Goals and Agreements

## Verifiable Contribution Records, Impact Evidence, Role-Bound Recognition, Privacy-Preserving Proofs, and Boundary-Safe Institutional Alignment

### Why Treaty-Linked Credentialing Matters

Institutions, projects, companies, public-good organizations, investors, operators, communities, researchers, and individuals are increasingly asked to demonstrate how their actions relate to sustainable development, environmental and social performance, governance quality, resilience, climate adaptation, public health, disaster-risk reduction, infrastructure reliability, financial responsibility, and international commitments. Yet most contribution claims remain weakly evidenced. They are often reported through static PDFs, narrative disclosures, self-attested impact statements, spreadsheet metrics, consultant reports, dashboard screenshots, or proprietary scoring systems that are difficult to verify, compare, update, dispute, or connect to real operational outcomes.

The Nexus Sovereignty Framework introduces a credential architecture that can make selected SDG, ESG, and treaty-linked contribution records more verifiable. These credentials do not certify impact by themselves. They do not create official SDG status, ESG compliance, treaty compliance, investment eligibility, procurement approval, insurance readiness, regulatory approval, or institutional endorsement. Instead, they provide structured, cryptographically verifiable records that link declared contributions, evidence, simulation outputs, clause executions, monitoring records, public-safe summaries, project evidence, and governance review into portable proof objects.

This matters because global risk governance increasingly requires evidence that can move across institutions without losing context. A climate-resilience project may need to show how its monitoring evidence relates to SDG 13 and local adaptation priorities. A water infrastructure initiative may need to show how its evidence aligns with SDG 6, climate-risk reduction, community safeguards, and operational monitoring. A health systems project may need to link facility resilience, service continuity, workforce capacity, and public-safe reporting. A company may need to organize ESG evidence across operational, environmental, cyber, supply-chain, and governance domains. A consortium member may need to prove participation, contribution, review, or stewardship roles without exposing sensitive data. A Project SPV may need finance-readiness or insurance-readiness evidence that is structured, traceable, and current, without implying that finance or insurance has been approved.

The core doctrine is:

**SDG, ESG, and treaty-linked credentials in Nexus are verifiable contribution and evidence records. They support recognition, review, reporting, routing, governance participation, and readiness analysis, but they do not by themselves create certification, compliance, endorsement, finance approval, underwriting, procurement approval, treaty enforcement, or public authority status.**

### Credentialing for Evidence, Not Impact Washing

SDG and ESG language is often vulnerable to overclaiming. A project may claim alignment with global goals without demonstrating measurable contribution. A company may report ESG progress without independent evidence. A platform may label actions as sustainable without showing methodology, boundaries, or tradeoffs. A governance system may reward visible metrics while ignoring displacement, community harm, biodiversity loss, social risk, or uncertainty.

Nexus credentialing must be designed against this problem. It should require evidence classes, metric definitions, source provenance, simulation assumptions, public-safe boundaries, jurisdictional context, and correction paths. A credential should say what was observed, what was modeled, what was contributed, which metric was used, who issued or reviewed the credential, what evidence supports it, when it expires, where it applies, what it does not mean, and how it can be revoked, disputed, superseded, or corrected.

This turns credentials into claims discipline. A credential is not a badge of virtue. It is a structured evidence object that can be inspected, challenged, and updated.

### Credential Types Supported in Nexus

The NSF credential layer can support multiple SDG, ESG, and treaty-linked credential types. These should be W3C-compatible where appropriate, privacy-preserving where necessary, revocable, scope-bound, jurisdiction-aware, and linked to audit records.

An **SDGContributionVC** records evidence that an actor, project, institution, community process, or governance workflow contributed to a declared SDG target or indicator category under a defined methodology.

An **SDGAlignmentVC** records that a clause, project evidence package, campaign, program, or institutional activity has been mapped to one or more SDG goals and targets, without claiming verified outcome unless evidence supports it.

An **ESGEvidenceVC** records evidence relating to environmental, social, governance, resilience, cybersecurity, labor, supply-chain, climate, biodiversity, public-safe, or community-related performance.

An **ESGReadinessVC** records that a set of evidence is organized for review against a declared ESG or sustainability reporting framework, without claiming compliance or assurance.

A **TreatyAlignedEvidenceVC** records that evidence, simulation, reporting logic, or clause mapping is aligned to a treaty, framework, compact, or institutional policy reference, without claiming treaty compliance or enforcement.

A **ProjectImpactEvidenceVC** records project-level evidence such as monitoring outputs, hazard exposure, community safeguards, resilience performance, water access evidence, emissions evidence, biodiversity indicators, health service continuity, or infrastructure uptime.

A **PublicGoodContributionVC** records contribution to Nexus public-good infrastructure, such as standards review, model validation, public-safe review, evidence curation, community stewardship, data contribution, clause review, or audit participation.

A **FinanceReadinessEvidenceVC** structures evidence for authorized financial review, without finance approval, investment advice, securities placement, credit rating, or guarantee.

An **InsuranceReadinessEvidenceVC** structures exposure, monitoring, hazard, basis-risk, and claims-evidence preparedness records, without underwriting, coverage, pricing, claims determination, or insurability.

A **RoleStewardshipVC** records governance participation, review role, domain contribution, or stewardship activity, without implying title, office, employment, public authority, or automatic leadership status beyond the declared scope.

All credentials should include explicit non-meaning fields. The credential should state what it proves and what it does not prove.

### SDG Alignment Framework

SDG-linked credentials should be structured around goal, target, metric, evidence, methodology, jurisdiction, time window, actor role, and review status. A credential should not merely state “aligned with SDG 6.” It should specify whether the claim concerns water access, water quality, wastewater, water-use efficiency, integrated water resources management, ecosystem protection, capacity building, community participation, or another target-linked category. It should identify whether the evidence is observed, simulated, modeled, reported, audited, community-verified, project-monitored, or public-data derived.

A safe SDG credential may look like:

```json
{
  "credential_type": "SDGContributionEvidenceVC",
  "goal": "SDG 6",
  "target": "6.1",
  "metric": "water_access_improvement_evidence",
  "subject": "ProjectEvidenceRecord#0x71ab",
  "evidence_basis": [
    "MonitoringRecord#0x88",
    "SimulationRunVC#0xabc",
    "PublicSafeSummary#0x41"
  ],
  "issued_by": "did:nsf:org:WaterEvidenceGovernanceRegistry",
  "jurisdiction_scope": ["KEN"],
  "valid_from": "2025-01-01T00:00:00Z",
  "valid_until": "2026-01-01T00:00:00Z",
  "review_status": "evidence-reviewed",
  "non_meaning": [
    "not-UN-endorsement",
    "not-official-SDG-certification",
    "not-finance-approval",
    "not-procurement-approval"
  ]
}
```

The seed example used `UNWaterDAO`. Unless such a relationship is formally authorized, examples should avoid naming UN entities as credential issuers. Nexus can map to SDG goals and targets and remain compatible with SDG reporting logic without implying that UN bodies issue, sign, endorse, or verify Nexus credentials.

The SDG Alignment Framework should support multiple evidence maturity levels. A low maturity credential may indicate thematic alignment. A higher maturity credential may indicate monitored contribution evidence. A still higher maturity credential may include third-party review, community review, simulation validation, public-safe review, and observed outcome verification. These levels should be explicit rather than hidden behind a generic SDG badge.

### ESG Integration and Verification

ESG-related credentials should be evidence-specific and domain-specific. ESG is too broad to be treated as one undifferentiated score. Environmental evidence may include emissions, water, biodiversity, waste, land use, climate exposure, adaptation, resilience, pollution, and ecosystem impact. Social evidence may include community safeguards, labor conditions, access, inclusion, health and safety, grievance mechanisms, human rights due diligence, Indigenous and community data governance, and public-safe communication. Governance evidence may include board oversight, audit trails, conflict-of-interest records, procurement neutrality, risk controls, cybersecurity, data governance, AI governance, disclosure controls, and correction mechanisms.

A Nexus ESGEvidenceVC should define the framework or internal reference profile it maps to, the metric category, evidence source, methodology, review status, time window, and boundary. It should distinguish self-reported, monitored, audited, simulated, independently reviewed, and public-safe evidence. It should also identify whether the credential is project-level, institution-level, asset-level, jurisdiction-level, supply-chain-level, or portfolio-level.

ESG credentials can support dashboards, evidence rooms, governance review, public-safe summaries, Project Evidence records, finance-readiness evidence, and insurance-readiness evidence. They should not be used to imply public ESG scoring, investment eligibility, regulatory compliance, sustainability certification, green labeling, assurance, or rating unless a competent authorized process has provided that status.

Aggregation should be handled carefully. A bundle of ESGEvidenceVCs may show that evidence exists across categories. It should not automatically compute a public score without methodology, weighting, uncertainty, and review. Composite scores can hide tradeoffs and should be explainable, challengeable, and context-specific.

### Treaty-Aligned Role Credentialing

Treaty-linked credentialing should be framed as **treaty-aligned evidence and role mapping**, not treaty enforcement. Nexus can record that an actor holds a role relevant to a treaty-aligned workflow, such as evidence reviewer, reporting coordinator, simulation validator, public-safe reviewer, community steward, data provider, or institutional observer. It can link that role to source mappings, jurisdictional scope, credential status, and governance review. It should not claim that the actor is officially appointed under a treaty, authorized by treaty parties, or empowered to enforce obligations unless such authority exists.

A TreatyAlignedRoleVC may define:

The treaty, compact, framework, or reference profile.

The role type.

The issuer.

The jurisdiction or institutional scope.

The permitted actions.

The prohibited actions.

The evidence or reporting function.

The validity window.

The dispute and revocation path.

The non-meaning boundary.

For example:

```json
{
  "credential_type": "TreatyAlignedEvidenceRoleVC",
  "reference_profile": "ClimateAdaptationReportingReferenceProfile@1.0",
  "role": "ScenarioEvidenceReviewer",
  "subject": "did:nsf:person:0x91",
  "issued_by": "did:nsf:org:ClimateEvidenceGovernanceRegistry",
  "scope": {
    "jurisdiction": ["INTL-REFERENCE"],
    "permitted_actions": [
      "review-scenario-evidence",
      "attach-review-note",
      "route-to-governance-review"
    ],
    "prohibited_actions": [
      "determine-treaty-compliance",
      "enforce-treaty-obligation",
      "issue-public-authority-decision"
    ]
  },
  "valid_until": "2026-01-01T00:00:00Z"
}
```

Treaty role credentials can improve clarity in multilateral evidence workflows. They should not be allowed to create diplomatic, legal, regulatory, or enforcement authority by implication.

### Credential Bundling and Proof Aggregation

Actors may need to present multiple credentials at once. A project may present SDG contribution evidence, ESG evidence, Project Evidence, public-safe review, community steward review, climate scenario evidence, finance-readiness evidence, and insurance-readiness evidence. An individual reviewer may present domain expertise, conflict-of-interest disclosure, public-safe reviewer status, and jurisdictional authorization. An institution may present governance role, evidence issuer status, audit participation, and registry standing.

Credential bundling reduces verification overhead. Bundles may use Merkle trees, signed ClaimVCs, selective disclosure, ZK proofs, or proof aggregation methods to show that required credentials exist without exposing all underlying data. A verifier may learn that a project has sufficient evidence for a defined review workflow without seeing confidential telemetry, community-protected data, or commercially sensitive records.

A bundle should include a manifest, credential hashes, issuer references, status roots, validity windows, jurisdictional scopes, disclosure level, and non-meaning statements. It should also include whether the bundle is for internal review, public summary, controlled evidence room, public registry, finance-readiness review, insurance-readiness review, or governance participation.

Privacy-preserving proof is essential. SDG and ESG evidence can involve sensitive community, health, labor, environmental, asset, financial, or operational data. A proof of sufficiency should not become uncontrolled disclosure.

### SDG and ESG Credential Usage in Governance

SDG, ESG, and treaty-aligned credentials can be used inside governance workflows, but only under carefully declared scope. They may help determine review eligibility, evidence completeness, public-safe disclosure status, Project Evidence maturity, contributor recognition, role eligibility, governance participation, priority for evidence review, or readiness for referral to authorized actors.

For example, a clause may require a ProjectImpactEvidenceVC and PublicSafeReviewVC before a public-facing SDG contribution summary can be published. A Project Evidence workflow may require an ESGEvidenceVC before a finance-readiness evidence package is marked complete for internal review. A community governance workflow may require CommunityStewardReviewVC before a sustainability claim involving local knowledge can be disclosed. A governance body may require ConflictOfInterestDisclosureVC before a reviewer participates in ESG evidence evaluation.

Credentials can also support contribution recognition. A contributor may receive a PublicGoodContributionVC for validating a model, reviewing a clause, improving a template, participating in public-safe review, or supporting community evidence governance. Such credentials should recognize contribution without implying employment, office, public authority, certification, or guaranteed future role.

Credential-based governance should avoid “pay-to-authority” or “badge-to-power” dynamics. Authority should depend on mandate, role, credentials, expertise, jurisdiction, governance review, and conflict controls, not token holdings, donor status, or self-claimed ESG standing.

### Institutional Recognition and Cross-Jurisdictional Validity

SDG, ESG, and treaty-linked credentials require recognition metadata. A credential valid in one governance domain may not be recognized in another. A project-level SDG evidence credential may be acceptable for a Nexus public-safe summary but not for a government program. An ESGEvidenceVC may be accepted in an enterprise evidence room but not by a regulator. A TreatyAlignedEvidenceVC may support multilateral reporting review but not legal compliance.

Recognition metadata should include issuer, jurisdiction, recognized\_by records, accepted use, prohibited use, expiry, revocation registry, dispute status, privacy profile, and standard mappings. ISO 3166 jurisdiction tags may help identify geography, but they do not prove legal validity. Mappings to SDG targets, ESG reporting frameworks, World Bank or IMF-related categories, development finance evidence categories, or sustainability indices may improve legibility, but they do not imply endorsement, eligibility, investment approval, or official recognition unless formally established.

Cross-jurisdictional portability should therefore be explicit and limited. A credential should be portable as evidence, not automatically portable as authority.

### DAO-Compatible Credential Lifecycle Management

Credential lifecycle governance may be implemented through DAO-compatible systems, off-chain institutional workflows, registry governance, national nodes, regional consortium bodies, community steward review, enterprise evidence rooms, or hybrid processes. The design should remain DAO-compatible but not DAO-dependent.

Governance functions may propose, issue, renew, restrict, suspend, revoke, restore, supersede, or archive SDG, ESG, and treaty-linked credentials. They may define credential schemas, evidence requirements, simulation thresholds, public-safe review rules, jurisdictional restrictions, and dispute processes. They may link clause execution logs, SimulationRunVCs, monitoring records, CACs, public-safe summaries, and Project Evidence records to credential issuance.

Lifecycle events should be audit-linked. If a credential is revoked or disputed, dependent claims should be flagged. If a credential expires, public summaries should reflect that. If evidence is corrected, the credential may be superseded. If a credential was issued based on a model later quarantined, its reliance status may become under review.

This lifecycle discipline prevents credentials from becoming permanent unsupported claims.

### SDG and ESG Credentialing for AI Agents

AI agents can use SDG and ESG credentials in evidence workflows, but they must not create claims beyond the credential scope. An agent may summarize SDG contribution evidence, identify missing ESG evidence, draft a Project Evidence update, compare credential bundles, or prepare a public-safe summary. It must not claim official SDG certification, ESG compliance, investment eligibility, insurance readiness in the underwriting sense, treaty compliance, procurement approval, or public authority recognition unless such status exists in the record.

AI agent policies should require the agent to check credential status, issuer, scope, validity, recognition record, public-safe boundary, and non-meaning fields before generating outputs. If a credential is expired, disputed, restricted, or advisory-only, the agent should state that status. If evidence is sensitive, the agent should use selective disclosure and public-safe rules.

Credential-aware AI can reduce impact-washing by forcing claims to match evidence.

### SDG, ESG, Project SPVs, Finance-Readiness, and Insurance-Readiness

Project SPV evidence workflows are one of the most important use cases for SDG and ESG credentials. Projects often need to show environmental, social, governance, resilience, climate, community, and operational evidence to different stakeholders. Nexus can structure this evidence into verifiable credentials and bundles.

An SDGContributionEvidenceVC may link a water project to monitored service access evidence. An ESGEvidenceVC may link the project to environmental monitoring, community safeguards, and governance controls. A ProjectImpactEvidenceVC may link asset telemetry, hazard exposure, and public-safe summaries. A FinanceReadinessEvidenceVC may organize evidence for authorized financial review. An InsuranceReadinessEvidenceVC may organize exposure, monitoring, and basis-risk evidence for authorized insurance review.

These credentials should make evidence more readable, portable, and auditable. They must not imply that a project is financed, insured, approved, endorsed, certified, procurement-ready, bankable, investable, or insurable. Those determinations belong to competent authorized actors under applicable law, contracts, licenses, fiduciary duties, and professional standards.

Nexus can make evidence stronger. It should not convert evidence into regulated approval.

### Boundary Statement for SDG, ESG, and Treaty-Linked Credentialing

SDG, ESG, and treaty-linked credentialing supports verifiable contribution records, evidence alignment, impact evidence, role recognition, treaty-aligned evidence, Project SPV evidence workflows, finance-readiness evidence, insurance-readiness evidence, public-safe review, credential bundling, selective disclosure, governance participation, cross-jurisdictional evidence portability, and audit-ready institutional reporting.

It does not by itself create legal authority, public authority status, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official SDG status, ESG rating, assurance opinion, official public warning status, treaty enforcement, professional licensing, sovereign consent, community consent, institutional endorsement, UN endorsement, development finance eligibility, legal compliance determination, or guaranteed outcomes. A credential proves only that a declared issuer recorded a declared evidence claim under a declared schema, scope, validity window, and review status. Its institutional meaning depends on issuer authority, governance review, recognition records, jurisdiction, applicable law, contracts, community rules, licensed actors, and competent adoption.

An SDG credential is not official UN certification.

An ESG credential is not ESG assurance or rating by itself.

A treaty-aligned credential is not treaty compliance or enforcement.

A contribution credential is not legal entitlement.

A finance-readiness credential is not finance approval.

An insurance-readiness credential is not underwriting.

A Project Evidence credential is not procurement approval.

A credential bundle is not automatic institutional acceptance.

This boundary should appear in credential schemas, ClaimVCs, credential bundles, Credential Oracle outputs, Project Evidence records, finance-readiness evidence records, insurance-readiness evidence records, public-safe outputs, AI agent policies, dashboards, and documentation.

### Building a Global Credential Infrastructure for Risk, Equity, and Contribution Evidence

SDG, ESG, and treaty-linked credentialing gives Nexus a way to make contribution claims more disciplined. It connects goals to targets, targets to metrics, metrics to evidence, evidence to simulations, simulations to CACs, CACs to credentials, credentials to governance, and governance to audit. It makes roles clearer. It makes evidence portable. It makes claims narrower and more truthful. It allows privacy-preserving proof instead of uncontrolled disclosure. It allows institutions to recognize contribution without confusing recognition with certification. It allows Project SPV evidence to become more structured. It makes finance-readiness and insurance-readiness evidence more legible without crossing into regulated execution.

This is not merely an access layer. It is a proof layer for public-good contribution, sustainability evidence, resilience evidence, and treaty-aligned coordination.

It supports recognition without overclaiming.

It supports reporting without self-certification.

It supports governance without hidden authority.

It supports equity by making contribution and evidence visible, not just institutional status.

It supports correction by making claims revocable, disputable, and supersedable.

The purpose of SDG, ESG, and treaty-linked credentialing in the Nexus Sovereignty Framework is to ensure that global-goal alignment, sustainability claims, project impact, institutional participation, and treaty-referenced evidence can be verified, scoped, reviewed, and corrected through transparent proof infrastructure, while preserving the legal and institutional boundaries that make such claims trustworthy.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/viii.-interoperability-and-integration/policy-linked-credentialing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.